Seit dem 2. August 2026 ist das AI Office für Anbieter von KI-Modellen mit allgemeinem Verwendungszweck (GPAI) und bestimmte KI-Systeme zuständig, nationale zuständige Behörden für andere KI-Systeme und der EDSB für KI-Systeme von EU-Institutionen. Teams sollten abgegrenzte Bewertungen, Kontrollen, Vorfälle, Offenlegungen und Laufzeitnachweise für die jeweils zuständige Behörde bereithalten.
Wer ermittelt nach dem EU AI Act in welchem Fall?
Die Kommission erläutert die Zuordnung der Zuständigkeiten. Die Zuständigkeit hängt von KI-Modell, System, Anbieter und Bereitstellungszusammenhang ab. Das Regelwerk unterscheidet drei Behördenkategorien:
AI Office
Setzt Regeln für GPAI-Modell-Provider durch; für KI-Systeme, die vom Provider des zugrunde liegenden GPAI-Modells oder einem Provider derselben Unternehmensgruppe entwickelt wurden; sowie für KI-Systeme, die in nach dem DSA benannte Very Large Online Platforms (VLOPs) oder Very Large Online Search Engines (VLOSEs) integriert sind.
Nationale zuständige Behörden
Behörden der Mitgliedstaaten setzen die Regeln für andere KI-Systeme durch. Die Seite der Kommission nennt nicht jede nationale Behörde und beschreibt nicht deren jeweilige Befugnisse.
EDSB
Der Europäische Datenschutzbeauftragte setzt die Regeln für KI-Systeme durch, die von EU-Institutionen genutzt werden. Der Überblick enthält keine vergleichbare Übersicht der EDSB-Befugnisse.
Für jedes System sollten Zweckbestimmung, KI-Modell-Anbieter, die Rolle als Anbieter oder Betreiber, die Integration in einen benannten VLOP oder VLOSE und die Nutzung durch eine EU-Institution erfasst werden. Diese Fakten helfen bei der Zuordnung einer Anfrage mehr als das allgemeine Label „KI-Agent“.
Was das AI Office und die Kommission tun können
Die detaillierten Befugnisse im Überblick der Kommission gelten ausdrücklich für das AI Office und die Kommission. Die Seite erklärt nicht, dass nationale zuständige Behörden oder der EDSB dieselben Instrumente besitzen.
Was das AI Office bisher angefordert hat
Dem am 12. Oktober 2026 veröffentlichten Bericht der Kommission über die Sitzung des Wissenschaftlichen KI-Gremiums vom 9. Oktober zufolge hat das Gremium jüngste Vorfälle mit Kontrollverlust untersucht und mit dem AI Office Fragen an die Unternehmen erarbeitet, die die betreffenden KI-Modelle entwickelt haben. Die Mitteilung nennt diese Schritte:
Die Mitteilung nennt keine Anbieter, KI-Modelle oder Ergebnisse, kein Datum der einzelnen Anfragen und keine Sanktionen. Sie sagt auch nicht, auf welche Rechtsgrundlage sich die einzelnen Anfragen stützen. Zur Einordnung: Nach Artikel 91 kann die Kommission Dokumentation und Informationen von Anbietern von GPAI-Modellen anfordern, auch auf hinreichend begründeten Antrag des wissenschaftlichen Gremiums.
Vorsitz und stellvertretender Vorsitz des Gremiums haben der Exekutiv-Vizepräsidentin und dem AI Office außerdem Empfehlungen zu Sicherheit und Gefahrenabwehr bei Frontier-KI vorgelegt. Demnach sollen Risiken interner KI-Modelle während der Entwicklung und im Testeinsatz gesteuert, EU-Kapazitäten zur Erkennung, Bewertung und Untersuchung solcher Vorfälle gestärkt und Trainingstechniken und Architekturen, die die Überwachbarkeit verringern, genauer geprüft werden. Außerdem empfehlen sie eine internationale Initiative für Informationsaustausch, gemeinsame Anforderungen an Entwickler von Frontier-KI sowie gemeinsame Krisenreaktion und -prävention. Ob die Kommission die Empfehlungen übernimmt, lässt die Mitteilung offen.
Pflichten der Modellanbieter und eigene Aufzeichnungen
Nach Artikel 55 müssen Anbieter von GPAI-Modellen mit systemischem Risiko einschlägige Informationen über schwerwiegende Vorfälle und mögliche Abhilfemaßnahmen erfassen, dokumentieren und unverzüglich das AI Office sowie gegebenenfalls die nationalen zuständigen Behörden darüber unterrichten. Ein Team, das einen Agenten auf einem solchen KI-Modell aufbaut, behält die Pflichten seiner eigenen Rolle für das KI-System. Die Berichte des Anbieters dokumentieren nicht, wie sich dieses System verhalten hat.
Für Hochrisiko-KI-Systeme regelt Artikel 73 eine eigene Meldepflicht für schwerwiegende Vorfälle: Anbieter des Systems melden sie den Marktüberwachungsbehörden der Mitgliedstaaten, in denen der Vorfall eingetreten ist. Gibt ein Modellanbieter einen Vorfall bekannt, muss das Team anhand eigener Aufzeichnungen klären, ob sein System betroffen war.
Drei Beschwerde- und Meldekanäle
Artikel 2 des EU AI Act beschreibt den räumlichen Anwendungsbereich. Der EU AI Act erfasst Anbieter, die KI-Systeme unabhängig vom Standort auf den EU-Markt bringen oder in Betrieb nehmen, in der EU ansässige Betreiber sowie Anbieter oder Betreiber aus Drittländern, wenn das Ergebnis des Systems in der Union verwendet wird.
Das Anwendungsdatum ist nur ein Teil der Vorbereitung. Teams müssen auch wissen, welche Behörde Fragen stellen könnte und ob sie einen genauen, abgegrenzten Nachweis über Bewertungen, Kontrollen, Vorfälle, Offenlegungen und den Systembetrieb erstellen können.
Bei der Auswahl einer KI-Agenten-Plattform sollten Governance-Aufzeichnungen und Nachweisprozesse zu den Kriterien gehören. Für Teams, die noch eine Auswahlliste erstellen, dient der Vergleich der besten KI-Agenten-Plattformen für EU-Unternehmen 2026 als Orientierung.
Weiterführende Quellen: Beginn der Durchsetzung des EU AI Act.
Was der EU AI Act verlangt
Der EU AI Act nutzt ein risikobasiertes Regelwerk. Eine praktische Prüfung unterscheidet verbotene Praktiken, Hochrisikosysteme, Anwendungen mit spezifischen Transparenzpflichten und Anwendungen mit weniger systemspezifischen Pflichten.
Die Klassifizierung folgt Artikel 6 und der Zweckbestimmung des Systems, nicht dem Wort „Agent“. Ein kundenorientierter Assistent kann eine Offenlegung nach Artikel 50 auslösen, während ein Agent für einen bestimmten Zweck nach Anhang III als Hochrisikosystem gelten kann. Die Rolle der betreibenden Organisation bestimmt die anwendbaren Pflichten. Unsere Plattform kann betriebliche Kontrollen und abgegrenzte Laufzeitnachweise organisieren.
Plane die Kontrollen für den EU AI Act
Wir ordnen den Anwendungsfall und die relevanten Pflichten den connic-Traces, Freigaberegeln, Audit-Logs sowie der menschlichen Aufsicht und Betreiberdokumentation zu.
Zeitplan für Anwendung und Durchsetzung des EU AI Act
Der EU AI Act wird phasenweise eingeführt. Manche Bestimmungen gelten bereits und sind durchsetzbar; andere stehen noch bevor:
Bestimmte Transparenzpflichten sind jetzt durchsetzbar. Der vom Service Desk veröffentlichte Zeitplan zur Durchsetzung sollte vor der Bereitstellung eines Agenten geprüft werden. Pflichten für Betreiber von Hochrisikosystemen wurden durch den AI Omnibus auf Dezember 2027 und August 2028 verschoben. Der Aufbau der Protokollierungs- und Aufsichtsinfrastruktur für diese Pflichten benötigt dennoch Zeit.
Was der AI Omnibus geändert hat
Die Zusammenfassung der Kommission zum AI Omnibus erläutert die Änderungen. Die Verordnung (EU) 2026/1744 änderte den Zeitplan des EU AI Act und mehrere inhaltliche Bestimmungen, darunter Teile des Regelwerks für Hochrisikosysteme.
Der Omnibus schuf keinen allgemeinen Aufschub. Für Agenten, die mit Menschen sprechen oder Inhalte generieren, gelten die einschlägigen Pflichten aus Artikel 50 bereits. Unsere Erklärung der Leitlinien zu Artikel 50 erläutert die fünf Auslöser von Offenlegungspflichten im Detail.
So lassen sich Pflichten des EU AI Act KI-Agenten zuordnen
Der EU AI Act gilt für KI-Agenten, die unter seine Definition und seinen Anwendungsbereich fallen. Eine Organisation, die einen Agenten in eigener Verantwortung einsetzt, kann Betreiber sein. Eine Organisation, die einen Agenten entwickelt oder entwickeln lässt und unter eigenem Namen auf den Markt bringt, kann Anbieter sein. Manche Teams haben beide Rollen.
Für Teams, die Hochrisikosysteme betreiben, kehren in der Praxis folgende Kontrollbereiche regelmäßig wieder:
Diese Kontrollen brauchen verknüpfte Aufzeichnungen. Die Plattform sollte Governance-Entscheidungen mit den Systemen und Laufzeitnachweisen verbinden, für die sie gelten.
Wie connic die Vorbereitung auf Nachweisanfragen unterstützt
connic Enterprise KI-Governance organisiert Aufzeichnungen rund um ein auf ein Projekt begrenztes KI-System. Teams können Zweckbestimmung, Verantwortliche, Regionen, betroffene Personen, verknüpfte Umgebungen, Bereitstellungen und Agenten dokumentieren, unveränderliche versionierte Vorbewertungen führen, betriebliche Kontrollen zuordnen, Transparenznachweise und Vorfälle verfolgen sowie abgegrenzte Nachweispakete exportieren.
Der durchgängige Prozess deckt die Rollen von Anbietern und Betreibern ab. Die Rollen Bevollmächtigter, Händler, Einführer und Produkthersteller bleiben in der Bewertung, blockieren aber Freigabe, Erstellung oder Aktualisierung von Kontrollen sowie den Export, bis die Abdeckung geklärt ist.
connic bestimmt weder die Jurisdiktion noch nimmt es eine abschließende rechtliche Klassifizierung vor, berechnet Meldefristen, beurteilt die Akzeptanz von Nachweisen durch eine Behörde oder zertifiziert die Konformität. Diese Entscheidungen verbleiben bei der Organisation und ihrer Rechtsberatung. Die KI-Governance-Dokumentation und die Übersicht zur Governance-Funktion enthalten weitere Details.
Vom Vorfallseintrag zum Nachweispaket
Ein hypothetisches Beispiel: Ein Support-Agent nutzt das KI-Modell eines Drittanbieters. Der Modellanbieter gibt einen schwerwiegenden Vorfall bekannt, der das KI-Modell betrifft, das für die Produktivbereitstellung des Agenten konfiguriert ist. Das Team leitet eine eigene Untersuchung ein:
Den Vorfall beim KI-System erfassen. Zeitpunkt der Kenntnisnahme, Schweregrad und Status des Kausalzusammenhangs (unbekannt, vermutet, bestätigt oder ausgeschlossen) festhalten und die betroffene Umgebung, Bereitstellung oder Ausführung referenzieren. Ein auf Umgebungen begrenztes Nachweispaket enthält nur Vorfälle, die mit einer ausgewählten Umgebung verknüpft sind.
Die Entscheidung zur Meldepflicht dokumentieren. Den Meldestatus aktualisieren, während die Rechtsberatung den Fall prüft. Die Bestätigung einer Meldefrist setzt die Angabe einer Grundlage voraus. connic erfasst die Frist, berechnet sie aber nicht.
Nachweise zur Behördenbenachrichtigung ergänzen. Bei einer Benachrichtigung Zeitpunkt, Empfänger oder Behörde, Kanal und externe Referenz erfassen. Ohne diese Nachweise lässt sich ein Vorfall in connic nicht als gemeldet oder abgeschlossen markieren.
Ein abgegrenztes Nachweispaket erstellen. System, Umgebungen und Zeitraum auswählen. Das Paket enthält die neueste Bewertung, die Kontrollen und den Monitoring-Plan des Systems, abgegrenzte Telemetrie zu Ausführungen, Freigaben und Judges sowie alle Vorfälle, deren Zeitpunkt der Kenntnisnahme im Zeitraum liegt.
Prüfen, was außerhalb bleibt. Titel, Beschreibungen, Notizen zu Eindämmung und Untersuchung, Fristgrundlagen, Details zu Korrekturmaßnahmen sowie Empfänger, Kanäle und Notizen von Benachrichtigungen bleiben im Vorfallseintrag. Roh-Prompts und KI-Modell-Ausgaben bleiben in den Ausführungs-Traces. Für jeden Vorfall enthält das Paket Kennungen, Schweregrad und Statusfelder, die Zeitpunkte von Kenntnisnahme, Abschluss und Meldefrist, die Anzahl betroffener Rechte, Mitgliedstaaten, Korrekturmaßnahmen und Benachrichtigungen sowie Zeitpunkt und externe Referenz jeder Benachrichtigung.
Das Ergebnis ist ein unveränderlicher, per Hash prüfbarer Nachweis zum aktuellen Status und zu den wichtigsten Zeitpunkten des Vorfalls, verknüpft mit dem System und seiner Telemetrie. Ob er eine konkrete Anfrage beantwortet und welche Aufzeichnungen von außerhalb des Pakets hinzukommen, entscheiden weiterhin das Team und seine Rechtsberatung.
Menschliche Aufsicht: bedingte Freigaberegeln
Artikel 14 des EU AI Act verlangt, dass Hochrisiko-KI-Systeme für wirksame menschliche Aufsicht ausgelegt sind. Artikel 26 verlangt von Betreibern, die Aufsicht Personen mit der nötigen Kompetenz, Schulung, Befugnis und Unterstützung zuzuweisen. Je nach System und Risiko kann die Aufsicht die Überwachung, Interpretation von Ausgaben, das Übersteuern oder Rückgängigmachen eines Ergebnisses oder die Unterbrechung des Betriebs umfassen. Eine Freigabe vor der Ausführung ist ein Implementierungsmuster für sensible Aktionen, keine allgemeine Pflicht.
Der Beitrag zu bedingten Freigaben beschreibt den Ablauf. connic pausiert die Ausführung, wenn ein Agent eine sensible Aktion erreicht (Datensätze löschen, eine Erstattung verarbeiten, eine externe E-Mail senden). Eine prüfende Person sieht den Prüfkontext: Agent und Ausführung, das aufgerufene Tool und die verwendeten Parameter. Eine Freigabe setzt den Agenten fort; bei Ablehnung folgt er dem konfigurierten Fehler- oder Fortsetzungspfad.
Aktionen ohne konfigurierte Regel laufen ohne Freigabe weiter. Bei jeder Entscheidung werden Zeitpunkt, prüfende Person, Tool, Parameter und eine optionale Begründung aufgezeichnet. Wo die Pflicht gilt, kann dieser Eintrag eine Nachweisprüfung nach Artikel 26 unterstützen.

Transparenz: Agentenverhalten nachvollziehbar machen
Artikel 50 verlangt für bestimmte interaktive Anwendungen eine Offenlegung und für bestimmte synthetische Inhalte eine Kennzeichnung oder Offenlegung. Separate Pflichten für Hochrisikosysteme verlangen Informationen, Protokollierung und Aufsicht. connic zeigt Betreibern, was der Agent tatsächlich getan hat, damit sie sein Verhalten untersuchen und Nachweise erstellen können.
Die connic-Observability für KI-Agenten zeichnet folgende Daten zum Betrieb eines Agenten auf:

Aufzeichnungen: abgegrenzte Betriebsnachweise
Artikel 12, 19 und 26 legen Protokollierungs-, Aufbewahrungs- und Monitoring-Pflichten für Hochrisikosysteme und die von diesen Vorschriften erfassten Betreiber fest. Fragt eine Behörde, was ein Agent an einem bestimmten Datum mit einer bestimmten Eingabe getan hat, erfordert die Antwort einen präzisen, abgegrenzten Betriebsnachweis.
connic zeichnet die folgenden Betriebsdaten auf. Welche Felder rechtlich relevant sind, hängt vom System, der Rolle der Organisation, der Anfrage und der anwendbaren Pflicht ab:
Diese Laufzeitaufzeichnungen lassen sich einem Governance-Prozess zuordnen und in Untersuchungen oder Compliance-Prüfungen verwenden. KI-Governance-Exporte enthalten nur Metadaten und schließen Roh-Prompts und KI-Modell-Ausgaben bewusst aus. Teams sollten deshalb bestimmen, welche zusätzlichen Aufzeichnungen sie außerhalb des Exports aufbewahren müssen.
Risikomanagement: Guardrails mit Laufzeitprüfungen
Artikel 9 und 15 legen Pflichten zu Risikomanagement, Robustheit und Cybersicherheit für Hochrisikosysteme fest. Relevante Risiken für Agenten umfassen Prompt-Injection, die Offenlegung personenbezogener Daten (PII), die Extraktion des System-Prompts, themenfremde Antworten und Datenexfiltration. Die OWASP Top 10 for Agentic Applications 2026 decken außerdem Goal Hijacking, Tool-Missbrauch, Missbrauch von Identitäten und Privilegien, Memory Poisoning und kaskadierende Fehler ab.
Der Beitrag zu connic guardrails beschreibt die Anwendung. Konfigurierte Regeln prüfen Eingabe- und Ausgabepfade auf solche Bedrohungen:
Guardrails unterstützen die Modi block und warn; konfigurierte PII-Regeln unterstützen außerdem redact. Teams können auch eigene Guardrails schreiben und in Python domänenspezifische Compliance-Regeln umsetzen, etwa für Finanzhinweise, regulatorische Sprachanforderungen und interne Terminologierichtlinien.
Jede Guardrail-Auswertung wird als Trace-Span aufgezeichnet. Der Eintrag zeigt, welche Kontrolle ausgeführt wurde, welches Ergebnis sie lieferte und wie die Laufzeitumgebung reagierte. Er kann Tests und Prüfungen der Kontrolle unterstützen, ohne ihre rechtliche Tragfähigkeit zu belegen.
Kontinuierliche Evaluation: Regressionssignale aufzeichnen
Anwendbare Monitoring-Pflichten bestehen nach der Bereitstellung fort. Das Verhalten eines Agenten kann sich durch KI-Modell-Updates, Prompt-Änderungen oder veränderte Nutzereingaben ändern. Automatische Evaluationen können fortlaufende Nachweise liefern.
LLM Judges bewerten passende Ausführungen mit der konfigurierten Stichprobenrate anhand eigener Kriterien. Genauigkeit, Nützlichkeit, Sicherheit und die Einhaltung organisationsinterner Richtlinien werden als strukturierte Ergebnisse erfasst; Änderungen der Bewertung werden im Dashboard sichtbar. Teams können außerdem A/B-Tests ausführen und bei Prompt-Änderungen die Ergebnisse vor einem breiteren Rollout vergleichen.

Eine Evaluation je Ausführung kann einen Risikomanagementprozess nach Artikel 9 unterstützen, indem sie Regressionen zwischen formalen Prüfungen sichtbar macht. Diese Evaluation ersetzt nicht das umfassendere rechtliche und betriebliche Risikomanagementprogramm.
Daten-Governance: Kontrollen für Umfang und Datenresidenz
Artikel 10 legt Anforderungen an die Daten-Governance für Trainings-, Validierungs- und Testdatensätze fest, die von Hochrisikosystemen verwendet werden. Für Daten, die ein Agent verarbeitet, können separat die DSGVO und andere Datenschutzgesetze gelten. Unsere Plattform bietet folgende Kontrollen und Bereitstellungsoptionen:
- ✓Kein Training mit Kundendaten durch connic. Unsere Plattform verwendet Kundendaten nicht zum Trainieren von KI-Modellen. Die Verarbeitung durch BYOK-Anbieter folgt den von unseren Kunden gewählten Anbieterbedingungen.
- ✓Zugriffskonfiguration. Tool-Konfiguration und Umgebungsvariablen begrenzen, auf welche Quellen ein Agent zugreifen kann. Unsere Kunden bestimmen diesen Umfang.
- ✓Datenresidenz. Die Ausführung der connic/*-KI-Modelle bleibt in der EU. Die durchgängige Datenresidenz eines Projekts hängt außerdem von der gewählten Deployment-Region und allen von unseren Kunden konfigurierten Anbietern, Tools, Judges, Guardrails und Zielen ab.
- ✓Durchgängige Verschlüsselung. Alle Daten werden bei der Übertragung (TLS 1.2+) und im Ruhezustand (AES-256) verschlüsselt. Secrets werden zur Laufzeit injiziert und nie in Code oder Logs gespeichert.
- ✓KI-Modell-Auswahl. Unsere Kunden können ein EU-gehostetes connic/*-KI-Modell auswählen oder einen BYOK-Anbieter konfigurieren und ihre eigenen Zugangsdaten verwenden. Artikel 51–56 der Verordnung (EU) 2024/1689 behandeln die Pflichten von GPAI-Modell-Anbietern. Pflichten für Anbieter und Betreiber auf Systemebene hängen weiterhin von der Rolle und dem Anwendungsfall unserer Kunden ab.
Sicherheit und Robustheit: Schutz auf Infrastrukturebene
Artikel 15 verlangt von Hochrisikosystemen ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit. Plattform- und Laufzeitkontrollen können diese Arbeit unterstützen, ihre rechtliche Tragfähigkeit hängt jedoch vom System und seinen Risiken ab.
Ausführliche Details stehen auf der Sicherheitsseite und der Compliance-Seite zum EU AI Act.
Sanktionsobergrenzen des EU AI Act
Der EU AI Act ist verbindliches Recht. Artikel 99 und 101 der Verordnung (EU) 2024/1689 legen die gesetzlichen Sanktionsstufen fest:
Artikel 99 wendet umsatzbasierte Obergrenzen auf Unternehmen an und sieht niedrigere Maximalbeträge für KMU vor. Die genaue Obergrenze hängt daher von Organisation und Verstoß ab. Die genannten Beträge sind die höchsten Sanktionsstufen des EU AI Act, nicht die automatisch verhängte Geldbuße in jedem Fall.
Die Obergrenze von 7,5 Millionen Euro oder 1 % gilt für Auskunftsverstöße bei KI-Systemen. Die Übersicht der Kommission behandelt Auskunftsverstöße bei GPAI-Modellen mit anderen Maximalbeträgen. Teams sollten die Obergrenze für KI-Systeme daher nicht standardmäßig auf GPAI-Anfragen anwenden.
Durch die neuen Beschwerde- und Meldekanäle wird die Qualität der Nachweise Teil der Reaktion auf Vorfälle. Eine vollständige, abgegrenzte Aufzeichnung hilft einem Team, einen Vorwurf zu untersuchen, die Rechtsberatung zu informieren, ein Problem zu beheben und auf eine Behördenanfrage präzise zu antworten.
Governance und Laufzeitnachweise verknüpft halten
Teams können Prozesse für menschliche Aufsicht, Audit-Logging, Guardrails, Evaluationspipelines und Governance-Aufzeichnungen über separate Tools hinweg zusammenstellen. Sind diese Aufzeichnungen nicht verknüpft, müssen Anwendungsbereich und Beziehungen zwischen System, Bewertung, Kontrolle, Vorfall und Laufzeitnachweis manuell rekonstruiert werden.
connic verknüpft diese Aufzeichnungen mit den Umgebungen, Bereitstellungen und Agenten, für die sie gelten. Freigaben, Ausführungs-Traces, darin aufgezeichnete Guardrail-Ergebnisse, Judges, Vorfälle und Nachweispakete unterstützen so einen gemeinsamen Prüfprozess, statt eine manuelle Rekonstruktion über getrennte Daten hinweg zu erfordern.
Checkliste zur Vorbereitung auf Nachweisanfragen
Teams, die KI-Agenten betreiben oder deren Bereitstellung planen, sollten ein Nachweispaket für Behördenanfragen zusammenstellen, bevor eine Informationsanfrage, Beschwerde oder ein Vorfall eintrifft:
Angaben zur rechtlichen Zuständigkeit festhalten. Für jedes System Zweckbestimmung, KI-Modell-Anbieter, die Rollen der Organisation, relevante Regionen, die Integration in einen VLOP oder VLOSE und die Nutzung durch eine EU-Institution dokumentieren.
Eine versionierte Bewertung führen. Rollen- und Risikoanalyse, Begründung, Quellversion, prüfende Person, offene Fragen und die aus der neuesten freigegebenen Vorbewertung zugeordneten Pflichten aufbewahren.
Kontrollen mit Nachweisen verknüpfen. Verantwortliche Person, Umsetzungs- und Nachweisstatus, Ausnahmen, Freigaben, Traces, Guardrail-Ergebnisse, Evaluationen und die kundenseitig verwaltete Dokumentation zu Artikel 50 erfassen.
Den Verlauf eines Vorfalls pflegen. Zuständigkeit für das Monitoring, Signale, Prüfdaten, Zeitpunkt der Kenntnisnahme, Korrekturmaßnahmen, Entscheidungen zur Meldepflicht und Nachweise zu Behördenbenachrichtigungen festhalten. Das für jede Bereitstellung konfigurierte KI-Modell und ein gegebenenfalls konfiguriertes Fallback-Modell dokumentiert halten, damit sich ein vom Modellanbieter bekannt gegebener Vorfall den betroffenen Bereitstellungen und Ausführungen zuordnen lässt.
Die Antwort proben. Eine verantwortliche Person für Informationsanfragen benennen, den Exportpfad testen, Aufzeichnungen außerhalb reiner Metadatenpakete identifizieren und Genauigkeit, Vollständigkeit, Anwendungsbereich und Vertraulichkeit durch die Rechtsberatung prüfen lassen.
Die dokumentierten Nachweise sollten aktuell bleiben. Vor einer Antwort an eine Behörde sollten qualifizierte Rechtsberater den offiziellen Text, die Klassifizierung des Systems und den Umfang der Antwort prüfen.