Braucht ein technischer Benutzer oder ein KI-gestützter Prozess eigene Zugriffsgrenzen? Aus Datenschutz- und Informationssicherheitssicht lautet die kurze Antwort: ja, stets. Dieser Beitrag zeigt, warum Need-to-know bei KI und Robo-Konten unverändert gilt, wie sich der Grundsatz praktisch umsetzen lässt und welche Fragen vor einer Freigabe geklärt sein sollten.
Gilt Need-to-know auch für KI und Robo-Konten?
Need-to-know ist kein Begriff der DSGVO. Es handelt sich um eine Konkretisierung von Art. 5 Abs. 1 lit. f (Integrität und Vertraulichkeit), Art. 25 (Datenminimierung durch Technikgestaltung) sowie Art. 32 Abs. 1 lit. b und Abs. 4 DSGVO. Sicherheitsseitig findet sich der Grundsatz in ISO 27001 (A.5.15 und A.5.18), aufsichtsrechtlich in den VAIT und in Art. 9 DORA.
Entscheidend ist ein oft übersehener Punkt: Diese Normen knüpfen an die Verarbeitung an, nicht an die handelnde Identität. Ob ein Zugriff durch einen Menschen, ein Skript oder einen Agenten erfolgt, ist rechtlich irrelevant. Verantwortlicher bleibt in jedem Fall das Unternehmen. Ein Robo-Konto hat auch keinen eigenen Bedarf, denn der Bedarf ist immer der des Prozesses, der das Konto steuert.
Für technische Benutzer lässt sich Need-to-know deshalb präziser formulieren: Der Berechtigungsumfang der technischen Identität darf nicht über den Umfang der ihr zugewiesenen, spezifizierten Prozessschritte hinausgehen. Damit gilt das Prinzip für Robo- und KI-Nutzer vollständig und unverändert. Die Betrachtung von KI und Datenschutz führt hier zu einem erstaunlich gleichlaufenden Ergebnis.
Warum ist Need-to-know beim Robo präziser umsetzbar?
Ein menschlicher Sachbearbeiter braucht Handlungsspielraum. Er nimmt z. B. Kundenanrufe an, bearbeitet Sonderfälle, vertritt Kollegen und muss Zusammenhänge erkennen, die niemand vorab spezifiziert hat. Fachrollen sind deshalb zwangsläufig großzügiger geschnitten, als es der einzelne Vorgang erfordert. Das kann sachlich gerechtfertigt und angemessen sein.
Der digitale Mitarbeiter hat dagegen keinen Ermessensspielraum. Sein Aktionsvorrat ist vollständig vorab spezifiziert und deterministisch, gute Prozessbeschreibungen listen ihn auf Klick-Ebene auf. Damit ist die theoretisch minimale Rechtemenge exakt benennbar, was bei einem Menschen nie der Fall ist. Die übliche Rechtfertigung für breite Rollen entfällt also gerade beim Robo. Gleichzeitig übernimmt dieser Funktionen mehrerer Mitarbeitender, wobei die jeweiligen Aufgaben streng definiert sind und der Zugriff auf Datenelemente nur entsprechend der Aufgabenzuweisung erfolgt.
Aus präzisen Prozessbeschreibungen lässt sich eine Soll-Berechtigungsmatrix ableiten und gegen den Ist-Umfang der Rolle stellen. Typische Einträge einer solchen Matrix sind:
- Aufgabe öffnen und zuweisen
- Vertragsbeendigung sowie Storno mit dokumentiertem Grund
- Dokumentenerstellung und Wiedervorlage
Setzt ein technischer Benutzer auf einer bereits etablierten und freigegebenen Fachrolle auf, ohne weitergehende Rechte als ein menschlicher Sachbearbeiter im selben Prozess, entsteht keine neue Zugriffskategorie, sondern ein zusätzlicher Nutzer einer bekannten Rolle. Datenschutzrechtlich ist das ein deutlich anderer Sachverhalt als eine Rechteerweiterung.
Welche Need-to-know-Ebenen entstehen beim KI-Einsatz?
Ein Sprachmodell hat in der Regel kein Konto und keine Rolle im Fachsystem. Es greift auf nichts zu, sondern bekommt geliefert. Sein Need-to-know manifestiert sich nicht in Berechtigungen, sondern im Payload, also in dem, was in den Prompt gepackt wird. Bei KI-Nutzern ist Need-to-know praktisch identisch mit Kontextminimierung pro Anfrage: nur die benötigten Seiten, nur die benötigten Felder, keine Bestandsdaten im Prompt, wenn der Abgleich lokal möglich ist.
In einem typischen Projekt sind damit drei Ebenen zu unterscheiden:
| Ebene | Ausprägung | Typischer Status |
|---|---|---|
| Technischer Benutzer (RPA) | klassisches Least Privilege auf Rollen und Transaktionen | häufig vertretbar gelöst, Prüfung auslösen |
| KI-Anfrage (LLM) | Kontext- und Payload-Minimierung pro Aufruf | konzeptionell vorgesehen, Prompt-Review erledigen |
| Ergebnisverbreitung | wer sieht die erzeugten Ausgaben | oft nicht betrachtet, Annahme: keine Änderung |
Wichtig ist die Abgrenzung nach unten: Need-to-know bedeutet nicht, dass der Robo weniger sehen darf als ein Mensch. Wenn der Prozess die Auswertung einer vollständigen Akte erfordert, ist das der legitime Bedarf. Der Grundsatz begrenzt den Umfang auf den Zweck, nicht auf ein Unbehagen. Relevant und in Projektunterlagen selten adressiert ist dagegen ein anderer Punkt: Der Robo erzeugt möglicherweise neue, verdichtete Informationsobjekte, und diese Verdichtung ist ein Thema für sich.
Rechtevergabe bleibt eine Frage der Governance
Die Rechtevergabe für Robo-Konten ist weniger eine Einzelfallfrage als ein Governancethema. Technische Identitäten sollten in die reguläre Berechtigungsmatrix aufgenommen und dort regelmäßig bewertet werden, mit benanntem Verantwortlichen, Rezertifizierung und dokumentierter Begründung. Vor der Freigabe empfiehlt sich die Klärung von drei Punkten:
- Ist die Rolle identisch mit der Rolle der Sachbearbeitung in den betroffenen Fachbereichen, ohne Zusatzrechte für den technischen Benutzer?
- Enthält die Rolle keine administrativen oder privilegierten Funktionen, insbesondere keine Benutzer- und Rechteverwaltung, keine Konfigurationsänderungen und keinen Zugriff auf Protokolle?
- Enthält die Rolle keine Massenoperationen, also keine Massenexporte, Massenlöschungen oder Sammelverarbeitungen von Bestandsdaten?
Sobald ein Robo künftig agentisch arbeitet und selbst entscheidet, welches Werkzeug es aufruft, kommt eine vierte Ebene hinzu: das Tool- und Aktions-Scoping. Dann genügt es nicht mehr, Rollen und Prompts zu prüfen, sondern der Werkzeugvorrat selbst wird zum Gegenstand der Berechtigungsbetrachtung. Wer heute eine saubere Soll-Berechtigungsmatrix und ein dokumentiertes Prompt-Design aufbaut, schafft dafür eine belastbare Grundlage.
Zusammengefasst: Need-to-know gilt für technische und KI-gestützte Nutzer vollständig, weil es an die Verarbeitung anknüpft und nicht an die Identität. Es ist bei ihnen sogar präziser umsetzbar als bei Menschen, weil der Aktionsvorrat vorab bekannt ist. Wenn die Fachbereiche die Berechtigungen als notwendig dokumentieren und diese Dokumentation Teil des regulären Berechtigungsmanagements wird, bleibt das Need-to-know-Prinzip auch datenschutzrechtlich gewahrt.
