Der architektonische Wandel, der erforderlich ist, um AI-Agenten zu regieren

AI ist nicht mehr nur ein Chatbot, der Text generiert. In Unternehmensumgebungen führen AI-Agenten Aktionen aus, wie z. B. das Abrufen sensibler Daten, das Auslösen von Workflows, das Aufrufen von Tools und das Protokollieren von Aktivitäten über Systeme hinweg. Autonomie verändert die Regierungsdiskussion vollständig; Kontrollen und Verfahren, die ursprünglich für menschliche Benutzer und traditionelle Anwendungen konzipiert wurden, waren nicht dafür ausgelegt, Software zu regieren, die mehrschrittige Aktionen während der Laufzeit ausführen kann.

Das Risiko ist nicht theoretisch. Kleine Lücken in der Sichtbarkeit, der Zugriffskontrolle und der Prüfbarkeit können sich schnell zu Laufzeitfehlern vergrößern, die schwer zu erkennen und noch schwerer rückgängig zu machen sind.

Um mit dieser neuen Ära Schritt zu halten, kann die Regierung von AI-Agenten nicht durch das Hinzufügen von mehr Richtliniendokumenten erfolgen. Es erfordert eine Regierung durch Design: einen architektonischen Ansatz, bei dem Kontrollen in der Steuerungsebene eingebettet und während der Laufzeit kontinuierlich durchgesetzt werden. Wenn Agenten wie digitale Kollegen handeln sollen, müssen sie die gleichen Unternehmenssicherheitsvorkehrungen wie Menschen erben, plus eine stärkere Laufzeitüberwachung.

Warum die Regierung in der Ära der Konvergenz fehlschlägt

Die Unternehmensarchitektur ist in eine Ära der Konvergenz eingetreten. Daten und Workloads erstrecken sich nun über mehrere Clouds, private Rechenzentren und Edge-Umgebungen hinweg.

Es gibt Organisationen, die ihre Plattformen in parallelen Systemen betreiben, da sie mehrere Prozesse gleichzeitig verwalten müssen. Dazu gehören separate Identitätssysteme, Protokollpipelines, Kataloge und genehmigte Prozesse. Das Ergebnis ist, was einige als “Frankenstein-Plattform” bezeichnen, bei der die Integrationsüberhead mit jedem neuen Tool oder Cloud-Umgebung zunimmt. Tatsächlich zeigt sich diese Fragmentierung in der alltäglichen Realität.

Laut einer jüngsten Umfrage nennen 47 % der Befragten komplizierte Zugriffsanforderungen und Prozesse und 44 % nennen begrenzte Sichtbarkeit darüber, wo Daten gespeichert sind, als Hindernisse für die effektive Nutzung von Daten.

Genau hier zeigen Agenten die Nähte zwischen Systemen auf.

Um eine Geschäftsfrage zu beantworten, muss ein Agent möglicherweise Daten aus einem lokalen ERP-System, einem Cloud-CRM, einer operativen Telemetrie in einer anderen Cloud und Dokumenten in einer Kollaborationssuite abrufen. Wenn die Organisation die Richtlinie in jedem Ort unterschiedlich durchsetzt, wird der Agent entweder fehlschlagen oder, schlimmer noch, auf Weise erfolgreich sein, die Sie nicht erklären oder kontrollieren können.

Dies ist der Moment, in dem Unternehmensleiter aufpassen müssen. Agenten erzwingen eine höhere Latte, die Konsistenz über Umgebungen hinweg und Rechenschaftspflicht während der Laufzeit fordert.

Die Regierung wird aus diesem Grund von Regulierungsbehörden und Sicherheitsagenturen in den Vordergrund gerückt. Ein Beispiel dafür ist das NIST AI-Risikomanagement-Framework, das Risikomanagement über den gesamten AI-Lebenszyklus hinweg betont, nicht nur während der Build-Zeit. Es ist eine Erinnerung daran, dass Compliance und Vertrauen operative Verantwortungen sind, nicht nur einmalige Checklisten.

Von Richtlinie zu Plattform

Regierung durch Design bedeutet, dass die Regierung mit der Workload reist, anstatt in jedem Silo neu implementiert zu werden. In der Praxis hängt dies von drei Bausteinen ab:

• Ein einheitlicher Steuerungsplan

Ein Ort, an dem Identität, Zugriff, Richtlinie, Kataloge und Berechtigungen über Clouds und Rechenzentren hinweg definiert und durchgesetzt werden können.

Das Ziel ist es, Richtlinien einmal zu schreiben und sie überall durchzusetzen, wo Daten und Modelle ausgeführt werden, anstatt Kontrollsysteme systemweise neu aufzubauen. Dies verhindert das Verhalten von Agenten, bei dem derselbe Agent in einer Umgebung sicher und in einer anderen Umgebung gefährlich handelt.

Ein praktischer Test ist einfach: Wenn ein Benutzer keinen Zugriff auf eine Spalte hat, sollte überprüft werden, ob ein Agent, der in seinem Namen handelt, auch keinen Zugriff darauf hat. Dies sollte anzeigen, ob die geschriebenen Richtlinien über die gesamte Ebene hinweg durchgesetzt werden.

• Ein Datenstoff, der auf offenen Standards basiert

Agenten benötigen Kontext, um zu handeln. Wenn dieser Kontext über verschiedene Strukturen verteilt ist, die von verschiedenen Teams besessen werden, hilft ein Datenstoff dabei, Semantik und Zugriffsmuster zu standardisieren, sodass Agenten nicht für jedes Dataset eine neue Satz von Regeln lernen müssen.

Offene Tabellenformate wie Apache Iceberg unterstützen dies, indem sie es mehreren Motoren ermöglichen, die gleichen reglementierten Daten zu teilen, ohne sie in einen neuen Silo zu kopieren. Dies ist wichtig, da Datenverdopplung der Ort ist, an dem die Regierung normalerweise fehlschlägt. Sobald Teams beginnen, “nur das zu kopieren, was der Agent benötigt”, haben Sie eine neue, weniger reglementierte Umgebung geschaffen.

Wenn Agenten über Datenbestände hinweg handeln können, ohne neue Berechtigungslücken einzuführen, funktioniert die Regierung wie beabsichtigt.

• Echtzeit-Beobachtbarkeit und Herkunft

Agenten sind nur reglementierbar, wenn Sie sehen können, was sie während der Laufzeit tun.

Beobachtbarkeit ist hier nicht nur ein “Nice-to-have”, sondern die Grundlage für Laufzeitkontrollen und Reaktionsmaßnahmen bei Vorfällen.

Insbesondere muss es einen endgültigen Beweis für Agentenaktionen geben. Agenten sollten in der Lage sein, Aktionen wie den Zugriff auf Daten und den Aufruf von Tools zu beweisen, und von dort aus kann die Herkunft Ausgaben mit Eingaben verbinden. Dies ermöglicht es Teams, Entscheidungen zu prüfen und bei Bedarf Ausfälle zu beheben, wodurch die Gesamtkonformität nachgewiesen wird.

Behandeln Sie Agenten wie “digitale Kollegen”

Eines der nützlichsten mentalen Modelle ist, Agenten als digitale Kollegen zu behandeln.

Hier ist ein Vergleich, der dies aufschlüsselt: Genau wie Mitarbeiter Zutrittskarten haben, die den Zugang zu bestimmten Gebäuden und Räumen gewähren, aber nicht zu anderen, ermöglicht die Regierung es Agenten, Zugriff mit Einschränkungen zu haben. Ein wichtiger Zusatz ist, dass Agenten situationsbewusst sein müssen, was sie preisgeben dürfen.

Betrachten Sie einen Support-Agenten. Er muss möglicherweise auf vorherige Supportfälle zugreifen, um ein Problem zu lösen, aber er kann nicht die privaten Details eines anderen Kunden weitergeben, während er dies tut. Anders ausgedrückt, kann der Agent eingeschränktes Wissen verwenden, um zu begründen, aber er muss dennoch Offenlegungsgrenzen durchsetzen. Dies ist kein “Prompt-Schreibproblem”, das wir historisch gelernt haben, zu navigieren; stattdessen ist es ein Identitäts- und Laufzeitdurchsetzungsproblem.

Was sich 2026 ändert: Agenten wechseln von Experimenten zur Produktion

2026 ist das Jahr, in dem Experimente enden und Agenten den Produktionsplatz einnehmen.

Dieser Wechsel zwingt Unternehmen, mit zwei Geschwindigkeiten zu arbeiten. Die eine ist die Innovationsgeschwindigkeit, bei der Teams neue Modelle, Tools und Agenten-Workflows testen, um einen Wettbewerbsvorteil zu erzielen. Und die andere ist die sichere Geschwindigkeit, bei der Systeme den Anforderungen an Konformität und Betrieb entsprechen müssen, was auch strenge Zugriffskontrollen und Blindstellen umfassen kann.

Ohne eine festgelegte architektonische Regierung werden diese beiden Geschwindigkeiten in Konflikt geraten.

Wenn Teams diese Agenten bereitstellen, bevor sie reglementiert sind, wird es ein Flickwerk aus Einzelkontrollen und Betriebsfehlern geben. Und wenn das Gegenteil eintritt, gibt es einen Ausfallmodus, bei dem Sicherheit alles blockiert und Innovation in Schatten-IT wechselt, was die Regierung untergräbt.

Das Ziel ist nicht, eine Geschwindigkeit zu wählen. Es ist, eine Architektur zu bauen, die beide unterstützt.

Eine praktische Checkliste für die Regierung von Agenten während der Laufzeit

• Wenn Sie Agenten aufbauen oder skaliert werden, ist es wichtig, sich selbst die folgenden Fragen zu stellen, um zu überprüfen, ob die Regierung tatsächlich architektonisch ist: Können Sie erläutern, von Anfang bis Ende, welche Daten ein Agent abgerufen hat, um eine Antwort zu geben oder eine Aktion auszuführen?
• Sind Zugriffsentscheidungen konsistent über hybride Umgebungen hinweg oder unterscheiden sie sich je nach Plattform?
• Haben Sie Telemetrie für Agentenaktionen, einschließlich Toolaufrufen, Richtlinienprüfungen und Eskalationen an Menschen?
• Können Sie einen Agenten während der Laufzeit drosseln, pausieren oder isolieren, wenn er unerwartet handelt?
• Haben Sie einen Überwachungsplan nach der Bereitstellung, der Ihren regulatorischen Verpflichtungen und Ihrem Risikoprofil entspricht?

Wenn Sie diese Fragen nicht beantworten können, behandeln Sie die Bereitstellung Ihres Agents wie einen Produktionsvorfall, der passieren wird.

Der Regierungswechsel muss architektonisch sein, oder er existiert nicht

Agenten werden eine Standardzusatz zu Unternehmensoperationen. Die Frage ist, ob sie eine zuverlässige Komponente von Unternehmensoperationen werden.

Wenn Agenten nicht mindestens so zuverlässig reglementiert werden wie Menschen und kritische Software, werden die Folgen real sein. Wir werden diese Folgen in Datenlecks, Konformitätsfehlern, Betriebsausfällen und Verlust des Vertrauens in AI-Programme sehen.

Führungskräfte müssen aufhören, die Regierung von Agenten als Dokumentationsübung zu behandeln. Wenn die Plattformfähigkeiten expandieren, sollte die Regierung von Agenten eine derjenigen sein, die die Aufsicht über andere Rollen übernimmt. Dies bedeutet, Kontrollen in der Steuerungsebene einzubetten, Aktionen beobachtbar und Entscheidungen prüfbar zu machen. Und dann skaliert.

Das ist, wie Sie Agenten bekommen, die schnell handeln, ohne das Unternehmen zu brechen.