Warum Agentenprotokolle Artikel 12 nicht erfüllen: Entscheidungsprotokolle, Kausalität und Herkunft
Agentenprotokolle erfüllen nicht Artikel 12 des EU-KI-Gesetzes. Protokollieren Sie Entscheidungen von KI-Agenten als dauerhafte Objekte mit kausalen Verbindungen, hash-basiertem Ursprungsverlauf und festgelegten Regeln.
Im August 2026 trat eine Vorschrift in vollem Umfang in Kraft, die die meisten Ingenieurteams noch nicht zu spüren bekommen haben. Artikel 12 des EU-KI-Gesetzes besagt, dass hochriskante KI-Systeme technisch eine automatische Aufzeichnung von Ereignissen während ihrer gesamten Lebensdauer ermöglichen müssen, wobei die Nachvollziehbarkeit dem Zweck des Systems angemessen sein muss. Artikel 26 legt dem Betreiber eine entsprechende Pflicht auf: Er muss diese Protokolle mindestens sechs Monate lang aufbewahren, länger, wenn andere Gesetze dies erfordern.
Ein Ingenieur, der den Text liest, bemerkt ein seltsames Ungleichgewicht. Das Ziel wird präzise formuliert, während das erforderliche Format kaum erwähnt wird. Das Ziel besteht darin, nachträglich eine einzelne Entscheidung rekonstruieren zu können. Ein APM-Produkt bietet dies nicht, da es für etwas anderes entwickelt wurde. Auch ein Vektorlager bietet dies nicht.
Der Zeitpunkt ist unglücklich gewählt, denn die Mitarbeiter haben gerade aufgehört, Fragen zu beantworten, und beginnen nun zu handeln. Sie genehmigen Ausgaben, passen die Infrastruktur an, bearbeiten Versicherungsansprüche, lehnen Bewerber ab und geben Freigaben. Jede dieser Handlungen ist eine Entscheidung, für die jemand letztendlich eine Begründung von dem Unternehmen verlangen könnte, und in den meisten Organisationen heute wäre die ehrliche Antwort, dass dieses dies nicht kann.
Ein Kleinstrechtsfall, der das Problem vorwegnahm
Noch bevor die Vorschrift existierte und die Mitarbeiter handeln konnten, prüfte ein Gericht in British Columbia diese Schwäche in kleinem Maßstab. Er bleibt das klarste verfügbare Beispiel.
Jakes Moffatts Großmutter starb im November 2022. Am selben Tag besuchte er die Website von Air Canada, um einen Flug nach Toronto zu buchen, und da er sich nicht sicher war, wie die Tarife für Trauerfälle funktionierten, fragte er den Chatbot der Fluggesellschaft. Der Bot sagte, er könne sofort ein Ticket zum vollen Preis kaufen und innerhalb von 90 Tagen rückwirkend einen vergünstigten Tarif für Trauerfälle beantragen. Bevor er darauf vertraute, tat Moffatt etwas Vernünftiges und machte ein Screenshot der Antwort. Anschließend buchte er, flog, nahm an der Beerdigung teil und reichte seinen Antrag ein.
Air Canada lehnte ab. Es gab keine solche Richtlinie, und der Bot hatte sie erfunden.
Der Folgeteil ist der lehrreiche Teil. Vor dem Civil Resolution Tribunal argumentierte die Fluggesellschaft, sie könne nicht für das Verhalten ihres Chatbots verantwortlich gemacht werden, und bezeichnete den Bot als eigenständige Einheit, die für ihre eigenen Handlungen verantwortlich sei. Der Tribunal-Mitglied Christopher Rivers bezeichnete dieses Argument als bemerkenswert und stellte fest, dass die Fluggesellschaft nie erklärt habe, warum jemand es akzeptieren sollte. Ein Chatbot ist Teil einer Website, und ein Unternehmen ist für seine Website verantwortlich. Air Canada zahlte 812,02 CAD.
Diese Summe ist unbedeutend. Die entscheidende Zahl ist null – die Anzahl der Unterlagen, die Air Canada vorlegen konnte, um zu zeigen, warum ihr eigenes System genau das gesagt hat. Das einzige dauerhafte Beweismittel in der gesamten Anhörung war das Screenshot des Kunden.
Derselbe Fehler hat sich seither weiter verschlimmert. Im April 2025 entwickelte ein Support-Bot bei Cursor eine Richtlinie, die Abonnements auf ein einziges Gerät beschränkte. Kunden begannen, ihre Abonnements zu kündigen, und das Unternehmen erfuhr davon erst, weil ein Mitbegründer den entsprechenden Thread auf Reddit entdeckte. Das Muster ist identisch, der Einflussbereich größer und das Tempo schneller – und es war kein Schiedsgericht nötig.
Stellen Sie sich nun dieselbe mangelhafte Beweislage vor, die einem Regulierungsbehörden vorgelegt wird und mit einem Agenten verbunden ist, der Geld bewegt.
Debugging und Rechenschaftspflicht sind unterschiedliche Aufgaben
Die meisten Technologiestrukturen ziehen hier nie eine bedeutende Unterscheidung.
Observability ist auf die Ausführung ausgerichtet. Sie erfasst, was ein Prozess während eines Laufs getan hat: Zeitintervalle, Toolaufrufe, Tokenzahlen, Wiederholungsversuche und Latenzzeiten. Sie wird stichprobenartig erhoben, nach einer bestimmten Aufbewahrungszeit ungültig und auf eine Anfrage beschränkt. Das ist genau das Richtige, um an einem Dienstag einen Fehler aufzuspüren.
Die Rechenschaftspflicht ist domänenzentriert. Sie dokumentiert, zu welchen Schlussfolgerungen die Organisation gelangt ist, auf welchen Beweisen, nach welcher Richtlinie und was danach geschah. Sie muss Migrationen von Frameworks, Außerdienststellung von Modellen, Neubau von Indizes, Umstrukturierungen sowie den Weggang von zwei Kollegen überstehen.
Anderswo in einem Unternehmen ist das Routine. Eine Produktivitätsänderung wird niemals aus Anwendungsprotokollen neu erstellt, da ein Änderungsprotokoll einen Autor, eine Ticket-Nummer und eine Freigabe enthält. Eine finanzielle Situation wird niemals aus HTTP-Spuren neu erstellt, da Buchungseinträge vorhanden sind. Bestellungen, Zahlungen, Freigaben und Bereitstellungen sind dauerhafte Objekte, von denen jedes ein Lebenszyklus, einen Eigentümer und eine Aufbewahrungsregel hat.
Die Entscheidungen von Agenten sind die einzige Art von bedeutungsvollem Ereignis, das weiterhin als unstrukturierte Ausgabe ohne feste Struktur bleibt – im Glauben, dass alles gut geht.
Die Version um 3 Uhr morgens
Durch die Darstellung als Compliance-Problem klingt das Versagen exotisch, obwohl es eigentlich ganz gewöhnlich ist – daher hilft ein konkreter Fall.
Zwanzig Minuten nach dem Release beginnen die Tests, 5xx-Fehler zurückzugeben. Ein Triage-Mitarbeiter vergleicht die Fehlerrate mit dem Rollout-Fenster, stellt keine Infrastrukturwarnungen fest und klassifiziert den Vorfall als Regression des Releases. Ein Korrekturmaßnahmen-Mitarbeiter rollt das Release zurück – die Fehler gehen auf normales Niveau zurück. Ein Release-Mitarbeiter öffnet die Deploy-Queue erneut. Jemand postet ein Daumen-hoch im Incident-Channel und das Team geht schlafen. Insgesamt elf Minuten vergehen, ohne dass eine Nachbesprechung stattfindet, weil das Problem sich anscheinend von selbst gelöst hat.
Aber das Release war nie schuld. Ein nachgelagerter Zahlungsdienstleister hatte seine Leistung verschlechtert und kam zufällig genau zum Zeitpunkt des Rollbacks wieder in Ordnung. Der Zusammenhang war reiner Zufall, und die Mitarbeiter konstruierten daraufhin eine glaubwürdige Erklärung.
Die Wahrheit kommt im Oktober ans Licht, wenn sich dasselbe Muster wiederholt und jemand fragt, ob das Ereignis im April dieselbe Ursache hatte. Es ist an der Zeit, nachzuprüfen.
Bis jetzt sind die Spuren veraltet und im Juni gelöscht worden. Das Prompt-Muster wurde bereits zweimal überarbeitet. Als sich das Embedding-Modell änderte, wurde der Abrufindex neu erstellt, sodass die Abschnitte aus dem Runbook, die der Agent damals las, nicht mehr die gleichen sind wie die, die er heute abrufen würde. Die im Anfrage-Header angegebene Modellversion ist bereits eingestellt worden. Was übrig bleibt, ist ein Chat-Thread, der mit einem Daumen-hoch-Emoji endet.
Die Frage kann nicht beantwortet werden. Niemand war nachlässig. Nichts im System war jemals dafür konzipiert, die Antwort zu speichern.
Warum besseres Gedächtnis das Problem nicht löst
Der übliche Instinkt ist es, die Speicherschicht zu nutzen, was in der Regel ein Vektor-Speicher ist. Das befasst sich jedoch mit einem völlig anderen Problem.
Die Einbettungssuche löst eine Frage gut: Was sieht so aus wie dieses? Sie kann nicht angeben, was das System zu einem bestimmten Zeitpunkt um 14:02 geglaubt hat, welche frühere Schlussfolgerung zu dieser geführt hat, woher ein bestimmter Fakt stammt oder ob eine Richtlinie, die eigentlich eine Aktion blockieren sollte, tatsächlich ausgelöst wurde.
Es gibt auch einen subtileren Fehler. Die Abfrageergebnisse bleiben im Laufe der Zeit nicht reproduzierbar. Wenn man das Korpus mit einem neueren Modell erneut einbettet, liefert derselbe Abfragebegriff ein anderes Ergebnis, sodass das als Datensatz betrachtete Element heimlich verändert wurde. Ein Audit-Trail, der durch das Aktualisieren einer Abhängigkeit stillschweigend überschrieben werden kann, ist kein echter Audit-Trail.
Jede Schicht beantwortet ihre eigene Frage:
- Vektor Suche: Welche Elemente sehen so aus wie dieses?
- Wissensgraph: Was ist damit verknüpft?
- Ursprung: Woher stammt es und ist es noch gültig?
- Entscheidungsprotokolle: Was wurde festgelegt und auf welcher Grundlage?
- Kausale Verbindungen: Welches Ereignis hat welches beeinflusst?
- Regeln: Welche Richtlinie bestimmt das Ergebnis?
- Zeitlicher Zustand: Welche Eigenschaften galt es für das System am 14. März?
Eine echte Untersuchung nach dem Motto „Warum hat es das getan?“ benötigt die meisten dieser Elemente. Nur eines davon ist ein Vektorlager.
Umwandlung einer Entscheidung in ein Objekt
Hier lohnt es sich, Semantica genauer anzusehen. Es handelt sich um eine unter MIT-Lizenz stehende Python-Schicht, die unter einem Agentenframework liegt und den Kontext als Graph statt als Textblock behandelt. Das Erstellen von Graphen, das Reasoning sowie die Nachverfolgung der Herkunft sind deterministisch und beinhalten keine LLMs – was wichtig ist, wenn das Ergebnis als Beweis dienen soll.
Die zentrale Idee ist einfach. Eine Entscheidung wird zu etwas, das absichtlich aufgeschrieben wird, und nicht zu etwas, das einfach in ein Protokoll geschrieben wird.
from semantica.context import ContextGraph
ctx = ContextGraph(advanced_analytics=True)
decision_id = ctx.record_decision(
category="incident_triage",
scenario="Checkout 5xx elevated 20 minutes after release 2026.31",
reasoning="Error onset correlates with rollout window; no infra alerts; "
"no dependency alarms visible at time of assessment",
outcome="classified_as_release_regression",
confidence=0.83,
)
Die Mechanik ist einfach. Was sich ändert, ist, was der Autor ausführlich darlegen muss. Anstelle von freiem Text in einer Protokollzeile müssen Kategorie, Szenario, Grundlagen, Ergebnis sowie ein Vertrauenswert angegeben werden. All das bleibt auch nach achtzehn Monaten abrufbar, was bei Prosa nicht der Fall ist.
Betrachten Sie den reasoning-String im Oktober-Szenario. Darin steht, dass zum Zeitpunkt der Bewertung keine Abhängigkeitsalarme sichtbar waren. Dieser eine Satz verändert die Darstellung von einem Agenten, der einen Fehler machte, zu einem Agenten, der aus einem unvollständigen Signal zu einem angemessenen Schluss kam – was auf eine Lücke in der Überwachung hindeutet, die geschlossen werden sollte. Die beiden Darstellungsweisen führen zu völlig unterschiedlichen Besprechungen.
Eine Warnung bezüglich dieses Feldes: Es dient nicht dazu, die unzuverlässige, manchmal erfundene Rohgedankenkette des Modells festzuhalten, die außerdem vor Dritten nicht Satz für Satz verteidigt werden kann. Erfassen Sie stattdessen die Begründung, hinter der die Organisation steht: die abgewogenen Beweise, die überschrittene Schwellenwert, angewandte Richtlinien sowie die Person, die eine Entscheidung aufgehoben hat. Das dient der Produktion ohnehin besser.
Eine einzige Eintragung ist eine Protokollzeile, eine Kette ist die Infrastruktur
Reale Agenten-Arbeitsabläufe breiten sich aus, und der Schaden liegt selten in einem einzelnen Knoten – er zeigt sich vielmehr in allen nachfolgenden Elementen, die stillschweigend eine falsche Schlussfolgerung übernommen haben.
Das bekannteste Beispiel vor der Einführung von KI ist Knight Capital. Ein fehlerhafter Einsatz im Jahr 2012 ließ einen veralteten Code weiterhin in Betrieb, und innerhalb von etwa 45 Minuten erlitt das Unternehmen Verluste in Höhe von rund 440 Millionen Dollar. Niemand zweifelte an der Funktionsweise der Software, und jede Order wurde protokolliert. Was jedoch niemand tun konnte, war, den Folgen so schnell wie möglich manuell nachzugehen, sobald sie sich ausbreiteten.
Semantica ermöglicht es, die Zusammenhänge zwischen Entscheidungen bereits bei ihrer Erstellung festzulegen:
triage_id = ctx.record_decision(
category="incident_triage",
scenario="Checkout 5xx elevated after release 2026.31",
reasoning="Error onset correlates with rollout window; no infra alerts",
outcome="classified_as_release_regression",
confidence=0.83,
)
rollback_id = ctx.record_decision(
category="remediation",
scenario="Contain checkout 5xx",
reasoning="Regression attributed to release; rollback is lowest-risk action",
outcome="rolled_back_to_2026.30",
confidence=0.91,
)
unblock_id = ctx.record_decision(
category="release_gate",
scenario="Resume deploy queue after containment",
reasoning="Error rate normal for 30 minutes post-rollback",
outcome="deploy_queue_reopened",
confidence=0.86,
)
ctx.add_causal_relationship(triage_id, rollback_id, relationship_type="CAUSED")
ctx.add_causal_relationship(rollback_id, unblock_id, relationship_type="INFLUENCED")
why = ctx.trace_decision_chain(unblock_id)
blast_radius = ctx.analyze_decision_impact(triage_id)
Es existieren drei Beziehungsarten: CAUSED, INFLUENCED und PRECEDENT_FOR. Das Vokabular ist klein, und das ist in Ordnung. Der Großteil der Informationen stammt von einer einzigen Operation.
Als im Oktober festgestellt wurde, dass die Triage falsch war, ändert sich die Fragestellung. Die Anfrage, welche Spuren Rückgaben beim Bezahlen erwähnen, liefert vierzigtausend Zeilen. Die Anfrage, welche Entscheidungen zu diesem Schluss kamen, ergibt eine kurze, begrenzte Liste: den Rollback, die Wiedereröffnung der Warteschlange, die an die Kunden gesendeten Nachrichten sowie das Nachbesprechungsdokument, das niemand verfasst hat. Das zeigt den Einflussbereich von Urteilsentscheidungen – und genau diese Operation ist notwendig, sobald die Mitarbeiter aufhören, nur Vorschläge zu machen, und tatsächlich handeln.
find_similar_decisions() arbeitet in die entgegengesetzte Richtung und gibt Präzedenzfälle zurück. Hat dieses System bereits eine solche Anfrage erhalten und was hat es getan? So wird ein Agent entlarvt, der jeden dritten Dienstag heimlich gegen sich selbst handelt – ein echter Fehler, auf den niemand achtet, weil es dafür keine Messgröße gibt.
Kausalität ist nicht Herkunft
Die beiden Begriffe werden ständig verwechselt, obwohl sie unterschiedliche Fragen beantworten. Zu wissen, dass die Entscheidung C auf Entscheidung A beruht, ist ohne Kenntnis der Beweise, auf denen A beruhte, kaum nützlich.
Das Herkunftsmodul in Semantica folgt W3C PROV-O. Es ist veraltet, aber korrekt.
from semantica.provenance import ProvenanceManager
prov = ProvenanceManager(storage_path="./provenance.db")
prov.track_entity(
entity_id="release_2026_31",
source="ci/pipeline_runs/2026-31/manifest.json",
metadata={"stage": "canary", "extractor": "ManifestParser", "confidence": 0.99},
)
lineage = prov.get_lineage("release_2026_31")
Zwei Gestaltungsentscheidungen hier sind selbst für Teams, die die Bibliothek niemals installieren, eine Übernahme wert.
Zunächst bilden die Herkunftsangaben eine Hash-Kette. Jeder Eintrag enthält eine Sequenznummer sowie eine Prüfsumme, die ihn mit dem vorherigen verbindet, und verify_chain() zeigt an, ob die Historie bearbeitet oder Einträge entfernt wurden. Das ist es, was eine Tabelle, die jeder einfach UPDATE können kann, von etwas unterscheidet, das als Beweismittel dient.
Zweitens werden Fakten ungültig gemacht, aber nicht gelöscht. Wenn etwas nicht mehr zutrifft, wird es zusammen mit dem Verantwortlichen und dem Grund ersetzt:
prov.invalidate(
"release_2026_31",
agent_id="human_sre_lead",
reason="Error attribution corrected; degradation traced to payments provider",
)
Eine veränderliche Spalte mit valid=false gibt den aktuellen Zustand an. Ein Protokoll zeigt an, dass der Zustand einst unterschiedlich war, wer ihn geändert hat, wann und warum. Kehren Sie zur Air Canada-Anhörung zurück und fragen Sie, welchen der beiden Zustände die Fluggesellschaft benötigte. Die Antwort ist offensichtlich.
Politik aus dem Prompt entfernen
Ein weiterer stiller Vorteil ist, dass Semantica echte Reasoning-Engine beinhaltet: forward chaining, Rete, Datalog und SPARQL. Die Logik ist einfach: Wenn eine Organisation bereits eine Regel kennt, gibt es keinen Grund, von einem Sprachmodell zu verlangen, dass es diese bei jeder Anfrage auf Englisch improvisiert.
from semantica.reasoning import ReteEngine, Rule, Fact, RuleType
engine = ReteEngine()
engine.build_network([
Rule(
rule_id="dual_control_prod",
name="Human approval required for high blast-radius prod changes",
conditions=[
{"field": "env", "operator": "==", "value": "production"},
{"field": "blast_radius", "operator": "in", "value": ["high", "critical"]},
],
conclusion="require_human_approval",
rule_type=RuleType.IMPLICATION,
)
])
engine.add_fact(Fact("chg_014", "change", [{"env": "production", "blast_radius": "high"}]))
matches = engine.match_patterns()
Das Modell verarbeitet weiterhin die unstrukturierten Eingaben und schlägt Aktionen vor. Der Wandel liegt in der Überprüfung, die diese Aktionen genehmigt oder blockiert: Es handelt sich nicht mehr um einen hoffnungsvollen Absatz innerhalb eines Systemauftrags, den ein seltsam formulierter Sonderfall umgehen könnte. Da rule_id im Entscheidungsprotokoll gespeichert werden kann, wird die Abfrage, welche Richtlinie angewandt wurde, zu einer einfachen Suche – anstatt zu einer Debatte zwischen zwei Teams.
Eine Einschränkung: Der Bedingungsabgleicher ist absichtlich einfach gehalten. Testen Sie ihn gründlich mit dem tatsächlichen Regelwerk, bevor er zwischen einem Agenten und einer regulierten Aktion steht. Ein Demonstrations-Regelwerk stellt keine Konformitätskontrolle dar, und das Entdecken von Lücken während einer Prüfung ist eine kostspielige Art, dies zu lernen.
Einfache Standards überdauern Frameworks
PROV-O kümmert sich um Herkunftsinformationen, RDF-Repräsentationen, SPARQL-Abfragen, SHACL-Beschränkungen sowie OWL-Ontologien. Nichts davon ist besonders aufregend – genau das ist aber der Sinn.
Agent-Frameworks haben eine Halbwertszeit von etwa achtzehn Monaten. Audit-Anforderungen hingegen nicht. Ein Prüfer im Jahr 2030 wird sich nicht dafür interessieren, welche Orchestrierungsbibliothek zum Zeitpunkt einer Entscheidung im Umlauf war, und niemand möchte eine dauerhafte Aufzeichnung in dem proprietären Exportformat eines Startups haben, das inzwischen eine andere Richtung eingeschlagen hat.
Es gibt außerdem einen MCP-Server, der über python -m semantica.mcp_server gestartet wird. Seine Tools umfassen Extraktion, Aufzeichnung von Entscheidungen, Abgleich von Präzedenzfällen, Kausalketten und Reasoning. Mit diesem Setup kann der Agent seine eigenen Entscheidungen durch einen gewöhnlichen Tool-Aufruf aufzeichnen, ohne dass ein zusätzliches Logging-Wrapper hinzugefügt werden muss, das der Agent umgehen könnte.
Der eigentliche Preis
Die Kosten verdienen eine klare Darstellung.
Der erste Kostenfaktor ist ein neuer, zustandsbasierter Service samt seinen Backups, Migrationsprozessen, Schema sowie Zugriffskontrollmechanismen. Der zweite Faktor sind die Anstrengungen bei der Modellierung, da niemand anderes entscheiden kann, was als Entscheidung für die Aufzeichnung in Frage kommt. Jeder Schritt, der erfasst wird, erzeugt ein weiteres Protokoll – nur zu höheren Kosten. Zu geringe Erfassung hingegen hinterlässt Lücken in der Kette genau dort, wo die Frage relevant wird.
Auch kulturelle Kosten existieren und werden oft unterschätzt. Ein Entscheidungsgraph zeigt sehr deutlich, dass ein Agent seit vier Monaten eine bestimmte Aktion falsch ausführt. Das ist zwar der Zweck, doch die Besprechung bleibt dennoch unangenehm.
Das Projekt entwickelt sich außerdem schnell. Fixieren Sie die validierte Version. Wer unveröffentlichtes Verhalten benötigt, sollte von einer Quelle herunterladen, die auf einen bestimmten Commit festgelegt ist. Behandeln Sie dies als Infrastruktur – niemals als bequeme Importmöglichkeit.
Fangen Sie mit einem Workflow an
Es ist ein Fehler, alles grafisch darzustellen. Zeichnen Sie nur das auf, was verteidigt werden muss.
Wählen Sie einen Arbeitsablauf aus, bei dem ein falscher Entscheidungsprozess echtes Geld oder Vertrauen kostet. Erfassen Sie Entscheidungen nur an den Stellen, an denen Befugnisse ausgeübt werden, wie zum Beispiel bei der Genehmigung, Ablehnung, Ausgabe, Übermittlung an die Produktion oder Zusicherung gegenüber einem Kunden. Speichern Sie zu jeder Entscheidung die darauf beruhenden Beweise sowie die Regel-ID, wenn es sich um eine deterministische Richtlinie handelt. Führen Sie die Änderungen asynchron im Graphen durch, sodass keine Schreibvorgänge auf einem Pfad liegen bleiben, auf den ein Benutzer wartet.
Nach dreißig Tagen versuchen Sie, eine echte „Warum hat es das getan?“-Frage ausschließlich mithilfe des Graphen zu beantworten. Sofort werden Lücken auftauchen, und es werden nicht die erwarteten sein. Diese Übung bringt mehr bei als jede Menge vorab durchgeführtes Schema-Design.
Was man sich merken sollte
Zwei Jahre wurden damit verbracht, Erklärbarkeit zu erreichen, was hauptsächlich darin bestand, versuchen zu müssen, in das Modell hineinzuschauen. Dieses Ziel ist falsch und rückt nicht näher. Das Modell bleibt probabilistisch, und keine clevere Anfrage macht seine Interna an irgend einem relevanten Punkt akzeptabel.
Rechenschaftspflicht ist die erreichbare Alternative, und jeder Aspekt davon befindet sich außerhalb des Modells: die Entscheidung, ihre ursächlichen Faktoren, die Beweise, die Herkunft, die angewandte Politik, die nachfolgenden Auswirkungen sowie spätere Korrekturen. All das sind gewöhnliche strukturierte Daten. Solche Aufzeichnungen werden bereits seit der Doppeltbuchführung geführt. Die Gewohnheit endete einfach, als der Entscheidungsträger zu einem Sprachmodell wurde, als hätte das etwas an der Funktion einer Aufzeichnung geändert.
Wenn der juristische Jargon wegfällt, ist die Forderung des Artikels 12 bescheiden. Sie verlangt keine weiteren Protokolle, sondern lediglich eine Aufzeichnung, deren Bedeutung drei Jahre lang erhalten bleibt – auch nachdem das Framework nicht mehr genutzt wird, der Index zweimal neu erstellt wurde und der Autor der Anfrage weitergezogen ist.
Ein besseres Testverfahren als das regulatorische ist es, den Vorfall um 3 Uhr morgens nochmals zu betrachten. Niemand dort trug Schuld. Die Mitarbeiter zogen aus den vorliegenden Informationen sinnvolle Schlussfolgerungen und der Vorfall wurde innerhalb von elf Minuten abgeschlossen; doch die Erklärung verschwand bereits nach einem Vierteljahr. Wenn bereits ein gewöhnlicher Dienstagtag die Fähigkeit, eine Entscheidung zu erklären, auslöschen kann, wird ein Prüfer das nicht als Erster bemerken. Im Laufe eines Treffens Monate später wird allen allmählich klar werden, dass niemand von den Anwesenden weiß, was eigentlich passiert ist.
Was Air Canada wirklich kostete, war nicht die Summe von 812 CAD. Bei der Anhörung hatte das Unternehmen nichts zu dem Verhalten seines eigenen Systems zu sagen und berief sich stattdessen darauf, dass die Verantwortung für die Software bei jemand anderem liege. Die Verteidigung brach zusammen, obwohl nur ein Ticket und ein betroffener Passagier involviert waren – ein Passagier, der versuchte, die Chat-Unterhaltungen aufzunehmen.
Heutzutage genehmigen, veranlassen, einsetzen und ablehnen Mitarbeiter Dinge schneller, als jemand Zeit hat, dies zu überprüfen, und niemand macht Screenshots davon. Erstellen Sie die Aufzeichnungen, bevor jemand danach fragt. Die Frage stellt sich immer zum schlechtestmöglichen Zeitpunkt – bis dahin ist die Antwort entweder in einer Datenbank gespeichert oder endgültig verloren gegangen.
Verwandte Artikel
- Praktische Hinweise: Die 10 praktischsten Agentenfähigkeiten im Jahr 2026 (und in der nächsten Generation) – Detaillierte Anleitung zu den Praktischen Hinweisen: Die 10 praktischsten Agentenfähigkeiten im Jahr 2026 (und in der nächsten Generation): Verträge, Überprüfungen sowie Code-Blöcke für Teams, die dieses Muster nutzen.
- Selbstverbessernde Agenten durch Fähigkeiten: Wiederverwendung, Auswahl, Reparatur und Überprüfung – Ein vierteiliges Konzept für Agenten, die ihre eigenen Fähigkeiten verbessern: Speichern von funktionsfähigem Code, Verfeinern von Beschreibungen, Vorschlagen von überprüften Korrekturen sowie Überprüfen der Ausgabe vor der Weitergabe.