Schnelle KI-Prototypen, langsame Compliance-Probleme: wenn interne Apps zum DSGVO-Risiko werden

Schloss und Ordner auf neutraler Oberfläche, Daten-Governance und Zugriffskontrollen

Der Guardian-Artikel über “rogue AI agents” ist aus einem einfachen Grund nützlich: Er verdichtet in einem einzigen Beitrag einen Fehler, der bereits in ganz normalen Unternehmen auftaucht [1].

Ich rede nicht von seltsamen Labors oder Science-Fiction-Szenarien. Ich rede von Teams, die interne KI-Apps bauen und sie an CRM, E-Mail, Angebote, Verträge, Tickets, geteilte Laufwerke und operative Tools anbinden. Das Muster ist immer ähnlich. Die Idee fängt klein an, der Prototyp funktioniert, jemand fragt “kannst du das gleich noch mit dem Rest verbinden,” und plötzlich hat das Unternehmen Software, die echte Daten berührt, ohne dass jemand den langweiligen Teil erledigt hat. Dafür gibt es inzwischen einen Namen: Vibe Coding. Du beschreibst, was du willst, das Modell schreibt es, es läuft beim ersten Versuch. Das Problem: “läuft” bedeutet “macht die Sache”: es sagt nichts darüber, welche Daten es berührt, welche Zugriffsrechte es anfordert oder was passiert, wenn es sich mit etwas Realem verbindet.

Genau dieser langweilige Teil ist entscheidend. Der Artikel nennt es “rogue agents.” Der eigentliche Schmerz heißt: zu weite Berechtigungen, geteilte Accounts, schlecht durchdachte Konnektoren, schlecht verwaltete Logs und persönliche Daten im System, weil es praktisch war.

Es gibt viel KI-Diskussion, die das Problem irgendwo weit entfernt verortet, bei den Modellen, den Labs, den großen Namen. Für ein KMU liegt das Problem meistens viel näher. Es steckt in der internen App, die jemand schnell zusammengebaut hat, um 20 Minuten täglich zu sparen, und dabei ein System geschaffen hat, das Zugriff auf Kunden-, Mitarbeiter- oder Bewerberdaten hat.

Wo es anfängt, schief zu laufen

Ein Unternehmen braucht keinen “autonomen Agenten” zu bauen, um in ernsthafte Schwierigkeiten zu geraten. Ein paar bequeme Entscheidungen hintereinander reichen.

Die erste ist naheliegend. Jemand fügt persönliche Daten in ein Tool ein, weil es schneller geht als den Prozess sauber aufzusetzen. Lebensläufe, Interviewnotizen, Kunden-E-Mails, Tickets mit Namen und Kontakten, Vertriebsnotizen, Meeting-Zusammenfassungen. Nichts bricht sofort. Das Risiko kommt trotzdem rein.

Die zweite ist, der App mehr Zugriff zu geben als nötig. Ein Ordner wird zum gesamten Laufwerk. Eine Pipeline wird zum gesamten CRM. Ein Assistent, der eigentlich Text vorschlagen sollte, bekommt die Möglichkeit zu exportieren, zu schreiben oder zu senden. In den Tests von Irregular, die dem Guardian-Artikel zugrunde liegen, fanden die Agenten Wege, weil die Wege da waren, offen [2].

Die dritte ist, Instruktionen und Inhalte ohne Disziplin zu vermischen. Wenn eine App Dokumente, Wiki-Seiten, E-Mails, Tickets oder sonstigen per Suche abgerufenen Inhalt liest, wird die Grenze zwischen Daten und Instruktionen deutlich brüchiger. Das OWASP behandelt Prompt Injection bereits als eines der zentralen praktischen Risiken in LLM-basierten Systemen [5]. Das ist längst keine akademische Kuriosität mehr.

Die vierte ist, Konnektoren überall zu verteilen und so zu tun, als wäre das noch ein harmloser Prototyp. SharePoint, Google Drive, Slack, Microsoft 365, CRM, ERP, Ticketing, interne APIs, MCP-Server, Drittanbieter-Automatisierungen. Jede Verbindung öffnet eine weitere Tür. Und eine weitere Frage, die jemand vorher hätte stellen sollen: Welche Daten können hier herausfließen, wer hat das genehmigt, und wer entzieht den Zugriff, wenn das Experiment endet?

Die fünfte ist, einen geteilten technischen Account zu nutzen und weiterzumachen, als wäre Auditierbarkeit ein Detail. Wenn es einen Vorfall gibt, verschlechtert sich das Gespräch schnell. Wer hat die App ausgeführt? Welche Daten hat sie gesehen? Welchen Output hat sie erzeugt? Gab es eine menschliche Kontrolle? Wenn niemand das ohne Raten beantworten kann, arbeitet man bereits rückwärts.

Die DSGVO greift früher, als viele denken

Genau hier sehe ich, wie Unternehmen stolpern. Das Tool fühlt sich noch wie ein Prototyp an, aber der regulatorische Rahmen hat sich bereits verändert.

Sobald eine interne KI-App E-Mails, CRM, Dokumente, Tickets, Lebensläufe, HR-Notizen, identifizierbare Outputs oder Logs mit personenbezogenen Daten berührt, ist sie bereits im DSGVO-Geltungsbereich [3][7]. Die Technologie mag neu erscheinen. Die Fragen sind alt.

Welche Daten kommen rein?

Für welchen Zweck?

Wer hat Zugriff?

Wie lange werden alle Daten gespeichert?

Welcher Anbieter ist im Kreislauf?

Gibt es einen Vertrag, administrative Transparenz und ausreichende Kontrolle über Aufbewahrung und nachgelagerte Nutzung?

Die Versuchung ist, all das als technisches Detail zu behandeln. Das wird meistens teuer. Das EDPB hat in seiner KI-Stellungnahme bekräftigt, dass diese Bewertungen weiterhin fallweise erfolgen, und dass das Bezeichnen eines schlecht anonymisierten Systems als “anonym” nichts löst [3]. Wichtig zu behalten: Nützlichkeit ist keine Rechtsgrundlage.

Die CNIL benennt dasselbe Thema operativer. Viele Daten zu sammeln, weil das Tool es technisch kann, ist eine Entscheidung mit Konsequenzen. Prompts und Outputs für immer zu speichern, weil Speicher günstig ist, genauso [7]. Wenn ein Unternehmen eine interne App mit Speicher, Logs, Integrationen und echten Daten aufbaut, wird jede Bequemlichkeitsentscheidung später sichtbar sein.

Mitarbeiterdaten verdienen besondere Sorgfalt. Sobald die App Bewertungen, interne Notizen, Kennzahlen oder HR-Prozesse berührt, wird das Gespräch heikler. Ich habe zu oft gesehen, wie Unternehmen das mit “Einwilligung” lösen wollten. Das ist eine bequeme und schwache Antwort.

Und NIS2?

NIS2 kommt ins Spiel, aber nicht auf die oberflächliche Weise, die man inzwischen überall sieht.

Nicht jedes Unternehmen, das eine interne KI-App baut, fällt automatisch in den NIS2-Anwendungsbereich. Gleichzeitig werden viele Unternehmen echten Druck über Verträge, Kundenanforderungen, engere Lieferketten und Mindestkontrollen spüren, die aufhören, optional zu sein.

In der Praxis lenkt NIS2 das Gespräch auf Themen, die diese Apps ebenfalls schnell berühren: Incident-Management, Kontinuität, Supply Chain, MFA, Zugriffskontrollen, Nachweise, Reaktionsfähigkeit [8]. Für einige Organisationen ist das eine direkte Verpflichtung. Für viele andere wird es marktgetriebene Disziplin sein.

Das war der zentrale Gedanke in meinem kürzlichen Beitrag über NIS2 in Portugal. Das Thema bleibt selten im rechtlichen Bereich. Es landet in der Betriebsführung. Und dort tut es weh.

Was ich tun würde, bevor eine solche App in die Produktion geht

Ich mag schnelle Prototypen. Ich nutze sie. Sie helfen, schnell herauszufinden, ob echter Nutzen vorhanden ist. Der Fehler passiert, wenn der Prototyp Konnektoren, Speicher und Berechtigungen bekommt, und niemand innehält, um ihn ein System zu nennen.

Bevor ich so etwas mit der Produktion verbinde, würde ich 5 Dinge geklärt haben wollen.

Erstens, einen Use Case mit Grenzen. Soll die App zusammenfassen, suchen, vorschlagen, genehmigen, senden, oder was genau?

Zweitens, definierte Datenkategorien. Was darf rein und was bleibt draußen?

Drittens, eine eigene Identität. Dedizierter Service-Account, minimale Berechtigungen, Trennung von Lese- und Schreibzugriff, sauberer Widerruf.

Viertens, menschliche Kontrolle an den Punkten, wo die Kosten eines Fehlers steigen: externe Versendungen, Exporte, öffentliche Links, Berechtigungsänderungen, finanzielle Genehmigungen, sensible operative Aktionen.

Fünftens, nützliche Logs und begrenzte Aufbewahrung. Genug zum Untersuchen. Kein ewiges Archiv aus Prompts, Outputs und personenbezogenen Daten.

Nichts davon ist glamourös. Das sollte es auch nicht sein. Der größte Teil der ernsthaften internen KI-Arbeit hat heute diese Textur: operative Disziplin statt Demos.

Das langsame Problem zeigt sich nach der Demo

Das ist es, woran der Guardian-Artikel erinnert. Der Schaden beginnt selten mit einem großen Fehlschlag. Er beginnt mit einer Folge kleiner Zugeständnisse, die im Moment alle vernünftig erschienen.

“Gib ihm auch Zugriff auf diesen Ordner.”

“Bind es an die E-Mail an, dann ist es nützlicher.”

“Nimm diesen geteilten technischen Account, das regeln wir später.”

“Speicher erst mal alles, wir schauen uns das dann an.”

“Es ist ja nur intern.”

Ich habe diese Geschichte zu oft in verschiedenen Formen gesehen, um sie als Detail zu behandeln. Wenn die App lebende Systeme und echte Daten berührt, ist sie kein Wochenendprojekt mehr.

Wenn Ihr Unternehmen bereits interne Assistenten, Copilots oder KI-Automatisierungen testet, die an CRM, E-Mail, Dokumente oder andere operative Tools angebunden sind, lohnt es sich, zuerst eine kurze Governance- und Implementierungsprüfung durchzuführen. Welche Daten kommen rein, welche Zugriffe existieren, welche Tools Sinn ergeben, was in der Sandbox bleibt und welche Kontrollen vor dem Rollout vorhanden sein müssen.