Der gefährlichste AI-Act-Fehler ist nicht ein schlechter Prompt, sondern ein Agent, der nichts beweisen kann.
Viele Teams diskutieren gerade Modellwahl, Halluzinationen und Kosten. Alles wichtig. Aber wenn ein Agent später Entscheidungen vorbereitet, Nutzer beeinflusst oder Daten verarbeitet, wird eine andere Frage unangenehm: Kannst du erklären, was passiert ist?
Nicht ungefähr. Nicht aus dem Bauch heraus. Sondern mit einem Audit-Trail, der zeigt: Eingabe, Kontext, Modell, Tool-Aufruf, Ausgabe, Nutzeraktion, Löschung.
Das ist trocken. Und genau deshalb wird es zum Wettbewerbsvorteil.
Warum Logging jetzt Thema wird
Der EU AI Act läuft nicht an einem einzigen Tag los. Laut offizieller EU-Timeline gelten seit Februar 2025 bereits Regeln zu verbotenen Praktiken und AI Literacy. Seit August 2025 greifen Governance- und GPAI-Pflichten. Am 2. August 2026 sollen die meisten Regeln in Anwendung kommen, inklusive Transparenzpflichten nach Artikel 50 und Regeln für Hochrisiko-Systeme nach Annex III. Die EU-Kommission weist zusätzlich darauf hin, dass es im Rahmen des Digital-Omnibus-Pakets Vorschläge zur Anpassung einzelner Fristen gibt.
Heißt praktisch: Wer AI Agents in Europa baut, sollte nicht auf den letzten finalen Guidance-Text warten. Denn Logging ist kein PDF, das du am Abend vor der Prüfung schreibst. Logging ist Architektur.
AgentYard beobachtet genau diesen Shift: Der Markt redet über autonome Agents, aber Entscheider fragen immer öfter nach Nachvollziehbarkeit. Besonders bei Finance, HR, Education und Productivity-Agents.
Das kontraintuitive Insight: Mehr Logs, weniger Risiko — aber nicht mehr Daten
Viele verwechseln Audit-Trails mit Datensammeln. Das ist falsch.
Gutes AI-Logging speichert nicht möglichst viel. Es speichert die richtigen Ereignisse in einer Form, die später überprüfbar ist. Der Unterschied ist entscheidend, weil DSGVO und AI Act nicht gegeneinander ausgespielt werden dürfen.
Ein schlechter Log enthält komplette Prompts mit personenbezogenen Daten, rohe Dokumente und Nutzertexte für immer.
Ein guter Log enthält Hashes, IDs, Zeitpunkte, Modellversionen, Tool-Namen, Risikoklassen, Statuscodes und Löschreferenzen. Personenbezogene Inhalte werden minimiert, pseudonymisiert oder getrennt gespeichert.
Das Ziel ist nicht Überwachung. Das Ziel ist Rechenschaft.
Welche Agent-Events du loggen solltest
Für einen typischen AI Agent reichen am Anfang sieben Event-Typen. Mehr ist oft nur Rauschen.
| Event | Warum es zählt | Beispiel |
|---|---|---|
| agent.created | Wer hat den Agent gebaut? | Creator-ID, Agent-ID, Risikoklasse |
| agent.updated | Was hat sich geändert? | Prompt-Version, Modellwechsel |
| conversation.started | Nutzung beginnt | Nutzer-ID-Hash, Locale, Agent-Version |
| model.called | Reproduzierbarkeit | Provider, Modell, Temperatur, Token |
| tool.called | Externe Wirkung | Tool-Name, Zweck, Erfolg/Fehler |
| output.delivered | Transparenz | Antwort-ID, Disclosure angezeigt? |
| data.deleted | DSGVO-Nachweis | Lösch-ID, Scope, Zeitpunkt |
Damit kannst du viele spätere Fragen beantworten: War der Nutzer informiert? Welches Modell war aktiv? Hat der Agent externe Tools genutzt? Wurde eine Löschung wirklich ausgeführt?
Ein einfaches JSON-Schema für Audit-Trails
Du brauchst dafür keinen Enterprise-GRC-Stack. Starte mit einem stabilen Event-Schema. Wichtig ist, dass jedes Event append-only geschrieben wird und keine sensiblen Rohdaten erzwingt.
{
"event_id": "evt_01HZX...",
"timestamp": "2026-05-06T07:00:00Z",
"event_type": "model.called",
"actor": {
"type": "user",
"id_hash": "sha256:8f2..."
},
"agent": {
"id": "agent_budget_scout",
"version": "2026-05-06.1",
"risk_tier": "limited"
},
"model": {
"provider": "openai",
"name": "gpt-4o-mini",
"parameters_hash": "sha256:91a..."
},
"context": {
"input_hash": "sha256:a33...",
"knowledge_refs": ["kb_2026_04_finance_csv_template"],
"contains_personal_data": true
},
"result": {
"status": "success",
"output_hash": "sha256:f19...",
"disclosure_shown": true
}
}
Das Schema ist absichtlich langweilig. Gute Compliance-Systeme sind selten elegant. Sie sind konsistent.
Was FRIA für Agent-Builder bedeutet
FRIA steht für Fundamental Rights Impact Assessment. Nach Artikel 27 betrifft das nicht jeden kleinen Chatbot, sondern bestimmte Hochrisiko-Nutzungen und bestimmte Betreiber, etwa öffentliche Stellen oder Anbieter öffentlicher Dienste. Trotzdem ist FRIA als Denkmodell nützlich.
Wenn dein Agent in HR, Bildung, Kreditwürdigkeit, Zugang zu Leistungen oder ähnlichen Bereichen arbeitet, solltest du früh prüfen:
- Welche Entscheidung beeinflusst der Agent?
- Wer ist betroffen?
- Kann ein Mensch das Ergebnis sinnvoll überprüfen?
- Welche Fehler wären real schädlich?
- Wie kann ein Nutzer widersprechen oder Daten löschen lassen?
Diese Fragen sind nicht nur juristisch. Sie verbessern Produktdesign. Ein Agent, der keinen Einspruchspfad hat, ist auch aus UX-Sicht schwach.
Transparenz ist ein Produktfeature
Artikel 50 macht Transparenz für bestimmte AI-Interaktionen relevant. Für Agent-Builder heißt das: Nutzer sollten wissen, dass sie mit KI interagieren, wann Inhalte synthetisch erzeugt wurden und wann ein Agent externe Aktionen anstößt.
Das muss nicht hässlich sein. Ein kurzer Hinweis reicht oft:
“Dieser Agent nutzt KI, kann Fehler machen und führt keine externen Aktionen ohne Bestätigung aus.
Noch besser ist kontextuelle Transparenz. Wenn ein Agent nur Text zusammenfasst, braucht der Nutzer weniger Warnung als bei einem Agent, der Bewerbungen bewertet oder Budgetentscheidungen empfiehlt.
Auf dem AgentYard Marketplace ist genau diese klare Einordnung wichtig: Creator sollen Agents bauen, die verkauft werden können, ohne dass Käufer später Compliance-Risiken entdecken. Wer selbst loslegen will, startet über AgentYard Creator und sollte Logging von Anfang an mitdenken.
Minimal-Checkliste für deinen nächsten Agent
Bevor du einen Agent veröffentlichst, prüfe diese Punkte:
- Hat der Agent eine klare Zweckbeschreibung?
- Ist die Risikoklasse dokumentiert?
- Wird angezeigt, dass KI genutzt wird?
- Werden Modell- und Prompt-Versionen gespeichert?
- Sind Tool-Aufrufe nachvollziehbar?
- Werden personenbezogene Inhalte minimiert?
- Gibt es einen Lösch- oder Exportpfad?
- Kann ein Mensch kritische Ausgaben prüfen?
Wenn du nur einen Punkt heute umsetzt, nimm Prompt-Versionierung. Ohne Versionen kannst du nie sicher sagen, welche Regeln zum Zeitpunkt einer Antwort galten.
Fazit: Compliance gewinnt nicht durch PDFs
AI-Act-Readiness entsteht nicht in einem Notion-Dokument. Sie entsteht in jedem Event, das dein Agent sauber schreibt.
Der Markt bewegt sich Richtung Managed Agents, Multi-Model-Plattformen und Creator-Monetarisierung. Gleichzeitig steigt die Erwartung an Transparenz. Das ist keine Bremse. Es ist eine Chance für europäische Anbieter.
AgentYard setzt deshalb auf EU-first, offene Modellwahl und nachvollziehbare Agent-Strukturen statt Blackbox-Automation. Nicht weil Compliance sexy ist. Sondern weil Agents, die Geld verdienen sollen, Vertrauen brauchen.
Wenn du deinen nächsten Agent baust, frag nicht nur: Was kann er automatisieren?
Frag: Was kann er später beweisen?
Weiterlesen: Unser EU AI Act Fristen-Update 2026 und der Guide Was AI Agent Entwickler ab 2026 beachten müssen. Quellen: EU AI Act Service Desk Timeline und EU AI Act FAQ.