Sichere agentische KI im Produktivbetrieb

Repetitiv, aber nicht standardisiert

Große Unternehmen betreiben Postfächer, deren einziger Zweck es ist, Fragen zu beantworten. Bei unserem Kunden senden tausende Lieferanten Rückfragen zu ihren Rechnungen via E-Mail an ein zentrales Buchhaltungspostfach: Ist die Rechnung angekommen? Wann wird sie bezahlt? Warum blieb die Mahnung unbeantwortet? Oder sie teilen eine neue Bankverbindung mit.

Die Antwort benötigt interne Informationen und Prozesswissen. Ein typischer Fall: Ein Lieferant schreibt, seine Rechnung sei fällig, aber nicht bezahlt. Die Buchhaltung sucht zunächst die Rechnungsreferenzen im Mailtext, im Betreff oder in den Anhängen, häufig Screenshots, PDF- oder Excel-Dateien. Anschließend ermittelt sie im führenden System den Status der Rechnung und den Grund für die ausstehende Zahlung und teilt beides dem Lieferanten mit.

Die Arbeit ist repetitiv, aber kann nicht auf feste Regeln reduziert werden. Referenzen kommen fehlerhaft formatiert oder mit führenden Nullen an, eine einzelne Mail kann hunderte Referenzen enthalten und Fragen werden in verschiedenen Sprachen gestellt.

Es liegt nahe, Lieferanten auf ein Portal zu verlagern, in dem sie den Status ihrer Rechnungen selbst prüfen können. Bei tausenden Lieferanten, viele davon ohne eigene Systemanbindung, wäre der Wechsel jedoch aufwändig und für die meisten ist E-Mail-Kommunikation der präferierte Weg, Fragen zu klären.

Warum funktionsfähige Prototypen selten live gehen

Neben der offenen Frage, wie sich die Lösung technisch umsetzen lässt, veränderte die Entscheidung für ein agentisches System das Risikoprofil. Drei Sicherheitsfragen mussten geklärt werden.

Erstens: Der Agent verarbeitet Inhalte, die Personen außerhalb des Unternehmens verfasst haben. Lieferantenmails und ihre Anhänge bieten eine Angriffsfläche für Prompt Injection: In der Mail oder deren Anhängen versteckte Anweisungen werden vom Large Language Model genau so gelesen wie auch die daneben stehende Rechnungsnummer.

Zweitens: Der Agent benötigt lesenden Zugriff auf Lieferantendaten, um die Aufgabe bearbeiten zu können. Es muss unmöglich sein, dass Informationen über Lieferant A an Lieferant B gesendet werden können, sei es versehentlich oder durch eine gezielt manipulierte Anfrage.

Drittens: Identitätsprüfung und Autorisierung sind im Falle von E-Mail-Verkehr nicht trivial. Damit der Agent nicht nur antworten, sondern auch Daten in produktiven Systemen anlegen und ändern darf, wurde ein robuster Mechanismus benötigt, der den Absender authentifiziert und Berechtigungen verifiziert.

Hinzu kam der Bedarf der Fachbereiche: Ein User Interface, um Aktionen des Agenten zu prüfen, bei Bedarf einzugreifen und Kennzahlen zu Qualität und Leistung einzusehen.

Ohne eine geeignete Lösung, die diese Fragen adressiert, konnte der Prototyp nicht produktiv geschaltet werden.

Zudem wurde ein verlässliches System benötigt, das die Entscheidungen des Agenten beobachtet und bewertet, um unzureichende Ergebnisse für eine menschliche Prüfung zu eskalieren.

Ein System Prompt ist kein Kontrollmechanismus. Der System Prompt und die manipulierte Lieferantenmail stehen im selben Kontext. Wer versucht, einen Agenten in natürlicher Sprache zu programmieren, macht etwas falsch.

Cornelius HöfigExpert IT Architect

Garantie vor Autonomie

Je autonomer ein agentisches System ist, desto größer der mögliche Schaden. mmkdigital hat daher zunächst die folgenden Systemgarantien festgelegt:

• Sicherheitsprüfungen werden nicht vom Agenten ausgeführt oder angestoßen. Sie werden vom Harness erzwungen und sind deterministisch.
• Der Agent kann nur auf Daten zugreifen, die mit dem Lieferanten verknüpft sind. Antworten werden ausschließlich vom Harness an E-Mail-Adressen versendet, die dem Lieferanten zugeordnet sind.
• Der Agent arbeitet je Aufruf in einer isolierten Sandbox. Zwischen Eingang einer Mail und dem Versand der Antwort gibt es keinen Weg, auf dem Daten das Unternehmen verlassen können.

Sicherheitsrelevantes Verhalten wird durch deterministischen Code außerhalb des Modells erzwungen. Die Garantien sind damit eine Eigenschaft des Systems und hängen nicht vom Verhalten des Modells ab. Aussagen über das erwartete Verhalten des Agenten sind durch ein umfangreiches automatisiertes Testset mit Auswertungen belegt und müssen vor einem Rollout in das Produktivsystem bestanden werden. Die Infrastruktur nutzt vom Kunden freigegebene Cloud Building Blocks, sodass das Security Review auf einer akzeptierten Basis aufsetzt. Das System wurde modular konzipiert und so aufgebaut, dass es auf weitere Anwendungsfälle ausgeweitet werden kann.

Während der Hypercare-Phase nach dem Go-live prüft eine Person die Antworten vor dem Versand sowie bei Bedarf auch die Aktionen der Agenten. Im finalen Betriebsmodell ist eine menschliche Prüfung nur in Ausnahmefällen erforderlich.

Eine menschliche Freigabe ist in der Hypercare-Phase die richtige Wahl, bis das System seine Qualität im Live-Betrieb bewiesen hat. Wir messen, wie oft die agentische Qualitätsprüfung mit der Entscheidung des Menschen übereinstimmt. Erreicht diese Quote den vereinbarten Schwellenwert, darf das System vollständig autonom arbeiten.

Efstratios BaxivanelisProfessional IT Architect

Architektur, Cloud Engineering, Delivery

mmkdigital war mit zwei Personen für Lead Solution Architecture, Cloud Architecture und Engineering verantwortlich und arbeitete dabei mit einem Software Engineer, einem Enterprise Architect und mehreren Fachbereichsmitarbeitern auf Kundenseite zusammen. Die Entscheidungen zur Fachlogik traf unser Kunde. Gemeinsam mit dem Fachbereich haben wir den Prozess analysiert, in fachlichen Ablauf und technische Umsetzung gegliedert und für den Einsatz eines Agenten optimiert. Die IT-Architektur, mit der der Agent ihn sicher ausführt, entstand ebenfalls gemeinsam.

Technisch setzt die Lösung auf Amazon Bedrock AgentCore. Eingang, Ablage und Verarbeitung sind voneinander entkoppelt, und jede Nachricht wird unveränderbar archiviert, bevor der Agent sie bearbeitet. Prozesswissen und Arbeitsanweisungen erhält er über Skills, die der verantwortliche Fachbereich pflegt. Sie werden erst zur Laufzeit geladen, und zwar nur die, die der jeweilige Fall braucht. Das hält den Kontext des Agenten schlank: Er arbeitet mit den Anweisungen, die für den Fall relevant sind, statt mit einem umfangreichen Gesamtregelwerk.

Die Sicherheit liegt in einem deterministischen Harness rund um das Modell. Bevor der Agent startet, leitet das Harness aus dem verifizierten Absender ab, auf welche Lieferantendaten zugegriffen werden darf und an wen die Antwort geht. Beides wird in einem Speicherbereich festgeschrieben, den das Modell weder lesen noch ändern kann. Während des Laufs arbeitet der Agent in einer eigenen Sandbox, getrennt von anderen Fällen, und ein Policy Broker prüft jeden Tool- oder MCP-Call vor der Ausführung und jedes Ergebnis vor der Rückgabe. Erlaubt ist nur, was ausdrücklich freigegeben ist. Ein QA-Subagent prüft anschließend den Antwortentwurf und darf ihn bis zu zwei Mal korrigieren, ohne dabei eine Kontrolle aushebeln zu können.

Alles, was wir dem Agenten nicht anvertrauen können, erzwingt Code außerhalb seiner Reichweite. Der Agent entscheidet nicht, auf welche Lieferantendaten er zugreifen darf, er kann den Empfänger einer Antwort weder sehen noch ändern und er entscheidet nicht, ob eine Mail das System verlassen darf. Das legt das Harness fest, bevor das erste Token generiert wird.

Efstratios BaxivanelisProfessional IT Architect

Im Produktivbetrieb mit messbarer Qualität

Der erste Use Case deckt Lieferantenkorrespondenz im Produktivbetrieb ab. Von Kick-off bis Go-live, einschließlich Security Clearance, vergingen drei Monate. Schon bei minimaler Skalierung und allein für diesen Use Case gerechnet ergibt sich ein Business Case in Millionenhöhe über fünf Jahre. Jede weitere Abteilung, die die Lösung übernimmt und anpasst, erhöht diesen Wert.

Fester Bestandteil des Entwicklungsprozesses ist eine Evaluations-Suite mit über hundert Testfällen, die bei jedem Deployment läuft. Sie deckt die verschiedenen Arten von Anfragen ab, die der Agent unterscheiden muss, deutsche und englische Formulierungen, in Anhängen hinterlegte Referenzen sowie eigene Tests für Prompt Injection und die Trennung der Lieferantendaten. Verschlechtert sich das Sicherheitsverhalten oder die Antwortqualität, schlägt die Pipeline fehl und verhindert einen Rollout auf das Produktivsystem.

Ein Live-Dashboard ordnet jeden geprüften Fall einem von sieben Ergebnissen zu, von „unverändert versendet“ über „Fakten von einer Person korrigiert“ bis „korrekt abgelehnt“. Dazu kommen acht KPIs, darunter der Anteil autonom erfolgreich bearbeiteter Fälle, der Anteil unnötig blockierter Fälle und die Kosten pro Fall.

Das Dashboard hat die Hypercare-Phase deutlich transparenter gemacht. Der Business Owner sieht, wie oft ein Entwurf unverändert rausging, wie oft jemand einen Fakt korrigieren musste und wie oft das System eine Anfrage zu Recht abgelehnt hat. Dies schafft übersichtliche und transparente Qualitätsmetriken für die Umstellung auf einen fast vollständig autonomen Betrieb.

Cornelius HöfigExpert IT Architect

Was agentische KI produktionsreif macht

Ausgangspunkt war ein alltägliches Muster, das es in jedem großen Unternehmen gibt: ein Postfach voller Fragen, die sich nur mit einem Blick in interne Systeme beantworten lassen und Mail für Mail von Hand bearbeitet werden. Bei einem internationalen Automobilhersteller mit tausenden Lieferanten im Purchase-to-Pay-Prozess ist dieses Postfach nie leer.

Generative KI macht es möglich, eine adaptive Antwort zu formulieren, und das Harness erlaubt dem Modell, die notwendigen Informationen für die Antwort abzufragen und eine Antwortdatei zu erstellen. Durch Prompt Injection und nicht-deterministisches Verhalten können dieselben Systeme jedoch erhebliche Sicherheitsrisiken mit sich bringen.

mmkdigital hat daher Guardrails festgelegt, um unerwünschte Szenarien ausschließen zu können und die Fähigkeiten des Agenten daran ausgerichtet.

Zudem wurden Evaluationsmechanismen, Observability und Tests implementiert. Erfasste Traces zeigen im Detail, wie der Agent Entscheidungen trifft und ermöglichen gezielte Verbesserungen bei Grenzfällen. Testfälle fangen Regressionen ab, bevor sie das Produktivsystem erreichen. Eine Bewertung per LLM-as-a-Judge erkennt Fehlverhalten im laufenden Betrieb und jeder solche Fall wird zum neuen Testfall für das nächste Deployment.

Das Ergebnis ist ein abgesichertes, wiederverwendbares agentisches System, dessen Verhalten in natürlicher Sprache vom Fachbereich bestimmt wird und das schon mit dem ersten Use Case einen Business Case in Millionenhöhe ermöglicht. In regulierten Unternehmen entscheiden Architektur und Sicherheitsmechanismen darüber, ob der Agent produktionsreif oder ein vielversprechender Prototyp ist.

Ihre Herausforderung,unsere Leidenschaft.

Schildern Sie uns Ausgangslage und Ziel. Gemeinsam konzipieren wir eine geeignete Lösung und setzen sie um.