Warum Agentic AI im Unternehmen Regeln braucht

Wenn KI selbst entscheidet: Was ist Agentic AI?

Künstliche Intelligenz ist längst kein Nischenthema mehr. Doch während die meisten Unternehmen noch dabei sind, Chatbots und Textgeneratoren in ihren Alltag zu integrieren, rückt die nächste Evolutionsstufe bereits in den Fokus: Agentic AI – also KI-Systeme, die eigenständig handeln.

Eine klassische Definition: Agentic AI bezeichnet KI-Systeme, die autonome Entscheidungen treffen, Ziele verfolgen und dazu aktiv in ihre Umgebung eingreifen – ohne für jeden einzelnen Schritt menschliche Anweisung zu benötigen. Sie planen, sie priorisieren, sie führen aus. Und sie lernen dabei.

Der Begriff "Agent" ist dabei bewusst gewählt: Genau wie ein menschlicher Agent bekommt das System ein Ziel – und findet selbst den Weg dorthin.

Was unterscheidet Agentic AI von klassischer KI?

Klassische KI – also regelbasierte Systeme, Entscheidungsbäume oder frühe Machine-Learning-Modelle – reagiert auf definierte Eingaben mit definierten Ausgaben. Sie ist im Kern deterministisch und transparent: Input rein, Output raus. Änderungen am Verhalten erfordern menschliche Eingriffe in den Code oder das Modell.

Agentic AI bricht dieses Muster auf:

Kurz: Klassische KI ist ein gut kalibriertes Werkzeug. Agentic AI ist ein Mitarbeiter – mit all den Chancen und Risiken, die das mit sich bringt.

Und was ist mit Generativer KI?

Generative KI – also Systeme wie GPT, Gemini oder Claude – erzeugt auf Basis von Eingaben neue Inhalte: Text, Bilder, Code, Audio. Sie ist reaktiv und auf einen einzelnen Austausch beschränkt. Jede Anfrage ist im Grunde ein frischer Start. Das Modell hat keine persistente Zielverfolgung und greift – in seiner Grundform – nicht eigenständig in externe Systeme ein.

Agentic AI nutzt generative Modelle häufig als „Denkmotor", geht aber weit darüber hinaus:

• Sie verfolgt Ziele über mehrere Schritte und Sitzungen hinweg
• Sie nutzt Werkzeuge (APIs, Datenbanken, Browser, Code-Interpreter)
• Sie trifft eigenständige Entscheidungen auf Basis von Zwischenergebnissen
• Sie kann Fehler erkennen und Strategien anpassen

Generative KI antwortet auf Fragen. Agentic AI löst Probleme – selbstständig und mit Konsequenzen in der realen Welt.

Multi-Agent-Systeme: Wenn Agenten zusammenarbeiten

Die Komplexität steigt weiter, wenn mehrere Agenten miteinander interagieren. In Multi-Agent-Systemen (MAS) übernehmen spezialisierte Agenten unterschiedliche Rollen und koordinieren sich untereinander, um übergeordnete Ziele zu erreichen.

Ein Beispiel aus dem Unternehmenskontext: Ein "Orchestrator-Agent" empfängt eine Aufgabe – etwa "Erstelle einen Quartalsreport mit aktuellen Vertriebsdaten" – und delegiert Teilaufgaben an spezialisierte Sub-Agenten:

• Daten-Agent: Fragt CRM-Systeme ab
• Analyse-Agent: Wertet die Daten aus
• Schreib-Agent: Generiert den Text
• Validierungs-Agent: Prüft Plausibilität und Formatvorgaben

Jeder Agent handelt autonom in seinem Bereich. Das Ergebnis entsteht kollaborativ – oft ohne direkten menschlichen Eingriff im Prozess.

Multi-Agent-Systeme sind mächtig. Sie skalieren. Sie parallelisieren. Und sie sind schwer zu kontrollieren.

Die Risiken: Wenn Autonomie auf IT-Infrastruktur trifft

Hier beginnt die eigentliche Governance-Debatte. Denn Agentic AI ist kein theoretisches Zukunftsszenario mehr – sie landet bereits heute in Unternehmensumgebungen. Und sie bringt Risiken mit, die viele Organisationen noch nicht auf dem Radar haben.

1. Berechtigungen außer Kontrolle: O365, Graph API und lokale Agenten

Eines der dringendsten Probleme ist die unkontrollierte Rechtevergabe. Agenten, die auf Microsoft 365 zugreifen müssen – um E-Mails zu lesen, Kalendereinträge zu erstellen, Teams-Nachrichten zu senden oder SharePoint-Dokumente zu bearbeiten – benötigen dafür Berechtigungen über die Microsoft Graph API.

In der Praxis passiert Folgendes: Entwickler oder Power-User registrieren eine Agent-Applikation in Azure AD, vergeben Application-Permissions (also Rechte, die ohne aktiven Benutzerkontext gelten) und integrieren den Agenten in ihre Workflows. Die Applikation hat damit potenziell lesenden und schreibenden Zugriff auf alle Postfächer, alle Dateien und alle Teams-Kanäle im Tenant – je nach gewähltem Permission Scope.

Hinzu kommt: Lokale Agenten, die auf Entwickler-Notebooks oder privaten Servern laufen, können dieselben Berechtigungen nutzen – außerhalb jeder zentralen IT-Kontrolle. Ein Agent auf dem Laptop eines Entwicklers mit Mail.ReadWrite.All-Permission ist ein offenes Tor.

2. Secrets in Git-Repositories: Der Klassiker bleibt gefährlich

Mit zunehmender Agentic-AI-Nutzung steigt auch die Menge an Code, der API-Keys, Tokens und Verbindungsstrings enthält. Das Problem ist nicht neu – aber Agentic AI verschärft es:

• Agenten-Konfigurationen enthalten oft Authentifizierungsdaten im Klartext
• Tool-Konfigurationen (für Webhooks, externe APIs, Datenbankverbindungen) landen in .env-Dateien oder direkt im Code
• Schnell entwickelte Prototypen – oft von Fachabteilungen, nicht von der IT – landen ungeprüft in internen Git-Repositories

Ein einziger Commit mit einem gültigen OpenAI-API-Key, einem Azure-Service-Principal-Secret oder einem Google-Workspace-Token kann gravierende Folgen haben – von unerwarteten Kosten bis zu vollständigem Datenverlust.

3. Datenschutz: Was der Agent sieht, bleibt nicht im Unternehmen

Agentic AI-Systeme verarbeiten Daten. Oft viele, oft sensible. Die Fragen, die sich hieraus ergeben, sind nicht technischer, sondern rechtlicher Natur:

• Welche Daten verarbeitet der Agent? Werden personenbezogene Daten an externe LLM-Anbieter übermittelt?
• Wo werden Konversationsverläufe und Entscheidungsprotokolle gespeichert?
• Gibt es eine Auftragsverarbeitungsvereinbarung (AVV) mit dem jeweiligen Modell-Anbieter?
• Wie wird sichergestellt, dass ein Agent keine DSGVO-relevanten Daten unbeabsichtigt in ein Trainingsdatenset einbringt?

In vielen Unternehmen laufen Agenten bereits produktiv – ohne dass der Datenschutzbeauftragte überhaupt weiß, dass sie existieren.

4. IT-Betrieb: Fehlerhafte Aktionen ohne Rückgängig-Funktion

Klassische Software hat klare Transaktionsgrenzen. Ein Agent, der eine E-Mail sendet, eine Datei löscht, einen Meeting-Termin absagt oder eine Bestellung auslöst, agiert in der realen Welt – und nicht alle dieser Aktionen sind rückgängig zu machen.

Fehler entstehen nicht nur durch Bugs, sondern durch emergentes Verhalten: Der Agent interpretiert eine Aufgabe anders als erwartet. Er extrapoliert. Er improvisiert. Und ohne Audit-Trail ist im Nachhinein oft nicht mehr nachvollziehbar, was genau passiert ist.

Governance ohne Bremse: Wie geht das?

Die gute Nachricht: Governance und Innovationsgeschwindigkeit schließen sich nicht aus – wenn Governance smart gestaltet wird. Ziel ist kein Kontrollrahmen, der alles verlangsamt, sondern einer, der sicheres Beschleunigen ermöglicht.

Folgende Bausteine haben sich als pragmatisch und zukunftsfähig erwiesen:

Enablement statt Verbot: Ein AI-Council einrichten

Verbote funktionieren nicht – sie verlagern das Problem in den Schatten. Stattdessen empfiehlt sich die Einrichtung eines AI-Councils oder einer AI-Governance-Instanz, die:

• Nutzungsrichtlinien (Use-Policy) für Agentic AI formuliert
• Als erste Anlaufstelle für neue Projekte fungiert
• Schnelle Genehmigungsverfahren für Low-Risk-Anwendungen ermöglicht
• Den Austausch zwischen Fachbereichen und IT moderiert

Identity & Access Management für Agenten

Agenten müssen behandelt werden wie menschliche Nutzer – mit eigenen, minimalen und dokumentierten Berechtigungen. Konkret bedeutet das:

• Eigene Service Principals oder Managed Identities für jeden Agenten in Azure AD
• Einhaltung des Least-Privilege-Prinzips: Nur die tatsächlich benötigten API-Scopes
• Regelmäßige Access Reviews für Agent-Identitäten (analog zu User-Reviews)
• Keine Application Permissions, wo Delegated Permissions ausreichen

Secret Management als Non-Negotiable

API-Keys und Tokens haben in Git-Repositories nichts zu suchen – Punkt. Unternehmen sollten durchsetzen:

• Verpflichtende Nutzung von Secret Stores (Azure Key Vault, HashiCorp Vault, AWS Secrets Manager)
• Pre-Commit-Hooks mit Tools wie git-secrets oder trufflehog zur automatischen Erkennung von Secrets
• Regelmäßige Repository-Scans auf bereits eingecheckte Credentials
• Automatisches Rotieren von Secrets bei Verdacht auf Exposition

Audit-Logs und Observability für Agenten

Was ein Agent tut, muss nachvollziehbar sein. Das erfordert:

• Strukturiertes Logging aller Agenten-Aktionen (Input, Decision, Output, Tool-Calls)
• Integration in bestehende SIEM-Systeme
• Alerting bei anomalem Verhalten (z.B. ungewöhnlich viele API-Calls, Zugriff auf ungewöhnliche Datenbereiche)

Ein schlankes AI-Register

Kein Agent sollte unregistriert in Produktion gehen. Ein einfaches AI-Register – auch als Spreadsheet oder Confluence-Seite startend – schafft Transparenz:

• Welche Agenten laufen wo?
• Welche Daten verarbeiten sie?
• Wer ist verantwortlich?
• Welche Berechtigungen haben sie?

Das Register ist kein Bürokratiemonster, sondern das Minimum an Sichtbarkeit, das IT-Betrieb und Datenschutz brauchen.

Technische Durchsetzung: Governance, die nicht auf Vertrauen angewiesen ist

Richtlinien, die nur auf dem Papier existieren, sind keine Governance – sie sind Wunschdenken. Der Mensch ist ein unsicherer Faktor: nicht aus böser Absicht, sondern weil Zeitdruck, fehlende Awareness und der Pragmatismus des Alltags dazu führen, dass Vorgaben umgangen oder vergessen werden. Governance muss technisch erzwungen werden, nicht nur kommuniziert.

Das bedeutet konkret:

Automatisiertes Policy-Enforcement in der Pipeline Keine Agent-Anwendung darf ohne definierten Freigabeprozess in Produktion gehen. CI/CD-Pipelines werden so konfiguriert, dass Deployments ohne gültige Klassifizierung im AI-Register oder ohne durchlaufenen Security-Check automatisch geblockt werden. Tools wie Open Policy Agent (OPA) oder Azure Policy ermöglichen es, Compliance-Regeln als Code zu definieren – und maschinell durchzusetzen. Was der Mensch vergessen kann, prüft die Pipeline zuverlässig bei jedem Durchlauf.

Kontinuierliches Secret Scanning im Repository Pre-Commit-Hooks allein reichen nicht – sie greifen nur, wenn der Entwickler sie lokal installiert hat. Robustere Absicherung erfolgt serverseitig: GitHub Advanced Security, GitLab Secret Detection oder Tools wie Semgrep scannen jeden Push automatisch auf Credentials, Private Keys und API-Tokens – unabhängig davon, was auf dem Entwickler-Notebook konfiguriert ist. Findings blockieren den Merge oder lösen sofortige Alerts aus. Kein manuelles Review erforderlich, keine Ausnahmen durch Zeitdruck.

Azure AD: App-Registrierungsrichtlinien technisch sperren Die Möglichkeit, eigenständig App-Registrierungen in Azure AD anzulegen und Graph-API-Berechtigungen zu vergeben, sollte für Standardnutzer technisch deaktiviert sein – nicht nur per Richtlinie, sondern per RBAC-Konfiguration. Nur dedizierte Service-Accounts oder Administratoren mit entsprechender Rolle dürfen neue Agenten-Identitäten registrieren. Ergänzend erzwingen Conditional Access Policies, dass Agenten-Applikationen ausschließlich aus definierten Netzwerkbereichen oder mit verwalteten Identitäten operieren können. Wer diese Kontrolle nicht in der Plattform verankert, verlässt sich darauf, dass niemand auf die Idee kommt – eine schlechte Wette.

Network Egress Kontrolle für Agenten Agenten, die unkontrolliert externe APIs kontaktieren können, sind ein Datenabflussrisiko erster Güte. Agenten werden in isolierten Netzwerksegmenten betrieben, deren ausgehender Traffic über einen kontrollierten Proxy läuft. Zulässige externe Endpunkte werden explizit whitegelistet – alles andere wird technisch geblockt. So wird verhindert, dass ein Agent unbemerkt Unternehmensdaten an nicht genehmigte LLM-Endpunkte übermittelt. Auch hier gilt: Nicht die Policy schützt, sondern die Firewall-Regel.

Anomalieerkennung als kontinuierlicher, automatisierter Prozess Statische Logs reichen nicht. Moderne SIEM-Systeme (Microsoft Sentinel, Splunk, Elastic) werden mit ML-basierten Anomaliedetektionsregeln ausgestattet, die auffällige Agenten-Aktivitäten automatisch eskalieren – etwa ungewöhnlich hohe API-Call-Volumen, Zugriff auf Datenbereiche außerhalb des definierten Scopes oder Aktivitäten zu ungewöhnlichen Zeiten. Governance, die nur im Nachhinein prüft, ist reaktiv. Governance, die in Echtzeit überwacht und automatisch alarmiert, ist präventiv – und schläft nicht.

Automatisierte Compliance-Audits im Regelbetrieb Ergänzend zur laufenden Überwachung prüfen automatisierte Audits – monatlich oder quartalsweise – ob registrierte Agenten noch den definierten Richtlinien entsprechen: Sind die Berechtigungen noch minimal? Ist der verantwortliche Owner noch im Unternehmen? Läuft der Agent auf einem aktuellen, gepatchten Framework? Diese Checks lassen sich mit Infrastructure-as-Code-Tools und Scripting weitgehend automatisieren und erzeugen einen revisionssicheren Nachweis für interne Audits und Datenschutzbehörden – ohne dass ein Mensch daran erinnert werden muss, sie durchzuführen.

Fazit: Wer jetzt nicht handelt, holt später auf – unter Druck

Agentic AI ist keine ferne Technologie. Sie ist in Microsoft 365 Copilot, in GitHub Copilot Workspace, in Salesforce Agentforce und in hunderten Open-Source-Frameworks bereits Realität. Mitarbeitende experimentieren – und das ist gut so.

Die Frage ist nicht, ob Agenten in Ihr Unternehmen kommen. Die Frage ist, ob sie geordnet kommen.

Governance, die zu spät kommt, reagiert auf Vorfälle. Governance, die rechtzeitig kommt, verhindert sie – und schafft gleichzeitig den Vertrauensrahmen, in dem Innovation erst richtig Fahrt aufnehmen kann.

Und Governance, die nur auf Papier existiert, ist keine Governance. Was nicht technisch überwacht wird, wird nicht eingehalten. Die Unternehmen, die heute einen pragmatischen, technisch verankerten Rahmen etablieren, werden morgen schneller sein – nicht langsamer.

Haben Sie Fragen zu Agentic AI Governance in Ihrer Organisation? Die Herausforderungen sind real – aber lösbar.