AI compliance: rendere l’AI sicura e scalabile

Per AI compliance possiamo intendere la capacità di progettare, mettere in produzione e governare sistemi di intelligenza artificiale nel rispetto dei requisiti normativi applicabili, integrando allo stesso tempo controlli su rischi, dati, sicurezza e responsabilità lungo l’intero ciclo di vita. È una definizione operativa coerente con l’approccio dell’AI Act europeo, che lega la conformità a presidi come gestione del rischio, qualità dei dati, tracciabilità, supervisione umana, robustezza e cybersecurity, e con ISO/IEC 42001, che porta questi principi dentro un sistema strutturato di governance dell’AI.

Per questo superare i test tecnici non basta. Un sistema AI può funzionare correttamente in fase sperimentale e restare inadatto alla produzione: quando entra in un processo aziendale deve operare con dati reali, identità, permessi, integrazioni e responsabilità definite, e deve rimanere controllabile quando il modello cambia, l’output è errato o un agente esegue un’azione non prevista.

Per le imprese, questa esigenza non è più soltanto progettuale: ha ormai anche una dimensione normativa concreta. L’AI Act europeo è diventato applicabile il 2 agosto 2026, data dalla quale sono entrati in vigore anche specifici obblighi di trasparenza e poteri di enforcement; le regole per diversi sistemi ad alto rischio seguiranno dal 2 dicembre 2027 e, per quelli integrati in prodotti regolamentati, dal 2 agosto 2028.

Il calendario di applicazione dell’AI Act rende quindi necessario anticipare il lavoro di compliance rispetto al rilascio: inventario dei sistemi, classificazione dei rischi ed evidenze devono essere costruiti mentre il progetto evolve, non ricostruiti quando l’AI è già pronta per entrare in produzione.

Quanture affronta il passaggio dalla sperimentazione di un caso d’uso AI alla sua messa in produzione con un criterio compliant-by-design: sicurezza, governance e scalabilità entrano nella progettazione insieme al caso d’uso. La compliance diventa così una capacità operativa, anziché ridursi a una raccolta di documenti predisposta dopo il go-live.

Gestione del rischio AI: definire perimetro e autonomia

La valutazione parte dal processo. Occorre stabilire quale risultato deve produrre l’AI, quali utenti o clienti coinvolge, quali sistemi tocca e quali conseguenze può avere un errore. Un assistente che prepara una sintesi interna presenta un profilo di rischio più contenuto rispetto a un agente che modifica un ordine, invia un’offerta o tratta dati personali: cambiano l’impatto potenziale dell’errore, il livello di autonomia, la sensibilità delle informazioni coinvolte e, di conseguenza, i controlli, le autorizzazioni e la supervisione necessari.

Dall’AI che suggerisce all’AI che agisce

Il livello di controllo deve crescere lungo una scala precisa: lettura, elaborazione, proposta, decisione, modifica ed esecuzione. Per ogni passaggio vanno definiti permessi, soglie di confidenza, approvazioni ed escalation. L’autonomia, da sola, non basta a misurare il rischio: contano anche la gravità dell’errore, la reversibilità dell’azione, la sensibilità dei dati coinvolti e l’esposizione verso clienti, fornitori o altri sistemi. Un’azione facilmente annullabile su un dataset interno non richiede lo stesso presidio di una modifica irreversibile su ERP o di una comunicazione inviata all’esterno. Le domande da porsi quindi sono qual è la massima autonomia accettabile per questo processo, quali condizioni la limitano e chi risponde quando il sistema supera il perimetro autorizzato?

Dalla lettura all’azione: come cambiano i controlli con l’autonomia dell’AI

Schema operativo Quanture: all’aumentare dell’autonomia del sistema devono rafforzarsi controlli, tracciabilità, supervisione e meccanismi di arresto.

La compliance parte dai dati, prima ancora che dal modello

In un percorso di AI compliance, un sistema resta governabile solo se l’organizzazione conosce le informazioni che lo alimentano: origine, qualità, classificazione, base giuridica, localizzazione, tempi di conservazione e soggetti autorizzati. La mappa deve includere dati personali e confidenziali, knowledge base aziendali, contenuti inviati a servizi esterni e output salvati nei sistemi interni.

Questi dati svolgono però ruoli diversi. Vanno distinti almeno i dati forniti al modello durante l’inferenza, le fonti interrogate tramite RAG o knowledge base, l’eventuale memoria mantenuta da un agente e gli output che vengono poi archiviati o scritti in sistemi come CRM ed ERP. Per ciascun livello servono lineage e ownership: da dove arriva l’informazione, chi ne autorizza l’uso, per quanto tempo può essere conservata, dove risiede e quali identità possono leggerla o modificarla. La governance deve quindi seguire il dato lungo tutto il percorso, non fermarsi al dataset iniziale o al modello.

Nell’approccio Quanture, discovery, classificazione, protezione e auditabilità appartengono allo stesso modello operativo. Questo collegamento evita un errore frequente: applicare controlli al modello mentre documenti, database e fonti RAG rimangono privi di ownership o di regole coerenti. Se provenienza e permessi non sono ricostruibili, la governance dei modelli non può compensare il rischio.

Come progettare un’architettura AI compliant by design

In un sistema enterprise, sicurezza e compliance AI devono tradurre i rischi in controlli concreti su accessi, dati, componenti e azioni del sistema, così da sapere come vengono applicati durante il suo funzionamento Affidabilità e gestione del rischio devono essere integrate lungo tutto il ciclo di vita del sistema: dalla progettazione allo sviluppo, fino all’utilizzo e alla valutazione continua. Per l’impresa, questo significa distribuire controlli e responsabilità nelle diverse fasi del progetto, evitando di concentrare le verifiche solo nel collaudo finale.

Identità e minimo privilegio

Utenti, applicazioni, agenti, servizi e API devono avere identità distinguibili. Per gli agenti AI questo requisito diventa ancora più concreto: nell’ecosistema Microsoft, Entra Agent ID consente di attribuire identità verificabili e governare accessi e permessi. Il principio resta quello del minimo privilegio: ogni componente può vedere e fare soltanto ciò che serve al caso d’uso, mentre privilegi elevati e credenziali devono essere limitati, protetti e revocabili. L’obiettivo è sapere chi ha agito e poter applicare policy coerenti all’identità che opera sui sistemi.

Ambienti separati e componenti sotto controllo

Sviluppo, test e produzione richiedono dati, secret e autorizzazioni segregati. Modello, prompt, knowledge base, connector, policy e librerie devono essere inventariati e versionati perché possono cambiare indipendentemente. Quando una nuova versione del sistema passa dall’ambiente di test a quello di produzione, è necessario registrare che cosa è stato modificato e testato, con quali dati e criteri di valutazione e chi ne ha autorizzato il rilascio.

Osservabilità e controllo devono arrivare fino al runtime

Per un sistema AI in produzione non basta conservare il log finale. Occorre osservare anche come il sistema ha operato: quali fonti ha consultato, quale versione ha risposto, quali tool ha invocato, con quali permessi e quali policy sono state applicate durante l’esecuzione.

Il Responsible AI Transparency Report 2026 di Microsoft lega esplicitamente identità degli agenti, runtime policy, telemetria e audit log: per l’impresa significa poter ricostruire l’esito insieme alla sequenza di azioni e agli eventi di controllo che lo hanno prodotto. Questa osservabilità permette di investigare anomalie e incidenti e di intervenire mentre il sistema opera.

AI agentica: controllare le azioni, non soltanto gli output

Quando un agente accede a CRM, ERP, mailbox, documenti o workflow, la superficie di rischio comprende gli strumenti che può attivare. L’OWASP Top 10 for Agentic Applications 2026 individua dieci categorie di rischio specifiche delle applicazioni agentiche, cioè dieci modalità con cui un agente può essere manipolato, usare in modo improprio i propri strumenti o produrre effetti non previsti.

Tra queste rientrano il goal hijacking (la manipolazione degli obiettivi o del percorso decisionale dell’agente), l’abuso degli strumenti, i privilegi eccessivi, le vulnerabilità della supply chain e i guasti a cascata. I rischi riguardano quindi obiettivi, identità, permessi, tool e interazioni tra componenti, per questo valutare soltanto la qualità dell’output testuale copre solo una parte del problema.

Definire il perimetro operativo dell’agente

Un agente non dovrebbe ricevere genericamente “accesso al CRM” o “accesso all’ERP”. Il perimetro va definito come relazione tra agente, tool, risorsa, azione e condizione: quale agente può invocare quale strumento, su quali dati o oggetti, per compiere quale operazione e con quali vincoli.

Un agente può, per esempio, leggere una scheda cliente ma non modificarla; preparare un ordine ma non confermarlo; interrogare una mailbox ma non inviare messaggi senza approvazione. Questo modello rende applicabile il principio del minimo privilegio anche all’AI agentica e riduce il rischio che un singolo permesso troppo ampio si trasformi in autonomia non prevista.

Human-in-the-loop, escalation e arresto

La supervisione umana deve essere prevista nei punti in cui un errore dell’AI può produrre conseguenze rilevanti sul processo, sui dati o sugli utenti coinvolti. Lettura e classificazione possono essere automatiche; modifiche, comunicazioni esterne e azioni irreversibili possono invece richiedere un’approvazione esplicita. Nei sistemi agentici, l’human-in-the-loop permette di configurare condizioni di autorizzazione, esaminare log e risultati di valutazione e, quando serve, attivare, bloccare o revocare un agente, senza imporre una revisione manuale di tutto. Soglie di confidenza, gestione delle eccezioni, fallback e rollback devono essere progettati prima dell’attivazione, con un responsabile operativo identificato.

AGENTIC AI

Governare un agente significa governarne identità, azioni e possibilità di arresto

PERIMETRO

Agente governato

Non basta concedere “accesso al CRM” o “accesso all’ERP”: va definito quale agente usa quale tool, su quali risorse, per quali azioni e in quali condizioni. 

LEAST PRIVILEGE

IDENTITÀ

Permessi attribuibili e revocabili

utenti, applicazioni e agenti devono avere identità distinguibili e policy coerenti con il ruolo.

RUNTIME

Policy e telemetria durante l’esecuzione

tool invocati, permessi, policy applicate e azioni devono essere osservabili mentre il sistema opera.

APPROVAL

Supervisione dove l’impatto lo richiede

approval gate, escalation, fallback, blocco o revoca devono essere previsti prima dell’attivazione.

Dal PoC alla produzione: 5 controlli prima del go-live

Il passaggio dal PoC alla produzione può essere gestito come un “decision gate”, cioè un momento formale in cui si decide se il sistema è realmente pronto per il go-live. La decisione dovrebbe basarsi su cinque criteri di verifica, che permettono di valutare insieme valore, governance, tracciabilità, resilienza e capacità di scalare. Per ciascuno di questi criteri devono esistere evidenze concrete che dimostrino come il requisito viene soddisfatto, non semplici dichiarazioni o verifiche informali:

• Valore misurabile: il caso d’uso genera benefici rispetto a una baseline definita, per esempio in termini di tempi, errori, qualità o costi.

• Dati e accessi governati: dati, identità, accessi e integrazioni hanno ownership e perimetri chiaramente definiti.

• Tracciabilità: versioni, richieste, fonti, output e azioni possono essere ricostruiti.

• Gestione degli errori: eccezioni e anomalie attivano escalation, fallback o meccanismi di arresto controllato.

• Scalabilità dei controlli: architettura e presidi possono essere replicati senza moltiplicare privilegi, complessità e rischio.

Se uno di questi criteri non è soddisfatto, la soluzione può continuare a essere sperimentata, ma non è ancora enterprise-ready. Il decision gate serve anche a proteggere il budget, perché evita di portare su scala un sistema tecnicamente convincente che non ha ancora dimostrato valore, responsabilità operative e capacità di gestione.

Monitoraggio AI: la compliance continua dopo il go-live

Con il go-live non significa che il lavoro di compliance sia concluso. Una volta in produzione, il sistema deve continuare a dimostrare di operare entro il perimetro definito e di mantenere nel tempo le condizioni che ne hanno consentito il go-live.

Non basta quindi monitorare se il sistema è disponibile (uptime) e se produce risultati accurati: si devono considerare anche accessi, tool call, azioni eseguite, applicazione delle policy, anomalie, escalation, interventi umani, utilizzo dei dati e costo per esecuzione. Per gli agenti, la governance deve estendersi anche alla fase di runtime, cioè al momento in cui il sistema opera effettivamente: il comportamento va valutato anche dopo il deployment e le soglie devono attivare responsabilità e azioni concrete, come ad esempio revisione del prompt, limitazione di un permesso, sostituzione di una fonte, blocco dell’agente, sospensione di un connector o ritorno a una procedura manuale.

Ogni modifica rilevante riapre una parte della valutazione. Significa capire quale controllo viene impattato, senza ripetere ogni volta l’intero assessment. Un nuovo modello può richiedere nuove valutazioni di qualità e sicurezza; una knowledge base aggiornata può cambiare provenienza e autorizzazioni dei dati; un nuovo connector o tool modifica la superficie d’azione; un’estensione dei permessi aumenta l’autonomia reale; una variazione del processo o delle soglie può spostare il punto in cui serve supervisione umana. Anche incidenti e anomalie significative devono alimentare il riesame. Change management, incident response e verifiche periodiche mantengono così allineati sistema reale, documentazione ed evidenze.

Scalare l’AI significa standardizzare il modo in cui viene governata

Quando i sistemi AI aumentano, l’AI governance deve passare dal singolo caso d’uso a un modello comune: non è sostenibile definire da zero regole, ruoli e controlli per ogni sistema. Servono policy comuni, architetture di riferimento, livelli di autonomia, pattern di sicurezza, procedure di approvazione e requisiti minimi di monitoraggio. Un AI operating model rende questi controlli riutilizzabili e lascia ai singoli casi d’uso solo le variazioni motivate dal rischio. È in questo passaggio dalla governance del singolo sistema alla governance organizzativa che entra in gioco ISO/IEC 42001: lo standard definisce i requisiti per istituire, mantenere e migliorare nel tempo un sistema di gestione dell’AI. Non sostituisce i controlli tecnici del singolo progetto; li inserisce in un quadro comune di responsabilità, gestione del rischio, verifica e miglioramento continuo.

Dall’AI compliance all’AI enterprise-ready: l’approccio Quanture

Per portare un sistema AI dalla sperimentazione alla produzione, Quanture mette in relazione competenze che spesso vengono gestite separatamente: Data & AI, cybersecurity, gestione delle identità, infrastruttura ibrida e business application. È questa integrazione che permette di governare insieme dati, accessi, architettura, sicurezza e continuità operativa. Il lavoro parte dal processo e dai KPI, prosegue con la mappa di dati e integrazioni, traduce i rischi in controlli architetturali e assegna ownership per esercizio, monitoraggio ed escalation.

Il punto, quindi, non è aggiungere la compliance a un sistema AI quando è già stato progettato, ma costruire fin dall’inizio le condizioni per governarlo mentre entra nei processi aziendali e continua a evolvere. Regole, responsabilità e controlli devono crescere insieme al livello di autonomia, alle integrazioni e all’impatto delle azioni che il sistema può compiere.

È su questa capacità di mantenere l’AI controllabile, tracciabile e governabile nel tempo che si misura la sua reale maturità enterprise: non solo sulla capacità di portarla in produzione, ma su quella di farla evolvere senza perdere il controllo su ciò che legge, decide e fa.