Le aziende hanno scritto policy per l’intelligenza artificiale, definito limiti sull’uso dei dati e istituito comitati di controllo. Ma, quando arriva un audit o un incidente, spesso non riescono a dimostrare con evidenze affidabili che quelle regole siano state effettivamente applicate, su ogni modello, agente e flusso operativo. È questa distanza tra la regola dichiarata e la prova della sua esecuzione a essere al centro di Governing at Machine Speed: An Adaptive Intelligence Architecture for Real-Time AI Policy Enforcement, preprint pubblicato su arXiv l’11 settembre da Sandeep Bokkasam e B. Durgalakshmi.

Il lavoro introduce il concetto di attestation deficit: una carenza strutturale di attestazioni verificabili. In altri termini, il problema non sarebbe l’assenza di documenti di governance, ma l’incapacità di produrre entro i tempi richiesti dalle norme una traccia d’audit resistente alle manomissioni, capace di collegare una decisione automatizzata alla policy che l’ha autorizzata, modificata o bloccata.

Gli autori propongono AGIL, acronimo di Adaptive Governance Intelligence Layer, come architettura concettuale da collocare tra i sistemi aziendali e le applicazioni AI. L’obiettivo è trasformare la governance da attività prevalentemente successiva agli eventi a controllo operativo: una decisione dovrebbe essere valutata mentre passa attraverso l’infrastruttura, non ricostruita settimane dopo da log frammentari.

Dal regolamento interno alla prova dell’esecuzione

Il tema acquista peso perché l’adozione dell’AI nelle organizzazioni procede più rapidamente delle strutture di sorveglianza. Il paper richiama una penetrazione dell’AI nel 78% delle organizzazioni a livello globale, insieme a dati provenienti dallo Stanford 2026 AI Index Report, dallo studio IBM/Ponemon sul costo delle violazioni e da una rilevazione EY/AIUC-1 Consortium. I numeri citati descrivono un quadro di monitoraggio incompleto: il 38% delle realtà interpellate disporrebbe di osservazione end-to-end e il 17% coprirebbe le interazioni tra agenti.

Queste percentuali vanno lette con cautela, perché nel preprint sono dati ripresi da fonti esterne e non il risultato di un esperimento AGIL. Tuttavia illustrano una difficoltà concreta. Un’impresa può sapere quali chatbot ufficiali siano stati approvati e quali repository abbiano regole di accesso, senza per questo riuscire a vedere tutti i modelli incorporati nei software, gli strumenti usati dai team senza autorizzazione formale o gli agenti che richiamano altri agenti e servizi.

In questo scenario la conformità non coincide con una checklist annuale. Diventa una proprietà dell’esecuzione quotidiana: chi ha inviato un dato, a quale modello, con quali permessi, quale controllo è scattato, quale versione della policy era valida in quel momento e se la decisione è stata alterata da un operatore o da un processo automatico. Senza questa catena, una policy può esistere sulla carta ma restare difficile da verificare davanti a un’autorità, a un cliente o al consiglio di amministrazione.

Come dovrebbe funzionare AGIL

L’architettura delineata dagli autori è divisa in cinque livelli, ciascuno dedicato a un passaggio della supervisione. Il primo è la scoperta autonoma di quello che viene spesso chiamato shadow AI: servizi e modelli utilizzati al di fuori dei canali governati dall’azienda. La proposta non si limita a censire applicazioni note, ma immagina il ricorso a impronte comportamentali per individuare schemi d’uso riconducibili a sistemi AI non registrati.

Il secondo livello classifica il rischio comportamentale. AGIL punta a riunire in una stessa valutazione aspetti che nelle aziende sono frequentemente separati: sicurezza, possibilità di allucinazioni, privacy e responsabilità. L’idea è offrire un punteggio o un giudizio operativo che tenga conto non soltanto del modello impiegato, ma anche del contesto e del tipo di azione richiesta.

Al centro c’è poi un gateway di enforcement delle policy. Sarebbe il punto in cui una chiamata o un’azione viene autorizzata, negata oppure modificata prima di proseguire. Il paper indica come obiettivo una latenza inferiore a 100 millisecondi. È un requisito ambizioso: nei flussi ad alta frequenza, un controllo troppo lento verrebbe facilmente percepito come un ostacolo operativo e finirebbe per essere aggirato o disattivato.

Ogni decisione dovrebbe alimentare il quarto livello, un motore di attestazione continua. Qui risiede l’elemento più rilevante della proposta: l’evidenza non sarebbe preparata a posteriori per l’auditor, ma generata come sottoprodotto dell’applicazione della regola. Gli autori parlano di registri a prova di manomissione, cioè tracce progettate per rendere rilevabili modifiche o alterazioni successive.

L’ultimo livello è dedicato all’evoluzione adattiva delle policy. In un contesto in cui norme e prescrizioni differiscono tra giurisdizioni, il sistema dovrebbe usare tecniche di machine learning per aggiornare la logica di controllo. Non significa, almeno nella formulazione del paper, che un modello possa riscrivere autonomamente gli obblighi legali: la proposta riguarda piuttosto un meccanismo capace di tradurre cambiamenti normativi e segnali operativi in aggiornamenti della governance.

Una proposta utile, ma non una soluzione già disponibile

AGIL non è un prodotto, né un framework dimostrato in un ambiente aziendale. Gli stessi autori lo presentano esplicitamente come un impianto teorico e architetturale, la cui validazione richiederà deployment controllati. Questa precisazione è sostanziale: non sono forniti risultati sperimentali che dimostrino la capacità di rilevare shadow AI, mantenere la soglia di latenza indicata, ridurre incidenti o produrre registri sufficienti per specifici regimi regolatori.

Restano inoltre aperti problemi tecnici e organizzativi. Un controllo inline può essere efficace soltanto se intercetta davvero i percorsi critici: API dirette, integrazioni SaaS, endpoint locali, workflow automatizzati e collegamenti tra agenti. Se parti del traffico restano fuori dal gateway, anche l’attestazione sarà inevitabilmente parziale. La qualità della prova dipende poi dalla qualità della policy tradotta in regole eseguibili: una prescrizione vaga su equità, responsabilità o uso proporzionato dei dati non diventa automaticamente una decisione binaria affidabile.

C’è anche il tema della classificazione del rischio. Un sistema che blocchi troppo rischia di rallentare processi legittimi; uno troppo permissivo produce una rassicurazione ingannevole. E l’uso di machine learning per adattare le policy richiede a sua volta guardrail, versionamento e supervisione umana, altrimenti la piattaforma deputata a controllare l’AI aggiunge un ulteriore livello opaco alla catena decisionale.

Il contributo del lavoro è quindi soprattutto nel mettere a fuoco una priorità spesso trattata come dettaglio tecnico: per governare l’AI non basta pubblicare principi né conservare log generici. Occorre collegare, in modo tempestivo e verificabile, policy, decisione e conseguenza. Per i responsabili di sicurezza, compliance, privacy e procurement questo sposta l’attenzione dalla sola valutazione dei modelli alla progettazione dell’infrastruttura che li rende osservabili.

Il passo successivo, per AGIL, sarà passare dalla struttura proposta alla verifica sul campo. Serviranno casi d’uso delimitati, metriche pubbliche e confronti con strumenti già adottati per identity management, controllo degli accessi, monitoraggio e audit. Solo allora sarà possibile capire se l’attestazione continua può reggere il carico dei sistemi AI reali senza trasformarsi nell’ennesimo strato burocratico o in una promessa di conformità difficilmente dimostrabile.

Fonti