Ein Versicherer, der einem KI-Agenten die Polizzenverwaltung überlässt, muss vorher wissen, welche Datensätze dieser Agent lesen und welche er verändern darf, weil derselbe Zugriff bei einer Sachbearbeiterin durch eine Berechtigungsprüfung laufen würde. Die Sachbearbeiterin darf dabei die Daten vieler Kunden bearbeiten, ein Agent braucht weniger: genau diesen Kunden, genau diese Daten, genau für diese Aufgabe.

Diese Frage bleibt in den meisten KI-Projekten offen, und darum kommen sie über den Proof of Concept nicht hinaus.

KI Enablement bezeichnet alles, was ein Unternehmen herstellen muss, damit KI-Systeme im laufenden Betrieb arbeiten dürfen. In regulierten Häusern sind das drei Dinge: verlässliche Daten, kontrollierte Zugriffe und eine Infrastruktur, die den eigenen Vorgaben entspricht.

Was KI Enablement bedeutet

Zwei Bedeutungen laufen unter demselben Begriff. Die eine betrifft die Befähigung der Mitarbeitenden, also Schulungen, rollenspezifische Formate und die Frage, wie aus einmaligem Wissen tägliche Routine wird. Die andere betrifft die technische Grundlage, auf der KI-Systeme überhaupt laufen dürfen.

Beide Seiten gehören zusammen. In Banken und Versicherungen entscheidet allerdings die Reihenfolge darüber, ob am Ende etwas benutzt wird.

Warum Befähigung erst nach der Freigabe wirkt

Ein Team, das im Umgang mit einem Assistenten geschult ist, aber keinen Zugriff auf produktive Vertragsdaten bekommt, arbeitet weiter wie vorher. Die Sperre sitzt in der Freigabe.

Diese Freigabe hängt an drei Fragen, die kein Trainingsformat beantwortet: Woher kommen die Daten, wer darf was, und wo läuft das Modell. Solange diese drei Punkte offen sind, bleibt das geschulte Wissen im Testsystem.

Schulungen sind wichtig, sie wirken nur später, weil dann etwas da ist, das im Alltag verwendet werden darf. Darum steht hier die technische Seite vorne.

Warum KI-Agenten ohne Unternehmensdaten falsche Antworten liefern

Ein Sprachmodell kennt allgemeines Weltwissen, aber nicht Ihre Kundenstammdaten, Ihre Tarifhistorie und Ihre internen Prozessregeln. Sobald ein Agent eine Aussage zu einem konkreten Fall treffen soll, füllt er die Lücke mit einer plausiblen Erfindung.

Die Ursache liegt fast nie im Modell, sondern in der Datenlage. Kundendaten liegen im CRM, Vertragsdaten im Bestandssystem, Korrespondenz im Ticketsystem und Handbücher auf einem Fileshare, und derselbe Kunde ist in drei dieser Systeme unterschiedlich geschrieben.

Data Grounding heißt, diese Silos in einer gemeinsamen Datenplattform zu integrieren, etwa in Microsoft Fabric, und die Datensätze so aufzubereiten, dass ein Agent sie ohne Zwischenschritt konsumieren kann. Das bedeutet, dass unstrukturierte Dokumente ebenso aufbereitet werden wie Tabellen aus dem Bestandssystem.

Der organisatorische Teil wird oft unterschätzt. In einer Data-Mesh-Architektur pflegen die Fachbereiche ihre Datenpakete selbst, weil nur die Fachabteilung weiß, welcher Datensatz gültig ist und welcher eine Altlast aus einer früheren Migration ist.

Wie das im Kleinen aussieht, zeigt ein Beispiel aus dem eigenen Haus. Projektdatenbank und Zeiterfassung sind zusammengeführt worden, und daraus läuft ein Dashboard, das pro Projekt den verbrauchten Budgetanteil zeigt, ohne dass jemand Zahlen aus zwei Systemen zusammenkopiert. Der Fall ist klein, das Muster ist dasselbe wie bei einem Bestandssystem und einem CRM.

Wie KI-Agenten nur die Berechtigungen bekommen, die sie brauchen

Ein Agent, der Daten nur liest und dessen Ausgabe ein Mensch prüft, bevor sie zum Kunden geht, ist ein überschaubares Risiko. Sobald er in Systeme schreibt, Tickets schließt, ohne Prüfung antwortet oder Zahlungen anstößt, braucht er eine eigene Identität und ein Berechtigungsmodell, das mindestens so streng ist wie das für Menschen. Bei einem Team aus Agenten, die eigenständig handeln, kommt pro Agent eine eigene Beschränkung dazu, weil sonst der schwächste Zuschnitt für alle gilt.

Identity Delegation ist dabei die Obergrenze, nicht das Ziel. Der Agent erbt die Rechte der Person, die ihn ausgelöst hat, und darf innerhalb dieser Grenze weiter eingeschränkt werden, weil eine Aufgabe fast immer weniger verlangt als ein Arbeitsplatz.

Genau dieser Fall war bei uns der Auslöser. Ein Agent lief lokal auf dem Rechner eines Entwicklers und benutzte dessen angemeldete Werkzeuge, also die Azure-Kommandozeile und kubectl. Damit hätte er in jede Umgebung schreiben können, an der dieser Entwickler arbeitet, und getrennt hat die Umgebungen nur die Formulierung der Aufgabe.

Ein Vorfall ist daraus nie entstanden, weil jeder Schritt einzeln bestätigt wurde. Diese Bestätigung frisst allerdings genau den Zeitvorteil auf, wegen dem man einen Agenten überhaupt einsetzt.

Die fertigen Bausteine der Plattform-Anbieter haben diese Grenze nicht abgebildet. Sie regeln, welche Art von Aktion erlaubt ist, aber nicht, in welcher Umgebung, und teils standen sie noch im Vorschau-Status. Darum haben wir es selbst gebaut.

Heute hat jede Umgebung einen eigenen Zugang, dessen Rechte fest auf diese eine Umgebung begrenzt sind. Der Agent kommt nirgendwo anders hin, weil der Schlüssel nirgendwo anders passt. Die Rechte des Entwicklers sind dabei unangetastet geblieben.

Der Aufwand dafür ist real. Jede Umgebung hält ihre eigenen laufenden Zugänge, was eine Grundlast erzeugt, an der wir noch arbeiten, damit ungenutzte Umgebungen automatisch heruntergefahren werden. Dazu kommen regelmäßige Schlüsselwechsel und eine Protokollierung, wer welche Aktion ausgelöst hat, weil die sonst schlicht fehlt. Für die Nutzer ist dieser Zwischenschritt nicht spürbar.

Ob die Grenze hält, haben wir geprüft. In einem eigenen Sicherheitstest haben wir aktiv versucht, aus einer Umgebung in fremde Daten, fremde Zugänge und fremde Systeme auszubrechen. Die Umgebungsgrenze hat gehalten, und innerhalb der Umgebung sind Punkte aufgefallen, die wir nachziehen. Wir haben unser eigenes Setup angegriffen, bevor wir es Kunden empfehlen.

Bei Objectbay läuft dieser Cluster unter einer ISO-27001-Zertifizierung mit einem abgesicherten Entwicklungsprozess. Die Prinzipien für agentische Systeme stammen aus dem Zero-Trust-Papier von Anthropic.

Welche KI-Infrastruktur bleibt unter eigener Kontrolle?

In Banken, Versicherungen, im Gesundheitswesen und bei kritischer Infrastruktur verbietet die Regulatorik häufig, sensible Daten an eine externe API zu senden. Dazu kommen drei Abhängigkeiten, die Unternehmen erst bemerken, wenn sie eintreten: fehlende GPU-Kapazität beim Cloud-Anbieter, abgekündigte Modellversionen und Preisänderungen mitten im Betrieb.

Souveränität lässt sich in vier Stufen prüfen: Wo liegen die Daten, welches Modell wird verwendet, wem gehört die Rechenkapazität und wer betreibt die Infrastruktur. Die Antwort fällt pro Anwendungsfall unterschiedlich aus, weil ein interner Dokumentenassistent andere Anforderungen hat als ein Agent mit Schreibzugriff auf das Kernsystem.

Ein Fallback auf ein zweites Modell ist kein Konfigurationseintrag. Ein Prompt, der auf einem Modell zuverlässig funktioniert, liefert auf einem anderen abweichende Ergebnisse, darum gehört zu jedem Fallback eine Sammlung von Testfällen, die gegen beide Modelle läuft. Das ist der Aufwand, den Unternehmen bei der Planung der Ausfallsicherheit meist übersehen.

In welcher Reihenfolge Unternehmen vorgehen

Am Anfang steht die regulatorische Klärung, weil sie bestimmt, welche Architektur überhaupt zulässig ist. Wer diese Frage nach dem Aufbau stellt, baut die Plattform ein zweites Mal.

Danach kommt die Datenbasis, weil ein Agent ohne verlässliche Daten auch mit perfekten Berechtigungen keinen Nutzen liefert. Die Zugriffskontrolle wird vor der Produktivsetzung eingerichtet, nicht nach dem ersten Vorfall.

Erst die Berechtigungsfrage zeigt, welche Aufgaben ein Agent tatsächlich übernehmen darf, und damit auch, wie viel vom ursprünglich geplanten Anwendungsfall übrig bleibt.

Diese Reihenfolge gilt unabhängig davon, welche KI-Lösungen am Ende darauf laufen.

‍

Wenn in Ihrem Unternehmen eine dieser 3 Freigaben offen ist, melden Sie sich. Die Engineers, die unsere eigene Agentenumgebung gebaut haben, helfen Ihnen gerne, was in Ihrem Fall zuerst geklärt werden muss.