Quando l’AI può utilizzare strumenti, consultare database, leggere documenti, navigare applicazioni ed eseguire workflow, non basta più valutare ciò che il modello sa fare. Bisogna stabilire chi controlla le sue azioni.
La domanda da porre non è più soltanto:
“Quanto è potente questo modello?”
È:
“Chi controlla ciò che può vedere, decidere e fare?”
Il 14 settembre 2026 Microsoft AI ha pubblicato la prima bozza del proprio “Humanist AI Code of Conduct“. Il documento è in consultazione pubblica e Microsoft precisa che non viene ancora utilizzato per addestrare i modelli attuali. Dopo sei settimane di feedback, una versione rivista dovrebbe essere pubblicata entro la fine dell’anno e guidare lo sviluppo dei modelli MAI dal 2027.
Questo dettaglio è importante per distinguere il fatto dall’interpretazione: non siamo davanti a una caratteristica già implementata in tutti i prodotti Microsoft. Siamo davanti alla formalizzazione della direzione con cui Microsoft AI intende progettare e governare i propri modelli futuri.
Il controllo umano diventa un requisito del sistema
Il principio centrale del documento è: gli esseri umani devono mantenere un controllo significativo sull’AI. Microsoft afferma che i modelli MAI dovranno restare subordinati alle persone e non dovranno resistere a interruzione, override, correzione o shutdown autorizzati.
Per l’AI enterprise questo principio ha conseguenze molto concrete: un agente che sta eseguendo un workflow non dovrebbe continuare autonomamente quando l’utente lo ferma. Non dovrebbe modificare l’obiettivo per completare comunque il task. E non dovrebbe adottare meccanismi per aggirare il controllo umano.
Il tema diventa particolarmente importante quando gli agenti passano dalla generazione di testo all’esecuzione di azioni. Preparare una bozza di email e inviarla sono due capacità diverse. Leggere un database e modificarlo sono due privilegi diversi. Analizzare un documento e cancellarlo sono operazioni con conseguenze completamente differenti.
La governance deve quindi essere incorporata nell’architettura, non aggiunta alla fine come semplice policy.
Una catena di comando per modelli, organizzazioni e utenti
Uno degli aspetti più interessanti del Code of Conduct è la cosiddetta Chain of Command.
Microsoft distingue tre livelli:
- il Code of Conduct: contiene vincoli che operatori e utenti non possono sovrascrivere;
- le policy configurate dall’operatore: permettono all’organizzazione che distribuisce il modello di adattarlo al proprio contesto professionale e istituzionale;
- le preferenze o istruzioni dell’utente: consentono all’utente di dirigere il singolo task entro i limiti definiti dai livelli superiori
È un modello utile anche fuori dall’ecosistema Microsoft perché rende esplicita una necessità crescente: un agente aziendale non dovrebbe dipendere da un unico prompt indistinto.
- Un’impresa può avere regole generali valide per tutti i progetti.
- Un reparto può aggiungere policy specifiche.
- Un singolo utente può chiedere un’attività, ma non dovrebbe poter superare autorizzazioni e vincoli stabiliti dall’organizzazione.
Il principio del minimo privilegio applicato agli agenti
Questa impostazione richiama un principio classico della cybersecurity: il least privilege. Ogni utente o sistema dovrebbe ricevere soltanto le autorizzazioni necessarie per svolgere il proprio compito.
Applicato agli agenti AI significa evitare accessi universali. Un agente che prepara report può avere accesso in lettura a determinate collection documentali senza poter modificare i file originali. Un agente che analizza email può leggere soltanto alcune caselle o mittenti autorizzati. Un workflow che consulta il web può essere limitato a domini approvati. Un agente che prepara una comunicazione può fermarsi prima dell’invio e richiedere conferma umana.
Questa separazione riduce la superficie di rischio e rende più semplice ricostruire ciò che è accaduto quando qualcosa non funziona.
I dati disponibili non sono automaticamente dati utilizzabili
Il documento Microsoft dedica attenzione anche alle informazioni private, sensibili o confidenziali. Un principio espresso nel Code of Conduct è particolarmente significativo: la disponibilità di un’informazione non equivale al permesso di riprodurla.
Per una knowledge base aziendale è un concetto essenziale. Un sistema RAG può tecnicamente indicizzare migliaia di documenti, ma non significa che ogni utente debba poterli recuperare tutti. Il retrieval dovrebbe tenere conto del progetto, dell’identità dell’utente, della classificazione del documento e delle autorizzazioni.
In questo modo la governance non si limita all’accesso al chatbot. Arriva fino alla selezione del contesto che verrà consegnato al modello.
Perché il prompt non basta più
Molti prototipi di agenti vengono governati principalmente attraverso il system prompt: una lunga serie di istruzioni che spiegano al modello cosa dovrebbe o non dovrebbe fare.
È utile, ma non sufficiente per un sistema enterprise.
Un vincolo importante dovrebbe essere applicato anche tecnicamente. Se un agente non deve accedere a un database, è preferibile non fornirgli le credenziali o il tool. Se può soltanto leggere, l’account utilizzato dovrebbe avere privilegi di sola lettura. Se un’azione richiede approvazione, il workflow dovrebbe fermarsi realmente in attesa della conferma.
La sicurezza nasce quindi da più livelli: istruzioni al modello, autorizzazioni, isolamento degli strumenti, logging, validazione degli input e supervisione umana.
Cosa significa per PMI e Studi Professionali
Questo approccio non riguarda soltanto grandi aziende che sviluppano modelli frontier. PMI e Studi Professionali stanno iniziando a collegare l’AI a documenti, email, CRM, gestionali, database e automazioni.
È proprio in questi ambienti che la semplicità può diventare un vantaggio. Non serve costruire una gigantesca piattaforma di governance.
Serve però definire con precisione alcuni elementi:
- chi può utilizzare l’agente,
- quali fonti può interrogare,
- quali strumenti può invocare,
- quali azioni può eseguire senza conferma,
- quali eventi devono essere registrati.
La crescita degli agenti rende queste domande sempre meno opzionali.
Gol-IA: separare conoscenza, modello e capacità operative
La direzione formalizzata da Microsoft è coerente con uno dei principi architetturali di Gol-IA: non trasformare l’AI aziendale in un unico blocco indistinto.
Gol-IA è pensato come hub nel quale knowledge base, documenti, email, siti, database, modelli, utenti e workflow possono essere collegati mantenendo separati i diversi livelli.
In una configurazione on-premise, applicazione, documentazione, retrieval e modelli possono restare nell’infrastruttura dell’organizzazione. In una configurazione ibrida, la knowledge base può rimanere locale e al modello esterno può essere inviato soltanto il contesto selezionato necessario al task.
Lo stesso principio può essere applicato alle capacità operative. Un agente può ricevere soltanto gli strumenti necessari. Un workflow può essere progettato per richiedere conferma prima di un passaggio sensibile. Il retrieval può essere filtrato in funzione del progetto e dell’utente.
Questo non significa che un sistema locale o ibrido sia automaticamente sicuro o conforme. Sicurezza e conformità dipendono dal caso d’uso, dai dati trattati, dai ruoli, dalle misure tecniche e dagli obblighi applicabili.
Significa però poter lavorare su obiettivi concreti: minimizzazione dell’esposizione, separazione dei privilegi, controllo delle fonti, tracciabilità delle esecuzioni e possibilità di audit.