Die meisten KI-Assistenten bleiben untätig, bis Sie etwas fragen. Sie tippen eine Frage, erhalten eine Antwort, dann wartet der Assistent. Bei Handels-Compliance hat dieses Modell ein grundlegendes Problem: Risiken warten nicht, bis jemand nach ihnen fragt.
Bei Atlas Verified entwickelten wir autonome Cloud-Agenten, die Lieferketten kontinuierlich überwachen, behördliche Datenbanken prüfen und Compliance-Risiken nach Zeitplan aufzeigen – ohne Eingabe eines Prompts. Sie laufen im Hintergrund für jede Organisation auf unserer Plattform und liefern strukturierte Informationen direkt in ein Dashboard.
Dieser Beitrag behandelt die Technik ständig aktiver KI-Agenten: Unterschiede zu dialogorientierter KI, Bedeutung strukturierter Ausgabe und Herausforderungen der Orchestrierung autonomer Agenten im großen Maßstab.
Von reaktiv zu proaktiv
Dialogorientierte KI ist grundsätzlich reaktiv. Ein Nutzer fragt, das Modell denkt nach, ruft Werkzeuge auf und antwortet. Das eignet sich für spontane Recherche und Dokumentenanalyse. Compliance-Überwachung verlangt jedoch proaktive Informationen.
Ein Szenario: Das USDA setzt über Nacht die Bio-Zertifizierung eines Lieferanten aus. Eine seiner Sendungen ist bereits unterwegs. Eine neue OFAC-Einstufung setzt einen Spediteur auf die Sanktionsliste. Eine FDA-Importwarnung wird für einen aktiv importierten Rohstoff veröffentlicht.
Keines dieser Ereignisse wartet darauf, dass ein Compliance-Verantwortlicher sich anmeldet und die richtige Frage stellt. Bis jemand an die Prüfung denkt, kann das Zeitfenster für proaktives Handeln geschlossen sein. Die Ware ist im Hafen. Die Unterlagen sind eingereicht. Das Risiko ist real.
Cloud-Agenten lösen das durch Umkehr der Beziehung. Statt dass Nutzer die KI steuern, steuert sie sich nach Zeitplan selbst, prüft alles Relevante und sendet Erkenntnisse an Nutzer.
Architektur mit einem Agenten je Quadrant
Bei den ersten Prototypen nutzten wir einen einzigen Cloud-Agenten für alles: regulatorische Änderungen, Lieferantenstatus, Sendungsverfolgung und Dokumentenverarbeitung. Er erzeugte unfokussierte, ausschweifende Ausgabe, verfolgte einen interessanten Ansatz und vernachlässigte ganze Informationskategorien.
Die Lösung war die Aufteilung des Problems in gezielte Bereiche, die wir Quadranten nennen:
Informationen. Regulatorische Warnungen, Markttrends und bereichsübergreifende Risiken. Dieser Agent überwacht behördliche Datenbanken auf organisationsrelevante Änderungen – neue FDA-Importwarnungen, OFAC-Listenaktualisierungen, Zolländerungen und Bio-Zertifizierungsstatusänderungen.
Lieferanten. Zustand des Lieferantennetzwerks. Dieser Agent prüft Verifizierungsstatus, Compliance-Lücken, Zertifizierungsabläufe und Konzentrationsrisiken. Stammen 80% Ihres Bioangebots von einer einzigen Zertifizierungsstelle, kennzeichnet er dies.
Sendungen. Überwachung aktiver Sendungen. Dieser Agent verfolgt Schiffspositionen, Routenabweichungen und Verzögerungen und validiert die Vollständigkeit der Dokumentation. Er zeigt etwa länger als erwartet im Hafen stehende Container oder von angegebenen Routen abweichende Schiffe auf.
Arbeitsbereich. Betrieblicher Zustand. Dieser Agent prüft Dokumentenverarbeitungsstatus, ausstehende Verifizierungen, Teamaktivität und Plattformnutzungsmuster. Er zeigt etwa fehlgeschlagene Dokumentenverarbeitung mit Handlungsbedarf oder zu lange ausstehende Verifizierungen auf.
Jeder Agent läuft mit einem fokussierten Systemprompt und begrenzten bereichsrelevanten Werkzeugen. Das erzeugt deutlich bessere Ausgabe als ein allwissender Agent – aus demselben Grund, aus dem Spezialistenteams einen Generalisten übertreffen: tiefer Fokus.
Gemeinsame Werkzeugschicht mit dem Chat-Agenten
Eine der wichtigsten Architekturentscheidungen war, Cloud-Agenten exakt dieselbe Werkzeugschicht wie unserem dialogorientierten Chat-Agenten zu geben. Dieselben OFAC-Prüfungen, USDA-Abfragen, Schiffsverfolgung, Handelsdatenabfragen und Dokumentenanalysen unterstützen beide Systeme.
Das bietet erhebliche technische Vorteile:
Keine Werkzeugduplikate. Eine neue Datenquelle oder Verbesserung eines Adapters kommt Chat- und Cloud-Agenten sofort zugute. Eine Implementierung, ein Testsatz, eine Wartungsfläche.
Einheitliche Ergebnisse. Eine Sanktionsprüfung durch einen Cloud-Agenten und eine Nutzerprüfung im Chat rufen dieselbe Funktion mit derselben Logik auf. Ergebnisse sind direkt vergleichbar und abgleichbar.
Die Herausforderung: Für interaktive Nutzung entwickelte Werkzeuge funktionieren im Stapelkontext nicht immer gleich. Ein Chat-Agent kann bei mehrdeutiger Abfrage nachfragen. Ein Cloud-Agent nicht. Wir geben Cloud-Agenten deshalb konkretere Prompts und höhere Rekursionsgrenzen – sie haben mehr Zeit zur Selbstkorrektur, weil niemand in Echtzeit wartet.
Strukturierte Ausgabe: Von Freitext zu Dashboard-Karten
Hier unterscheiden sich Cloud- und Chat-Agenten am deutlichsten. Ein Chat-Agent erzeugt erläuternden Text, manchmal mit eingebetteten Karten. Ein Cloud-Agent muss ausschließlich strukturierte Ausgabe liefern, die direkt im Dashboard dargestellt wird.
Jeder Agentenlauf erzeugt ein Array von Informationskarten. Jede Karte hat einen definierten Typ und ein Schema:
Zähler zeigen Kennzahlen mit Trendindikatoren – aktive Sendungen, Lieferanten mit ablaufenden Zertifizierungen, ausstehende Verifizierungen.
Risikowarnungen heben konkrete Compliance-Bedenken hervor – ausgesetzte Lieferantenzertifizierung, Sanktionstreffer, FDA-Importwarnung.
Warnmeldungen vermitteln zeitkritische Informationen – regulatorische Änderungen, neue OFAC-Einstufungen, Zollaktualisierungen für aktive Sendungen.
Diagramme und Tabellen zeigen Analysedaten – Sendungsmengentrends, Handelsroutenverteilung, Verifizierungsabschlussquoten.
Karten zeigen geografische Informationen – Schiffspositionen, Hafenaktivitäten, Lieferantenverteilung.
Die technische Herausforderung ist, ein LLM konsequent auf gültige strukturierte Ausgabe zu begrenzen. Sprachmodelle wollen erzählen, erklären und einschränken. Ein sauberes JSON-Array von Karten mit richtigen Typen, Feldern und Daten erfordert sorgfältige Promptgestaltung und Ausgabevalidierung.
Passt die Ausgabe nicht zum erwarteten Kartenschema, verarbeiten wir das Verwertbare und verwerfen fehlerhafte Karten, statt den gesamten Lauf scheitern zu lassen. Teilweise Informationen sind besser als keine.
Individuelle Agenten: Nutzerdefinierte autonome Überwachung
Neben vier Systemagenten können Nutzer eigene Cloud-Agenten erstellen. Ein individueller Agent hat einen Namen, einen nutzergeschriebenen Systemprompt und einen Zeitplan. Er nutzt dieselbe Werkzeugschicht und Kartentypen, doch sein Schwerpunkt ist vollständig nutzerdefiniert.
Ein Nutzer könnte einen Agenten zur Störungsüberwachung einer Handelsroute erstellen, einen zum täglichen Sanktionsabgleich bestimmter Lieferanten oder einen zur Preisverfolgung eines Rohstoffs anhand von Handelsdatenquellen. Möglichkeiten sind nur durch den Datenzugriff der Werkzeugschicht begrenzt.
Für sichere und nützliche Umsetzung waren mehrere technische Entscheidungen nötig:
Organisationsabgrenzung. Jeder individuelle Agent gehört einer Organisation und darf nur auf deren Daten zugreifen. Er kann Organisationsgrenzen nicht überschreiten, selbst wenn der Nutzerprompt es versucht.
Filterung von Werkzeugfähigkeiten. Individuelle Agenten haben dieselben Verifizierungs- und Recherchewerkzeuge wie Systemagenten, übernehmen aber die Berechtigungsgrenzen der Organisation. Sie dürfen keine Werkzeuge oder Daten nutzen, auf die der Nutzer selbst im Chat keinen Zugriff hätte.
Zeitplanverwaltung. Individuelle Agenten laufen nach Nutzerzeitplänen innerhalb der Plattformgrenzen. So kann eine Organisation nicht durch Dutzende stündliche Agenten unverhältnismäßig viele Rechenressourcen verbrauchen.
Orchestrierung im großen Maßstab
Täglich geplante autonome Agenten über viele Organisationen hinweg bringen Herausforderungen, die in einem Chatsystem nicht existieren.
Duplikatvermeidung. Startet der Zeitplaner und ein Agent für Organisation A lief bereits im Duplikatvermeidungsfenster, wird er übersprungen. Das verhindert Doppelläufe durch Wiederholungen, überlappende Zeitpläne oder Störungen. Jedes Agent-Organisation-Paar gilt als eigene Planungseinheit.
Fehlerisolierung. Scheitert ein Organisationsagent – wegen Werkzeugfehler, nicht verarbeitbarer LLM-Ausgabe oder ausgefallenem Dienst –, darf das andere Organisationen nicht beeinflussen. Jeder Lauf ist ein unabhängiger Auftrag. Fehler werden protokolliert, der Lauf als fehlgeschlagen markiert und die Planung fortgesetzt.
Kartenlebenszyklus. Informationskarten haben eine Gültigkeitsdauer. Alte Karten laufen ab und werden beim nächsten Agentenlauf ersetzt. So zeigt das Dashboard aktuelle Informationen statt angesammelter veralteter Ergebnisse. Neue Karten ersetzen die bisherigen Karten des Quadranten atomar.
Ressourcenbudgetierung. Agentenläufe verbrauchen LLM-Tokens, externe API-Aufrufe und Datenbankverbindungen. Wir verfolgen Tokenverbrauch je Lauf und Organisation zur Kostensteuerung und Erkennung unverhältnismäßigen Verbrauchs. Ein ausufernder Agent mit 50 Aufrufen statt ausreichender 10 wird gekennzeichnet.
Cloud-Agenten und Chat verbinden
Cloud-Agenten und Chat-Agent sind keine isolierten Systeme. Sie bilden eine Rückkopplung.
Der Chat-Agent kann Cloud-Agent-Ausgaben abfragen. Fragt ein Nutzer „Was haben meine Agenten gefunden?“ oder „Gibt es Compliance-Risiken, die ich kennen sollte?“, ruft er die neuesten Informationskarten ab und stellt sie im Dialog dar. Er kann Warnungen erklären, Kontext ergänzen oder bei Maßnahmen helfen.
So entsteht ein natürlicher Ablauf: Cloud-Agenten zeigen über Nacht Probleme auf, der Nutzer prüft morgens das Dashboard und öffnet bei Vertiefungsbedarf einen Chat. Der Chat-Agent kennt die Ergebnisse bereits und kann dort weiterarbeiten.
Auch die Gegenrichtung funktioniert: Muster aus Nutzerchats beeinflussen die Anpassung von Cloud-Agent-Prompts. Fragen Nutzer häufig nach einem bislang nicht aufgezeigten Risiko, ist das ein Signal zur Schwerpunktanpassung.
Was wir gelernt haben
Die Entwicklung autonomer KI-Agenten lehrte uns Dinge, die beim Aufbau dialogorientierter Agenten nicht offensichtlich sind:
Strukturierte Ausgabe ist schwieriger als Freitext. Ein LLM konsequent zu gültigem, schemakonformem JSON zu bringen, ist eine deutlich andere Herausforderung als ein guter Absatz. Modelle wollen erklären; diese analytische Energie muss in strukturierte Felder gelenkt werden.
Der Umfang entscheidet. Ein fokussierter Agent mit klarem Bereich liefert bessere Informationen als ein breiter Agent mit Zugriff auf alles. Ein Agent je Quadrant war unsere größte Qualitätsverbesserung.
Teilergebnisse sind besser als fehlgeschlagene Läufe. In einem Stapelsystem können Sie Nutzer bei Problemen nicht fragen. Kontrollierter Weiterbetrieb – mögliche Karten erzeugen und Lücken benennen – ist unerlässlich.
Nutzer wollen Kontrolle. Individuelle Agenten gehörten zu den meistgewünschten Funktionen. Compliance-Experten kennen ihre Risiken besser als jedes allgemeine System. Autonome Überwachung in natürlicher Sprache programmieren zu können, eröffnete erheblichen Mehrwert.
Rückkopplung ist wichtig. Cloud- und Chat-Agenten sind gemeinsam wertvoller als einzeln. Proaktive Informationen setzen die Agenda; dialogorientierte KI liefert die Tiefe. Die frühzeitige Gestaltung dieses bidirektionalen Flusses verbesserte beide Systeme.
Ausblick
Cloud-Agenten verändern grundlegend unser Verständnis von KI in Compliance. Die Frage lautet nicht „Was kann die KI auf Anfrage beantworten?“, sondern „Was sollte sie ohne Aufforderung prüfen?“
Mit zusätzlichen Datenquellen und komplexerer Regulierung steigt der Wert autonomer Überwachung. Der Tag eines Compliance-Experten sollte nicht mit manuellen Prüfungen von sechs behördlichen Datenbanken und drei Verfolgungsdiensten beginnen. Er sollte mit einem Dashboard beginnen, das genau zeigt, was sich über Nacht geändert hat und Aufmerksamkeit benötigt.
Das liefern Cloud-Agenten. Zuverlässige, skalierbare und nützliche Umsetzung ist eine der lohnendsten technischen Herausforderungen unserer Arbeit.
Die Cloud-Agenten von Atlas Verified überwachen Lieferketten autonom, prüfen behördliche Datenbanken und zeigen Compliance-Risiken auf – damit Experten sich auf Entscheidungen statt Datensammlung konzentrieren.