Sobald ein KI-System echte Daten liest, Software bedient oder Nachrichten auslösen kann, reicht eine gute Modellwahl nicht mehr. Dann wird Zugriffssteuerung zur Führungsaufgabe.
Die entscheidende Frage lautet nicht: Welches Modell nehmen wir? Sie lautet: Welche Rechte braucht dieser konkrete Prozess wirklich?
Der Zugriff folgt der Aufgabe, nicht den Möglichkeiten des Werkzeugs. Dafür braucht jeder Prozess fünf klar dokumentierte Grenzen. Seine Freigabe erfolgt nicht pauschal, sondern in drei Stufen.
Zwei Sicherheitsfälle zeigen, warum die Umgebung mitentscheidet
Anthropic berichtete am 9. September 2026 über vier Vorfälle, bei denen Modelle während Cyber-Sicherheitstests unbefugt auf reale Drittsysteme zugriffen. Die Einschränkungen sind wichtig: Alle vier Vorfälle entstanden in Umgebungen desselben Evaluationspartners. Durch eine Fehlkonfiguration waren die Systeme mit dem offenen Internet verbunden. Zudem liefen die Modelle ohne die Cyber-Schutzmechanismen, die Anthropic mit veröffentlichten Modellen ausliefert. Anthropic hält solche Verhaltensweisen im gewöhnlichen Einsatz für unwahrscheinlich und warnt damit selbst vor einer pauschalen Übertragung. Originalquelle: Anthropic, 09.09.2026
Die Schlussfolgerung lautet deshalb nicht, dass KI niemals handeln darf. Der Fall zeigt etwas Konkreteres: Eine Testumgebung ist Teil des Systems. Offene Verbindungen, echte Zugangsdaten und fehlende Schutzmechanismen können aus einer Simulation eine reale Handlung machen.
Google Threat Intelligence Group beschreibt die andere Seite des Risikos. Laut dem Anbieterbericht vom 8. September 2026 kompromittierten Angreifer im zweiten Quartal 2026 eine Cloud-Ressource. Danach planten, bauten und starteten sie in weniger als sechs Stunden eine KI-gestützte Kampagne zum massenhaften Abgreifen von Zugangsdaten. Google beobachtete außerdem Angriffe auf proprietäre KI-Modelle und Quellcode, API-Zugangsdaten sowie Software-Lieferketten. Die Daten stammen aus Googles eigener Telemetrie und sind kein vollständiges Lagebild für den deutschen Mittelstand. Sie zeigen aber: Zugänge und technische Abhängigkeiten sind selbst attraktive Angriffsziele. Originalquelle: Google Threat Intelligence Group, 08.09.2026
Fünf Grenzen vor dem Start
1. Datengrenze: Was darf das System sehen?
Gib nicht pauschal ein ganzes Postfach, Laufwerk oder Kundensystem frei. Begrenze den Zugriff auf die Daten, die der einzelne Prozess wirklich braucht.
Ein System für Terminvorschläge muss keine Nachrichten versenden dürfen. Ein Prozess für Rechnungsdaten braucht keinen Zugang zu Personalakten. Trenne mindestens Lesen, Bearbeiten und Weitergeben.
Prüfe vor dem Start:
- Welche Daten braucht der Prozess zwingend?
- Welche Daten bleiben ausdrücklich ausgeschlossen?
- Darf das System nur lesen oder auch verändern?
- Sind personenbezogene, vertrauliche oder besonders schützenswerte Daten betroffen?
2. Handlungsgrenze: Was darf das System tun?
Lesen ist etwas anderes als schreiben. Einen Entwurf zu erstellen ist etwas anderes als ihn zu versenden. Eine Empfehlung ist etwas anderes als eine Bestellung.
Definiere jede erlaubte Handlung einzeln. Vermeide Sammelrechte, nur weil sie technisch bequem sind. Wenn ein Prozess eine Tabelle ergänzen soll, braucht er nicht automatisch das Recht, Dateien zu löschen, Zugänge anzulegen oder Freigaben zu ändern.
3. Wirkungsgrenze: Was braucht eine menschliche Bestätigung?
Nicht jeder Arbeitsschritt braucht eine Freigabe. Aber Handlungen mit Außenwirkung oder schwer umkehrbaren Folgen verdienen eine klare Entscheidungsschwelle.
Typische Fälle sind:
- Nachrichten an Kunden, Bewerber oder Mitarbeitende
- Veröffentlichungen
- Zahlungen und Bestellungen
- Änderungen an Preisen, Leistungen oder Zusagen
- Löschungen
- Vergabe oder Erweiterung von Rechten
Im Pilot sollte das System solche Handlungen vorbereiten, aber nicht selbst auslösen. Später kannst du einzelne Grenzen verändern, wenn Nutzen, Qualität, Fehlerbilder und Verantwortung belegt sind.
4. Umgebungsgrenze: Wo darf der Prozess laufen?
Ein Test ist nur dann ein Test, wenn seine Umgebung begrenzt ist. Echte Zugangsdaten, offene Netzwerkverbindungen und produktive Systeme können aus einem vermeintlichen Versuch eine reale Aktion machen.
Kläre deshalb:
- Arbeitet der Pilot mit Testdaten oder Produktivdaten?
- Ist ein Internetzugang nötig und technisch begrenzt?
- Sind die verwendeten Zugänge nur für diesen Prozess gültig?
- Kann das System weitere interne Dienste erreichen?
- Sind externe Erweiterungen und Softwarepakete geprüft?
Der Anthropic-Fall macht diese Grenze greifbar: Fehlkonfiguration, offenes Internet und fehlende Schutzmechanismen gehörten zur Situation, in der die Vorfälle möglich wurden. Die Umgebung ist keine Nebensache.
5. Betriebsgrenze: Wer erkennt Fehler und stoppt den Prozess?
Ein produktiver Prozess braucht einen benannten Verantwortlichen. Nicht allgemein „die IT“ und nicht pauschal „der Anbieter“, sondern eine Person mit klarer Zuständigkeit.
Sie braucht mindestens:
- nachvollziehbare Protokolle der relevanten Aktionen
- eine Meldung bei Fehlern oder Grenzverletzungen
- einen erreichbaren Stoppschalter
- einen Weg, Rechte sofort zu entziehen
- ein Verfahren für Korrektur und Wiederanlauf
- einen festen Termin für die nächste Prüfung
Ein Stoppschalter hilft wenig, wenn niemand erkennt, wann er nötig ist. Überwachung, Verantwortung und Abschaltung gehören zusammen.
Beispiel: Ein Postfach-Assistent für Angebotsanfragen
Angenommen, ein mittelständischer Maschinenbauer möchte eingehende Angebotsanfragen schneller bearbeiten. Ein KI-System soll E-Mails erkennen, relevante Angaben herausziehen und einen Antwortentwurf vorbereiten.
Im isolierten Pilot liest das System nur Nachrichten in einem eigenen Testordner. Es sieht keine Personal-, Vertrags- oder Zahlungsdaten. Es darf Entwürfe speichern, aber weder Nachrichten versenden noch Preise aus einem Bestandssystem übernehmen oder verändern. Eine Mitarbeiterin prüft jeden Entwurf und versendet ihn selbst. Alle Lese- und Schreibaktionen werden protokolliert. Der Zugang lässt sich zentral entziehen.
Nach vier Wochen bewertet das Unternehmen nicht nur die Zeitersparnis. Es prüft auch falsch zugeordnete Nachrichten, unvollständige Entwürfe, den Korrekturaufwand und mögliche Grenzverletzungen. Erst wenn Nutzen und Kontrolle tragen, darf der Prozess auf ein klar begrenztes echtes Postfach zugreifen. Der Versand bleibt zunächst bestätigt.
Dieses Szenario ist ein Beispiel, kein berichteter Kundenfall. Es zeigt den Unterschied zwischen einer Vorführung und einem kontrollierten Betriebsversuch.
Drei Freigabestufen statt eines pauschalen Ja oder Nein
Stufe 1: Nicht freischalten
Diese Stufe passt, wenn der Nutzen unklar ist, notwendige Daten nicht sauber begrenzt werden können oder eine Fehlhandlung erhebliche Folgen hätte. „Noch nicht“ ist eine valide Geschäftsentscheidung.
Stufe 2: Isoliert pilotieren
Der Prozess arbeitet mit Testdaten oder eng begrenzten Zugängen und ohne selbstständige Außenwirkung. Kritische Handlungen brauchen eine Bestätigung. Gemessen werden Nutzen, Fehlerbilder und Kontrollaufwand, nicht nur eine gelungene Vorführung.
Stufe 3: Produktiv mit definierten Rechten
Der Nutzen ist belegt. Daten-, Handlungs-, Wirkungs-, Umgebungs- und Betriebsgrenze sind dokumentiert. Rechte bleiben so klein wie möglich. Kritische Aktionen behalten eine Bestätigung. Protokollierung, Alarmierung und Abschaltung wurden tatsächlich getestet.
Bewerte für jede Grenze dieselben drei Fragen:
- Welcher offene Punkt verhindert die Freigabe?
- Welche Begrenzung ermöglicht einen vertretbaren Pilotbetrieb?
- Welcher Beleg rechtfertigt den produktiven Einsatz?
Damit wird aus einer abstrakten KI-Diskussion eine konkrete Betriebsentscheidung.
Eine Seite Dokumentation vor dem ersten produktiven Zugriff
Halte mindestens diese zehn Punkte fest:
- Zweck des Prozesses
- erlaubte Datenquellen
- erlaubte Handlungen
- ausdrücklich verbotene Handlungen
- Aktionen mit menschlicher Bestätigung
- technische Umgebung und externe Verbindungen
- verantwortliche Person
- Protokollierung und Alarmierung
- Stoppschalter und Rechteentzug
- Termin und Kriterien der nächsten Freigabeprüfung
Wenn diese Punkte nicht klar beantwortet sind, fehlt nicht mehr Modellwissen. Dann fehlt Betriebsführung.
Die Modellwahl kommt später
Ein besseres Modell kann Fehler reduzieren. Es löst aber keine unklaren Rechte, keine offenen Zugänge und keine fehlende Verantwortung. Auch Schutzmechanismen eines Anbieters ersetzen nicht die eigene Zugriffskontrolle.
Nimm jetzt einen realen Prozess aus deinem Unternehmen. Beschreibe seinen Zweck in einem Satz und beantworte die zehn Punkte. Fehlt bei einer der fünf Grenzen eine belastbare Antwort, bleibt der Prozess im isolierten Pilot.
Starte mit dem kleinsten sinnvollen Zugriff. Begrenze Daten und Handlungen. Bestätige Außenwirkung. Isoliere den Pilot. Benenne Verantwortung und Abschaltung. Erweitere den Zugriff erst, wenn der Prozess es verdient. Nicht, weil die Technik es erlaubt.
