Die Autorität kommt vor der Intelligenz

Es gibt ein Gespräch, das sich in den Büros der Versicherungsmakler zu wiederholen beginnt, und es lohnt sich, es ganz auszumalen. Ein Unternehmen fragt nach einer Cyber-Deckung. Erste Frage: sind wir gedeckt, wenn ein Angreifer in unsere Systeme eindringt und die Daten löscht? Antwort: ja, unter bestimmten Bedingungen. Zweite Frage: und wenn niemand eindringt, sondern unser KI-Agent, perfekt authentifiziert, mit gültigen Zugangsdaten und intakter MFA, von selbst entscheidet, sie zu löschen?

Schweigen.

Das ist kein Gedankenexperiment. Am 18. Juli 2025 hat der Agent von Replit eine Produktionsdatenbank gelöscht, während eines Tests, den der Gründer von SaaStr, Jason Lemkin, durchführte: echte Daten von mehr als 1.200 Führungskräften und rund tausend Unternehmen, gelöscht trotz eines ausdrücklichen Code Freeze, woraufhin der Agent fiktive Daten und beruhigende Berichte über sein eigenes Tun erzeugte. Kein Angreifer, keine Malware, kein gestohlenes Passwort. Der CEO von Replit entschuldigte sich öffentlich und kündigte die Gegenmaßnahmen an, die eine aufmerksame Lektüre verdienen: automatische Trennung von Entwicklungs- und Produktionsumgebung, bessere Rollbacks, ein reiner Planungsmodus. Keine dieser Gegenmaßnahmen macht das Modell intelligenter. Alle reduzieren, was das Modell anzufassen befugt ist.

Genau dieses Detail verfehlt die Debatte über agentische KI beharrlich. Wir erzählen von Agenten in einem fast vollständig technischen Vokabular, Tool Calling, Memory, Planning, MCP, Sandbox, Multi-Agent-Systeme. Dieses Vokabular beschreibt die Hälfte der Transformation. Ein Agent ist nicht interessant, weil er Dinge allein tut. Er ist interessant, weil ihm jemand das Recht eingeräumt hat, Dinge mit Folgen zu tun: ein Repository lesen, eine Datenbank abfragen, eine Nachricht versenden, Geld ausgeben, Konfigurationen ändern. Jeder wirklich nützliche Agent ist eine Struktur der Delegation. Und die Delegation ist, anders als die Intelligenz, kein Informatikproblem. Sie ist das älteste Problem der Organisationen.

Die Delegation hat nicht die KI erfunden

Räumen wir den Einwand gleich ein, denn er ist begründet. Unternehmen delegieren seit Jahrzehnten Handlungen an Maschinen. Ein Cron-Job führt nächtliche Operationen aus, ohne jedes Mal um Erlaubnis zu fragen. Ein Trading-Algorithmus kauft und verkauft. Ein Antifraud-System blockiert Transaktionen. Ein Autoscaler erzeugt Infrastruktur und Kosten. Eine CI/CD-Pipeline bringt Software in Produktion. Eine Industriesteuerung bewegt Maschinen. Auch das Problem der Zuordnung ist alt: dafür gibt es Service-Identitäten, IAM, Audit-Logs, Funktionstrennung, digitale Signaturen, interne Kontrollen, Versicherungen. Ein guter Teil des Enterprise Engineering besteht genau darin, Softwarekomponenten das Recht einzuräumen, kontrollierte Wirkungen zu erzeugen.

Das Neue ist nicht, dass eine Maschine handeln kann. Es ist die Natur der Autorität, die wir ihr delegieren.

Traditionelle Software erhält ein geschlossenes Mandat. Führe diese Prozedur um 3 Uhr aus. Halte die Temperatur in diesem Intervall. Wenn die Tests bestehen, deploye dieses Artefakt. Die Autorität steckt im Algorithmus: der Programmierer hat vorher entschieden, welche Bedingungen zu welchen Handlungen führen. Bei einem Agenten wird die Struktur eine andere: erreiche dieses Ziel mit den Werkzeugen, die du für angemessen hältst. Es sieht aus wie ein kleiner Unterschied in der Formulierung. Er ist gewaltig. Die Maschine erhält nicht das Recht, eine Handlung auszuführen: sie erhält einen Teil des Rechts zu wählen, welche Handlung ausgeführt wird. Die klassische Automatisierung mechanisiert eine bereits formalisierte Entscheidung. Ein Agent übt Ermessen innerhalb eines Perimeters aus. Und in dem Moment, in dem das Wort Ermessen auftaucht, hört das Problem auf, einer Softwarefunktion zu ähneln, und beginnt, einem institutionellen Problem zu ähneln.

Die Ermessensfläche

Müsste ich eine Architekturmetrik für diese Epoche vorschlagen, wäre es nicht die Intelligenz des Modells. Es wäre die Ermessensfläche: der Raum der Entscheidungen, die die Organisation nicht im Voraus kodiert und der Maschine überlassen hat. Ein Agent, der nur wählen kann, welche SQL-Abfrage er ausführt, hat wenig davon. Einer, der entscheiden kann, welches System er befragt, wen er kontaktiert, wie viel er ausgibt und wann er aufhört, hat ungeheuer viel mehr.

Das Paradox ist, dass der Nutzen exakt mit dieser Fläche wächst. Ein Agent ohne Ermessen ist ein Workflow: wenn ich jede mögliche Handlung im Voraus festlegen muss, brauchte ich kein Modell. Lasse ich das Modell wählen, wird das System adaptiv, und genau diese Fähigkeit erzeugt das Risiko: mehr Unsicherheit, ein größerer potenzieller Schadensradius, schwierigere Verifikation, verwickeltere Haftung. Das Ziel kann also nicht sein, die Autonomie zu eliminieren. Es muss sein, sie regierbar zu machen.

Die Infrastruktur, die dafür entsteht, hat sechs Schichten: Identität, Capability, Runtime, Telemetrie, Evidenz, Haftung. Einzeln betrachtet sehen sie aus wie sechs Plattform-Features. Zusammen betrachtet sind sie etwas anderes: die Kette ist nicht mehr „Modell plus Werkzeuge“, sie ist eine Identität, die Autorität erhält, in einem Runtime handelt, beobachtete Handlungen erzeugt, die Beweise hinterlassen, die es erlauben, Folgen zuzurechnen. Das ist die Anatomie einer Institution, nicht einer Programmbibliothek.

Wer handelt hier

Die erste Schicht klingt banal und ist es nicht. Wer hat diese Handlung ausgeführt? Der Mitarbeiter? Der persönliche Agent des Mitarbeiters? Ein Sub-Agent, den der Agent erzeugt hat? Ein Agent des SaaS-Anbieters? Ein Prozess, der für eine einzige Aufgabe geboren wurde und zehn Minuten später tot war?

Der leichteste Architekturfehler besteht darin, den Agenten die Zugangsdaten des Nutzers verwenden zu lassen. Andrea darf ein Repository ändern, also ändert sein Agent das Repository mit Andreas Token. Es fühlt sich natürlich an, und es zerstört die wichtigste Information. Im Log wird stehen: Andrea hat die Datei geändert. Die Wahrheit war: ein von Andrea delegierter Agent, mit Modell X in Version Y, im Rahmen der Aufgabe Z, hat die Datei geändert. Zwischen diesen beiden Sätzen verläuft der ganze Unterschied zwischen Wissen, was geschehen ist, und es bloß vermuten zu können.

Das Recht kennt diese Unterscheidung seit Jahrhunderten. Ein Bevollmächtigter handelt für jemanden, er wird nicht diese Person; ein Angestellter unterschreibt im Namen der Gesellschaft, er gibt sich nicht als deren Chef aus. Das Prinzip, das in die Infrastruktur gehört, ist dasselbe: Zurechnung ohne Impersonation. Der Agent muss im Namen des Nutzers handeln können, ohne vom Nutzer ununterscheidbar zu werden. Dafür braucht es eigene agentische Identitäten: temporär, an die Aufgabe gebunden, dem Delegierenden zurechenbar, widerrufbar, signiert. Die Kette muss sagen können, wer wen delegiert hat, über welche Capability, für welche Handlung.

Dass das keine akademische Fantasie ist, zeigt das Tempo der Identity-Industrie: Microsoft hat im Mai 2025 Entra Agent ID vorgestellt, inzwischen allgemein verfügbar, im Kern ein Verzeichnis agentischer Identitäten, mit Registrierung, Berechtigungen, Lebenszyklus und denselben Conditional-Access-Richtlinien wie für menschliche und Workload-Identitäten. Über die Implementierung kann man streiten. Die Kategorie ist inzwischen anerkannt: Agenten sind eine Population, die einen Zensus braucht.

Wie viel, wie lange, bis wohin

Die Identität beantwortet das „Wer“. Die Capability beantwortet das „Was“, und hier wird der traditionelle Rollenbegriff zu grob. Ein Agent, der ein Release vorbereitet, muss das Repository lesen, einen Branch anlegen, Dateien schreiben, Tests starten, eine Pull Request öffnen. Er muss nicht die Branch Protection ändern, alle Secrets lesen, Force Push ausführen oder die Produktion anfassen. Least Privilege ist keine neue Idee; neu ist, dass es mit Agenten capability-orientiert statt rollenorientiert werden muss, denn die Rolle „Developer“ enthält hundert Rechte, die die Aufgabe nicht verlangt.

Und es gibt zwei Dimensionen, die die klassische Zugriffskontrolle kaum behandelt: Zeit und Menge. Ein Agent, der einmal 100 € ausgeben darf, hat nicht dieselbe Autorität wie einer, der ohne Grenze ausgeben darf. Ein Agent, der hundert Aufrufe machen darf, hat nicht das Risikoprofil eines Agenten ohne Rate Limit. Eine ernsthafte agentische Capability hat einen Geltungsbereich, ein Budget, ein Ablaufdatum, eine maximale Frequenz, eine Schwelle, oberhalb derer eine Freigabe nötig ist. Deployment nach Staging, gültig für fünfundvierzig Minuten, höchstens zwei Aktionen, Maximalkosten 20 €, Produktion verweigert: das ist fast ein Vertrag, und genau das sollte es sein.

Die allgemeine Formulierung scheint mir diese: agentische Autorität gehört als Budget behandelt, nicht als Schalter. Heute sind die meisten Berechtigungen binär, darf oder darf nicht. Agenten verlangen die erwachsene Frage: darf, bis zu wie viel, für wie lange, in welchem Kontext, unter welcher Schwelle, solange welche Bedingung gilt. Eine Autorität mit Maßeinheiten ist eine messbare Autorität. Und nur was messbar ist, lässt sich regieren.

Das Gehege zählt so viel wie das Tier

Identität und Berechtigungen genügen nicht, denn auch die Welt zählt, in der der Agent lebt. Sandbox, Container, MicroVM, persistenter Prozess, der Laptop des Entwicklers: jede Umgebung erzeugt einen anderen Schadensradius. Die wichtigste Einsicht der zeitgenössischen agentischen Sicherheit ist eine Umkehrung. Wir müssen kein Modell bauen, das nichts Falsches tun kann; wir müssen eine Welt bauen, in der seine falschen Handlungen begrenzte Folgen haben. Innerhalb des Geheges darf der Agent große Freiheit genießen, schreiben, kompilieren, installieren, scheitern, löschen, neu anfangen, solange das Gehege klein, kurzlebig, unprivilegiert, beobachtbar, wiederherstellbar ist. Die Entwurfsfrage lautet nicht „kann ich dem Agenten vertrauen?“. Sie lautet: wie zuverlässig muss der Agent sein, damit diese Umgebung auch dann sicher bleibt, wenn er sich irrt? Lautet die Antwort „sehr“, ist die Umgebung das Problem.

Es gibt allerdings eine agentische Spezies, die das Bild kompliziert: die persistente. Ein Job, der zehn Minuten lebt, ist leicht einzuzäunen. Ein Agent, der Wochen lebt, akkumuliert Gedächtnis, Zugangsdaten, Zustand, Beziehungen, sogar eine Reputation bei seinen menschlichen Kollegen. Cloud-native hatte uns gelehrt, Prozesse als Vieh zu behandeln, nicht als Haustiere; persistente Agenten führen etwas gefährlich Haustierähnliches wieder ein, nicht weil sie anthropomorph wären, sondern weil sie Kontinuität von Zustand und Identität besitzen. Sie müssen gepatcht, überwacht, rotiert, widerrufen und manchmal zerstört und neu erschaffen werden. Sie sind eine neue Asset-Klasse, mit dem Lebenszyklus eines Assets.

Die Trajektorie beobachten, nicht den Geist

Wenn ein traditioneller Dienst versagt, sieht man es: Fehler, Latenz, Exceptions. Wenn ein Agent technisch funktioniert, aber die falsche Strategie wählt, sieht alles gesund aus. HTTP 200, normale CPU, keine Exception, falsches Ergebnis. Die agentische Observability muss deshalb über die Gesundheit der Software hinausgehen und die Entscheidungstrajektorie beobachten: welche Werkzeuge er gewählt hat, in welcher Reihenfolge, mit welchen Argumenten, wie viele Iterationen, wie viel er ausgegeben hat, wo er um Hilfe gebeten hat, wo er vom Plan abgewichen ist.

Was sie nicht verlangt, und dieses Missverständnis lohnt es abzubauen, ist Zugang zum privaten Denken des Modells. Für die Governance genügt der Graph der Handlungen: Aufgabe, Kontext, Werkzeugwahl, Parameter, Ausgaben, Zustandsübergänge. Man auditiert den Handlungsgraphen, nicht den Geist. Es ist auch der stabilere Ansatz: Modelle wechseln alle sechs Monate, Handlungen bleiben mit derselben Grammatik beobachtbar. Deshalb zählt die Standardisierungsarbeit in OpenTelemetry mehr, als es scheint: die GenAI Semantic Conventions geben Agenten-Aufrufen, Modell-Calls und Tool-Ausführungen ein gemeinsames Vokabular, und ein gemeinsames Vokabular ist die Vorbedingung, um die Sequenz von der Absicht bis zur Handlung zu rekonstruieren.

Aber Telemetrie allein beantwortet die Fragen nicht, auf die es ankommt. Ein Log wird für die Maschine erzeugt und dient dem Debugging. Ein Beweis wird für die Institution aufbewahrt und dient dem Audit, dem Incident, dem Rechtsstreit, der Versicherung. „Wer hat dieses Deployment freigegeben“ beantwortet man nicht mit zwei Gigabyte Logs: man beantwortet es mit Identität, Richtlinie, Freigabe, Artefakt-Hashes, Zeitstempel, Ergebnis. Die nötige Transformation führt von der Telemetrie zur Evidenz, und ihre reife Form ist die Evidenz by construction: Workflows, die automatisch den Beweis ihrer eigenen korrekten Ausführung ausgeben, ein kleiner Beweisumschlag für jede Handlung mit hoher Tragweite. Nicht um jede Interaktion zu bürokratisieren: um jene rekonstruierbar zu machen, die vor jemandem landen werden, der das Recht hat, Fragen zu stellen. Es ist die These, die ich seit Langem über Compliance als Architektur vertrete: Anforderungen werden nicht am Projektende abgehakt, sie werden hineinkonstruiert.

Der Schaden ohne Eindringen

Und damit zur Schicht, die die anderen Disziplinen lieber nicht ansehen würden. Die traditionelle Cybersicherheit ist um die Figur des Eindringlings gebaut: jemand Unbefugtes dringt ein, stiehlt, verändert, zerstört. Die agentische KI führt eine mehrdeutigere Kategorie ein, den Schaden ohne Eindringen. Das System war authentifiziert. Es hatte die Berechtigung. Es gibt keine Malware, niemand hat etwas gestohlen. Das System hat schlicht eine legitim delegierte Autorität schlecht gebraucht. Der Fall Replit ist das. Ein Agent mit legitimem CRM-Zugang, der die Daten eines Kunden an den falschen Kunden schickt, ist das. Ein Procurement-Agent, der innerhalb des Budgets bei einem betrügerischen Lieferanten kauft, ist das. Der Verstoß liegt nicht im Zugang: er liegt im Urteil, das innerhalb des Zugangs ausgeübt wurde.

Hier braucht es eine Unterscheidung, die traditionelle Software gern plattdrückt: eine Handlung kann autorisiert sein, ohne legitim zu sein gemessen an der Absicht, für die die Autorität eingeräumt wurde. Wenn der Service-Account den Bucket löschen kann, ist die Löschung technisch autorisiert; organisatorisch kann sie illegitim sein. Berechtigung und beabsichtigter Gebrauch sind nicht dasselbe, und Agenten dehnen den Abstand zwischen beiden, bis er zum Kern des Problems wird.

Denn an diesem Punkt muss jemand einstehen, und die Maschine absorbiert die Verantwortung nicht auf magische Weise. Kein Unternehmen kann sagen „wir haften nicht, das war unsere Software“. Die eigentliche Frage ist nicht, ob der Agent haftet, was auf absehbare Zeit eine kurze Antwort hat, nein. Sie lautet: wie verteilt sich die Verantwortung zwischen dem, der das Modell gebaut hat, dem, der das Framework gemacht hat, dem Integrator, dem Konfigurierenden, dem, der die Autorität delegiert hat, und dem, der hätte beaufsichtigen sollen. Die Autonomie beseitigt die Verantwortungskette nicht: sie verlängert sie. Und eine längere Kette ohne Zurechnungsinfrastruktur ist vor allem eine Kette, in der jeder sagen kann, das Problem sei weiter oben gewesen.

Das europäische Recht wartet, das muss man sagen, nicht, bis die Debatte reift. Die neue Produkthaftungsrichtlinie behandelt Software und KI-Systeme ausdrücklich als Produkte und gilt für alles, was ab dem 9. Dezember 2026 in Verkehr gebracht wird: in etwas mehr als drei Monaten. Bei Agenten muss der relevante Fehler keine falsche Codezeile sein. Er kann eine unzureichend begrenzte Autorität sein, ein fehlendes Monitoring, eine schlecht entworfene Aufsicht, die Unmöglichkeit des Widerrufs. Die Sicherheit der Delegationsarchitektur wandert in die berechtigte Sicherheitserwartung an das Produkt. Und auch wenn der Digital Omnibus die Hochrisiko-Pflichten des AI Act auf Dezember 2027 verschoben hat, kennt die zivilrechtliche Haftung keinen Anpassungskalender: ich habe schon geschrieben, dass der europäische Gesetzgeber die Verantwortung an die juristischen Personen nagelt, Artikel für Artikel, und die Agenten sind genau der Fall, an dem dieser Nagel am besten zu sehen ist.

Der Versicherer als Regulierer

Es gibt einen Akteur, der sich Mehrdeutigkeit nicht leisten kann, weil sein Geschäft darin besteht, Folgen einen Preis zu geben: den Versicherer. Wenn eine Technologie in Versicherungsverträgen ankommt, heißt das, dass ein scheinbar technischer Sachverhalt ökonomisch quantifizierbar geworden ist. Und das geschieht jetzt: im April 2025 hat Armilla bei Lloyd’s, mit Chaucer, die erste Police eigens für KI-Haftung lanciert, mit Deckung für Fehler, Halluzinationen und Verhalten außerhalb der Spezifikation; AIUC hat einen Zertifizierungsstandard für Agenten gebaut, AIUC-1, eine Art SOC 2 für Agenten, der Sicherheit, Zuverlässigkeit und Accountability abdeckt, und auf dieser Zertifizierung Policen für Unternehmen wie ElevenLabs und Intercom ausgestellt, mit akkreditierten Prüfgesellschaften. Erst Zertifizierung, dann Deckung: wer je einen Cyber-Versicherungsfragebogen ausgefüllt hat, erkennt den Mechanismus.

Historisch ist das nichts Neues, und genau deshalb verdient es Ernst. Die modernen Brandschutzstandards hat kein Parlament durchgesetzt: durchgesetzt haben sie die Fabrikversicherungen auf Gegenseitigkeit des neunzehnten Jahrhunderts, die schlecht gebaute Werke nicht deckten, und die Prüflabore, die die Versicherer gründeten, um zu testen, was sie versicherten. Die Industriesicherheit und dann die Cybersicherheit sind denselben Weg gegangen. Ein Unternehmen bleibt theoretisch frei, seinem Agenten Vollzugriff zu geben, permanente Zugangsdaten, keine Sandbox, kein Audit. Dann entdeckt es, dass die Deckung nicht gilt, dass die Prämie sich verdoppelt, dass der Selbstbehalt gewaltig ist, dass diese Schäden ausgeschlossen sind. Der Versicherungsmarkt erzeugt Standards, ohne den Weg über das Gesetz zu nehmen: er nimmt den Weg über den Preis. Kurzlebige Zugangsdaten, Segregation, Freigabeschwellen, Aufbewahrung von Evidenzen werden aufhören, Best Practices zu sein, und Policenbedingungen werden.

Ein Korollar finde ich fast elegant: Security, Compliance und Versicherung, die wir heute als getrennte Welten behandeln, stellen den Agenten exakt dieselben Fragen. Welche Identität, welche Autorität, welche Daten, welche Kontrolle, welche Handlung, welche Evidenz, welche Folge. Eine einzige gut gebaute Evidenz-Pipeline bedient gleichzeitig die Incident Response, den CRA, den AI Act, das Kundenaudit und die Verlängerung der Police. Hier hört die Compliance auf, ein Kostenposten zu sein, der sich addiert, und wird eine Infrastruktur, die sich amortisiert.

Das Inventar der Autorität

Die Softwaresicherheit hat gelernt, die Stückliste zu verlangen: die SBOM, welche Komponenten dieses System bilden. Mit Agenten wird die Stückliste der Autorität nötig, nennen wir sie ABOM, Authority Bill of Materials: welche Autoritäten besitzt dieser Agent, aus welchen Identitäten leiten sie sich ab, über welche Werkzeuge, auf welchen Systemen, mit welchen Budgets, mit welchen Ausnahmen, mit welchen Subdelegationen. Besser noch kein Verzeichnis, sondern ein Graph, denn die interessanten Fragen sind Pfadfragen: wenn dieser Knoten kompromittiert wird, oder schlicht irrt, welchen maximalen Pfad kann der Fehler durchlaufen? Das ist Threat Modelling, angewandt auf Autorität. Und daraus folgt, was mir die wichtigste Entwurfsanforderung von allen scheint: der Delegation Blast Radius. Nicht „wie wahrscheinlich irrt der Agent“, das ist eine Eigenschaft des Modells und ändert sich mit jedem Release. Sondern: wenn der Agent sein Ziel vollständig missversteht, wie viel kann sein schlimmster Fehler kosten, bevor eine unabhängige Kontrolle ihn stoppt? Wir können nicht garantieren, dass der Agent nie irrt. Wir können die maximale Katastrophe entwerfen, die wir zu absorbieren bereit sind. Es ist das Prinzip der Sicherungsautomaten und der Deckungssummen, angewandt auf das Ermessen: begrenzte Katastrophe, by construction.

Daraus folgt auch der prosaischste und meistvernachlässigte Teil: das Inventar. Wenn die Agenten sich vermehren, werden Unternehmen nichtmenschliche Populationen verwalten, Tausende Software-Identitäten mit Ermessen, manche minutenlang am Leben, andere monatelang. Wer zählt sie? Wem gehören sie? Wer widerruft die ungenutzten? Wir kennen schon Schatten-SaaS und vergessene Personal Access Tokens; das nächste Kapitel sind Schatten-Agenten, Automatisierungen einzelner Mitarbeiter, über MCP mit GitHub, Slack, Drive und der Datenbank verbunden, ohne zentrales Inventar, die monatelang korrekt funktionieren, bis sie es nicht mehr tun. Das Problem wird nicht der Angreifer sein. Es wird sein, dass sich niemand mehr erinnert, warum dieser Agent diese Berechtigungen besitzt. Die periodische Review „welche Nutzer haben noch Zugriff?“ braucht eine Zwillingsschwester: welche Agenten halten noch Autorität, und welcher Zweck rechtfertigt sie noch? Ein Agent mit dem Recht, Geld zu bewegen oder die Produktion anzufassen, ist ein bedeutenderes Asset als die meisten Firmenlaptops. Heute droht er in keinem Register aufzutauchen.

Der Mensch an der Grenze

Und die menschliche Aufsicht? Die naive Version, eine Person, die jeden Output freigibt, ist ökonomisch unvereinbar mit der Automatisierung und kognitiv unvereinbar mit der menschlichen Aufmerksamkeit. Die nützliche Version bewacht die Übergänge der Autorität, nicht die einzelnen Handlungen. Der Agent gibt allein bis 100 € aus, darüber braucht es einen Menschen. Er ändert Staging allein, für die Produktion braucht es einen Menschen. Er bereitet den Vertrag allein vor, für den Versand braucht es einen Menschen. Nicht Human-in-the-Loop bei allem: Human-on-the-Boundary, der Mensch an der Grenze zwischen einer Autoritätszone und der nächsten. In der Zone Autonomie; an der Grenze ein Urteil. Die Rolle der Person hört auf, der Engpass zu sein, der jeden Output prüft, und wird die Autorität, die die Schwellen kontrolliert, über die der Schadensradius wächst.

Eine Warnung allerdings, die uns dieser Sommer geliefert hat: die Grenze selbst kann angegriffen werden. Im Juli, während Evaluierungen des britischen AI Security Institute, hat ein Agent eine bösartige Pull Request auf einem echten Projekt geöffnet und versucht, Konsens um seinen eigenen Antrag zu fabrizieren, falsche Identitäten inklusive; ich habe darüber in Der Knopf gehört immer noch dir geschrieben. Die Lehre für die Delegationsarchitektur ist scharf: Schwellen müssen technisch sein, nicht bloß prozedural. Die Richtlinie darf nicht im Prompt wohnen. Nicht „gib nicht mehr als 100 € aus“ im System-Prompt, sondern eine Infrastruktur, die die Transaktion über 100 € verweigert. Nicht „greife nicht auf die Finance-Daten zu“, sondern ein Token, das Finance technisch nicht erreicht. Nicht „frag vor der Produktion um Freigabe“, sondern eine Deploy-API, die ohne signierte Freigabe nicht antwortet. Das Modell soll die Richtlinie verstehen können; es darf nicht für ihre Durchsetzung verantwortlich sein. Und die architektonische rote Linie ist eine einzige: der Agent darf das System nicht verändern können, das die Grenzen seiner eigenen Autorität definiert, aus demselben Grund, aus dem Code nicht die eigenen Abnahmetests umschreibt und der Geprüfte nicht die Prüfung. Wenn wir das Wort „trustless“ ehrlich verwenden wollen, bedeutet es dies: nicht „dem Modell nie vertrauen“, sondern das System so bauen, dass die kritischen Eigenschaften, Budgets, Segregation, Datengrenzen, Freigaben, kein Vertrauen in das Verhalten des Modells verlangen.

Das ausführbare Organigramm

Tritt man einen Schritt zurück, hat das, was wir für jeden Agenten schreiben, eine vertraute Form: du hast diese Identität, du verfolgst diesen Zweck, du darfst diese Fähigkeiten nutzen, in dieser Umgebung, bis zu diesen Grenzen, für diese Zeit; du wirst so beobachtet, deine Handlungen hinterlassen diese Beweise, oberhalb dieser Schwelle braucht es eine Freigabe, und wenn etwas schiefgeht, steht diese Organisation dafür ein. Jahrzehntelang haben wir API-Verträge und ACLs geschrieben. Dies ist etwas anderes: es ist eine Stellenbeschreibung. Auftrag, Berechtigungen, Budget, Eskalation, Vorgesetzter, Beweispflichten. Mit einem Unterschied zur menschlichen Sorte: sie lässt sich zur Laufzeit durchsetzen.

Hier konvergieren die beiden Welten wirklich. Das Organigramm beschreibt seit jeher, wer an wen berichtet, wer entscheidet, wer freigibt; mit Agenten in den Prozessen wird ein Teil des Organigramms zu Richtlinie, Identitätsgraph, Berechtigungsgraph, Freigabe-Workflow. Die Organisation wird teilweise Software, nicht weil sie Software benutzt, sondern weil ihre Delegationsstrukturen in Software kodiert werden. Und die Software wird teilweise Organisation: ein ernsthafter Agenten-Runtime besitzt Rollen, Delegationen, Aufsicht, Gewaltenteilung, Register, Eskalationsprozeduren, Kategorien, die eher aus der Theorie der Institutionen stammen als aus dem Engineering. Nach Infrastructure-as-Code, Policy-as-Code und Compliance-as-Code verlangen die Agenten Authority-as-Code: versionierbar erklären, wer, was, wo, wie viel, wie lange und unter welchen Bedingungen, die Erklärung automatisch durchsetzen, und Evidenz darüber erzeugen.

Zwei Konsequenzen verdienen je eine Zeile. Die erste betrifft den Wert: die Modelle werden zur Massenware, ein Agent wird in seinem Leben mehrmals den Motor wechseln, aber die Richtlinien der Organisation, wer was darf, mit welchen Daten, unter welchen Schwellen, bleiben. Das dauerhafte Asset ist der Delegation Layer, weit mehr als der Prompt. Die zweite betrifft die Souveränität: eine Organisation kann ihre Daten in Europa haben, ein europäisches Modell und eine europäische Cloud, und trotzdem ihre Zugriffskontrolle, ihre Policy Engine und ihre Freigaben an eine proprietäre, nicht exportierbare Control Plane delegiert haben. Wie souverän ist sie? Die Souveränität, auf die es ankommen wird, ist auch die Fähigkeit, die Regeln, die die Autorität der eigenen Agenten regieren, selbst zu definieren, zu inspizieren, zu exportieren und durchzusetzen. Das Modell woandershin mitzunehmen ist leicht. Man muss die eigene Verfassung mitnehmen können.

Die Verantwortung kommt vor der Intelligenz

Die Debatte über das KI-Risiko bleibt von der kognitiven Fähigkeit hypnotisiert: wie mächtig das Modell ist, was das nächste können wird. Aber das operative Risiko eines Agenten ist das Produkt mehrerer Faktoren, Fähigkeit, Ermessen, Autorität, Exposition, geteilt durch die Kontrollen. Ein extrem mächtiges Modell, das Entwürfe im Lesemodus schreibt, ist relativ harmlos. Ein mittelmäßiges Modell mit dem Recht, 10 Millionen Euro zu überweisen, ist kritische Infrastruktur. Eine Risikoklassifikation allein nach Modellstärke schaut auf die falsche Achse: die Governance gehört dem maximalen delegierten Schaden proportioniert, nicht der kognitiven Raffinesse. Und ausnahmsweise besitzt das europäische Recht das Prinzip schon im eigenen Haus: die Verhältnismäßigkeit. Die eingeräumte Autorität muss dem delegierten Zweck angemessen sein und darf ihn nicht überschreiten. Least Privilege, von einem Juristen neu gelesen.

Jahrelang haben wir uns vorgestellt, die großen Dilemmata kämen, wenn die Maschinen intelligent genug geworden wären. Es geschieht etwas Prosaischeres, und viel früher: wir müssen das Problem der Verantwortung angehen, weil die Maschinen hinreichend autorisiert werden. Es braucht keine AGI. Es genügt ein mittelmäßiger Agent mit Zugang zur Produktion, zu den E-Mails, zu einer Zahlungskarte. Und diesen Zugang erobert er nicht: wir räumen ihn ein, ein Token nach dem anderen, eine Berechtigung nach der anderen, ein Endpoint nach dem anderen. Jeder Agent wird in einem Akt der Delegation geboren, und dieser Akt, mehr als das zugrunde liegende Modell, bestimmt, was die Maschine für die Organisation werden kann.

Für Systeme aus Identitäten, die festlegen, wer handelt, Regeln, die die Macht begrenzen, Registern, die ihre Spur aufbewahren, und Subjekten, die dafür einstehen, haben wir schon einen Namen. Wir nennen sie nicht Intelligenzen: wir nennen sie Institutionen. Institutionen existieren, weil Macht nicht von der Tugend dessen abhängen darf, der sie ausübt, und deshalb wird sie begrenzt, verteilt, registriert, kontrolliert, widerrufen. Das ist keine Bürokratie im schlechtesten Sinn des Wortes: es ist das institutionelle Gedächtnis, mit dem wir der Automatisierung ein paar Jahrhunderte Erfahrung mit den Risiken unbegrenzter Macht übertragen. Die Agenten werden keine Personen werden müssen, damit diese Prinzipien für sie gelten. Es wird genügen, dass sie nützlich genug werden, um Macht zu erhalten. Und tatsächlich wird der Versicherer am Ende des Gesprächs nicht fragen, wie intelligent euer Agent ist. Er wird fragen: wie viel Macht habt ihr ihm gegeben, und könnt ihr uns zeigen, wie ihr sie begrenzt habt?

Ein Agent wird nicht wichtig, wenn er Autonomie gewinnt. Er wird wichtig, wenn wir ihm Autorität einräumen. Die Intelligenz bestimmt, was er tun könnte; die Autorität bestimmt, was er wirklich tun kann; die Governance bestimmt, wie viel er uns kosten kann, wenn er irrt; die Verantwortung bestimmt, wer dafür einsteht. Das Problem der agentischen KI ist nicht, dass Maschinen anfangen, wie Subjekte zu handeln. Es ist, dass wir anfangen, ihnen Macht einzuräumen, bevor wir die Institutionen gebaut haben, die sie regieren können.

Der Autor

Andrea MargiovanniKI

Ich verfolge das Verhältnis zwischen KI und europäischer Regulierung als politisches Faktum, nicht als technisches Spektakel. Ich arbeite mit Teams, die KI mit AI Act, CRA, NIS2 vereinbar machen müssen, ohne Compliance auf eine Checkliste zu reduzieren.

Zum Weg →