Governare gli output dell'AI nei settori regolamentati: un playbook tecnico

Oltre il prompt engineering

La maggior parte delle discussioni sulla sicurezza dell'AI si concentra su ciò che entra nel modello: system prompt, guardrail, filtri sui contenuti. Nei settori regolamentati conta altrettanto, spesso di più, ciò che esce e come viene governato dopo la generazione.

Che un sistema AI rientri nelle categorie ad alto rischio dell'AI Act dipende dalla sua finalità prevista e dalle condizioni fissate dal Regolamento, non dal fatto che giri in un ospedale o in una farmacia. Uno strumento che fa da componente di sicurezza di un dispositivo medico, o che decide sull'accesso alle cure, è un oggetto diverso da un assistente che recupera procedure per il personale, anche quando il codice è quasi identico. Dove un sistema rientra in quelle categorie, tracciabilità, verificabilità e sorveglianza umana effettiva smettono di essere buone pratiche e diventano obblighi. Dove non rientra, restano la differenza tra un sistema che sai spiegare e uno che non sai spiegare. E il motivo per costruirle è che la classificazione può cambiarti sotto i piedi, quando la finalità prevista si allarga senza che nessuno lo dichiari.

1. Audit logging a prova di manomissione

La registrazione che vale la pena tenere è quella che ti permette di ricostruire in seguito una risposta specifica: la domanda, il contesto recuperato, il modello invocato, la risposta generata e la persona che l'ha ricevuta, in un archivio append-only. Quanto sei obbligato a conservarne, e per quanto tempo, dipende dalla classificazione del sistema, dai regimi che si applicano al tuo settore, dalla tua governance e dalla tua policy di conservazione: un default di novanta giorni e un obbligo di dieci anni non sono lo stesso progetto. Il punto ingegneristico vale a prescindere da quello giuridico: una decisione che non si può ricostruire non si può difendere, e aggiungere la registrazione a un sistema che non è nato per tenerla di solito significa ricostruirlo.

In Nexus MDS Core lo realizziamo con un servizio di audit dedicato che intercetta ogni ciclo richiesta-risposta. Ogni record è cifrato e concatenato via hash al precedente, così qualsiasi alterazione spezza la catena e l'integrità si può verificare su richiesta.

2. Livello di validazione degli output

Tra l'output grezzo del modello e la risposta mostrata all'utente deve esserci un livello di validazione. Non è un filtro sui contenuti: è un controllo strutturato che verifica che l'output rispetti criteri di qualità specifici del dominio.

In ambito clinico significa verificare che le fonti citate esistano e siano aggiornate, che la risposta non contraddica linee guida note e che i segnali di confidenza siano accurati. In ambito farmaceutico significa verificare l'accuratezza dei riferimenti normativi e segnalare gli output che toccano la classificazione delle sostanze controllate.

3. Pattern human-in-the-loop

L'AI Act richiede una "sorveglianza umana efficace" per i sistemi ad alto rischio. In pratica significa progettare workflow in cui l'AI assiste ma non sostituisce la decisione umana. Tre pattern che mettiamo in produzione:

• Revisione prima dell'azione: l'AI genera una raccomandazione; una persona qualificata la rivede e la approva prima che arrivi all'utente finale.
• Soglia di confidenza: gli output sotto una soglia di confidenza vengono instradati automaticamente alla revisione umana. Sopra la soglia, vengono consegnati con un'etichetta chiara che li indica come generati dall'AI.
• Trigger di escalation: categorie di contenuto specifiche (ad es. indicazioni di dosaggio, ipotesi diagnostiche) attivano sempre la revisione umana, a prescindere dalla confidenza.

4. Model card e documentazione

Ogni modello in produzione deve avere una model card: un documento strutturato che ne descrive dati di addestramento, capacità, limiti noti, casi d'uso previsti e metriche di valutazione. L'AI Act non usa il termine "model card", ma la documentazione tecnica e le istruzioni per l'uso che richiede ai sistemi ad alto rischio coprono in gran parte lo stesso terreno, e una model card è un modo pratico per tenere quel materiale in un unico posto. Al di là di qualsiasi obbligo, è la base di una sorveglianza umana consapevole: non puoi governare ciò che non capisci.

In pratica, la model card di un deployment AI in sanità dovrebbe includere: le fonti dei dati di addestramento e la loro provenienza, l'architettura e la versione del modello, metriche quantitative di prestazione su benchmark specifici del dominio, i modi di errore noti (con esempi), i casi d'uso previsti e quelli esplicitamente esclusi, e la data dell'ultima valutazione. Non è un documento statico: va aggiornato ogni volta che il modello viene riaddestrato, che il benchmark di valutazione cambia o che emergono nuovi modi di errore.

5. Cicli di feedback e miglioramento continuo

La governance degli output non si implementa una volta per tutte. È un processo continuo che migliora nel tempo, ma solo se il sistema è progettato per imparare dai propri output. Significa chiudere il ciclo di feedback tra validazione degli output, revisione umana e miglioramento del sistema.

In Nexus MDS Core realizziamo tre meccanismi di feedback:

• Tracciamento dei rifiuti: quando un revisore umano rifiuta o modifica un output dell'AI, il motivo del rifiuto viene registrato e classificato. Nel tempo si forma un dataset di pattern di errore utile a migliorare il livello di validazione, la pipeline di retrieval o il modello stesso.
• Calibrazione della confidenza: le soglie di confidenza (dalla sezione 3) non sono fisse. Vengono ricalibrate periodicamente in base agli esiti reali della revisione umana. Se gli output sopra soglia vengono rifiutati più spesso del previsto, la soglia è troppo permissiva.
• Punteggio di qualità delle fonti: nei sistemi basati su RAG non tutti i documenti sorgente sono ugualmente affidabili. Il ciclo di feedback tiene traccia di quali fonti producono output che superano la revisione umana e quali producono output rifiutati, e ne ricava un punteggio di affidabilità della fonte che influenza il ranking del retrieval.

6. Pattern architetturali per la governance degli output

Implementare tutti e cinque i livelli di governance (audit logging, validazione degli output, human-in-the-loop, model card, cicli di feedback) richiede un pattern architetturale preciso. L'approccio ingenuo, aggiungere la governance come middleware nella pipeline delle richieste, crea colli di bottiglia sulla latenza e un accoppiamento stretto.

Il pattern che usiamo in produzione è un'architettura a eventi: ogni interazione con l'AI emette un evento su un bus di governance. Audit logging, validazione e tracciamento del feedback sono consumatori indipendenti di questo flusso di eventi. Così la governance è disaccoppiata dalla pipeline di inferenza, e un guasto della governance non blocca le risposte agli utenti (pur registrando ogni interazione ai fini della compliance).

Nei settori regolamentati la governance degli output non è un accessorio facoltativo: è la differenza tra un sistema AI che regge l'esame di un'autorità di controllo e uno che non lo regge. La Legge 132/2025 e l'AI Act europeo lo rendono esplicito. Le organizzazioni che investono oggi in un'architettura di governance saranno quelle in grado di portare l'AI su larga scala senza rischio normativo. Quelle che trattano la governance come un dettaglio da sistemare dopo si ritroveranno ad adeguare tutto a posteriori, a un costo molto più alto, quando le autorità cominceranno a fare domande.