Bericht zur Schließung von Lücken vor dem EU-Start

Warum ein Lückenbericht vor dem Launch wichtig ist

Wenn Sie ein KI-System in der EU veröffentlichen, müssen Sie nachweisen, dass Sie die im KI-Gesetz festgelegten Verpflichtungen erfüllt haben. Ein Lückenbericht wandelt diese rechtlichen Anforderungen in eine konkrete Liste von abgeschlossenen und noch ausstehenden Aufgaben um. Diese Liste ist für interne Teams, Prüfer und Aufsichtsbehörden nützlich, da sie genau zeigt, wo noch Arbeit erforderlich ist. Er verspricht keine Konformität, sondern zeigt lediglich den aktuellen Stand der Bemühungen.

Wir beginnen damit, den offiziellen Text des Gesetzes und die dazugehörigen Richtlinien der Europäischen Kommission zu lesen. Jede Verpflichtung wird wörtlich in eine Tabellenspalte kopiert. Neben jeder Verpflichtung fügen wir eine Spalte für Beweise (wie ein Richtliniendokument, ein Testergebnis oder ein Codekommentar) hinzu. Wenn die Beweisspalte leer ist, markieren wir die Zeile als Lücke. Die resultierende Tabelle wird zur Arbeitsliste, die die Beseitigung der Mängel vorantreibt.

Da das Gesetz in juristischer Sprache verfasst ist, übersetzen wir jeden Satz in einfache Aktionen. Zum Beispiel wird „klare Informationen über die Fähigkeiten des KI-Systems bereitstellen“ zu „eine benutzerfreundliche Beschreibung erstellen, die Eingabetypen, Ausgabeformate und bekannte Einschränkungen auflistet“. Dieser Übersetzungsschritt verhindert Fehlinterpretationen und erleichtert es, Eigentümer zuzuweisen.

Wie wir Aktverpflichtungen auf technische Kontrollen abbilden

Die Abbildung ist die Kernaktivität, die juristische Texte in Ingenieursarbeiten umwandelt. Wir verwenden eine dreispaltige Tabelle: Verpflichtung, Kontrolle, Beweis. Die Spalte Verpflichtung enthält den genauen Wortlaut des Akt. Die Spalte Kontrolle listet die konkreten technischen oder prozessualen Maßnahmen auf, die wir ergriffen haben, um diesen Wortlaut zu erfüllen. Die Spalte Beweis enthält einen Verweis auf ein Artefakt (einen Dokumentlink, ein Testlog oder eine Konfigurationsdatei).

Unten finden Sie ein Beispiel für die Tabelle, die wir pflegen. Es zeigt eine Teilmenge von Verpflichtungen im Zusammenhang mit Transparenz und Datenverwaltung. Die Tabelle wird in einem gemeinsam genutzten Tabellenkalkulationsprogramm gehalten, damit Produkt, Recht und Ingenieurwesen sie in Echtzeit aktualisieren können.

Verpflichtung (Akt-Wortlaut) | Kontrolle (was wir tun) | Beweis (Artefakt) Anbieter müssen sicherstellen, dass natürliche Personen darüber informiert werden, dass sie mit einem KI-System interagieren (Artikel 13(1)). | Ein persistentes Banner auf der Chat-Oberfläche hinzufügen, das „Sie sprechen mit einem KI-Assistenten“ anzeigt. | Screenshot des Banners im Staging-Umfeld (Link: interner Wiki/ai-banner). Anbieter müssen Informationen über die Fähigkeiten und Einschränkungen des KI-Systems in klarer und zugänglicher Weise bereitstellen (Artikel 13(2)). | Eine Modellkarte veröffentlichen, die den beabsichtigten Einsatz, bekannte Fehlermodi und Leistungsmetriken auflistet. | Modellkarte PDF im Compliance-Repository gespeichert (Pfad: docs/model-card-v2.pdf). Anbieter müssen geeignete Maßnahmen zur Datenverwaltung umsetzen, um sicherzustellen, dass die Trainingsdaten relevant, repräsentativ und frei von Fehlern sind (Artikel 10(1)). | Ein Nacht-Script zur Datenqualität ausführen, das fehlende Werte, Labelinkonsistenzen und out-of-Verteilungsmuster überprüft. | Script-Ausgabeprotokoll für den letzten Lauf (Link: interner Scripts/data-quality.log). Anbieter müssen die Schritte dokumentieren, die zur Minderung…

Die Tabelle macht es einfach, zu sehen, welche Verpflichtungen Beweise haben und welche nicht. Fehlende Beweiszeilen werden zu den Punkten in der Wiedergutmachungsarbeitsliste. Wir überprüfen die Tabelle bei jedem Sprint-Planungstreffen und weisen Besitzer zu, um die Lücken zu schließen.

Erstellung der Arbeitsliste: Schritte, die wir befolgen

Unser Prozess zur Umwandlung des Gesetzes in eine Arbeitsliste besteht aus fünf wiederholbaren Schritten. Jeder Schritt wird von einem kleinen, funktionsübergreifenden Team durchgeführt, das einen Rechtsanalysten, einen Produktmanager und einen Ingenieur umfasst.

- Quelltexte sammeln – laden Sie die offizielle Journal-Version des Gesetzes, die FAQ der Kommission und alle relevanten Standards (z. B. die OWASP LLM Top 10 oder den NIST AI RMF) herunter. Speichern Sie sie in einem schreibgeschützten Ordner. - Verpflichtungen extrahieren – kopieren Sie jeden Satz, der einen Auftrag an Anbieter auferlegt, in eine Masterliste. Verwenden Sie das wörtliche Wort; paraphrasieren Sie nicht in diesem Stadium. - In Aktionen übersetzen – schreiben Sie für jede Verpflichtung einen kurzen imperativen Satz, der beschreibt, was getan werden muss, um sie zu erfüllen. Halten Sie die Übersetzung unter 20 Wörtern, wo möglich. - Mit Kontrollen abgleichen – überprüfen Sie vorhandene Richtlinien, Code und Dokumentation, um zu sehen, ob bereits einige die übersetzte Aktion erfüllen. Wenn eine Übereinstimmung besteht, verlinken Sie den Beweis; wenn nicht, markieren Sie eine Lücke. - Lücken priorisieren – ordnen Sie eine Priorität basierend auf dem Risikolevel (hoch, mittel, niedrig) und dem Aufwandsschätzwert (klein, mittel, groß) zu. Hochrisikolücken mit geringem Aufwand werden zuerst angegangen.

Wir wiederholen den Zyklus, wenn das Gesetz geändert wird oder wenn wir eine neue Version des Modells veröffentlichen. Die Masterliste lebt in einer Confluence-Seite, die nur vom Compliance-Lead bearbeitet werden kann, um eine einzige Wahrheitsquelle sicherzustellen.

Beispiel: Transparenzpflichten (Artikel 13)

Artikel 13 konzentriert sich darauf, sicherzustellen, dass Benutzer wissen, dass sie mit einem KI-System interagieren, und verstehen, was es kann und nicht kann. Um dies zu erfüllen, haben wir drei konkrete Maßnahmen ergriffen.

Erstens haben wir einen sichtbaren Hinweis auf jedem benutzerorientierten Endpunkt hinzugefügt. Der Hinweis erscheint vor der ersten Interaktion und bleibt bis der Benutzer ihn ablehnt. Er enthält den genauen Satz, der durch das Gesetz erforderlich ist: „Sie interagieren mit einem KI-System“. Der Text des Hinweises wird in der Datei der Benutzeroberflächen-Zeichenfolgen (Pfad: src/i18n/de.json) gespeichert und wird von unserem automatisierten Benutzeroberflächen-Testframework überprüft.

Zweitens haben wir eine Modellkarte erstellt, die den beabsichtigten Einsatz, bekannte Einschränkungen und Leistungsmerkmale des Modells zusammenfasst. Die Karte folgt dem Format, das in der OWASP LLM Top 10-Richtlinie für Transparenz vorgeschlagen wird. Sie wird auf unserer internen Dokumentationswebsite gehostet und von der Hilfeseite des Produkts verlinkt.

Drittens haben wir eine quartalsweise Überprüfung eingerichtet, bei der das Produktteam überprüft, ob der Hinweis nach jedem Benutzeroberflächen-Release noch erscheint und ob die Modellkarte die neueste Version widerspiegelt. Jede Abweichung erstellt ein neues Lückenitem, das der Arbeitsliste hinzugefügt wird. Unsere Partner, wie unterstützen uns bei der Einhaltung dieser Vorschriften und stellen sicher, dass unsere KI-Systeme den Anforderungen der ClauseGuard und des entsprechen.

Beispiel: Datenregierungspflichten (Artikel 10)

Artikel 10 verlangt von den Anbietern, sicherzustellen, dass die für die Schulung verwendeten Daten angemessen sind und die ergriffenen Schritte zur Bekämpfung von Voreingenommenheit zu dokumentieren. Wir erfüllen diese Anforderungen durch eine Kombination aus automatisierten Überprüfungen und manueller Dokumentation.

Wir führen jede Nacht eine Datenqualitätspipeline aus, die den Trainingsdatensatz auf fehlende Werte, doppelte Einträge und Label-Fehler überprüft. Die Pipeline wird mit Open-Source-Komponenten erstellt und so konfiguriert, dass der Build fehlschlägt, wenn ein kritischer Schwellenwert überschritten wird. Die Pipeline-Protokolle werden in unserem Compliance-Bucket (Pfad: gs://clauseguard-compliance/data-quality/) archiviert.

Zur Minderung von Voreingenommenheit führen wir ein aktuelles Verzeichnis, das jede Intervention auflistet, die wir angewendet haben, wie z.B. die Neubewertung unterrepräsentierter Gruppen oder die Anpassung von Verlustgewichten. Das Verzeichnis enthält das Datum, den Grund für die Änderung und die gemessene Auswirkung auf Fairnessmetriken. Dieses Verzeichnis erfüllt die Dokumentationsanforderung und wird vom Ethikrat vor jeder Modellveröffentlichung überprüft.

Wir beziehen uns auch auf den NIST AI RMF, wenn wir Kontrollen für die Datenregierung auswählen. Die Kategorien des Rahmens (Govern, Map, Measure, Manage) helfen uns, zu überprüfen, ob unsere Pipeline alle notwendigen Aspekte abdeckt. Unsere Lösungen werden von unterstützt und sind mit kompatibel.

Was dies nicht ist

Dieser Lückenbericht ist kein Konformitätszertifikat. Er gewährleistet nicht, dass das KI-System alle Anforderungen des Gesetzes erfüllt. Er verspricht nicht, dass die Regulierungsbehörden die von uns vorgelegten Beweise annehmen. Er behauptet nicht, eine 100-%-Erfolgsrate bei der Identifizierung aller möglichen Lücken zu haben. Er behauptet nicht, dass die Arbeitsliste niemals ein Problem übersehen wird. Er ist einfach ein transparentes Protokoll darüber, was wir getan haben und was wir noch tun müssen, basierend auf den Quellen, die wir konsultiert haben.

Wie wir den Bericht auf dem neuesten Stand halten

Das Aufrechterhalten eines genauen Lückenberichts erfordert regelmäßige Aktualisierungen. Wir haben einen leichten Rhythmus eingeführt, der in unseren bestehenden Sprint-Zyklus passt.

Am Beginn jedes Sprints führt der Compliance-Verantwortliche ein Skript aus, das die aktuelle Version des Gesetzes (heruntergeladen vom offiziellen Portal der EU) mit der Master-Verpflichtungsliste vergleicht. Alle neuen oder geänderten Sätze werden als neue Zeilen hinzugefügt. Das Skript überprüft auch die Beweislinks, um zu sehen, ob sich einige geändert oder nicht mehr verfügbar sind; fehlerhafte Links werden für den verantwortlichen Besitzer gekennzeichnet.

Während der Sprint-Retrospektive überprüft das Team die Lückenliste und markiert Elemente als erledigt, wenn die zugehörigen Beweise hochgeladen und verifiziert wurden. Abgeschlossene Elemente werden in eine Archiv-Registerkarte verschoben, damit sie für Audits weiterhin zugänglich sind, aber die aktive Ansicht nicht überfüllen.

Alle Quartale halten wir ein formelles Überprüfungsmeeting mit den Verantwortlichen für Recht, Produkt und Ingenieurwesen ab. In diesem Meeting gehen wir die hochprioritären Lücken durch, bestätigen die Aufwandsschätzungen und passen die Zeitpläne bei Bedarf an. Das Ergebnis des Meetings ist eine kurze Aktualisierungsnotiz, die der Confluence-Seite hinzugefügt wird.

Da der Prozess leichtgewichtig und an bestehende Zeremonien geknüpft ist, vermeiden wir die Erstellung von zusätzlichem Overhead, während wir gleichzeitig sicherstellen, dass der Bericht den neuesten Rechtstext und unseren aktuellen Compliance-Zustand widerspiegelt.

Referenzen

- OWASP LLM Top 10 für Large Language Model-Anwendungen - NIST AI-Risikomanagement-Framework