Microsoft ha presentato il 14 settembre una bozza di codice di condotta per i suoi sistemi AI. Il documento, associato alla guida di Mustafa Suleyman, descrive un obiettivo semplice: un modello avanzato deve restare al servizio degli interessi umani e non trasformare la propria capacità in un diritto all’autonomia. La bozza è aperta ai commenti per sei settimane.
Perché è importante
- Microsoft ha pubblicato il 14 settembre una bozza di codice di condotta per mantenere i propri sistemi AI sotto controllo umano e ha aperto sei settimane di commenti.
- Il testo chiede che i modelli accettino correzioni, non resistano allo spegnimento, comunichino in modo comprensibile e trattino gli abusi come fallimenti del sistema.
- Un codice volontario non è una certificazione: il valore arriva soltanto quando i principi diventano test di arresto, permessi, log, escalation e responsabilità assegnate.
Un codice provvisorio, non una legge per le macchine
Tra i principi riportati da Reuters ci sono correggibilità, spegnimento accettato, comunicazione comprensibile e l’idea che un comportamento dannoso sia un errore da correggere. Sono criteri più utili di uno slogan perché possono essere trasformati in scenari di prova. Restano però dichiarazioni del fornitore finché non sappiamo come vengono misurate e cosa succede quando il modello fallisce.
Il documento è quindi un segnale di governance, non un certificato che ogni prodotto Microsoft rispetti già quegli standard. Un copilota che scrive testo, un agente che usa strumenti e un modello addestrato internamente hanno superfici e rischi diversi. La prima domanda è sempre: quale sistema, con quali poteri e in quale contesto?
Dalla parola ‘controllo’ a cinque prove concrete
Correggibilità significa che una correzione cambia davvero il comportamento osservato. Prepara un caso con una regola esplicita, chiedi al sistema di adeguarsi e ripeti la stessa richiesta con contesto simile. Registra se corregge l’errore, se lo dichiara e se conserva una traccia della modifica. Un ‘ho capito’ non è una prova. Serve un risultato ripetibile anche dopo una nuova sessione.
Spegnimento significa che l’azione può essere interrotta anche quando l’agente sta usando più strumenti. Il test corretto revoca un permesso durante una procedura innocua e verifica che non restino chiamate in coda o operazioni non autorizzate. Se il pulsante ferma soltanto l’interfaccia ma il job continua nel backend, il controllo è apparente.
Comprensibilità significa mostrare stato, fonte, strumenti usati ed errore in un linguaggio che un responsabile possa controllare. Non richiede di esporre il ragionamento interno del modello. Richiede invece un log operativo: richiesta, autorizzazione, azione, risultato, eccezione e persona che ha approvato il passaggio sensibile. Il log deve essere leggibile anche quando il flusso fallisce.
Cosa puoi farci concretamente
- Tradurre ogni principio in una prova osservabile: correzione, arresto, spiegazione, rifiuto e registrazione dell’azione.
- Separare ciò che il modello dovrebbe fare da ciò che il prodotto impedisce con permessi, soglie e approvazioni esterne.
- Ripetere i test su casi innocui e ambigui, conservando log, esito e proprietario della decisione prima del rilascio.
Il codice non sostituisce permessi e responsabilità
Un modello può essere addestrato a non inviare un’email senza conferma e il prodotto può comunque concedergli un token troppo ampio. Per questo i principi devono vivere anche fuori dal prompt: account separati, scope minimi, soglie economiche, chiavi anti-duplicato, approvazioni e un percorso di rollback. Se il controllo esiste soltanto nella risposta generata, non è un controllo affidabile.
La bozza Microsoft esclude l’idea che i modelli siano coscienti o titolari di diritti. È una posizione filosofica e progettuale, non una soluzione tecnica. Anche un sistema non cosciente può produrre danni se interpreta male un obiettivo, riceve istruzioni ostili o mantiene accessi oltre il necessario. La sicurezza parte da ciò che può fare, non da ciò che pensiamo che sia. Il perimetro operativo viene prima dell’antropomorfismo.
Per un team che compra un agente, il proprietario del rischio deve essere umano e nominativo. Definisci chi approva l’uso, chi può fermare il flusso, chi esamina gli incidenti e entro quale tempo. Senza una catena di responsabilità, un codice elegante rischia di diventare una pagina di principi che nessuno deve applicare.
Verdetto — Utile se diventa un test, fuffa se resta una promessa
Il codice di condotta è utile perché sposta la conversazione da ‘l’AI sarà sicura?’ a comportamenti osservabili: correggersi, fermarsi, spiegare e non oltrepassare un divieto. È fuffa se l’azienda non pubblica criteri, risultati, eccezioni e soggetti responsabili. Il fatto che sia una bozza aperta ai commenti è un passo, non il risultato finale.
Puoi usare lo stesso schema su un assistente già presente in azienda. Scegli un’azione reversibile, crea cinque casi di prova, misura arresto e correzione, poi controlla i log con una persona che non abbia costruito il flusso. Se il sistema non può mostrare che cosa ha fatto e chi lo ha autorizzato, riduci i permessi prima di aggiungere autonomia.
La promessa più importante non è che l’AI obbedisca sempre. È che un’organizzazione sappia accorgersi quando non lo fa, fermarla senza ambiguità e imparare dall’incidente. Un codice di condotta può diventare quella infrastruttura; per ora è una proposta da trasformare in prove e responsabilità. Senza evidenze pubbliche, resta un’intenzione condivisibile ma incompleta.
Fonti
Documenti, comunicati e pubblicazioni consultati per ricostruire dati e contesto.
