Ein Ticket, ein Screenshot, ein Fehler im Kundenportal. Du gibst die Aufgabe an einen Coding-Agenten, er findet die Ursache und bereitet eine Korrektur vor. Genau dafür willst du diese Werkzeuge haben: Ein Problem, das gestern noch liegen geblieben wäre, lässt sich heute direkt angehen.
Nur steht auf dem Screenshot auch der Name einer Kundin. Im Ticket hängt ein Protokoll mit ihrer E-Mail-Adresse. Und der Agent hat inzwischen vorgeschlagen, sich die Datenbank anzusehen.
Das ist kein Argument gegen KI-Agenten. Es ist der Moment, in dem aus einer Werkzeugfrage eine Architekturfrage wird: Welche Informationen braucht dieser Auftrag wirklich – und wohin dürfen sie gelangen?
Der Prompt ist nur die Eingangstür
Bei einem Chat denkst du zuerst an den Text, den du eingibst. Bei einem Coding-Agenten reicht dieser Blick nicht. Je nach Einrichtung kommen Projektdateien, Bilder, Terminalausgaben und Antworten angeschlossener Dienste hinzu. Was für dich nur „ein bisschen Kontext“ ist, kann für einen anderen Menschen ein Teil seiner persönlichen Geschichte sein.
Die praktische Bestandsaufnahme beginnt deshalb nicht bei der Modellversion, sondern beim Auftrag. Für unseren Fehler im Kundenportal würde ich drei Stationen durchgehen:
- Was geht hinein? Eine Fehlerbeschreibung, die betroffene Funktion und künstliche Beispieldaten. Braucht es den vollständigen Screenshot und das komplette Supportticket wirklich?
- Was wird unterwegs nachgeladen? Projektdateien, Ausgaben von Tests und gegebenenfalls ein angebundener Dienst. Ein zusätzlicher Zugriff erweitert den Auftrag nicht automatisch um die Erlaubnis, weitere Daten zu verarbeiten.
- Was bleibt zurück? Änderungen, Testberichte, Gesprächsverläufe oder gespeicherte Werkzeugausgaben. Auch das Ergebnis kann Informationen enthalten, die nicht in ein öffentliches Repository oder einen geteilten Bericht gehören.
Die Orientierungshilfe der Datenschutzkonferenz setzt ebenfalls beim konkreten Zweck und der dafür erforderlichen Verarbeitung an. Meine Übersetzung für den Entwicklungsalltag: Bereite einen kleinen, aussagekräftigen Fehlerfall vor, bevor du dem Agenten den ganzen Vorfall übergibst.
Vielleicht lässt sich der Fehler mit zwei erfundenen Konten nachstellen. Dann bekommt der Agent das Verhalten, das er verstehen muss, ohne die echte Kundin kennenzulernen. Klappt das nicht, wird der zusätzliche Datenbedarf bewusst geklärt. Aus einem echten Datensatz nur den Namen zu entfernen, ist jedenfalls noch kein belastbarer Anonymisierungsnachweis.
„Läuft in Azure“ beantwortet noch nicht die ganze Frage
In meinen Plattformprojekten nutze ich unter anderem Azure-OpenAI-Instanzen für KI-Funktionen. Gleichzeitig setze ich Coding-Agenten bei der Entwicklung ein. Das sind zwei unterschiedliche Verarbeitungsketten. Die Konfiguration einer KI-Funktion im Produkt sagt noch nichts darüber aus, wohin ein separat eingerichteter Entwicklungsagent seine Anfragen sendet.
Selbst innerhalb von Azure lohnt der genaue Blick. Microsoft unterscheidet bei den Verarbeitungsorten unter anderem zwischen Standard-, Global- und DataZone-Deployments. Bei Global kann die Verarbeitung außerhalb der gewählten Ressourcenregion stattfinden. Bestimmte Funktionen speichern außerdem Inhalte oder Gesprächszustände. „Unser Azure-Konto ist europäisch“ ist deshalb keine vollständige Beschreibung des Datenwegs.
Für die Werkzeugauswahl würde ich konkret festhalten: Welches Produkt, welcher Tarif und welche Konfiguration sind gemeint? Welche Dienste hängen zusätzlich daran? Was wird gespeichert, wofür genutzt und wann gelöscht? Die Antworten gehören zur Abstimmung mit Datenschutz und Informationssicherheit. Eine generelle Anbieterfreigabe, die diese Unterschiede verschluckt, hilft dem Team beim nächsten Plugin kaum weiter.
AI Act und DSGVO sind keine zwei Namen für dasselbe
Der EU AI Act betrachtet unter anderem Rolle, Einsatz und Risiken eines KI-Systems. Für den Teamalltag ist auch der Aufbau von KI-Kompetenz nach Artikel 4 relevant. Die EU-Kommission erläutert dazu einen kontextbezogenen Ansatz: Erfahrung der Beteiligten und tatsächliche Nutzung zählen; ein bestimmtes Zertifikat ist nicht vorgeschrieben.
Daneben bleiben Fragen aus der DSGVO: Auf welcher Grundlage werden personenbezogene Daten verarbeitet, für welchen Zweck und mit welchen Schutzmaßnahmen? Je nach Konstellation kommen etwa Auftragsverarbeitung, Drittlandtransfers oder eine Datenschutz-Folgenabschätzung hinzu. Eine Schulung beantwortet diese Einzelfragen nicht automatisch.
Ich würde daraus weder eine Paragraphenprüfung für jeden Entwickler machen noch ein Pflichtvideo, das alle neben dem Mittagessen laufen lassen. Für unser Portal-Ticket ist ein besserer Lernmoment: Jemand zeigt, welche Informationen der Agent tatsächlich erhalten würde, ersetzt unnötige Echtdaten und erklärt, warum der Datenbankzugriff zunächst aus bleibt. Danach weiß das Team etwas, das bei der nächsten Aufgabe wieder hilft.
Eine freundliche Bitte ist keine Zugriffssperre
„Verändere keine produktiven Daten“ ist eine sinnvolle Anweisung. Wenn der Agent gleichzeitig einen Zugang mit umfassenden Schreibrechten erhält, passen Text und Technik allerdings nicht zusammen. Ein Prompt ist kein Türschloss, auch nicht mit drei Ausrufezeichen.
Beim Kundenportal würde ich den ersten Durchlauf in einer getrennten Testumgebung halten. Der Agent bekommt die freigegebenen Projektdateien und Testdaten, kann eine Korrektur vorbereiten und Prüfungen ausführen. Produktive Zugangsschlüssel gehören nicht in diese Arbeitsumgebung. Veröffentlichung und zusätzliche Systemzugriffe bleiben außerhalb dieses Auftrags.
Auch „nur lesen“ ist nicht automatisch harmlos. Ein lesender Zugriff kann Daten offenlegen, ohne eine einzige Zeile in der Datenbank zu verändern. Bei einer Anbindung über MCP – einer Schnittstelle, über die Agenten weitere Werkzeuge nutzen können – interessiert mich deshalb nicht nur, ob sie funktioniert. Ich will wissen, auf welche Daten und Aktionen sie Zugriff eröffnet.
Und dann würde ich die Grenze ausprobieren: Kommt die Testumgebung tatsächlich ohne Produktivzugang aus? Sind nicht freigegebene Werkzeuge wirklich unerreichbar? Werden in einem Testbericht versehentlich vertrauliche Inhalte ausgegeben? Eine dokumentierte Absicht ist gut. Ein überprüfter Schutzmechanismus ist besser.
Der Fix ist fertig. Der Umgang damit auch?
Zurück zum Ticket: Der Agent hat eine Korrektur gebaut. Jetzt prüfen wir den gewünschten Ablauf und die relevanten Gegenfälle. Kann die Kundin wieder auf ihren Vorgang zugreifen? Bleibt der Vorgang eines anderen Kontos unsichtbar? Scheitert ein unberechtigter Aufruf kontrolliert?
Automatisierte Tests können diese Erwartungen dauerhaft festhalten. Sie erklären aber weder die Datenverarbeitung für rechtmäßig noch erkennen sie zuverlässig jede unzulässige Weitergabe. Fachliche Prüfung, Zugriffsschutz und Datenschutzbewertung lösen unterschiedliche Probleme. Ein grüner Testlauf ist wertvoll; ein universeller Freibrief ist er nicht.
Für den weiteren Betrieb reicht mir keine Chat-Sammlung mit tausend Nachrichten. Nützlich ist eine kurze, gepflegte Dokumentation: der erlaubte Einsatz, freigegebene Werkzeuge, Datenkategorien, Zugriffsgrenzen und Verantwortliche. Kommt später ein anderer Anbieter oder eine neue Anbindung hinzu, wird genau dieser Teil neu geprüft.
Ebenso wichtig ist ein verständlicher Weg für den Fall, dass doch Daten im falschen Werkzeug landen. Die betroffene Nutzung stoppen, Zugriffe bei Bedarf sperren und die zuständigen Stellen mit den nötigen Informationen einbeziehen. Nicht verschweigen, nicht in weitere Chats kopieren und auch nicht hektisch alle Spuren löschen. Wie ein Vorfall bewertet und behandelt wird, muss zum betrieblichen Ablauf passen.
Erfahrung wird dadurch nicht überflüssig. Sie wird praktisch.
Ich komme aus mehr als 15 Jahren Softwareentwicklung und Architektur, darunter Projekte im regulierten Banken- und Finanzumfeld. Vieles, was dort wichtig war, bleibt wichtig: Zuständigkeiten, Berechtigungen, nachvollziehbare Änderungen und ein Betrieb, den jemand versteht. KI-Agenten verkürzen die Umsetzung. Sie nehmen uns diese Fragen nicht ab.
Bei Entwicklerherz verbinde ich diese Erfahrung heute mit agentengestützter Entwicklung und der Arbeit an eigenen Plattformen wie Fachzirkel und SchemaCommunity. Mich begeistert, wie viel sich dadurch tatsächlich bauen und verbessern lässt. Gerade deshalb möchte ich nicht, dass ein ungeklärter Datenzugriff am Ende den gesamten Einsatz infrage stellt.
Ein guter Einstieg ist keine pauschale Erlaubnis und kein pauschales Verbot. Er ist ein klar beschriebener Anwendungsfall, den ein Team mit passenden Werkzeugen, begrenzten Daten und überprüfbaren Freigaben bearbeiten kann. Die Zusammenarbeit dahinter vertiefe ich im Artikel „KI-Agenten im Team: Was Führung leisten muss“.
Die entscheidende Freigabe lautet nicht „Wir nutzen KI“. Sie lautet: „Für diese Aufgabe, mit diesen Daten und innerhalb dieser Grenzen.“
Du möchtest daraus eine Arbeitsweise für dein Team machen? Im Entwicklerherz-Workshop „KI-Agenten sicher einsetzen: Datenschutz und EU AI Act in der Praxis“ erarbeitet ihr Datenflüsse, Zugriffs- und Freigaberegeln sowie einen ersten Pilotplan. Ein Tag, auf Deutsch, live online oder inhouse; Termin und Preis auf Anfrage. Datenschutz- und AI-Act-Workshop anfragen.
Stand: 10. September 2026. Dieser Beitrag beschreibt eine technische und organisatorische Perspektive. Er ersetzt keine rechtliche Einzelfallprüfung und ist keine Compliance-Zertifizierung.