Aangepaste LM's valideren en uitbrengen in gereguleerde domeinen

Notities uit de Release Cycle — Deel IV

Een general counsel komt de engineering-review binnen. Ze heeft één vraag: “Als er morgen een verzoek tot wissing onder artikel 17 van de EU AI Act binnenkomt waarin gevraagd wordt om elk feit dat ons model over een specifieke patiënt heeft geleerd te verwijderen, kunnen we dan bewijzen dat we dat gedaan hebben?”

Het eerlijke antwoord dat de meeste teams moeten geven luidt: “We kunnen het model fine-tunen om te vergeten. We kunnen je de training-run laten zien. Maar we kunnen niet bewijzen dat de informatie structureel weg is, omdat ze onder de juiste adversariële prompt weer kan opduiken.”

Dat is geen compliance-antwoord. Het is een non-antwoord met een procedureel schouderophalen.

Deze post gaat over hoe een echt compliance-antwoord eruitziet voor aangepaste LLM’s — over vier regelgevende kaders heen (EU AI Act, AVG artikel 17, HIPAA, NIST AI RMF), gekoppeld aan de pipeline met vier fasen (Register → Gate → Roll → Observe) die wij leveren voor klantreleases. De doorlopende spanning in elke vraag van elke toezichthouder is open-weights versus closed-API: wat je kunt bewijzen over een Gemma 4-finetune, kun je niet bewijzen over een release die achter een ondoorzichtige vendor-API wordt geserveerd. Het ontvangstbewijsformaat dat wij gebruiken zegt dat expliciet, regel voor regel. Die eerlijkheid is wat het ontvangstbewijs bruikbaar maakt voor een auditor.

De vier toezichthouders en wat ze elk daadwerkelijk vragen

Compliancediscussies vervallen vaak tot “we hebben dingen gedocumenteerd”. Die framing schiet tekort bij een auditor. Wat auditors willen is bewijs dat ze kunnen verifiëren zonder jouw infrastructuur te vertrouwen. De vier kaders hieronder gebruiken allemaal verschillende vocabulaires voor dezelfde onderliggende vraag.

De boetebedragen zijn niet wat deze kaders interessant maakt. De boetebedragen zijn wat ze dragend maakt. Het interessante onderdeel is de verificatieprimitief — hoe het artefact er volgens elk kader daadwerkelijk uit moet zien. Drie van de vier vragen om cryptografisch bewijsmateriaal in verschillende vocabulaires. Het vierde (NIST AI RMF) is vrijwillig maar de facto verplicht in enterprise-procurement. Ze komen samen op dezelfde vorm: een artefact dat een auditor kan verifiëren zonder je logs te vertrouwen.

De splitsing: open-weights versus closed-API

Vóór de mapping per fase volgt het belangrijkste voorbehoud in deze hele post:

Voor open-weights modelbackings — Gemma, Qwen, Llama, Mistral, GPT-OSS, alles waarbij de gewichten adresseerbaar en bewerkbaar zijn — emitteert elke Divinci-releasebeslissing een vindex-ontvangstbewijs met een weight-attestation: cryptografisch bewijs dat de actieve gewichten op het beslismoment exact de gewichten zijn die in het manifest geregistreerd staan. Dit is wat verifieerbare wissing onder AVG artikel 17 mogelijk maakt. Je past een DELETE-patch toe die een specifieke entiteit-relatie uit de gewichtsruimte verwijdert, het ontvangstbewijs bevat de hash van vóór en na, en een auditor kan verifiëren dat de wissing daadwerkelijk heeft plaatsgevonden door de verificatie opnieuw uit te voeren tegen de publieke vindex.

Voor closed-API modelbackings — OpenAI, Anthropic, Google via ondoorzichtige API’s — dekt hetzelfde ontvangstbewijs de beslisketen (welk manifest, welke gate-uitslag, welke monitor-meting, welke gebruiker welke actie triggerde) maar kan het geen aanspraak maken op gewichtsherkomst, omdat de provider geen gewichten beschikbaar stelt. Het ontvangstbewijs vermeldt dit expliciet in een veld weight_attestation: null met een note die uitlegt waarom. Dat is geen verminderde compliancepositie — het is de grens van wat verifieerbaar is, eerlijk opgeschreven. Een auditor die het ontvangstbewijs leest begrijpt exact welke klasse van bewijs wel en niet wordt geleverd.

Deze splitsing loopt door elke regelgeversvraag hieronder. Wanneer een kader iets eist op gewichtsniveau, kan het open-weights-pad dat invullen en het closed-API-pad niet. Dat zeggen we in het ontvangstbewijs, in plaats van een bewijs te impliceren dat we niet kunnen leveren.

Hoe elk kader op de vier pipelinefasen aansluit

De pipeline heeft vier fasen. De vraag van elke toezichthouder sluit aan op één of meer ervan. De onderstaande matrix is de werkelijke koppeling.

De twee ◐-cellen zijn de AVG-artikel-17-/open-weights-only-vermeldingen — dit zijn de vragen die het closed-API-pad niet volledig kan invullen. Al het overige geldt voor beide backings.

De rest van de post loopt door de bijdrage van elke fase.

Fase ① — Register

De Register-fase produceert een onveranderlijk JSON-manifest, geadresseerd via SHA-256. Voor gereguleerde releases bevat het manifest alles wat bijlage IV^[1] vraagt in één artefact:

• Het modelartefact (HF-repo + commit-SHA, of een vindex-patchreferentie)
• De prompt-template (elke variabele, elk systeembericht — onder versiebeheer)
• De routingregels (welke verkeersklasse op welke release terechtkomt)
• De datasetversie gebruikt om gate-drempels te berekenen (samenvatting trainingsdata via hash)
• De SHA van de vorige release (zodat de auditketen ononderbroken is)
• De disclosure-scope — voor HIPAA-deployments: welke PHI-categorieën het model mag ontvangen

Het manifest is de documentatie. Een auditor leest geen proza; ze lezen de manifest-hash en verifiëren de bundel. Geen zes-maanden-later geschreven prozasamenvatting nodig.

Open-weights-bonus. Wanneer het modelartefact verwijst naar een open-weights model, bevat het manifest ook de vindex_sha256 — de cryptografische vingerafdruk van de gepubliceerde vindex van het model. Die vingerafdruk is wat een derde partij in staat stelt om de actieve gewichten te verifiëren zonder ooit onze deployment-infrastructuur te hoeven vertrouwen.

Closed-API-voorbehoud. Wanneer het modelartefact verwijst naar een closed-API model, is het veld vindex_sha256 in het manifest null en is het weight_attestation_class van het manifest decision_chain_only. De auditor die dit leest, weet exact wat wel en wat niet wordt geclaimd.

Fase ② — Gate

De Gate-fase is waar de “maatregelen voor menselijk toezicht”^[1] uit de EU AI Act operationeel worden. Een toezichthouder die de EU AI Act leest en concludeert “we hebben een menselijke goedkeuringsworkflow nodig” mist het punt — de moeilijkere vraag is waartegen de mens goedkeurt. De Gate-fase beantwoordt die vraag met een per-slice Spearman-ρ tegen een door mensen verankerde beoordelaar^[3]. Elke slice die ertoe doet in jouw regelgevingspositie (pediatrische oncologie, IP-licentiëring, Belgisch Frans) krijgt zijn eigen drempel. Het overrride-pad vereist een schriftelijke rationale die in het audittrail terechtkomt.

Voor HIPAA-gedekte deployments leeft hier ook de “minimaal-noodzakelijke” disclosure-regel. De scored-QA-suite van de gate bevat negatieve tests voor PHI-overblootstelling — antwoorden die persoonlijke identifiers bevatten terwijl daarom niet werd gevraagd. Een release die regresseert op de over-exposure slice faalt op de gate, ongeacht hoe de andere slices presteren.

Voor NIST AI RMF dekt de Gate-fase de “measure”-functie — het numerieke bewijs per slice dat het systeem binnen geconfigureerde toleranties presteert.

Fase ③ — Roll

EU AI Act post-market monitoring^[1] vereist dat de operator doorlopende — niet alleen pre-launch — observatie van het AI-systeem in reële omstandigheden aantoont. Een 5% → 25% → 100% canary met kwaliteitsmonitor-checkpoints is de meest natuurlijke manier om hieraan te voldoen. De dwell op elk checkpoint, plus de monitor-metingen tijdens de dwell, is wat een auditor wil zien.

Voor HIPAA is de canary-fase ook waar per-verzoek audit-logging end-to-end wordt beproefd. Elk checkpoint produceert een steekproef van ondertekende verzoek/antwoord-ontvangstbewijzen; mocht een ervan een verkeerd geconfigureerde PHI-afhandeling hebben, dan komt dat aan het oppervlak bij 5% verkeer in plaats van bij 100%.

Fase ④ — Observe

Dit is de fase die het complianceverhaal verdient. De Observe-fase draait continue trace-replay door de actieve release, gescoord door dezelfde door mensen verankerde rechter uit Gate, met een kwaliteitsmonitor die een automatische rollback triggert als hij doorbreekt.

Elke releasebeslissing — register, gate-pass, gate-fail, gate-override, checkpoint-promote, checkpoint-hold, auto-rollback, manual-rollback, en elke toepassing van een AVG-artikel-17-DELETE-patch — emitteert een vindex-ontvangstbewijs. Hash-geketend aan het vorige ontvangstbewijs voor deze klant en het vorige ontvangstbewijs voor deze release.

Zo ziet een echt ontvangstbewijs eruit voor een AVG-artikel-17-DELETE-patch — rechtstreeks aangepast van het formaat dat op de compliancepagina is gedocumenteerd:

{
  "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)"
}

Dat artefact is verifieerbaar. Een auditor hoeft onze logs niet te vertrouwen. Ze pakken de vindex_sha256_after, halen de bijbehorende gepubliceerde vindex op van huggingface.co/Divinci-AI, en verifiëren dat feature 11179 in laag 27 structureel afwezig is in de top-25. Ze pakken de chain_signature en verifiëren deze tegen het voorgaande ontvangstbewijs. De hele keten wordt extern verankerd volgens een schema dat de klant configureert.

Dezelfde operatie tegen een closed-API model. De ontvangstbewijsvelden hierboven veranderen op drie manieren: operation.target wordt provider_api_endpoint, verification wordt een ander schema dat alleen bewijs uit de beslisketen dekt, en weight_attestation_class wordt decision_chain_only. De aanbieder van het closed-API model heeft geen gewichten beschikbaar gesteld, dus zegt het ontvangstbewijs dat. Een auditor die bewijs op gewichtsniveau wil, weet nu dat ze moeten escaleren naar de provider, niet naar ons.

Dit is de differentiatie die in 2026 niemand anders levert. Het eval-CI-kamp (Braintrust, Humanloop, Patronus) zit niet op verkeer en zendt geen beslissings-ontvangstbewijzen uit. Het serving-canary-kamp (SageMaker Deployment Guardrails^[2], KServe, Vertex, BentoCloud, Seldon) zendt infra-metric-logs uit maar geen hash-geketende compliance-ontvangstbewijzen. Het observability-kamp (Arize, Phoenix, Confident, Deepchecks) bekijkt output, maar handhaaft niet.

Wat verifieert een auditor daadwerkelijk?

Een nuttige oefening: loop de vragen door die een echte auditor zal stellen, en welk artefact elke vraag beantwoordt.

Wat de auditor niet hoeft te doen: onze Datadog vertrouwen. Onze CloudWatch vertrouwen. Een screenshot vertrouwen. Een export vertrouwen. Het hele punt van het ontvangstbewijsformaat is dat de auditor het onafhankelijk kan verifiëren.

Wat dit niet oplost

Drie eerlijke beperkingen:

Closed-API-regressies op AVG-artikel-17-terrein zijn niet oplosbaar op de platformlaag. Als je een healthcare-assistent achter een closed-API model serveert en een patiënt beroept zich op artikel 17, kan het platform attesteren dat het patiëntdossier is verwijderd uit je retrieval-store, je prompt-template en je routingregels — maar kan het niet attesteren dat de onderliggende modelgewichten de patiëntgegevens zijn vergeten. Je hebt ofwel een open-weights backing nodig, ofwel een toezegging van de vendor tot wissing op gewichtsniveau. Dat zeggen we in het ontvangstbewijs.

Documentatie is noodzakelijk maar niet voldoende. Een ontvangstbewijs dat bewijst dat een model een drempel haalde, bewijst niet dat de drempel de juiste drempel was. Als je scored-QA-suite niet de slice dekt die er voor een patiënt in jouw dienstverlening werkelijk toe doet, lost geen enkele hoeveelheid ontvangstbewijsketens dat op. Toezichthouders begrijpen dit steeds beter; “we hebben onze eval gehaald” is niet langer een voldoende compliance-antwoord als de eval de verkeerde eval was.

Het vindex-formaat is single-vendor. Wij gebruiken het omdat het de meest concrete cryptografische primitief is die vandaag beschikbaar is voor bewijs op gewichtsniveau. Als de industrie zich op een ander formaat vastlegt — model-cards-met-hashes, NIST-gepubliceerde artefactschema’s — zou het ontvangstbewijsformaat daarnaar moeten evolueren. De inhoud (hash-geketend, extern verifieerbaar, weight-attestation-bewust) is wat dragend is, niet de specifieke schema-naam. We verwachten dat dit verandert naarmate het regelgevings- en standaardenlandschap volwassen wordt.

FAQ

Wat is verifieerbare wissing onder AVG artikel 17 voor AI-systemen?

Verifieerbare wissing betekent dat een derde partij kan verifiëren dat de gegevens zijn verwijderd zonder je logs te hoeven vertrouwen. Een model fine-tunen om specifieke informatie te “vergeten” voldoet niet aan deze norm — de informatie kan onder adversariële prompting weer opduiken en er is geen cryptografische primitief die een auditor kan controleren. Een DELETE-patch op gewichtsniveau met een gepubliceerde voor/na-vindex-hash voldoet wel aan de norm, omdat de auditor de verificatie opnieuw kan uitvoeren tegen het publieke artefact.

Waarom kunnen closed-API modellen niet op dezelfde manier aan AVG artikel 17 voldoen?

Omdat de provider geen gewichten beschikbaar stelt. Zonder toegang tot de gewichten kan geen enkele derde partij — ook niet de klant die de API gebruikt — een wissing op gewichtsniveau uitvoeren of verifiëren. Het beslisketengedeelte van het ontvangstbewijs (welke prompt-template werd gebruikt, uit welke retrieval-store de data kwam, welke routingregels actief waren) is nog steeds verifieerbaar, maar de claim op gewichtsniveau niet. Dit is een grens van wat verifieerbaar is wanneer gewichten privé zijn, geen grens van het compliancekader.

Wat vereist bijlage IV van de EU AI Act, in begrijpelijk Nederlands?

Bijlage IV vraagt om technische documentatie die de logica van het systeem, de samenvatting van de trainingsdata, het beoogde gebruik, maatregelen voor menselijk toezicht en post-market monitoring dekt. De valkuil waar de meeste teams in vallen, is deze als vijf afzonderlijke documenten te behandelen. Het releasemanifest in fase 1 draagt de eerste drie vragen als één enkele hash; de Gate-fase dekt de vierde; de Roll- + Observe-fasen dekken de vijfde. Eén pipeline; vier vragen ingevuld als bijproduct van normale operaties.

Hoe snel moet de rollback zijn voor HIPAA-gedekte deployments?

HIPAA specificeert geen rollbacktijd, maar de HHS-richtlijnen voor breach-respons behandelen time-to-containment als dragend. Een rollback in de orde van seconden (in-flight drain op een manifest-gestuurde flip — ons getal is ongeveer 12 seconden) is structureel sneller dan een typische infra-metric blue-green die afhankelijk is van alarmpropagatie. Vergelijk met publieke postmortems: het incident van Cloudflare in juni 2022^[4] duurde 44 minuten om terug te draaien omdat engineers elkaars reverts oversprongen.

Hoe sluit NIST AI RMF aan op een releasepipeline?

De vier kernfuncties van NIST AI RMF — Govern, Map, Measure, Manage — beslaan de hele release-levenscyclus, niet één enkele fase. Govern is het gedocumenteerde releasebeleid plus de workflow voor gate-override-rationale (fasen Register + Gate). Map is de scored-QA-suite per slice (Gate). Measure is de Spearman-drempels per slice en de continue kwaliteitsmonitor (Gate + Observe). Manage is het rollback-pad en de ontvangstbewijsketen (Observe). Alle vier worden gedekt wanneer de pipeline zijn volledige ontvangstbewijsset emitteert.

References

1. EU AI Act. artificialintelligenceact.eu. Annex IV defines the technical documentation requirements for high-risk AI systems: system logic, training data summary, human oversight measures, post-market monitoring. Penalties up to 7% of global turnover for non-compliance.
2. AWS SageMaker Deployment Guardrails. Use canary traffic shifting + Auto-Rollback Configuration. Default TerminationWaitInSeconds 600, max MaximumExecutionTimeoutInSeconds 1800. Cited as the industry-standard infra-metric canary that the Stage 4 quality monitor is contrasted against.
3. Calibrated LLM-as-judge agreement. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS 2023). >80% overall GPT-4-vs-human agreement, with per-category variance from coding (86%) down to writing (36–44%). Anchor for the per-slice Spearman calibration that drives the Gate stage.
4. Cloudflare June 2022 outage. Cloudflare outage on June 21, 2022. 44 minutes from "we know what to revert" to revert complete because engineers walked over each other's reverts. Anchor for the "manifest-driven rollback can't have that failure mode" claim.
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.

Volgende in deze serie: Geautomatiseerde LLM-CI/CD-pipelines met instant rollback. Deze post liet zien wat een auditor wil. De volgende toont het operationele patroon dat het ontvangstbewijs in seconden in plaats van weken op het bureau van de auditor laat belanden — de automatisering onder de vier-fasen-pipeline, met focus op wat verandert wanneer de rollback uit zichzelf afgaat.