Autonome KI-Agenten verlassen zunehmend die Phase der Pilotprojekte und rücken in produktive Unternehmensumgebungen. Anders als klassische Chatbots planen sie mehrstufige Aufgaben, rufen Werkzeuge auf und interagieren mit Fachanwendungen. Für IT-Verantwortliche stellt sich damit die Frage, wie solche Systeme sicher in bestehende Netzwerke, Identitätsdienste und Datenflüsse eingebettet werden können, ohne bestehende Kontrollmechanismen zu unterlaufen.
Architektur autonomer KI-Agenten
Ein KI-Agent besteht typischerweise aus drei Bausteinen. Ein Sprachmodell übernimmt die Entscheidungsfindung, ein Speicherlayer hält Kontext und Verlauf, eine Werkzeug-Schnittstelle vermittelt den Zugriff auf externe Systeme. Orchestrierungs-Frameworks wie „LangGraph“, „Microsoft AutoGen“ oder „CrewAI“ modellieren diese Abläufe entweder als Zustandsgraph oder als Rollenverteilung zwischen mehreren spezialisierten Agenten. Für den Werkzeugzugriff hat sich mit dem von Anthropic im November 2024 veröffentlichten Model-Context-Protocol ein offener Standard etabliert, der die Anbindung von Datenquellen, APIs und Diensten vereinheitlicht.
Bei der praktischen Umsetzung greifen viele Unternehmen auf spezialisierte Dienstleister zurück, etwa eine KI Agentur Schweiz, die Erfahrung mit lokalen Datenschutzanforderungen und regionalen Cloud-Anbietern mitbringt. Regionale Nähe zum Umsetzungspartner spielt vor allem dann eine Rolle, wenn Fachdaten die Landesgrenzen nicht verlassen sollen oder wenn Fachabteilungen eng in die Entwicklung eingebunden werden.
Sicherheit und Identitätsmanagement für nicht-menschliche Akteure
KI-Agenten handeln mit Berechtigungen. Sie lesen aus Datenbanken, schreiben in CRM-Systeme, versenden E-Mails oder lösen Zahlungen aus. Damit entsteht eine neue Klasse nicht-menschlicher Identitäten, die verwaltet, rotiert und geprüft werden muss. Die OWASP Top 10 for LLM-Applications benennen als zentrale Risiken unter anderem Prompt-Injection, unsichere Ausgabeverarbeitung, exzessive Handlungsspielräume und die Kompromittierung der Modell-Lieferkette.
In der Praxis bewährt sich das Prinzip der minimalen Rechte. Jeder Agent erhält ein eigenes technisches Konto mit klar begrenztem Scope, kurzlebige Tokens werden über OAuth 2.1 oder Workload-Identitäten nach SPIFFE ausgestellt. Kritische Aktionen wie Buchungen oder Weiterleitungen laufen über eine explizite menschliche Freigabestufe. Eingaben aus nicht vertrauenswürdigen Quellen, etwa aus eingehenden E-Mails, Support-Tickets oder Webseiten, werden grundsätzlich als potenziell schädlich behandelt, da Prompt-Injection zu den am schwersten zu kontrollierenden Angriffsklassen zählt.
Governance, Standards und regulatorischer Rahmen
Der EU-AI-Act trat am 1. August 2024 in Kraft und gilt gestuft. Verbote für bestimmte Praktiken sind seit Februar 2025 anwendbar, Pflichten für Modelle mit allgemeinem Verwendungszweck seit August 2025, die Hauptregelungen für Hochrisikosysteme greifen ab August 2026. Für Unternehmen bedeutet das eine dokumentierte Risikoklassifikation ihrer KI-Anwendungen, Konformitätsbewertungen und eine kontinuierliche Überwachung im Betrieb.
Ergänzend liefert die Norm ISO/IEC 42001:2023 einen Rahmen für ein KI-Managementsystem, strukturell vergleichbar mit der bekannten ISO/IEC 27001 im Bereich Informationssicherheit. Das NIST-AI-Risk-Management-Framework beschreibt die vier Funktionen Govern, Map, Measure und Manage und ist besonders in international tätigen Unternehmen verbreitet. Für Schweizer Organisationen kommt das revidierte Datenschutzgesetz revDSG hinzu, das seit dem 1. September 2023 gilt und Transparenzpflichten sowie Meldepflichten bei Datenschutzverletzungen konkretisiert.
Integration in bestehende IT-Landschaften
Die technische Einbettung folgt meist einem klaren Muster. Agenten kommunizieren über definierte APIs mit den Fachsystemen, ein API-Gateway übernimmt Authentifizierung, Ratenbegrenzung und Protokollierung. Für den Zugriff auf interne Wissensbestände werden Vektordatenbanken angebunden, die mit dokumentenbasierten Berechtigungen verknüpft sind, damit ein Agent nie mehr sieht, als die zugehörige Nutzerrolle sehen dürfte.
Auf der Beobachtungsebene reicht klassisches Application-Monitoring nicht aus. Neben Latenz und Fehlerraten müssen Prompt- und Antwort-Traces, Werkzeugaufrufe, Token-Verbrauch und Halluzinationsindikatoren erfasst werden. Standards wie die „OpenTelemetry GenAI Semantic Conventions“ definieren dafür einheitliche Attribute. Regressionen lassen sich über Evaluationssets prüfen, in denen typische Aufgaben mit erwarteten Ergebnissen hinterlegt sind. Kennzahlen wie Task-Completion-Rate, Tool-Call-Genauigkeit oder mittlere Bearbeitungszeit pro Vorgang schaffen eine belastbare Grundlage für Optimierungen.
Ein oft unterschätzter Punkt ist die Kostenkontrolle. Agenten mit mehreren Denkzyklen und verschachtelten Werkzeugaufrufen verursachen deutlich höhere Token-Kosten als einfache Chat-Anfragen. Gartner rechnet in einer Prognose vom Juni 2025 damit, dass bis Ende 2027 über 40 Prozent der agentischen KI-Projekte wieder eingestellt werden, unter anderem wegen unklarer Geschäftslogik, mangelnder Risikokontrolle oder eskalierender Betriebskosten. Ein sauberes Budget-Management pro Agent, Zwischenspeicher für wiederkehrende Anfragen sowie eine Modellwahl passend zur Aufgabenkomplexität beugen solchen Effekten vor.
Nächste Schritte für IT-Verantwortliche
Vor dem produktiven Rollout eines KI-Agenten empfiehlt sich eine strukturierte Vorbereitung, die technische, organisatorische und rechtliche Aspekte gleichermaßen abdeckt.
Am Anfang steht eine Bestandsaufnahme der relevanten Datenquellen. Jede Quelle wird nach Schutzbedarf klassifiziert, typischerweise in Anlehnung an das BSI-Grundschutz-Modell oder eine unternehmensinterne Klassifikationsrichtlinie. Personenbezogene Daten, Geschäftsgeheimnisse und regulierte Inhalte etwa aus dem Finanz- oder Gesundheitsbereich erhalten eine gesonderte Kennzeichnung, die später in den Berechtigungsfiltern des Agenten wieder auftaucht. Ergänzend werden Datenherkunft, Aktualisierungsfrequenz und Verantwortlichkeiten dokumentiert, damit spätere Audits nachvollziehen können, welche Informationen ein Agent zu welchem Zeitpunkt verarbeitet hat.
Im nächsten Schritt entsteht ein Rollen- und Rechtemodell für technische Identitäten. Jeder Agent, jedes Werkzeug und jede nachgelagerte Automatisierung bekommt ein eigenes Konto mit klar begrenztem Scope, ergänzt um Regeln für Token-Lebensdauer, Rotation und Notfall-Deaktivierung. Bewährt hat sich eine Trennung zwischen Lese-, Schreib- und Ausführungsrechten, sodass ein kompromittierter Leseagent nicht automatisch auch Buchungen auslösen kann.
Parallel dazu wird ein Threat-Model erstellt, das die klassischen Angriffsflächen aus den OWASP-LLM-Risiken auf die konkrete Architektur überträgt. Prompt-Injection über eingehende Dokumente, Werkzeugmissbrauch durch überzogene Berechtigungen, Datenabfluss über generierte Ausgaben und die Kompromittierung von Modell- oder Plugin-Lieferketten gehören dabei zu den wiederkehrenden Prüfpunkten. Für jede identifizierte Bedrohung werden konkrete Gegenmassnahmen und Rückfallebenen definiert.
Ein Evaluationsrahmen mit messbaren Erfolgskriterien schliesst die Vorbereitung ab. Dazu zählen fachliche Kennzahlen wie Task-Completion-Rate, Antwortqualität nach Fachbewertung, Halluzinationsrate in Stichproben sowie Betriebskennzahlen wie Latenz, Token-Kosten pro Vorgang und Verfügbarkeit. Zusätzlich empfiehlt sich ein Regressionsdatensatz aus realen Anfragen, gegen den jede neue Modellversion vor dem Ausrollen automatisch geprüft wird.
Wer diese Schritte vor der Auswahl eines Frameworks oder eines externen Umsetzungspartners geht, reduziert die Wahrscheinlichkeit späterer Kurskorrekturen und schafft die Basis für einen belastbaren produktiven Betrieb.
