De 12 QA- en release-managementcapaciteiten die elk custom-LLM-platform moet leveren

Aantekeningen uit de Release Cycle — Deel III

Een jaar geleden, voordat we aan onze eigen release-pipeline begonnen te bouwen, gingen we zitten en somden we elke QA-en-release-capaciteit op waarvan we dachten dat een serieus LLM-platform die zou moeten leveren. Vervolgens evalueerden we twaalf andere platforms tegen die lijst — LangSmith, MLflow, Weights & Biases, Braintrust, Humanloop, Patronus, Arize, Phoenix, Confident, Deepchecks, SageMaker Deployment Guardrails, KServe, BentoCloud, Vertex AI Endpoints, Seldon Core. Niemand had alle twaalf. De combinaties die wel werden geleverd, clusterden zich in drie kampen die elkaar niet helemaal raakten.

Deze post is de resulterende capaciteitenlijst, op zichzelf bruikbaar gemaakt. Hij is georganiseerd volgens welke van onze vier pipeline-stadia elke capaciteit toebehoort — Registreer → Gate → Roll → Observeer — zodat hij netjes aansluit op de pipeline-architectuur en de faalmodi waarover we eerder geschreven hebben. Als je tools evalueert, werk de lijst dan van boven naar beneden tegen elke kandidaat; degenen met de diepste lacunes zullen je vertellen tot welk kamp ze behoren.

De drie kampen (zodat je weet waar je naar kijkt)

Vóór de checklist zelf, de vorm van de markt in 2026:

• Eval-CI-kamp — Braintrust, Humanloop, Patronus. Voeren geautomatiseerde evaluators uit bij PR-merge. Blokkeren slechte merges. Raken nooit live verkeer aan. Sterk op capaciteiten 4–6; afwezig op 7–12.
• Serving-canary-kamp — SageMaker Deployment Guardrails, KServe, Vertex AI Endpoints, BentoCloud, Seldon Core. Splitsen verkeer, monitoren infrastructuurmetrieken, auto-rollback op CloudWatch-achtige alarmen. Sterk op 1, 7, 9; afwezig aan de kwaliteitskant van 8 en 10–12.
• Observability-kamp — Arize Phoenix, Confident AI, Deepchecks. Bekijken productie, alarmeren mensen, escaleren. Sterk op 10 (monitoring), maar ze handhaven niets — alerting is geen auto-rollback.

Het gat tussen deze kampen — tussen “CI gepasseerd” en “live canary beoordeeld op kwaliteit, niet alleen latency” — is het deel dat iedereen handmatig moet overbruggen. Het sluiten van dat gat is de dragende claim in deze post.

De ontbrekende naad: per-slice kwaliteitsgate → atomic rollback aangedreven door outputkwaliteit, niet door infra-metrieken.

Stadium ① — Registreer

Capaciteit 1. Onveranderlijk release-manifest met een content-addressable SHA

Wat het is: een release is geen modelgewichtsbestand. Een release is een onveranderlijke bundel van alles — modelartefact, prompttemplate, routingregels, datasetversie, preprocessing-versie — geadresseerd door één enkele SHA-256. Twee mensen die “dezelfde release” uitrollen moeten dezelfde SHA produceren, anders weigert de pipeline.

Waarom het ertoe doet: zonder dit is “welke wijziging heeft productie gebroken?” onbeantwoordbaar wanneer state over drie systemen is gesplitst. Atlassian’s storing van april 2022^[1] duurde specifiek twaalf uur per site om te herstellen omdat state leefde in onafhankelijk geversioneerde systemen die weer met elkaar in overeenstemming moesten worden gebracht.

Wie levert het: serving-canary-kamp deels (model + routing); modelregisters (MLflow, W&B Models^[2]) deels (alleen modelartefact). Bijna niemand bundelt de prompttemplate in de SHA, wat juist het veld is dat het vaakst verandert.

Capaciteit 2. Atomaire versiebeheer over alle release-componenten

Wat het is: de overgang van release A naar release B wisselt alles in één instructie — gewichten en prompt en routing en dataset en preprocessing — niet als vijf afzonderlijke dashboardbewerkingen.

Waarom het ertoe doet: gedeeltelijke wissels creëren undefined-behavior-vensters. Als de prompt wordt bijgewerkt maar de routingregel niet, is elk verzoek dat de nieuwe prompt met de oude routingklasse raakt in een staat die niemand heeft gepland.

Wie levert het: niemand volledig. Het serving-canary-kamp wisselt de modelimage atomair; de prompt en routing leven doorgaans elders. Manifest-gestuurde wissels zijn waar Divinci’s atomic-rollback-claim^[5] vandaan komt.

Capaciteit 3. Training-serving omgevingspariteit

Wat het is: de preprocessing-pipeline die wordt gebruikt tijdens gate-evaluatie is dezelfde preprocessing die de productieserver gebruikt. Als ze divergeren, is elk offline cijfer een leugen.

Waarom het ertoe doet: training-serving skew is een van de tien release-fouten waarover we hebben geschreven. Het symptoom is “presteert prima in eval, gedraagt zich als een ander model in productie.” De remedie is preprocessing in het manifest registreren en gaten ten opzichte van de productie-preprocessingversie.

Wie levert het: containerization-frameworks (BentoML, KServe) krijgen gedeeltelijke punten door preprocessing samen met serving te plaatsen. Geen van hen bindt preprocessing aan de eval-gate-input.

Stadium ② — Gate

Capaciteit 4. Per-slice / per-domein kwaliteitsgate

Wat het is: de gate-beslissing consumeert per-slice scores — contractopstelling, statutaire interpretatie, IP-licentiëring — niet één enkel aggregaat. Elke individuele slice die onder zijn drempel valt, markeert de release gate_fail, ongeacht hoe het gemiddelde eruitziet.

Waarom het ertoe doet: aggregaatscores wassen gelokaliseerde regressies weg. Tianpan’s Semver Lie-rapport^[3] noemt dit als de dominante LLM-release-faalmodus van 2026: een model dat gemiddeld verbetert terwijl het stilletjes instort op één klasse user journeys.

Wie levert het: niemand anders in 2026. Eval-CI-tools — Braintrust, Humanloop, Patronus — scoren tegen één enkele globale rubriek of een platte takenlijst. Ze stellen geen per-slice drempel of slice-blinde override beschikbaar. Dit is de eerste plek waar de kampen elkaar niet kunnen ontmoeten.

Capaciteit 5. Mens-verankerde gekalibreerde judge (Spearman ρ versus mensbeoordelingen)

Wat het is: de judge is geen generieke LLM-as-judge. Het is een LLM-judge wiens Spearman ρ tegen een paneel van domeinexperts wordt gemeten en per slice geconfigureerd. De judge wordt geselecteerd omdat zijn rangordes overeenkomen met die van de mens, niet omdat hij een sterke reputatie heeft.

Waarom het ertoe doet: MT-Bench^[6] laat zien dat GPT-4-as-judge >80% overeenstemt met mensen over het geheel, met per-categorie variantie van coderen (86%) tot schrijven (36–44%). “Algehele overeenstemming” verbergt de slices waarin de judge onbetrouwbaar is. Het per slice kalibreren van de judge is de enige eerlijke manier om geautomatiseerde scoring betrouwbaar te maken.

Wie levert het: Braintrust, Humanloop, Patronus voeren judge-evaluators uit. Geen van hen vereist, exposeert of bewaart een per-slice mens-verankerde Spearman-kalibratie. De Divinci-kalibratiepipeline is gedocumenteerd in Calibrating the AI Judge.

Capaciteit 6. Override-pad met verplichte schriftelijke onderbouwing

Wat het is: het forceren van een gate-overschrijding is toegestaan (koude starts, geaccepteerde regressies, enz.) maar vereist twee velden — forceGateOverride: true EN overrideReason: "...". De reden gaat in het audittrail naast het gebruikers-ID. Geen anonieme overrides.

Waarom het ertoe doet: governance-gates zijn geen aparte compliance-feature; ze zijn een eigenschap van het gate-stadium zelf. Het audittrail moet niet alleen antwoord geven op “is deze override gebruikt?” maar ook op “wat was de onderbouwing op dat moment?” — want toekomstig-jij moet het lezen.

Wie levert het: eval-CI-tools hebben flags; geen van hen vereist de onderbouwing als structureel onderdeel van de override.

Stadium ③ — Roll

Capaciteit 7. Multi-checkpoint canary met dwell

Wat het is: verkeer beweegt van 0% naar productie via ten minste drie checkpoints — typisch 5% → 25% → 100% — en blijft bij elk hetzij voor een geconfigureerde dwell-tijd of een geconfigureerd aantal verzoeken, welke ook later komt. Geen instant 0%→100%.

Waarom het ertoe doet: long-tail bugs komen op schaal aan de oppervlakte. Een bug die 0,3% van de conversaties treft, is onzichtbaar op een 100-prompt eval en duidelijk op 5% van het productieverkeer. De dwell is wat de canary tijd geeft om de long tail te zien.

Wie levert het: het serving-canary-kamp levert dit. AWS SageMaker Deployment Guardrails^[4] documenteert een standaard TerminationWaitInSeconds van 600 (tien minuten). KServe, BentoCloud, Seldon en Vertex bieden allemaal vergelijkbare multi-step canary-configuraties. Dit is de verzadigde capaciteit.

Capaciteit 8. Outputkwaliteitsmonitor bij elk canary-checkpoint

Wat het is: bij elk checkpoint controleert de pipeline drie monitors voordat hij doorgaat — p95-latency, 5xx-rate, en een outputkwaliteitsscore berekend door dezelfde gekalibreerde judge uit capaciteit 5. Latency en 5xx alleen zijn niet genoeg.

Waarom het ertoe doet: dit is waar de kampen elkaar opnieuw niet ontmoeten. SageMaker, KServe, Vertex, BentoCloud, Seldon bewaken allemaal latency en foutpercentage. Geen van hen levert een per-checkpoint outputkwaliteitsmonitor — omdat ze geen gekalibreerde judge hebben om tegen te scoren. De eval-CI-tools hebben de judge maar zitten niet op het verkeer.

Wie levert het: niemand voltooit de brug. De dwelling-canary-infrastructuur bestaat in het serving-kamp; de gekalibreerde judge bestaat in het eval-CI-kamp; we hebben niemand gezien die ze met elkaar verbindt.

Capaciteit 9. Automatische stop bij kwaliteitsschending

Wat het is: een canary-checkpoint dat faalt op outputkwaliteit stopt automatisch. Promotie gaat niet verder. Geen menselijke page nodig om de uitrol te stoppen.

Waarom het ertoe doet: mensen zitten niet in de loop binnen de tijdspanne waarin uitrollen verlopen. Tegen de tijd dat een klantticket binnenkomt, is het 25%-checkpoint voorbij en heeft de 100%-promotie plaatsgevonden.

Wie levert het: serving-canary-kamp stopt op infrastructuurmetrieken. De kwaliteitsmetriek-stop is het deel dat capaciteit 8 vereist om te bestaan.

Stadium ④ — Observeer

Capaciteit 10. Continue productie-trace-replay door de kandidaat

Wat het is: nadat de canary naar 100% promoveert, blijft de observer draaien. Hij sampelt recente productie-traces, replayt ze door de kandidaat-(nu actieve)release, scoort ze met de gekalibreerde judge en zendt per minuut een kwaliteitsscore uit. Continu, niet periodiek.

Waarom het ertoe doet: stille kwaliteitsdalingen — model dat hedget, vol overtuiging een datum hallucineert, weigert waar dat niet zou moeten — verplaatsen nooit latency of 5xx. Het enige signaal dat je hiervoor krijgt is het klantticket, wat het slechtst mogelijke signaal is. Een continue kwaliteitsmonitor vangt ze in enkele minuten.

Wie levert het: niemand. Observability-kamp (Arize, Phoenix, Confident, Deepchecks^[7]) monitort productie-output maar handhaaft niet. Het serving-canary-kamp bewaakt infra. Het eval-CI-kamp zit niet op het verkeer. De gesloten lus — productie-traces → gekalibreerde judge → handhaving — is de ontbrekende naad.

Capaciteit 11. Atomic rollback in seconden, niet minuten

Wat het is: wanneer de observer afgaat (drie opeenvolgende minuten onder de drempel, bijvoorbeeld), wordt rollback automatisch afgevuurd. De rollback wijst routing opnieuw naar previous_release uit het manifest. Omdat de vorige release een volledig gebundeld manifest was, wisselt elke component atomair. End-to-end inclusief in-flight drain op een ~100-replica service: ongeveer 12 seconden^[5].

Waarom het ertoe doet: Cloudflare’s storing van juni 2022^[8] duurde 44 minuten om terug te draaien. De oorzaak was niet de terugdraaiing zelf — het was dat engineers over elkaars terugdraaiingen heen liepen omdat state gesplitst was. Manifest-gestuurde rollback is single-instruction; dat faalmodel kan niet voorkomen.

Wie levert het: serving-canary-kamp levert snelle infrastructuur-rollback (alarm-getriggerd, blue-green flip). Het architecturale verschil is of de trigger alleen infra is of kwaliteitsbewust (capaciteit 10).

Capaciteit 12. Hash-chained, extern verankerbaar compliance-ontvangstbewijs

Wat het is: elke releasebeslissing — register, gate-pass, gate-fail, gate-override, checkpoint-promote, auto-rollback — zendt een JSON-met-SHA-256 ontvangstbewijs uit, hash-chained aan het vorige ontvangstbewijs voor deze klant en het vorige ontvangstbewijs voor deze release. De keten wordt extern verankerd op een door de klant geconfigureerd schema.

Open-weights kanttekening. Wanneer de release wordt ondersteund door een open-weights model (Gemma, Qwen, Llama, Mistral, GPT-OSS), bevat het ontvangstbewijs een vindex weight-attestation — een bewijs dat de actieve gewichten op het beslissingsmoment de gewichten zijn die het manifest heeft geregistreerd. Wanneer de release wordt ondersteund door een closed-API model (OpenAI, Anthropic, Google via opaque APIs), dekt het ontvangstbewijs de beslissingsketen maar kan het geen aanspraak maken op weight-provenance, omdat de provider geen gewichten blootstelt. Het ontvangstbewijs zegt dat expliciet. Dit is de grens van wat verifieerbaar is.

Waarom het ertoe doet: gereguleerde sectoren krijgen vandaag logs. De EU AI Act en NIST AI RMF^[9] vragen steeds meer om bewijzen. Een hash-chained ontvangstbewijs is het verschil tussen “we hebben een log” en “een auditor kan de keten verifiëren zonder ons log te vertrouwen.”

Wie levert het: niemand anders. Dit is het deel van de differentiatie dat direct aansluit op Divinci’s bestaande compliance-pagina — hetzelfde ontvangstbewijsformaat, uitgebreid naar releasebeslissingen.

De 12 capaciteiten, per platformkamp

Het patroon is het punt. Vijf capaciteiten — per-slice gate, gekalibreerde judge, kwaliteits-canary-monitor, closed-loop replay, hash-chained ontvangstbewijs — verschijnen als ✗ over elk ander kamp. Dat is de naad. De andere zeven verdelen zich over de kampen op manieren die elk kamp intern coherent maar wederzijds incompleet maken.

Wat maakt QA anders voor custom language models dan voor software?

LLMs zijn niet deterministisch, zelfs op temperatuur nul — batching en hardwareverschillen veroorzaken outputvariatie. Die ene eigenschap breekt de meeste aannames waarop traditionele QA werd gebouwd:

• Je kunt geen expect(output).toEqual(X) assertions schrijven. Je hebt een distributiebewuste evaluatie nodig die rangcorrelatie consumeert tegen een mens-verankerde grader, niet gelijkheid tegen een fixture. Dit is waar capaciteit 5 over gaat.
• Een model kan een aggregaat-kwaliteitscheck passeren terwijl het faalt op een slice. Dat is waarom capaciteit 4 apart bestaat. Als je eval niet kan slicen, kan hij slice-bewuste regressies niet vangen.
• Kwaliteitsfouten zijn stil op de infrastructuurlaag. Latency en 5xx blijven schoon terwijl het model hedget of hallucineert. Capaciteiten 8 en 10 bestaan omdat geen infrastructuurmonitor dit kan zien.
• Rollback is niet optioneel. Omdat faalmodi probabilistisch zijn en sommige stil, moet het rollback-pad primaire infrastructuur zijn, geen back-upplan. Capaciteit 11 is wat “12 seconden” haalbaar maakt; capaciteit 2 is wat het correct maakt.

Een QA-en-release-platform dat geen rekening houdt met deze vier feiten, levert deterministische-software CI/CD met een LLM-logo erop geplakt. De markt doet dit veel.

Hoe ondersteunen audittrails AI-compliance, in de praktijk?

Het meest voorkomende compliance-gat dat we zien — wanneer een auditor zes maanden na deployment arriveert en vraagt “welke versie van het model draaide op 15 maart, en wie heeft die release goedgekeurd?” — is niet “we hebben geen logs.” Het is “we hebben logs verspreid over vijf systemen en de tijdlijnen komen niet overeen.”

Een compliance-ontvangstbewijs (capaciteit 12) lost dit op door het log zelf een verplaatsbaar artefact te maken: hash-chained, single-source, extern verankerbaar. Een auditor kan de keten verifiëren zonder onze infrastructuur te vertrouwen. Dat is het verschil tussen “we hebben records” en “de records zijn aantoonbaar.”

Voor open-weights modelondersteuning bevat het ontvangstbewijs ook een weight-attestation — een cryptografisch bewijs dat de actieve gewichten de gewichten zijn die het manifest heeft geregistreerd. Dit voldoet aan de zwaardere verzoeken (GDPR Artikel 17 recht op vergetelheid, EU AI Act provenance) omdat je niet alleen kunt bewijzen wat is uitgerold maar dat de onderliggende gewichten zijn wat ze beweren te zijn.

Voor closed-API-ondersteuning — wanneer het model wordt geleverd achter een opaque API en de gewichten niet worden blootgesteld — dekt het ontvangstbewijs de beslissingsketen maar kan het geen aanspraak maken op weight-provenance. We zeggen dit expliciet in het ontvangstbewijs in plaats van een bewijs te impliceren dat we niet kunnen leveren. Het is de grens van wat verifieerbaar is wanneer de provider gewichten intern houdt.

Wat deze checklist niet oplost

Drie eerlijke beperkingen:

Capaciteiten zijn geen vinkjes voor het vinkje. Een platform dat alle twaalf slecht levert, is erger dan een dat er acht goed levert. De checklist is een startpunt voor evaluatie, geen scorekaart voor vendor-RFP’s.

De competitieve momentopname is 2026 en zal verschuiven. Over zes maanden zullen enkele van de ✗-markeringen hierboven omdraaien — concurrenten zullen postmortems lezen en gaten dichten. Als je deze post in 2027 leest, controleer de markeringen dan zelf voordat je ze gelooft.

Sommige capaciteiten hangen af van andere. Capaciteit 8 (outputkwaliteits-canary-monitor) vereist capaciteit 5 (gekalibreerde judge). Capaciteit 10 (closed-loop trace-replay) vereist beide. Een platform dat 8 levert zonder 5 levert een placebo — de canary-monitor bestaat maar is nergens betrouwbaar tegenaan gegrond.

FAQ

Wat is de belangrijkste QA-capaciteit voor custom LLM-releases?

Een per-slice kwaliteitsgate (capaciteit 4) — wat betekent dat de releasebeslissing per-domein Spearman-scores consumeert tegen een mens-verankerde grader, niet één globaal aggregaat. Aggregaatscores wassen gelokaliseerde regressies weg, en gelokaliseerde regressies zijn de dominante LLM-release-faalmodus van 2026^[3]. Als je maar één capaciteit uit deze lijst kunt leveren, lever dan 4. Lever vervolgens 5, wat 4 betrouwbaar maakt.

Hoe evalueer je een LLM-QA-platform zonder het zes maanden te draaien?

Pas de 12-capaciteitenchecklist hierboven toe op vendor-documentatie, met twee specifieke tests. Vraag de leverancier eerst om je de per-slice gate-output te tonen voor een van hun referentieklanten — als ze alleen aggregaatscores hebben, hebben ze capaciteit 4 niet. Vraag ten tweede wat hun auto-rollback triggert — als het antwoord is “latency, foutpercentage en onze alarmen,” zitten ze in het serving-canary-kamp en ontbreekt capaciteit 10.

Wat is het verschil tussen eval-CI-tools en release-management-tools?

Eval-CI-tools (Braintrust, Humanloop, Patronus) voeren geautomatiseerde evaluators uit bij PR-merge en blokkeren slechte merges. Ze raken nooit live verkeer aan. Release-management-tools (deze categorie) bezitten het release-manifest, de canary, de observer en het rollback-pad. Eval-CI is onderdeel van een release-management-workflow maar geen vervanging ervoor. Veel teams leveren een van beide en ontdekken het gat wanneer een regressie die door CI is gekomen stilletjes productie raakt.

Hoe snel moet rollback zijn?

Order-of-magnitude seconden, geen minuten. De gemiddelde rollback-tijd op de Divinci-pipeline is ongeveer 12 seconden — dat is in-flight verzoek-drain op een ~100-replica service, niet de manifest-wissel zelf, die sub-seconde is. Vergelijk dit met Cloudflare’s incident van juni 2022^[8], dat 44 minuten kostte om terug te draaien omdat state verdeeld was over systemen. De architecturale beslissing die seconden-niet-minuten mogelijk maakt is het gebundelde release-manifest (capaciteiten 1 en 2).

Waarom zijn compliance-ontvangstbewijzen belangrijker dan compliance-logs?

Een log is iets wat jij hebt geschreven. Een ontvangstbewijs is iets wat een auditor kan verifiëren zonder jou te vertrouwen. De EU AI Act en NIST AI RMF^[9] maken steeds meer onderscheid tussen de twee — “gedocumenteerd” is niet hetzelfde als “aantoonbaar,” en de regelgevende richting gaat naar het laatste. Een hash-chained, extern verankerd ontvangstbewijs is de eenvoudigste beschikbare technologie om die lijn te overschrijden.

Referenties

1. Atlassian PIR April 2022. Post-Incident Review: April 2022 Outage. "De versnelde Restoration 2-aanpak duurde ongeveer 12 uur om een site te herstellen." Geciteerd voor capaciteit 1 — hoe state-spread-across-systems eruitziet op schaal.
2. W&B Models / MLflow registry. Weights & Biases Registry en MLflow Model Registry. De alleen-modelartefact-kant van capaciteit 1. Geen van beide levert prompttemplate-registratie.
3. The Semver Lie. Tianpan — The Semver Lie: how an LLM minor update breaks production (april 2026). Noemt de slice-bewuste regressie-faalmodus als het dominante 2026-patroon. Begeleidend: LLM postmortem template — fields SRE missed. Verankering voor capaciteit 4.
4. SageMaker Deployment Guardrails. Use canary traffic shifting en Auto-Rollback Configuration. Standaard TerminationWaitInSeconds van 600 (tien minuten), maximum 1800 (dertig minuten). De standaard infrastructuur-metriek-canary waar de post tegen contrasteert op capaciteiten 8 en 10.
5. Intern — atomic routing-flip via release-manifest. De ~12-seconden rollback-tijd is in-flight drain op een ~100-replica service; de manifest-wissel zelf is sub-seconde. Het getal komt van onze eigen service, niet van een benchmark. De architectuur die het mogelijk maakt is het gebundelde manifest uit capaciteit 1.
6. LLM-as-judge per-categorie variantie. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS 2023). >80% algehele GPT-4-vs-mens overeenstemming, met per-categorie variantie van coderen (86%) tot schrijven (36–44%). Verankering voor capaciteit 5 — waarom een gekalibreerde judge per-slice moet zijn.
7. Observability-kamp vergelijking. Arize Phoenix, Confident AI's 2026 observability tools-vergelijking. Allemaal leveren ze monitoring en alerting; geen handhaaft rollback. Verankering voor de "monitor zonder handhaving"-framing van capaciteit 10.
8. Cloudflare-storing juni 2022. Cloudflare outage on June 21, 2022. "06:58: Hoofdoorzaak gevonden en begrepen. Werk begint om de problematische wijziging terug te draaien… 07:42: De laatste van de terugdraaiingen is voltooid." 44 minuten van "we weten wat we moeten terugdraaien" tot terugdraaiing voltooid, deels omdat engineers over elkaars terugdraaiingen heen liepen. Verankering voor capaciteit 11.
9. NIST AI Risk Management Framework. NIST AI RMF. Governance, mapping, measurement, management — de vier kernfuncties waarop capaciteit 12 aansluit. Plus de EU AI Act provenance-vereisten op artificialintelligenceact.eu. Verankering voor capaciteit 12.

Volgende in deze serie: Validating and Releasing Custom LMs in Regulated Fields. De capaciteitenchecklist hierboven is generiek. De volgende post is specifiek: de EU AI Act, GDPR Artikel 17, HIPAA en NIST AI RMF — wat elk vraagt van een releaseproces, welke capaciteiten hierboven welke vereiste dekken, en waar de open-weights / closed-weights splitsing het compliance-verhaal werkelijk verandert.