Governance e controllo nei modelli AI: regole, rischi e risposte

Il Dipartimento della Sicurezza Interna degli Stati Uniti ordina alle agenzie civili di bloccare e rimuovere “tutti i prodotti DeepSeek”, inclusi “DeepSeek-affiliate products” e “third-party products and services developed using DeepSeek implementations”. L’ordine introduce la formula “developed using”, che estende il perimetro oltre il marchio del fornitore e apre un fronte operativo su inventario, routing e dipendenze tecniche¹. Tesi: vincoli regolatori e guasti in produzione spostano il baricentro su controlli continui e checkpoint umani, mentre nuovi modelli modificano velocità e forma del rischio¹.

1) Un ordine che allarga la compliance

“Developed using” è la chiave. Se indica accesso continuativo via API, le agenzie devono dismettere ogni servizio che instrada richieste su DeepSeek. Se si limita all’uso in sviluppo, il perimetro cambia. La differenza incide su cosa spegnere, cosa mantenere, come mappare le dipendenze¹.

Gateway di AI complicano il censimento. OpenRouter e Vercel AI Gateway espongono più provider tramite API, inclusi i modelli DeepSeek. Un’integrazione può parlare con un gateway e, a valle, raggiungere un modello vietato. Tracciare questi percorsi richiede visibilità su routing e configurazioni dinamiche. Rimuovere non significa soltanto disinstallare strumenti locali. Occorre chiudere flussi verso implementazioni bandite, anche se mascherate dietro un intermediario¹.

Un’ambiguità così non è semantica. Determina tempi, rischi di blocco e priorità di remediation. Un procurement centrato sul logo non basta. Servono mappe delle implementazioni e definizioni chiare su cosa rientri nel “developed using” in ogni ambiente regolato¹.

2) Perché i modelli “buoni sui benchmark” falliscono in produzione

Gli score scintillanti non proteggono dal contesto. 88% su MMLU, top percentile su GSM8K, Python impeccabile su HumanEval, poi in produzione arrivano perdite: politiche di reso inventate, payload API fuori schema, documenti obsoleti esposti con sicurezza. Non è degradazione, è valutazione fuori contesto².

I benchmark misurano capacità isolate in ambienti sterili. I sistemi reali espongono stato distribuito, input sporchi, regole che cambiano, vincoli a valle. La verifica una tantum in prerelease non intercetta derive operative, regressioni di integrazione, dipendenze non documentate. Serve verifica continua lungo il ciclo di vita del sistema, non solo del modello. Servono controlli su chiamate a strumenti, contratti di schema, gestione della conoscenza e risposta a input imperfetti².

Qui si aggancia la compliance. Un modello può “funzionare” sui task, ma violare un vincolo di routing del DHS se una libreria instrada su un provider non ammesso. La qualità misurata dai benchmark non copre la conformità dell’implementazione^1,2.

3) Checkpoint umani integrati nelle pipeline di automazione

ServiceNow presenta Autonomous Engineer. Automatizza pianificazione, build e test. Poi blocca la pipeline e chiede un’approvazione esplicita prima della messa in produzione. Il checkpoint umano non è un filtro laterale. Sta dentro il flusso standard, con decisioni tracciate e responsabilità assegnata³.

Paulius Pazdrazdys riconosce un pattern noto: quando un algoritmo guida azioni concrete, emergono verifiche indipendenti. Gli utenti costruiscono abitudini di controllo. L’esempio cita servizi di predizione sportiva come StakeHunters, dove i suggerimenti degli esperti fanno da controllo esterno. Non sostituiscono i modelli, li mettono alla prova³.

Autonomous Engineer formalizza questo pattern nell’enterprise. Automatizzare non significa togliere la decisione. Significa incorniciarla, registrarla, renderla ripetibile. In ambienti vincolati da ordini come quello del DHS, un checkpoint interno alla pipeline può intercettare bug e violazioni di perimetro tecnologico prima del deploy^1,3.

4) Nuovi modelli e la variabile velocità-capacità

Nace AI lancia Drex Max, un decision model che legge testo e immagini. Riceve uno stato e domande con nome. Restituisce, per ogni domanda, distribuzioni di probabilità calibrate. L’azienda usa il Decision Index 0.3.2 e attribuisce a Drex Max 67,59, 6,9 punti sopra Jev 1.14 di TypeSafe. Nei benchmark pubblicati registra 98,2 su BFCL per il tool calling e 92,2 su JevBench, contro 86,7 di Jev 1.14. Su HLE segna 19,0. L’obiettivo dichiarato: supportare agenti che usano computer e browser con una chiamata tipata e a basso costo per ogni click⁴.

Inception presenta Mercury 3, definito dall’azienda “il più capace diffusion LLM mai rilasciato”. Nei test interni pubblicati, il modello supera GPT-6 Luna e Claude Haiku 5.5. L’azienda comunica un vantaggio di latenza tra 4x e 8x “su una serie di benchmark” scelti in casa. Si tratta di prove interne, senza dettagli su protocolli di test o riproducibilità. L’azienda parla anche di un modello “più di 40 volte” la dimensione di Mercury 1. Il messaggio, nei materiali dell’azienda, è lineare: più grande, più capace, più rapido nei test descritti⁵.

Questi lanci introducono due pressioni operative: capacità calibrata per decisioni tipate e tool use, e riduzione dei tempi di risposta. Più bassa la latenza, più ampio il raggio d’azione dei guasti potenziali. Se un assistente esegue azioni in meno tempo, un errore di schema o un documento superato si propaga più velocemente. La calibrazione delle probabilità può aiutare a definire soglie di blocco e revisione. Integrare questi segnali nei controlli richiede processi e strumenti coerenti con le pipeline esistenti^2,4,5.

5) Implicazioni pratiche per ingegneria, QA e procurement

Tre conseguenze operative emergono dai fatti.

• Mappare per implementazione, non per marchio. Inventariare integrazioni e punti di accesso. Distinguere accesso runtime via API dall’uso in sviluppo. Adeguare percorsi di rete e policy per evitare routing verso implementazioni bandite. In presenza di gateway, verificare provider attivi e comportamento di instradamento. L’ambiguità di “developed using” impone scelte documentate e difendibili¹.

• Spostare la qualità dal laboratorio al ciclo di vita. Costruire test che includano stato condiviso, input sporchi, contratti di tool calling e varianti dei flussi a valle. Affiancare benchmark sintetici con monitoraggio continuo e verifiche su payload e fonti. Gli esempi di guasti su politiche, schemi e documentazione mostrano dove i numeri non bastano².

• Inserire checkpoint umani nelle pipeline di automazione. Valutare soluzioni che portano il controllo dentro il flusso, con approvazioni esplicite e tracciate. Questo riduce errori a valle e offre un punto chiaro di responsabilità. Con modelli che producono probabilità calibrate, soglie di stop possono diventare regole operative. Con modelli più rapidi, il ritmo del controllo deve seguire la latenza promessa dai fornitori^3,4,5.

Questo non elimina l’incertezza. La incanala. E rende visibili decisioni, deviazioni e dipendenze nascoste.

La prossima frizione arriverà dai confini dinamici: ordini che usano formule come “developed using”, gateway con routing variabile, modelli che accelerano i cicli. Qui si giocherà la differenza tra chi ferma in tempo, con prove tracciate, e chi scopre una dipendenza vietata quando è già in produzione¹.