Sind meine Daten in einem KI-Builder sicher?
Sind meine Daten in einem KI-Builder sicher?
Der wichtige Teil der Antwort ist baulich und nicht beruhigend. Bei Zugo liegen die Daten Ihrer Anwendung gar nicht im Builder. Sie liegen in Ihrem eigenen Supabase-Projekt und in Ihrem eigenen Stripe-Konto, auf Ihren Namen und Ihren Tarif. Nicht automatisch sind die Zugriffsregeln, und deren Prüfung ist Ihre Aufgabe.
Die meisten Texte zu dieser Frage beantworten eine andere, nämlich ob die Firma hinter dem Werkzeug vertrauenswürdig ist. Die Frage ist berechtigt, von außen aber nicht beantwortbar. Wo die Daten physisch liegen und wer sie erreichen kann, ist dagegen prüfbar.
Um welche Daten geht es eigentlich?
Um drei getrennte Arten, und weil sie ständig vermischt werden, wirkt die Frage unübersichtlich.
Da ist das Material, das Sie in den Builder tippen: Prompts, Projektbeschreibungen, die Historie der Builds. Da sind die Daten Ihrer Anwendung: die Datensätze, die sie speichert, die Konten, die Ihre Nutzer anlegen, die Dateien, die sie hochladen. Und da sind die Zahlungsdaten Ihrer Kunden, eine Kategorie mit eigenen Regeln und eigener Aufsicht.
Jede liegt woanders und geht auf andere Weise schief. Die Sorge um vertrauliche Prompts ist nicht dieselbe Sorge wie ein Kunde, der die Bestellungen eines anderen Kunden liest. Die zweite tritt in der Praxis erheblich häufiger ein.
Wo liegt welche Art von Daten?
In Konten, die Sie ohnehin selbst führen, jedenfalls überall dort, wo es zählt.
| Daten | Wo sie liegen | Wessen Konto |
|---|---|---|
| Datensätze Ihrer Anwendung | Supabase | Ihres |
| Nutzerkonten und Anmeldung | Supabase | Ihres |
| Hochgeladene Dateien | Supabase Storage | Ihres |
| Zahlungen, Karten, Abonnements | Stripe | Ihres |
| Versand von E-Mails | Resend | Ihres |
| Quelltext nach dem Export | GitHub | Ihres |
| Messung der Besuche | Google Analytics | Ihres |
| Prompts und Build-Historie | Zugo-Arbeitsbereich | Ihr Zugo-Konto |
| Die veröffentlichte Seite | <slug>.zugo.run oder Ihre Domain |
von Zugo ausgeliefert, Ihnen gehörend |
Lesen Sie die Spalte mit den Besitzverhältnissen genau, denn darin steckt die eigentliche Antwort. Hält ein Baukasten Ihre Datenbank, kostet ein Wechsel Sie die Daten. Lag die Datenbank von Anfang an in Ihrem eigenen Supabase-Projekt, war der Builder ein Werkzeug, das Code dagegen geschrieben hat, und dieser Code lässt sich jederzeit nach GitHub exportieren.
Die Zeile, die am häufigsten überrascht, sind die Zahlungsdaten. Kartennummern berühren Ihre Anwendung nie, weil Stripe sie hält. Genau so hätte es eine erfahrene Entwicklerin ohnehin gebaut.
Was tut eine generierte Anwendung für die Sicherheit, und was nicht?
Sie erzeugt den Code, einschließlich der Teile, die Daten nach der angemeldeten Person filtern, sofern Sie das verlangt haben. Was sie nicht tut, ist Ihr Berechtigungsmodell entscheiden, und sie kann nicht wissen, dass Sie etwas anderes gemeint haben, als Sie geschrieben haben.
Jeder Build wird vor der Übergabe in einer Sandbox gestartet, und was nicht öffnet, wird als Fehlschlag gemeldet statt ausgeliefert. Das ist eine Darstellungsprüfung. Sie senkt das Risiko, eine weiße Seite zu bekommen, und sagt nicht das Geringste darüber, wer was lesen darf.
Diese Unterscheidung gehört deutlich ausgesprochen, weil „geprüft" wie „sicher" klingt und es nicht ist. Eine Anmeldemaske, die jeden durchlässt, lädt einwandfrei und besteht die Prüfung. Sicherheit ist eine Eigenschaft der Regeln, und Regeln prüft man, indem man versucht, sie zu brechen.
Wie teste ich, ob die Regeln wirklich halten?
Mit einem zweiten Konto, von Hand, bevor jemand anderes die Anwendung anfasst. Das dauert eine Viertelstunde und ist nach einem Build mit Nutzerkonten das Wertvollste, was Sie tun können.
| Test | Wie er läuft | Wie ein Fehlschlag aussieht |
|---|---|---|
| Fremder Datensatz | Als Nutzer A einen Eintrag anlegen, als Nutzer B seine Adresse direkt öffnen | B sieht den Eintrag von A |
| Ohne Anmeldung | Abmelden, dann eine geschützte Seite aufrufen | Die Seite erscheint, statt umzuleiten |
| Doppelte Registrierung | Zweimal mit derselben E-Mail anmelden | Ein zweites Konto entsteht |
| Passwort zurücksetzen | Zurücksetzen anfordern und auf die Mail warten | Es kommt nichts an, weil Resend fehlt |
| Grenze zur Verwaltung | Als gewöhnlicher Nutzer eine Verwaltungsadresse aufrufen | Die Verwaltungsansicht öffnet sich |
Die erste Zeile wiegt am schwersten. Erreicht Nutzer B den Datensatz von Nutzer A, indem er die Adresse eintippt, wurde die Regel in der Oberfläche angewendet statt in der Datenbank erzwungen. Genau das ist die Formulierung für Ihre nächste Änderung.
Die Korrektur kostet eine Änderung zu 3 Credits, was für dieses Problem ein lächerlicher Preis ist. Der größere Zusammenhang steht in Kann KI eine Anmeldung bauen, die Einrichtung der Datenbank in Supabase anbinden.
Was gehört niemals in einen Prompt?
Echte Zugangsdaten. API-Schlüssel, Passwörter, Tokens und Datenbank-Zugänge gehören in die Einrichtung der Anbindung, die dafür gemacht ist, und nicht in eine Beschreibung dessen, was Sie gebaut haben wollen.
Dieselbe Zurückhaltung gilt für echte Kundendatensätze. Wenn der Build eine Bestellübersicht zeigen soll, beschreiben Sie die Form einer Bestellung und lassen Sie Beispielzeilen erfinden. Echte Namen, echte Adressen und echte Kartendaten machen die Ausgabe nicht besser und vergrößern nur den Kreis der Orte, an denen diese Daten schon einmal waren.
Das ist gewöhnliche Hygiene und keine Zugo-Besonderheit. Denselben Rat bekommen Sie für jedes Chatfenster, jedes Support-Ticket und jeden Screenshot, den jemand in eine Gruppe wirft.
Welche Pflichten bleiben bei Ihnen und nicht beim Werkzeug?
Die, die nie Software waren. Sie gehen nicht auf einen Builder über.
Eine Datenschutzerklärung, die der Wirklichkeit entspricht. Wenn Ihre Anwendung E-Mail-Adressen sammelt, schreiben Sie hin, dass sie es tut, wozu, und wie jemand die Löschung erreicht. Die Seite zu erzeugen erzeugt nicht den Text.
Auskunft und Löschung. Je nachdem, wo Ihre Nutzer wohnen, haben sie ein Recht auf ihre Daten oder auf deren Entfernung. Weil die Daten in Ihrem Supabase-Projekt liegen, können Sie das erfüllen. Weil es Ihr Projekt ist, wird es sonst niemand tun.
Wer Zugang hat. Zugangsdaten für Anbindungen sind Schlüssel zu echten Systemen. Behandeln Sie einen Supabase-Service-Key wie den Schlüssel zum Büro.
Eine Prüfung, bevor Geld oder Personendaten fließen. Generierte Zugriffsregeln verdienen den Blick von jemandem, der feindselig denkt. Zugo ersetzt bei einem anspruchsvollen Produkt kein Entwicklungsteam, und an der Zugriffskontrolle merkt man das zuerst.
Was sind die ehrlichen Grenzen dieser Antwort?
Drei, und es sind genau die, die eine Werbeseite weglassen würde.
Kein Builder kann Ihnen zusichern, dass Ihre Anwendung sicher ist. Er kann vernünftigen Code erzeugen, ihn starten und einen Fehlschlag als Fehlschlag melden. Ob die Regeln, die Sie beschrieben haben, die Regeln sind, die Sie gebraucht hätten, beurteilt keine automatische Prüfung.
Sehr spezifische Zugriffsregeln brauchen mehrere Durchgänge. Organisationen mit Teams, verschachtelten Rollen und Freigaben pro Datensatz entstehen über eine Folge von Änderungen. Das ist der vorgesehene Weg, und er bedeutet, dass Ihr Sicherheitsmodell erst nach den Durchgängen existiert, die Sie tatsächlich gemacht haben.
Fremde Dienste haben eigene Bedingungen. Supabase, Stripe, Resend und Google gehen jeweils eigene Wege im Umgang mit Daten. Verbindlich ist deren Dokumentation und nicht ein Blogtext von jemand anderem.
Praktisch heißt das: Daten in eigenen Konten halten, den Quelltext exportieren, damit ein Mensch ihn lesen kann, und den Test mit zwei Konten machen, bevor Sie jemanden einladen. Wie der Export läuft, steht in Kann ich den Quelltext exportieren. Wenn Sie die Reihenfolge ausprobieren wollen, beschreiben Sie Ihre Berechtigungsregeln in einem Absatz auf zugo.dev und prüfen Sie sie, bevor Sie starten.