Validierung und Freigabe maßgeschneiderter LMs in regulierten Branchen

Notizen aus dem Release-Zyklus — Teil IV

Eine Justiziarin betritt das Engineering-Review. Sie hat eine Frage: „Wenn morgen ein Löschantrag nach EU AI Act Artikel 17 eingeht, der verlangt, dass wir jede Information entfernen, die unser Modell über einen bestimmten Patienten gelernt hat — können wir nachweisen, dass wir das getan haben?“

Die ehrliche Antwort, die die meisten Teams geben müssen, lautet: „Wir können das Modell mit Fine-Tuning zum Vergessen bringen. Wir können den Trainingslauf vorzeigen. Aber wir können nicht beweisen, dass die Information strukturell verschwunden ist, weil sie unter dem richtigen adversarialen Prompt wieder auftauchen könnte.“

Das ist keine Compliance-Antwort. Das ist eine Nicht-Antwort mit einem prozeduralen Achselzucken.

Dieser Beitrag handelt davon, wie eine echte Compliance-Antwort für maßgeschneiderte LLMs aussieht — über vier Regulierungsrahmen hinweg (EU AI Act, DSGVO Artikel 17, HIPAA, NIST AI RMF), abgebildet auf die vierstufige Pipeline (Register → Gate → Roll → Observe), die wir für Kunden-Releases ausliefern. Die zentrale Spannung, die sich durch die Forderung jedes Regulators zieht, lautet Open-Weights gegen Closed-API: Was Sie über ein Gemma-4-Fine-Tune beweisen können, lässt sich nicht über ein Release beweisen, das hinter einer undurchsichtigen Anbieter-API ausgeliefert wird. Das von uns verwendete Beleg-Format sagt das ausdrücklich, Zeile für Zeile. Genau diese Ehrlichkeit macht den Beleg für einen Prüfer brauchbar.

Die vier Regulatoren und was sie jeweils wirklich wollen

Compliance-Diskussionen verfallen oft in „wir haben Dinge dokumentiert“. Diese Rahmung scheitert bei einem Prüfer. Was Prüfer wollen, sind Belege, die sie überprüfen können, ohne Ihrer Infrastruktur vertrauen zu müssen. Die vier folgenden Rahmenwerke benutzen alle unterschiedliches Vokabular für dieselbe Grundforderung.

Die Sanktionszahlen sind nicht das, was diese Rahmenwerke interessant macht. Die Sanktionszahlen sind das, was sie tragfähig macht. Das Interessante ist das Verifikations-Primitive — wie das Artefakt nach Vorstellung des jeweiligen Rahmenwerks tatsächlich aussehen soll. Drei der vier fordern in unterschiedlichem Vokabular einen Nachweis in kryptographischer Qualität. Das vierte (NIST AI RMF) ist freiwillig, in der Enterprise-Beschaffung aber de facto Pflicht. Sie konvergieren auf dieselbe Form: ein Artefakt, das ein Prüfer überprüfen kann, ohne Ihren Logs vertrauen zu müssen.

Die Trennlinie: Open-Weights gegen Closed-API

Vor dem stufenweisen Mapping die wichtigste Einschränkung dieses gesamten Beitrags:

Bei Open-Weights-Modell-Backings — Gemma, Qwen, Llama, Mistral, GPT-OSS, alles, wo die Gewichte adressierbar und editierbar sind — emittiert jede Divinci-Release-Entscheidung einen vindex-Beleg, der eine Gewichtsattestierung enthält: einen kryptographischen Nachweis, dass die aktiven Gewichte zum Entscheidungszeitpunkt genau die Gewichte sind, die das Manifest registriert hat. Genau das macht die nachprüfbare Löschung nach DSGVO Artikel 17 möglich. Sie wenden einen DELETE-Patch an, der eine bestimmte Entitäts-Relation aus dem Gewichtsraum entfernt, der Beleg bettet den Hash vor und nach der Operation ein, und ein Prüfer kann die Löschung verifizieren, indem er die Verifikation gegen den öffentlichen vindex erneut ausführt.

Bei Closed-API-Modell-Backings — OpenAI, Anthropic, Google über undurchsichtige APIs — deckt derselbe Beleg die Entscheidungskette ab (welches Manifest, welches Gate-Ergebnis, welche Monitor-Messung, welcher Nutzer hat welche Aktion ausgelöst), kann aber keine Gewichts-Provenienz beanspruchen, weil der Anbieter die Gewichte nicht freilegt. Der Beleg vermerkt das ausdrücklich in einem Feld weight_attestation: null mit einem note-Feld, das die Begründung enthält. Das ist keine verschlechterte Compliance-Position — es ist die Grenze dessen, was verifizierbar ist, ehrlich niedergeschrieben. Ein Prüfer, der den Beleg liest, versteht genau, welche Beweisklasse erbracht wird und welche nicht.

Diese Trennlinie zieht sich durch jede der unten aufgeführten Regulatorenforderungen. Sobald ein Rahmenwerk etwas auf Gewichtsebene verlangt, kann der Open-Weights-Pfad das erfüllen und der Closed-API-Pfad nicht. Wir sagen das im Beleg, statt einen Beweis anzudeuten, den wir nicht liefern können.

Wie jedes Rahmenwerk auf die vier Pipeline-Stufen abgebildet wird

Die Pipeline hat vier Stufen. Die Forderung jedes Regulators bildet sich auf eine oder mehrere davon ab. Die folgende Matrix ist die tatsächliche Abbildung.

Die beiden ◐-Zellen sind die Einträge unter DSGVO Artikel 17 / nur Open-Weights — das sind die Forderungen, die der Closed-API-Pfad nicht vollständig erfüllen kann. Alles Übrige gilt für beide Backings.

Der Rest des Beitrags geht den Beitrag jeder einzelnen Stufe durch.

Stufe ① — Register

Die Register-Stufe erzeugt ein unveränderliches JSON-Manifest, adressiert per SHA-256. Für regulierte Releases trägt das Manifest alles, was Anhang IV^[1] verlangt, in einem einzigen Artefakt:

• Das Modell-Artefakt (HF-Repo + Commit-SHA, oder eine vindex-Patch-Referenz)
• Das Prompt-Template (jede Variable, jede System-Message — versionsverwaltet)
• Die Routing-Regeln (welche Traffic-Klasse landet auf welchem Release)
• Die Datensatzversion, mit der die Gate-Schwellenwerte berechnet wurden (Trainingsdaten-Zusammenfassung per Hash)
• Die SHA des vorhergehenden Releases (damit die Audit-Kette ungebrochen ist)
• Der Offenlegungs-Scope — bei HIPAA-Einsätzen die PHI-Kategorien, die das Modell empfangen darf

Das Manifest ist die Dokumentation. Ein Prüfer liest keinen Fließtext; er liest den Manifest-Hash und verifiziert das Bundle. Eine sechs Monate später nachgereichte Prosa-Zusammenfassung ist nicht nötig.

Open-Weights-Bonus. Wenn das Modell-Artefakt auf ein Open-Weights-Modell verweist, bettet das Manifest zusätzlich den vindex_sha256 ein — den kryptographischen Fingerabdruck des veröffentlichten vindex des Modells. Genau dieser Fingerabdruck ermöglicht es einer dritten Partei, die aktiven Gewichte zu verifizieren, ohne unserer Deployment-Infrastruktur jemals vertrauen zu müssen.

Closed-API-Vorbehalt. Wenn das Modell-Artefakt auf ein Closed-API-Modell verweist, ist das Manifestfeld vindex_sha256 gleich null, und die weight_attestation_class des Manifests lautet decision_chain_only. Der Prüfer, der das liest, weiß genau, was beansprucht wird und was nicht.

Stufe ② — Gate

In der Gate-Stufe wird die Anforderung des EU AI Act zu „menschlichen Aufsichtsmaßnahmen“^[1] operationalisiert. Ein Regulator, der den EU AI Act liest und daraus „wir brauchen einen menschlichen Freigabe-Workflow“ ableitet, hat den Punkt verfehlt — die schwierigere Frage lautet wogegen der Mensch eigentlich freigibt. Die Gate-Stufe beantwortet das mit einer Slice-spezifischen Spearman-ρ gegen einen menschlich verankerten Grader^[3]. Jeder Slice, der in Ihrer regulatorischen Lage zählt (pädiatrische Onkologie, IP-Lizenzierung, belgisches Französisch), bekommt seinen eigenen Schwellenwert. Der Override-Pfad verlangt eine schriftliche Begründung, die in den Audit-Trail eingeht.

Bei HIPAA-pflichtigen Einsätzen wohnt hier auch die „minimal nötige“ Offenlegungsregel. Die Scored-QA-Suite des Gates enthält negative Tests für PHI-Überexposition — Antworten, die persönliche Identifikatoren enthalten, obwohl danach nicht gefragt wurde. Ein Release, das auf dem Überexpositions-Slice regrediert, fällt durch das Gate, unabhängig davon, wie seine anderen Slices abschneiden.

Für NIST AI RMF deckt die Gate-Stufe die „Measure“-Funktion ab — die slice-spezifische numerische Evidenz, dass das System innerhalb konfigurierter Toleranzen arbeitet.

Stufe ③ — Roll

Die Marktüberwachung nach Release gemäß EU AI Act^[1] verlangt vom Betreiber, fortlaufende — und nicht nur vor-launch — Beobachtung des Verhaltens des KI-Systems unter realen Bedingungen nachzuweisen. Ein 5 % → 25 % → 100 %-Canary mit Qualitäts-Monitor-Checkpoints ist die natürlichste Form, das zu erfüllen. Die Verweildauer an jedem Checkpoint zuzüglich der Monitor-Messwerte während der Verweildauer ist genau das, was ein Prüfer sehen will.

Für HIPAA ist die Canary-Stufe auch der Ort, an dem das Audit-Logging pro Anfrage durchgehend geübt wird. Jeder Checkpoint produziert eine Stichprobe signierter Request-Response-Belege; falls einer davon eine fehlkonfigurierte PHI-Behandlung aufweist, fällt das bei 5 % Traffic auf statt erst bei 100 %.

Stufe ④ — Observe

Das ist die Stufe, die die Compliance-Geschichte einlöst. Die Observe-Stufe lässt fortlaufend Trace-Replay durch das aktive Release laufen, bewertet vom selben menschlich verankerten Judge aus dem Gate, mit einem Qualitäts-Monitor, der bei einer Schwellenwertverletzung einen automatischen Rollback auslöst.

Jede Release-Entscheidung — Register, Gate-Pass, Gate-Fail, Gate-Override, Checkpoint-Promote, Checkpoint-Hold, Auto-Rollback, manueller Rollback und jede Anwendung eines DELETE-Patches nach DSGVO Artikel 17 — emittiert einen vindex-Beleg. Hash-verkettet mit dem vorhergehenden Beleg für diesen Kunden und dem vorhergehenden Beleg für dieses Release.

So sieht ein echter Beleg für einen DELETE-Patch nach DSGVO Artikel 17 aus — direkt aus dem auf der Compliance-Seite dokumentierten Format adaptiert:

{
  "name": "gdpr-art17-patient-12348-removal",
  "version": 1,
  "base_model": "google/gemma-4-E2B-it",
  "manifest_sha256": "9abaeaf6c91f8b...",
  "previous_manifest_sha256": "8f72b1de4a93c5...",
  "created_at": "2026-05-29T03:17:42Z",
  "user_id": "compliance-officer-7c4e1a",
  "operation": {
    "op": "delete",
    "entity": "patient-record-12348",
    "relation": "diagnosis-association",
    "target": "weight-feature-11179-layer-27",
    "weight": -1.0
  },
  "verification": {
    "before_feature_11179_score": 17.34,
    "before_feature_11179_rank": 1,
    "after_feature_11179_score": null,
    "after_feature_11179_rank": "ABSENT_FROM_TOP_25",
    "perplexity_delta_wikitext103": "+0.02%",
    "vindex_sha256_before": "abc12...",
    "vindex_sha256_after":  "def34..."
  },
  "weight_attestation_class": "full",
  "chain_signature": "sha256(manifest || prev_manifest || user_id || created_at || prev_chain_signature)"
}

Dieses Artefakt ist verifizierbar. Ein Prüfer muss unseren Logs nicht vertrauen. Er nimmt den vindex_sha256_after, lädt den entsprechenden veröffentlichten vindex von huggingface.co/Divinci-AI und verifiziert, dass Feature 11179 in Layer 27 strukturell nicht mehr unter den Top-25 erscheint. Er nimmt die chain_signature und verifiziert sie gegen den vorhergehenden Beleg. Die gesamte Kette wird extern verankert, nach einem vom Kunden konfigurierten Zeitplan.

Dieselbe Operation gegen ein Closed-API-Modell. Die Beleg-Felder oben ändern sich in drei Punkten: operation.target wird zu provider_api_endpoint, verification wird zu einem anderen Schema, das nur Belege der Entscheidungskette enthält, und weight_attestation_class wird zu decision_chain_only. Der Closed-API-Modellanbieter hat die Gewichte nicht freigelegt, also sagt der Beleg genau das. Ein Prüfer, der einen Nachweis auf Gewichtsebene will, weiß nun, dass er das beim Anbieter eskalieren muss, nicht bei uns.

Das ist die Differenzierung, die im Jahr 2026 sonst niemand ausliefert. Das Eval-CI-Lager (Braintrust, Humanloop, Patronus) sitzt nicht auf dem Traffic und emittiert keine Entscheidungsbelege. Das Serving-Canary-Lager (SageMaker Deployment Guardrails^[2], KServe, Vertex, BentoCloud, Seldon) emittiert Infra-Metrik-Logs, aber keine hash-verketteten Compliance-Belege. Das Observability-Lager (Arize, Phoenix, Confident, Deepchecks) beobachtet Output, erzwingt aber nichts.

Was prüft ein Auditor tatsächlich?

Eine nützliche Übung: die Fragen durchgehen, die ein echter Prüfer stellen wird, und welches Artefakt jeweils antwortet.

Was der Prüfer nicht tun muss: unserem Datadog vertrauen. Unserem CloudWatch vertrauen. Einem Screenshot vertrauen. Einem Export vertrauen. Genau der Sinn des Beleg-Formats ist, dass der Prüfer es unabhängig verifizieren kann.

Was das nicht löst

Drei ehrliche Einschränkungen:

Closed-API-Regressionen im Gebiet von DSGVO Artikel 17 sind auf Plattformebene nicht lösbar. Wenn Sie einen Healthcare-Assistenten hinter einem Closed-API-Modell ausliefern und ein Patient sich auf Artikel 17 beruft, kann die Plattform attestieren, dass der Datensatz des Patienten aus Ihrem Retrieval-Store, Ihrem Prompt-Template und Ihren Routing-Regeln entfernt wurde — sie kann aber nicht attestieren, dass die zugrundeliegenden Modellgewichte die Daten des Patienten vergessen haben. Sie brauchen entweder ein Open-Weights-Backing oder eine Zusage des Anbieters zur Löschung auf Gewichtsebene. Wir sagen das im Beleg.

Dokumentation ist notwendig, aber nicht hinreichend. Ein Beleg, der nachweist, dass ein Modell einen Schwellenwert erreicht hat, beweist nicht, dass der Schwellenwert der richtige Schwellenwert war. Wenn Ihre Scored-QA-Suite den Slice nicht abdeckt, der für einen Patienten in Ihrem Service tatsächlich relevant ist, repariert keine noch so lange Beleg-Kette das. Regulatoren begreifen das zunehmend; „wir haben unsere Eval bestanden“ ist keine ausreichende Compliance-Antwort mehr, wenn die Eval die falsche Eval war.

Das vindex-Format ist Single-Vendor. Wir verwenden es, weil es das konkreteste kryptographische Primitive ist, das heute für Gewichts-Nachweise verfügbar ist. Sollte die Branche sich auf ein anderes Format einigen — Model-Cards-mit-Hashes, NIST-veröffentlichte Artefakt-Schemata — sollte sich das Beleg-Format dahin entwickeln. Tragend ist die Substanz (hash-verkettet, extern verifizierbar, gewichts-attestierungsbewusst), nicht der spezifische Schema-Name. Wir erwarten, dass sich das ändert, sobald die regulatorische und Standardisierungslandschaft reift.

FAQ

Was bedeutet nachprüfbare Löschung nach DSGVO Artikel 17 für KI-Systeme?

Nachprüfbare Löschung bedeutet, dass eine dritte Partei verifizieren kann, dass die Daten entfernt wurden, ohne Ihren Logs vertrauen zu müssen. Ein Modell durch Fine-Tuning zum „Vergessen“ spezifischer Informationen zu bringen, erfüllt diesen Standard nicht — die Informationen können unter adversarialem Prompting wieder auftauchen, und es existiert kein kryptographisches Primitive, das ein Prüfer überprüfen könnte. Ein DELETE-Patch auf Gewichtsebene mit einem veröffentlichten Vorher-/Nachher-vindex-Hash erfüllt den Standard, weil der Prüfer die Verifikation gegen das öffentliche Artefakt erneut ausführen kann.

Warum können Closed-API-Modelle DSGVO Artikel 17 nicht auf dieselbe Weise erfüllen?

Weil der Anbieter die Gewichte nicht freilegt. Ohne Zugang zu den Gewichten kann keine dritte Partei — einschließlich des Kunden, der die API nutzt — eine Löschung auf Gewichtsebene anstoßen oder verifizieren. Der Teil des Belegs, der die Entscheidungskette betrifft (welches Prompt-Template verwendet wurde, aus welchem Retrieval-Store die Daten stammten, welche Routing-Regeln aktiv waren), bleibt verifizierbar, der Anspruch auf Gewichtsebene jedoch nicht. Das ist eine Grenze dessen, was verifizierbar ist, wenn Gewichte privat sind, keine Grenze des Compliance-Rahmens.

Was verlangt Anhang IV des EU AI Act in einfachen Worten?

Anhang IV fordert technische Dokumentation, die die Logik des Systems, eine Trainingsdaten-Zusammenfassung, den vorgesehenen Einsatz, menschliche Aufsichtsmaßnahmen und die Marktüberwachung nach Release abdeckt. Die Falle, in die die meisten Teams tappen, ist, das als fünf separate Dokumente zu behandeln. Das Release-Manifest in Stufe 1 trägt die ersten drei Forderungen als einen einzigen Hash; die Gate-Stufe deckt die vierte ab; die Stufen Roll + Observe decken die fünfte ab. Eine Pipeline; vier Forderungen als Nebenprodukt des Normalbetriebs erfüllt.

Wie schnell sollte ein Rollback für HIPAA-pflichtige Einsätze sein?

HIPAA spezifiziert keine Rollback-Zeit, aber die Leitlinien der HHS zur Reaktion auf Datenschutzverletzungen behandeln Time-to-Containment als tragend. Ein Rollback in der Größenordnung von Sekunden (Drain in-flight auf einem manifest-getriebenen Flip — unsere Zahl liegt bei rund 12 Sekunden) ist strukturell schneller als ein typisches Infra-Metrik-Blue-Green, das von Alarm-Propagation abhängt. Vergleichen Sie das mit öffentlichen Post-Mortems: Der Cloudflare-Vorfall vom Juni 2022^[4] brauchte 44 Minuten zum Revert, weil Engineers die Reverts der Kollegen überschrieben.

Wie bildet sich NIST AI RMF auf eine Release-Pipeline ab?

Die vier Kernfunktionen von NIST AI RMF — Govern, Map, Measure, Manage — spannen den gesamten Release-Lifecycle auf, nicht nur eine einzelne Stufe. Govern ist die dokumentierte Release-Policy plus der Workflow zur Begründung von Gate-Overrides (Stufen Register + Gate). Map ist die slice-spezifische Scored-QA-Suite (Gate). Measure sind die slice-spezifischen Spearman-Schwellenwerte und der kontinuierliche Qualitäts-Monitor (Gate + Observe). Manage ist der Rollback-Pfad und die Beleg-Kette (Observe). Alle vier sind abgedeckt, sobald die Pipeline ihre vollständige Beleg-Sammlung emittiert.

References

1. EU AI Act. artificialintelligenceact.eu. Anhang IV definiert die Anforderungen an die technische Dokumentation für Hochrisiko-KI-Systeme: Systemlogik, Trainingsdaten-Zusammenfassung, menschliche Aufsichtsmaßnahmen, Marktüberwachung nach Release. Sanktionen von bis zu 7 % des globalen Umsatzes bei Verstoß.
2. AWS SageMaker Deployment Guardrails. Use canary traffic shifting + Auto-Rollback Configuration. Default TerminationWaitInSeconds 600, max MaximumExecutionTimeoutInSeconds 1800. Zitiert als der branchenübliche Infra-Metrik-Canary, gegen den der Qualitäts-Monitor von Stufe 4 abgegrenzt wird.
3. Calibrated LLM-as-judge agreement. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS 2023). >80 % Gesamtübereinstimmung GPT-4 gegen Mensch, mit kategorie-spezifischer Varianz von Coding (86 %) bis Writing (36–44 %). Anker für die slice-spezifische Spearman-Kalibrierung, die die Gate-Stufe antreibt.
4. Cloudflare June 2022 outage. Cloudflare outage on June 21, 2022. 44 Minuten von „wir wissen, was wir reverten müssen" bis zum abgeschlossenen Revert, weil Engineers die Reverts der Kollegen überschrieben. Anker für die Behauptung, dass „ein manifest-getriebener Rollback diesen Fehlermodus nicht haben kann".
5. NIST AI Risk Management Framework. NIST AI RMF. Voluntary framework — Govern, Map, Measure, Manage — that has become the de facto enterprise procurement baseline for AI governance. Voluntary but enforced in practice through customer due-diligence questionnaires.
6. HIPAA Privacy Rule. HHS Office for Civil Rights. Minimum-necessary disclosure, access audit, and breach response timing requirements applicable to any AI system that touches PHI. Civil monetary penalties up to $1.9M per violation-type per year per CMP inflation adjustment, 2025.
7. GDPR Article 17 (Right to Erasure). gdpr-info.eu/art-17-gdpr. The data subject's right to obtain erasure of personal data, and the controller's obligation to demonstrate compliance under Article 5(2) accountability. Penalties up to €20M or 4% of annual global turnover.
8. Internal — vindex receipt format. The receipt JSON in this post is adapted from the format documented on the compliance page and demonstrated in the "Deleting Paris from a Language Model" post. The hash chain is SHA-256 over manifest || prev_manifest || user_id || created_at || prev_chain_signature. Externally anchorable on a customer-configured schedule.

Als Nächstes in dieser Reihe: Automatisierte LLM-CI/CD-Pipelines mit sofortigem Rollback. Dieser Beitrag hat gezeigt, was ein Prüfer will. Der nächste zeigt das operationelle Muster, das dafür sorgt, dass der Beleg in Sekunden statt Wochen auf dem Schreibtisch des Prüfers landet — die Automatisierung unter der vierstufigen Pipeline, mit Fokus darauf, was sich ändert, wenn der Rollback von selbst feuert.