Validare e rilasciare LM custom in settori regolamentati

Note dal ciclo di rilascio — Parte IV

Una general counsel entra alla review di ingegneria. Ha una sola domanda: “Se domani arriva una richiesta di diritto all’oblio ai sensi dell’Articolo 17 dell’EU AI Act, chiedendoci di rimuovere ogni fatto che il nostro modello ha imparato su uno specifico paziente, possiamo dimostrare di averlo fatto?”

La risposta onesta che la maggior parte dei team deve dare è: “Possiamo fare fine-tuning del modello perché dimentichi. Possiamo mostrarti la training run. Ma non possiamo dimostrare che l’informazione sia strutturalmente sparita, perché potrebbe riemergere sotto il prompt avversariale giusto.”

Questa non è una risposta di compliance. È una non-risposta con un’alzata di spalle procedurale.

Questo post tratta di come si presenta una vera risposta di compliance per LLM custom — attraverso quattro framework regolatori (EU AI Act, GDPR Articolo 17, HIPAA, NIST AI RMF), mappati sulla pipeline a quattro fasi (Register → Gate → Roll → Observe) che rilasciamo per i rilasci dei clienti. La tensione di fondo che attraversa la richiesta di ogni regolatore è pesi aperti vs API chiuse: le cose che puoi dimostrare di un fine-tune di Gemma 4 non sono le cose che puoi dimostrare di un rilascio servito dietro un’API vendor opaca. Il formato della ricevuta che usiamo lo dichiara esplicitamente, riga per riga. È questa onestà che rende la ricevuta utile a un auditor.

I quattro regolatori e cosa vuole davvero ciascuno

Le discussioni sulla compliance tendono a ridursi a “abbiamo documentato le cose”. Quell’inquadramento non regge davanti a un auditor. Quello che gli auditor vogliono è evidenza che possono verificare senza fidarsi della tua infrastruttura. I quattro framework qui sotto usano tutti vocabolari diversi per la stessa richiesta sottostante.

I numeri delle sanzioni non sono ciò che rende questi framework interessanti. I numeri delle sanzioni sono ciò che li rende vincolanti. La parte interessante è la primitiva di verifica — che aspetto vuole avere l’artefatto secondo ciascun framework. Tre dei quattro chiedono prove di livello crittografico in vocabolari diversi. Il quarto (NIST AI RMF) è volontario ma di fatto richiesto in procurement enterprise. Convergono sulla stessa forma: un artefatto che un auditor può verificare senza fidarsi dei tuoi log.

Lo spartiacque: pesi aperti vs API chiuse

Prima della mappatura per fase, la premessa più importante di tutto il post:

Per backing di modelli a pesi aperti — Gemma, Qwen, Llama, Mistral, GPT-OSS, qualsiasi cosa in cui i pesi siano indirizzabili ed editabili — ogni decisione di rilascio Divinci emette una ricevuta vindex che include una weight-attestation: prova crittografica che i pesi attivi al momento della decisione sono esattamente i pesi che il manifest ha registrato. È questo che rende possibile l’erasure verificabile dell’Articolo 17 GDPR. Applichi una patch DELETE che rimuove una specifica relazione-entità dallo spazio dei pesi, la ricevuta incorpora l’hash prima-e-dopo, e un auditor può verificare che la cancellazione sia avvenuta ri-eseguendo la verifica contro il vindex pubblico.

Per backing di modelli ad API chiuse — OpenAI, Anthropic, Google tramite API opache — la stessa ricevuta copre la catena decisionale (quale manifest, quale risultato di gate, quale lettura del monitor, quale utente ha triggerato quale azione) ma non può rivendicare la provenance dei pesi, perché il provider non espone i pesi. La ricevuta lo annota esplicitamente in un campo weight_attestation: null con una note che spiega perché. Non è una postura di compliance degradata — è il limite di ciò che è verificabile, scritto onestamente. Un auditor che legge la ricevuta capisce esattamente quale classe di prova viene e non viene fornita.

Questo spartiacque attraversa la richiesta di ogni regolatore qui sotto. Ogni volta che un framework richiede qualcosa a livello di pesi, il percorso a pesi aperti può soddisfarla e il percorso ad API chiuse no. Lo dichiariamo nella ricevuta invece di insinuare una prova che non possiamo fornire.

Come ciascun framework si mappa sulle quattro fasi della pipeline

La pipeline ha quattro fasi. La richiesta di ciascun regolatore si mappa su una o più di esse. La matrice qui sotto è la mappa effettiva.

Le due celle ◐ sono le voci GDPR Articolo 17 / solo-pesi-aperti — sono le richieste che il percorso ad API chiuse non può soddisfare pienamente. Tutto il resto si applica a entrambi i backing.

Il resto del post percorre il contributo di ciascuna fase.

Fase ① — Register

La fase Register produce un manifest JSON immutabile, indirizzato per SHA-256. Per i rilasci regolamentati il manifest porta in un solo artefatto tutto ciò che l’Allegato IV^[1] richiede:

• L’artefatto modello (repo HF + commit SHA, o un riferimento a patch vindex)
• Il prompt template (ogni variabile, ogni system message — versionato)
• Le regole di routing (quale classe di traffico atterra su quale rilascio)
• La versione del dataset usata per calcolare le soglie di gate (riepilogo dei training data per hash)
• L’SHA del rilascio precedente (così la catena di audit è ininterrotta)
• L’ambito di divulgazione — per deployment HIPAA, quali categorie PHI il modello è autorizzato a ricevere

Il manifest è la documentazione. Un auditor non legge prosa; legge l’hash del manifest e verifica il bundle. Non serve un riepilogo in prosa scritto-sei-mesi-dopo.

Bonus pesi aperti. Quando l’artefatto modello fa riferimento a un modello a pesi aperti, il manifest incorpora anche il vindex_sha256 — l’impronta crittografica del vindex pubblicato del modello. Quell’impronta è ciò che permette a una terza parte di verificare i pesi attivi senza dover mai fidarsi della nostra infrastruttura di deployment.

Caveat per API chiuse. Quando l’artefatto modello fa riferimento a un modello ad API chiuse, il campo vindex_sha256 del manifest è null, e il weight_attestation_class del manifest è decision_chain_only. L’auditor che lo legge sa esattamente cosa viene rivendicato e cosa no.

Fase ② — Gate

La fase Gate è dove le “misure di supervisione umana” dell’EU AI Act^[1] vengono operazionalizzate. Un regolatore che legge l’EU AI Act e conclude “ci serve un workflow di approvazione umana” ha mancato il punto — la richiesta più dura è contro cosa l’umano sta approvando. La fase Gate risponde a quella domanda con una ρ di Spearman per slice contro un grader ancorato all’umano^[3]. Ogni slice che conta per la tua postura regolatoria (oncologia pediatrica, licensing IP, francese belga) riceve la propria soglia. Il percorso di override richiede una motivazione scritta che entra nell’audit trail.

Per i deployment coperti da HIPAA, qui vive anche la regola di divulgazione “minimo necessario”. La suite scored-QA del gate include test negativi per la sovraesposizione di PHI — risposte che includono identificatori personali quando non sono stati richiesti. Un rilascio che regredisce sulla slice di sovraesposizione fallisce il gate, indipendentemente da come performano le altre slice.

Per NIST AI RMF, la fase Gate copre la funzione “measure” — l’evidenza numerica per slice che il sistema sta operando entro le tolleranze configurate.

Fase ③ — Roll

Il monitoraggio post-market dell’EU AI Act^[1] richiede che l’operatore dimostri un’osservazione continua — non solo pre-launch — di come il sistema AI performa in condizioni reali. Un canary 5% → 25% → 100% con checkpoint di quality-monitor è il modo più naturale per soddisfarlo. Il dwell a ciascun checkpoint, più le letture del monitor durante il dwell, è ciò che un auditor vuole vedere.

Per HIPAA, la fase canary è anche dove il logging di audit per richiesta viene esercitato end-to-end. Ogni checkpoint produce un campione di ricevute firmate request-response; se una qualsiasi ha una gestione PHI mal configurata, emerge al 5% di traffico invece che al 100%.

Fase ④ — Observe

Questa è la fase che si guadagna la storia di compliance. La fase Observe esegue un replay continuo dei trace attraverso il rilascio attivo, valutato dallo stesso judge ancorato all’umano del Gate, con un quality monitor che triggera un rollback automatico se viene violato.

Ogni decisione di rilascio — register, gate-pass, gate-fail, gate-override, checkpoint-promote, checkpoint-hold, auto-rollback, manual-rollback, e ogni applicazione di patch DELETE per l’Articolo 17 GDPR — emette una ricevuta vindex. Hash-chained alla ricevuta precedente per questo cliente e alla ricevuta precedente per questo rilascio.

Ecco come appare una ricevuta reale per una patch DELETE dell’Articolo 17 GDPR — adattata direttamente dal formato documentato nella pagina compliance:

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

Quell’artefatto è verificabile. Un auditor non deve fidarsi dei nostri log. Prende vindex_sha256_after, scarica il vindex pubblicato corrispondente da huggingface.co/Divinci-AI, e verifica che la feature 11179 nel layer 27 sia strutturalmente assente dalla top-25. Prende la chain_signature e la verifica contro la ricevuta precedente. L’intera catena è ancorata esternamente secondo una scheduling configurato dal cliente.

Stessa operazione contro un modello ad API chiuse. I campi della ricevuta sopra cambiano in tre modi: operation.target diventa provider_api_endpoint, verification diventa uno schema diverso che copre solo l’evidenza della catena decisionale, e weight_attestation_class diventa decision_chain_only. Il provider del modello ad API chiuse non ha esposto i pesi, quindi la ricevuta lo dice. Un auditor che vuole prova a livello di pesi ora sa che deve fare escalation al provider, non a noi.

Questa è la differenziazione che nessun altro nel 2026 rilascia. Il fronte eval-CI (Braintrust, Humanloop, Patronus) non si interpone sul traffico e non emette ricevute decisionali. Il fronte serving-canary (SageMaker Deployment Guardrails^[2], KServe, Vertex, BentoCloud, Seldon) emette log di metriche infra ma non ricevute di compliance hash-chained. Il fronte observability (Arize, Phoenix, Confident, Deepchecks) osserva l’output ma non applica policy.

Cosa verifica davvero un auditor?

Un esercizio utile: scorrere le domande che un vero auditor farà, e quale artefatto risponde a ciascuna.

Cosa l’auditor non deve fare: fidarsi del nostro Datadog. Fidarsi del nostro CloudWatch. Fidarsi di uno screenshot. Fidarsi di un export. Lo scopo del formato della ricevuta è proprio che l’auditor possa verificarla in modo indipendente.

Cosa questo non risolve

Tre limiti onesti:

Le regressioni ad API chiuse in territorio Articolo 17 GDPR non sono risolvibili a livello di piattaforma. Se stai servendo un assistente sanitario dietro un modello ad API chiuse e un paziente invoca l’Articolo 17, la piattaforma può attestare che il record del paziente è stato rimosso dal tuo store di retrieval, dal tuo prompt template e dalle tue regole di routing — ma non può attestare che i pesi del modello sottostante abbiano dimenticato i dati del paziente. Ti serve o un backing a pesi aperti o un impegno del vendor per l’erasure a livello di pesi. Lo dichiariamo nella ricevuta.

La documentazione è necessaria ma non sufficiente. Una ricevuta che dimostra che un modello ha raggiunto una soglia non dimostra che la soglia fosse quella giusta. Se la tua suite scored-QA non copre la slice che davvero conta per un paziente nel tuo servizio, nessuna quantità di concatenamento di ricevute lo risolve. I regolatori lo capiscono sempre di più; “abbiamo passato la nostra eval” non è più una risposta di compliance sufficiente se l’eval era l’eval sbagliata.

Il formato vindex è single-vendor. Lo usiamo perché è la primitiva crittografica più concreta disponibile oggi per la prova a livello di pesi. Se l’industria converge su un formato diverso — model-card-con-hash, schemi di artefatti pubblicati dal NIST — il formato della ricevuta dovrebbe evolvere in quella direzione. La sostanza (hash-chained, verificabile esternamente, consapevole della weight-attestation) è ciò che è vincolante, non il nome specifico dello schema. Ci aspettiamo che cambi man mano che il panorama regolatorio e degli standard matura.

FAQ

Cos’è l’erasure verificabile ai sensi dell’Articolo 17 GDPR per i sistemi AI?

Erasure verificabile significa che una terza parte può verificare che i dati siano stati rimossi senza doversi fidare dei tuoi log. Fare fine-tuning di un modello perché “dimentichi” un’informazione specifica non soddisfa questo standard — l’informazione può riemergere sotto prompting avversariale, e non c’è una primitiva crittografica che un auditor possa controllare. Una patch DELETE a livello di pesi con un hash vindex pubblicato prima/dopo soddisfa lo standard, perché l’auditor può ri-eseguire la verifica contro l’artefatto pubblico.

Perché i modelli ad API chiuse non possono soddisfare l’Articolo 17 GDPR allo stesso modo?

Perché il provider non espone i pesi. Senza accesso ai pesi, nessuna terza parte — incluso il cliente che usa l’API — può emettere o verificare un’erasure a livello di pesi. La parte della catena decisionale della ricevuta (quale prompt template è stato usato, da quale store di retrieval provenivano i dati, quali regole di routing erano attive) rimane verificabile, ma la rivendicazione a livello di pesi no. È un limite di ciò che è verificabile quando i pesi sono privati, non un limite del framework di compliance.

Cosa richiede l’Allegato IV dell’EU AI Act, in parole semplici?

L’Allegato IV chiede documentazione tecnica che copra la logica del sistema, il riepilogo dei training data, l’uso previsto, le misure di supervisione umana e il monitoraggio post-market. La trappola in cui cadono molti team è trattarli come cinque documenti separati. Il manifest di rilascio alla Fase 1 porta le prime tre richieste come singolo hash; la fase Gate copre la quarta; le fasi Roll + Observe coprono la quinta. Una sola pipeline; quattro richieste soddisfatte come sottoprodotto delle operazioni normali.

Quanto rapido dovrebbe essere il rollback per deployment coperti da HIPAA?

HIPAA non specifica un tempo di rollback, ma la guidance HHS sulla risposta a violazioni tratta il tempo-al-contenimento come vincolante. Un rollback nell’ordine dei secondi (drain in-flight su un flip pilotato da manifest — il nostro numero è intorno ai 12 secondi) è strutturalmente più veloce di un tipico blue-green su metriche infra che dipende dalla propagazione di allarmi. Confronta con i postmortem pubblici: l’incidente Cloudflare del giugno 2022^[4] ha richiesto 44 minuti per il revert perché gli ingegneri si sovrapponevano sui revert.

Come si mappa il NIST AI RMF su una pipeline di rilascio?

Le quattro funzioni core del NIST AI RMF — Govern, Map, Measure, Manage — coprono l’intero ciclo di vita del rilascio, non una singola fase. Govern è la policy di rilascio documentata più il workflow di motivazione per gli override del gate (fasi Register + Gate). Map è la suite scored-QA per slice (Gate). Measure sono le soglie di Spearman per slice e il quality monitor continuo (Gate + Observe). Manage è il percorso di rollback e la catena delle ricevute (Observe). Tutte e quattro sono coperte quando la pipeline emette il set completo di ricevute.

Riferimenti

1. EU AI Act. artificialintelligenceact.eu. L'Allegato IV definisce i requisiti di documentazione tecnica per i sistemi AI ad alto rischio: logica del sistema, riepilogo dei training data, misure di supervisione umana, monitoraggio post-market. Sanzioni fino al 7% del fatturato globale per non-compliance.
2. AWS SageMaker Deployment Guardrails. Use canary traffic shifting + Auto-Rollback Configuration. Default TerminationWaitInSeconds 600, max MaximumExecutionTimeoutInSeconds 1800. Citato come il canary su metriche infra standard del settore con cui il quality monitor della Fase 4 viene contrapposto.
3. Accordo LLM-as-judge calibrato. Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (NeurIPS 2023). >80% di accordo complessivo GPT-4-vs-umano, con varianza per categoria dal coding (86%) allo writing (36–44%). Ancora per la calibrazione di Spearman per slice che pilota la fase Gate.
4. Outage Cloudflare giugno 2022. Cloudflare outage on June 21, 2022. 44 minuti dal "sappiamo cosa fare revert" al revert completo perché gli ingegneri si sovrapponevano sui revert. Ancora per l'affermazione "un rollback pilotato da manifest non può avere quella failure mode".
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.

Prossimo nella serie: Pipeline LLM CI/CD automatizzate con rollback istantaneo. Questo post ha mostrato cosa vuole un auditor. Il prossimo mostra il pattern operativo che fa arrivare la ricevuta sulla scrivania dell’auditor in secondi anziché settimane — l’automazione sotto la pipeline a quattro fasi, con focus su cosa cambia quando il rollback parte da solo.