Das 'Wer darf was sehen'-Problem: Nutzerrechte in deiner KI-gebauten App

In dem Moment, in dem deine KI-gebaute App aufhört, nur für dich zu sein, werden Berechtigungen zu einem echten Problem. Bis dahin zeigt jede Seite alles. Jede Liste zeigt jede Zeile. Jeder Button funktioniert für alle. Es ist eine Singleplayer-App, die so tut, als wäre sie Multiplayer.

Dann fügst du dein:e erste:n Teamkolleg:in hinzu, oder den ersten Kunden, oder den ersten Beta-Tester — und sie sehen etwas, das sie nicht sehen sollten. Vielleicht ist es das Gehalt eines Teamkollegen. Vielleicht ist es ein Entwurf, der noch nicht fertig war. Vielleicht sind es die Admin-Einstellungen, versehentlich offengelegt.

Das ist das “Wer darf was sehen”-Problem, und es ist das Eine, das nicht-technische Builder am häufigsten falsch machen, wenn sie ein KI-App-Builder-Projekt ausliefern. Die gute Nachricht: Du musst kein:e Security-Expert:in werden, um es zu lösen. Du brauchst nur eine klare Art, mit deinem KI-Builder darüber zu sprechen.

Warum deine KI-gebaute App freizügig startet

Wenn du einem KI-Builder eine App beschreibst — “Ich will ein CRM, in dem ich Kund:innen und Notizen anlegen kann” —, optimiert der Builder für eine Sache: dass es für die Person funktioniert, die es beschreibt. Die Standard-App lautet “jede:r, der eingeloggt ist, kann alles sehen”. Für ein persönliches Tool ist das in Ordnung. Es ist eine Katastrophe in dem Moment, in dem ein:e zweite:r Nutzer:in auftaucht.

Das ist kein Bug im KI-App-Builder. Es ist die natürliche Folge davon, dass du ihm nicht gesagt hast, wer was sehen darf. Der Builder hat keine Ahnung, dass deine Kundenliste sensibel ist oder dass “Notizen” Dinge enthalten könnten, die Kund:innen nicht sehen sollen. Du musst es sagen.

Die drei Fragen, die du dir stellen solltest, bevor du eine:n zweite:n Nutzer:in hinzufügst

Bevor du jemanden einlädst, frag dich drei Dinge. Schreib die Antworten auf — du fütterst sie im nächsten Schritt in deinen KI-Builder.

1. Welche Rollen gibt es?

Nicht die Personen — die Kategorien. Die meisten Apps haben irgendwo zwischen zwei und vier. Für ein Freelancer-Portal: “Ich” und “Kunde”. Für ein internes Tool: “Admin”, “Manager”, “Teammitglied”. Für eine Community-App: “Moderator”, “Mitglied”, “Gast”. Widersteh dem Drang, früh über vier Rollen hinauszugehen. Jede Rolle verdoppelt die Regeln, die du im Blick behalten musst.

2. Was darf jede Rolle sehen?

Geh im Kopf jede Seite deiner App durch. Frag dich für jede: Sollte ein Kunde diese Seite überhaupt sehen? Sollte er alle Daten darauf sehen oder nur seine eigenen? Sollte er die Seite sehen, aber mit einigen ausgeblendeten Feldern?

Das einfachste Muster: Inhaber:innen sehen alles; alle anderen sehen nur, wozu ihnen ausdrücklich Zugriff gegeben wurde. Das funktioniert für 80 % der Apps ohne viel Anpassung.

3. Was darf jede Rolle tun?

Dieselbe Übung, aber für Buttons und Aktionen. Darf ein Mitglied ein Projekt löschen? Darf ein Kunde sein Profil bearbeiten, aber nicht seinen Tarif? Darf ein Manager neue Leute einladen? Die meisten nicht-technischen Builder vergessen diesen Schritt komplett und landen bei Apps, in denen jede:r eingeloggte Nutzer:in mit einem einzigen Button-Klick die ganze Datenbank löschen kann.

So sprichst du mit deinem KI-Builder über Berechtigungen

Sobald du Antworten hast, schreibt sich der Prompt an deinen KI-Builder von selbst. Er sieht so aus:

Aktualisiere diese App, sodass sie zwei Rollen unterstützt: Inhaber und Kunde.

Inhaber können alle Kund:innen, alle Projekte und alle Rechnungen sehen. Inhaber können alles erstellen, bearbeiten und löschen.

Kunden können nur ihre eigenen Projekte und ihre eigenen Rechnungen sehen. Sie können die Kundenliste, die Team-Seite oder die Einstellungsseite nicht sehen. Sie können ihre Projekte ansehen, aber nicht bearbeiten. Sie können ihre eigenen Rechnungen ansehen und bezahlen.

Wenn ein Kunde eingeloggt ist, blende die Navigationslinks zu Einstellungen und Team aus. Wenn ein Kunde versucht, diese Seiten per URL aufzurufen, leite ihn zu seinem Dashboard um.

In diesem Prompt zählen drei Dinge:

Sei konkret nach Seite und Aktion. “Kunden können ihre Projekte sehen” ist vage. “Kunden können ihre eigenen Projekte auf der Seite /projects ansehen, aber nicht bearbeiten” ist etwas, das ein KI-Builder tatsächlich umsetzen kann.
Sag, was mit der Navigation passiert. Den Link auszublenden ist nicht dasselbe wie die Seite zu blockieren. Du willst beides.
Deck den URL-Tipp-Fall ab. Sonst kann ein:e neugierige:r Nutzer:in /admin in seine Adressleiste einfügen und einfach hereinspazieren.

Die vier Fehler, die ich jede Woche sehe

Nachdem ich vielen Buildern beim Ausliefern ihrer ersten Multi-User-App zugesehen habe, tauchen immer dieselben Fehler auf:

Den Button auszublenden heißt nicht, die Daten auszublenden. Wenn du deinem KI-Builder sagst, er soll “den Löschen-Button für Kunden ausblenden”, verschwindet der Button vom Bildschirm. Aber die zugrunde liegende Löschen-Operation funktioniert weiterhin, wenn jemand herausfindet, wie er sie aufruft. Die Lösung: Sag dem Builder auch, er soll “Löschanfragen von Nicht-Inhaber-Konten im Backend abweisen”. Wenn der Builder nicht weiß, was “Backend” in deiner App bedeutet, bitte ihn, “die Aktion serverseitig zu blockieren, nicht nur den Button auszublenden”.

Eine Rolle für zwei Aufgaben. Menschen werfen “die Leute, die zahlen” mit “den Leuten, die die App nutzen” zusammen. Ein Kunde, der dich für Arbeit bezahlt, und ein Kunden-Mitarbeiter, der das für diesen Kunden gebaute Dashboard nutzt, sind nicht dieselbe Rolle. Wenn du sie vermischst, verbringst du den nächsten Monat damit, Sonderregeln zu flicken. Zwei Rollen. Immer.

Nutzer:innen ab Tag eins Nutzer:innen einladen lassen. Es ist verlockend, sofort “Lade ein:e Teamkolleg:in ein” hinzuzufügen. Tu es nicht. Für deine ersten 10 Nutzer:innen lädst du sie selbst ein, von Hand, aus einem Admin-Panel, das nur du sehen kannst. Self-Service-Einladungen sind eine ganze Kategorie von Berechtigungsregeln (wer darf wen einladen? welche Rolle bekommen Eingeladene? können sie andere einladen?). Warte, bis du es wirklich brauchst.

Dem KI-Builder glauben, ohne nachzuprüfen. KI-Builder werden dir selbstbewusst sagen, dass die Berechtigungen eingerichtet sind. Vielleicht sind sie es. Vielleicht nicht. Teste immer, indem du dich als Nicht-Inhaber einloggst und versuchst, böse Dinge zu tun: auf Löschen-Buttons klicken, Admin-URLs einfügen, Felder bearbeiten, die du nicht bearbeiten können solltest. Wenn etwas funktioniert, das nicht sollte, bitte den Builder, es gezielt zu beheben.

Eine kurze Checkliste, bevor du jemanden einlädst

Bevor du diese erste Einladung an eine:n zweite:n Nutzer:in schickst, geh das hier durch:

Ich kann die Rollen in meiner App an einer Hand aufzählen.
Für jede Rolle weiß ich, welche Seiten sie sehen sollte und welche nicht.
Ich habe mich als Nicht-Inhaber eingeloggt und bestätigt, dass die falschen Seiten ausgeblendet sind.
Ich habe als Nicht-Inhaber versucht, eine Admin-URL in den Browser einzufügen, und wurde blockiert.
Ich habe versucht, auf Löschen- oder Bearbeiten-Buttons zu klicken, die tabu sein sollten, und wurde blockiert.
Falls etwas schiefgeht, habe ich eine Möglichkeit, einem Nutzer schnell den Zugriff zu entziehen.

Wenn einer dieser Punkte nicht durchgeht, ist das das nächste Gespräch mit deinem KI-Builder — bevor du die Einladung schickst, nicht danach.

Der eine Perspektivwechsel, der hilft

Berechtigungen für eine Multi-User-App zu bauen, bedeutet vor allem, dir vorzustellen, du wärst eine leicht neugierige Version deines am schlechtesten benehmenden Nutzers. Nicht böswillig — nur neugierig. Er wird auf Dinge klicken. Er wird URLs einfügen. Er wird versuchen, zu sehen, was auf der “Einstellungen”-Seite steht, die ihm auf deinem Screenshot aufgefallen ist.

Dein Job — und der Job deines KI-Builders — ist sicherzustellen, dass die Antwort, wenn er nachschaut, konsistent ist: Entweder er kann es sehen, weil es seine Daten sind, oder er kann es nicht sehen, weil es das nicht sind. Keine Ränder. Keine versehentlich offengelegten Admin-Seiten. Kein “Ich hatte vergessen, dass es diese Seite gibt”.

Die meisten Builder denken nicht über Berechtigungen nach, bis etwas Peinliches passiert. Die gute Nachricht: 20 Minuten, in denen du vor dem Ausliefern über Rollen nachdenkst, ersparen dir die 20 Stunden, es später zu beheben — plus die Mail, die du nicht an die Kundin schreiben willst, die das Falsche gesehen hat.

Baust du etwas mit einer Multi-User-Seite? Wenn du dich das nächste Mal mit deinem KI-App-Builder hinsetzt, beginne die Sitzung damit, die Rollen in deiner App laut aufzuzählen. Es ist die einfachste Fünf-Minuten-Gewohnheit, die du dir aneignen kannst, und sie fängt die meisten der schlimmsten Fehler ab, bevor sie passieren.