Gli esperti federali sollecitano rigorosi test sull’IA prima dell’implementazione

Google News ha riportato alla luce un avvertimento federale caratterizzato da un netto contrasto: le agenzie stanno implementando sempre più IA, mentre test affidabili restano costosi, lenti e incompleti.

Il rapporto di riferimento descrive gli esperti tecnologici federali che invitano le agenzie a testare ripetutamente l’IA prima di utilizzarla in contesti con conseguenze rilevanti. La loro preoccupazione non si limita alle note questioni sui dati di addestramento distorti. Vogliono inoltre che le agenzie esaminino il comportamento dei modelli con utenti reali, informazioni sensibili, pressione operativa e condizioni non previste dagli sviluppatori.

Questa posizione mette in discussione la parallela spinta del governo federale verso un’adozione più rapida. Alle agenzie è stato chiesto di rimuovere ostacoli non necessari, modernizzare i servizi e usare l’IA commerciale in modo più efficiente. Eppure le stesse istituzioni restano responsabili quando una raccomandazione automatizzata, un controllo dell’identità, un riepilogo o un’azione software danneggiano il pubblico.

Il titolo di Google News evidenzia un divario più ampio nei test

Lo sviluppo importante non è un nuovo divieto federale, ma una crescente richiesta di evidenze prima che l’IA raggiunga flussi di lavoro con conseguenze rilevanti.

La discussione sui test federali ha riunito funzionari e specialisti del Department of Homeland Security, dell’Idaho National Laboratory e di HP Federal. I loro commenti si sono concentrati sui pregiudizi, sulla supervisione umana e sul valore di test continui.

Arun Vemury, consulente senior presso la Science and Technology Directorate del DHS, ha descritto i test come una spesa essenziale ma spesso trascurata. Le organizzazioni li evitano spesso perché una valutazione significativa richiede tempo, dati adeguati, specialisti tecnici e ambienti che somiglino alle operazioni effettive.

Questa omissione crea una scorciatoia pericolosa. Un modello può funzionare bene durante una dimostrazione controllata e fallire comunque quando viene implementato su popolazioni, dispositivi, luoghi o condizioni di lavoro differenti.

Un sistema di riconoscimento facciale offre un esempio chiaro. La sua accuratezza media dice poco ai decisori sulle prestazioni in condizioni di scarsa illuminazione, con credenziali danneggiate o tra gruppi demografici diversi. Un punteggio complessivo impressionante può nascondere errori concentrati che colpiscono persone specifiche.

I modelli linguistici creano un diverso problema di misurazione. Le loro risposte variano in base ai prompt, ai documenti recuperati, alle versioni del modello e alle istruzioni di sistema. Un team non può stabilire l’affidabilità inviando alcune domande favorevoli e registrando le risposte migliori.

Gli esperti federali trattano quindi i pregiudizi come qualcosa che deve essere gestito per l’intero ciclo di vita di un sistema. Questa impostazione conta perché rifiuta l’idea che gli sviluppatori possano eliminare ogni tendenza indesiderabile durante l’addestramento.

Il comportamento di un modello emerge dalla selezione dei dati, dalla progettazione del sistema, dall’interazione degli utenti e dal contesto di implementazione. Anche un modello tecnicamente competente può produrre un risultato dannoso quando il compito assegnato è definito in modo inadeguato.

La presentazione di Google News riduce questo argomento a un chiaro invito a test rigorosi. La questione completa è più complessa: le agenzie hanno bisogno di programmi di test che riflettano ogni missione, popolazione interessata e livello accettabile di errore.

Questo requisito cambia chi partecipa a un progetto di IA. I responsabili degli acquisti devono chiedere evidenze, i responsabili di programma devono definire il compito previsto e gli esperti di settore devono identificare gli esiti inaccettabili. I team di sicurezza devono testare i confini di accesso, mentre gli utenti devono valutare se gli output siano utili nella pratica.

Gli sviluppatori da soli non possono rispondere a queste domande. Comprendono il sistema, ma non rappresentano ogni persona interessata dalle sue decisioni.

La distinzione tra una dimostrazione e un’implementazione è particolarmente importante. Una dimostrazione chiede se uno strumento di IA possa produrre un risultato desiderato. I test di implementazione chiedono con quale frequenza fallisca, quali utenti incontrino tali fallimenti e se i controlli esistenti li intercettino.

Le agenzie federali operano inoltre con vincoli che le aziende di software per consumatori non sempre condividono. I loro sistemi possono elaborare cartelle cliniche, informazioni sulle prestazioni, dati delle forze dell’ordine, fascicoli del personale e materiali di sicurezza nazionale.

Un errore innocuo in un assistente di scrittura non equivale a un errore in un flusso di lavoro relativo a identità, salute o ammissibilità. I test devono seguire le conseguenze, non l’entusiasmo che circonda il modello.

Ecco perché il titolo merita attenzione anche senza una nuova norma. Cattura un passaggio pratico dalla discussione sui principi dell’IA alla richiesta di prestazioni osservabili in condizioni reali.

Un’adozione federale più rapida alza la posta in gioco

Le agenzie federali subiscono pressioni da entrambe le direzioni: muoversi troppo lentamente e perdere capacità utili, oppure troppo rapidamente ed esporre il pubblico a sistemi poco compresi.

La portata dell’adozione spiega perché i test siano diventati urgenti. Una revisione federale sull’IA del Government Accountability Office ha esaminato gli inventari di 11 agenzie.

Tali inventari contenevano 571 casi d’uso dell’IA segnalati nel 2023 e 1.110 nel 2024. I casi d’uso segnalati dell’IA generativa sono saliti da 32 a 282 nello stesso periodo, con un incremento di circa nove volte.

Questi numeri non dimostrano che ogni sistema elencato sia arrivato in produzione. Gli inventari possono includere usi pianificati, esplorativi e operativi. Mostrano comunque che i team federali stanno valutando l’IA per molte più attività rispetto al passato.

I casi d’uso vanno oltre i chatbot pubblici. Il GAO ha identificato possibili applicazioni nella comunicazione scritta, nell’accesso alle informazioni, nel monitoraggio dei programmi, nell’imaging medico e nell’estrazione di informazioni di salute pubblica dai documenti.

Ogni categoria crea una diversa definizione di prestazione accettabile. Un assistente di scrittura può tollerare una frase poco elegante se una persona la revisiona. Un sistema a supporto del lavoro medico o della sicurezza pubblica necessita di evidenze molto più solide.

I responsabili delle agenzie devono quindi classificare il rischio prima di scegliere un piano di valutazione. La domanda chiave non è se un modello utilizzi l’IA generativa. È cosa accade quando il modello sbaglia.

Si consideri uno strumento che riepiloga una politica interna. Il suo rischio più evidente è un riepilogo impreciso. Tuttavia può anche omettere un’eccezione, esporre testo riservato, citare una norma superata o produrre risposte diverse per utenti simili.

Un progetto pilota potrebbe non rilevare questi fallimenti perché i partecipanti conoscono già il materiale di origine. I nuovi dipendenti potrebbero fidarsi dello stesso output senza riconoscere ciò che è scomparso.

Gli acquisti aggiungono un ulteriore livello. Le agenzie spesso acquisiscono modelli, servizi cloud e applicazioni dai fornitori anziché sviluppare tutto internamente. Gli acquirenti dipendono quindi da documentazione ed evidenze di valutazione che potrebbero non corrispondere all’ambiente governativo.

Il benchmark di un fornitore può stabilire che un modello ottenga buoni risultati in un test standard. Non può stabilire che il sistema completo dell’agenzia si comporterà in modo sicuro con dati locali, strumenti di recupero, autorizzazioni e utenti.

La distinzione diventa più seria con l’IA agentica. Un agente IA è un sistema che può scegliere ed eseguire azioni attraverso software connessi, anziché limitarsi a restituire testo.

Un normale chatbot può generare una raccomandazione falsa. Un agente connesso può agire su di essa modificando un record, inviando un messaggio, chiamando un servizio esterno o avviando un altro flusso di lavoro.

I test devono quindi coprire sia il modello sia la sua autorità. I valutatori devono determinare quali azioni siano consentite, come funzionino le approvazioni e se il sistema si fermi quando le istruzioni entrano in conflitto.

Tamara Lilly, assistente ispettore generale presso il Department of Health and Human Services, ha avvertito che i sistemi automatizzati possono operare più rapidamente dei controlli tradizionali. Le sue linee guida sulla governance operativa hanno sottolineato confini chiari, regole di accesso ed evidenze continue che i controlli funzionano.

Questo è l’obiettivo della pressione alla base della storia di Google News. I chief information officer e i chief AI officer devono produrre risultati utili evitando che la sperimentazione diventi un’implementazione incontrollata.

La tensione sul budget è inevitabile. Ambienti di valutazione, dataset rappresentativi, red team, revisioni dell’accessibilità, test di sicurezza e monitoraggio post-implementazione consumano tutti risorse.

Queste spese possono sembrare un ritardo per i benefici della missione. Tuttavia, test insufficienti non eliminano il costo. Trasferiscono quel costo a utenti, addetti alla risposta agli incidenti, revisori e futuri interventi di correzione.

Il governo ha anche un problema di fiducia dal quale le organizzazioni private talvolta possono sottrarsi. Le persone non possono sempre scegliere un altro sistema di prestazioni, processo di frontiera o agenzia pubblica dopo un fallimento automatizzato.

Questa mancanza di scelta innalza lo standard. Le agenzie hanno bisogno di evidenze che uno strumento funzioni per il suo scopo definito, non di un’affermazione generica secondo cui il modello sottostante è avanzato.

Un programma di adozione utile separerà quindi l’assistenza a basso rischio dal supporto decisionale con conseguenze rilevanti. Può procedere rapidamente per attività di redazione reversibili, applicando al contempo controlli più severi ai sistemi che incidono su diritti, accesso, sicurezza o servizi essenziali.

Questo approccio non richiede di trattare ogni funzionalità di IA come ugualmente pericolosa. Richiede di commisurare le evidenze e l’intensità dei controlli alle conseguenze del fallimento.

Velocità contro garanzia è il vero conflitto dell’IA federale

Il conflitto centrale non è innovazione contro regolamentazione; è implementazione rapida contro garanzia specifica per la missione.

La Casa Bianca ha rafforzato l’adozione federale più rapida nell’aprile 2025 attraverso politiche riviste sull’uso e sugli acquisti di IA da parte delle agenzie. La politica federale sull’IA ha sottolineato la riduzione delle barriere non necessarie, mantenendo al contempo protezioni per privacy, diritti civili e libertà civili.

Sulla carta, questa combinazione sembra compatibile. Nella pratica, velocità e garanzia competono per lo stesso personale, denaro e attenzione della leadership.

Un team può acquisire rapidamente un assistente commerciale. Non può determinare istantaneamente come tale assistente gestisca ogni documento riservato, istruzione fuorviante, affermazione non supportata o richiesta insolita da parte di un utente.

Il compromesso che ne deriva viene spesso presentato in modo errato. Ai leader viene chiesto se sostengano l’adozione dell’IA o preferiscano la cautela. Questa impostazione trasforma un lavoro ingegneristico essenziale in una preferenza politica.

I test sono parte dell’implementazione, non un argomento contro di essa. Aviazione, tecnologia medica, cybersecurity e altri settori ad alta conseguenza si basano sulla valutazione perché anche sistemi utili possono fallire.

L’IA complica questo principio perché il suo comportamento è probabilistico. Un sistema probabilistico può produrre output diversi da input simili, soprattutto dopo che un fornitore aggiorna il modello.

I test del software tradizionale restano necessari, ma non sono sufficienti. Uno sviluppatore può verificare che un’API restituisca una risposta senza stabilire se tale risposta sia accurata, equa, sicura o utile.

I team federali necessitano di diversi livelli di garanzia. I test di capacità chiedono se il sistema completi il compito assegnato. I test avversariali chiedono come risponda ai tentativi di manipolazione.

I test sul campo esaminano le prestazioni con utenti reali e condizioni operative realistiche. Il monitoraggio verifica se i risultati cambiano dopo l’implementazione, nuovi dati o un aggiornamento del modello.

La supervisione umana collega questi livelli. Una persona non può supervisionare in modo significativo un sistema di IA senza tempo, autorità e conoscenza del settore sufficienti per contestarne l’output.

Un pulsante di approvazione puramente nominale non crea supervisione. Se i dipendenti elaborano centinaia di raccomandazioni sotto la pressione delle scadenze, potrebbero accettare automaticamente gli output.

Le agenzie devono testare il flusso di lavoro umano insieme al modello. Dovrebbero misurare se i revisori individuano gli errori, comprendono l’incertezza e sanno quando inoltrare un risultato a un livello superiore.

Questo crea un’inversione scomoda. L’AI viene spesso acquistata per ridurre il lavoro, eppure un’implementazione sicura può inizialmente richiedere più lavoro specializzato.

I team di programma hanno bisogno di esperti di settore per costruire casi di test. Gli specialisti della sicurezza devono esaminare i flussi di dati, i legali devono valutare gli obblighi giuridici e gli esperti di accessibilità devono analizzare l’impatto sugli utenti.

L’investimento può comunque dare risultati. Un sistema testato può ridurre il lavoro ripetitivo, mantenendo le persone concentrate sulle eccezioni e sul giudizio. Tuttavia, i responsabili non dovrebbero fingere che la supervisione compaia automaticamente.

Lo stesso conflitto riguarda i fornitori. Gli acquirenti governativi vogliono accedere rapidamente a modelli più nuovi, ma aggiornamenti frequenti possono invalidare i risultati delle valutazioni precedenti.

Un fornitore può migliorare il ragionamento generale modificando al contempo il comportamento di rifiuto, la formattazione o le prestazioni in un’attività specializzata. Le agenzie hanno bisogno di controlli delle versioni e di criteri che attivino una nuova convalida prima di accettare tali aggiornamenti.

I fornitori di modelli non possono neppure testare da soli ogni contesto federale. Un sistema per uso generale incontra rischi diversi quando viene collegato a registri sull’immigrazione, dati scientifici, documenti di approvvigionamento o flussi di lavoro clinici.

La responsabilità è quindi condivisa, ma non intercambiabile. I fornitori dovrebbero divulgare le limitazioni e le modifiche rilevanti. Le agenzie devono comunque testare il sistema assemblato nel suo ambiente previsto.

Google News offre un percorso semplice per scoprire la questione, ma il conflitto politico va molto più in profondità di un singolo titolo. Ai responsabili federali viene chiesto di accelerare l’adozione senza abbassare gli standard associati all’autorità pubblica.

La risposta praticabile è un’implementazione graduale. I team iniziano con un’attività circoscritta, dati limitati, autorizzazioni ristrette e criteri di successo misurabili.

Si espandono poi soltanto quando le evidenze supportano l’espansione. Questo metodo preserva lo slancio, creando al contempo una documentazione che revisori, dirigenti e utenti interessati possono esaminare.

La gradualità rende inoltre i fallimenti più informativi. Un progetto pilota contenuto può rivelare che un modello non è adatto senza creare un problema di servizio a livello nazionale.

L’alternativa è l’implementazione guidata dall’entusiasmo. Questo approccio considera la fluidità iniziale come una prova, confonde i benchmark dei fornitori con le prestazioni rispetto alla missione e scopre le limitazioni attraverso incidenti pubblici.

Test rigorosi dell’AI devono accompagnare il sistema in produzione

Un test prima dell’implementazione è un punto di partenza, perché il comportamento dell’AI può cambiare dopo modifiche a modelli, dati, utenti e strumenti connessi.

Il National Institute of Standards and Technology descrive i test attraverso il processo più ampio di testing, valutazione, verifica e convalida. Questo processo viene spesso abbreviato in TEVV.

Il framework di rischio del NIST afferma che i sistemi AI dovrebbero essere testati prima dell’implementazione e regolarmente durante il funzionamento. Richiede inoltre metodi documentati, criteri misurabili, condizioni realistiche e il coinvolgimento di esperti indipendenti o interni esterni al team di sviluppo.

Queste indicazioni mostrano perché la parola “rigoroso” è importante. Sottoporre un modello una sola volta a un elenco fisso di prompt non dimostra prestazioni affidabili.

Una valutazione significativa parte da un’attività definita. Le agenzie dovrebbero specificare gli utenti previsti, i dati disponibili, le condizioni operative, le azioni vietate e le conseguenze di un fallimento.

I valutatori possono quindi costruire test attorno a casi realistici. Dovrebbero includere esempi ordinari, casi rari, input avversari, informazioni incomplete e situazioni in cui il sistema dovrebbe rifiutarsi di agire.

Anche le metriche devono riflettere la missione. L’accuratezza può essere importante, ma potrebbe non cogliere se gli errori si concentrano tra gruppi specifici.

Un team che valuta i riepiloghi potrebbe misurare affermazioni non supportate, requisiti mancanti, citazioni errate e divulgazione di informazioni riservate. Un team che valuta tecnologie di identificazione avrebbe bisogno di misure diverse.

Le soglie dovrebbero essere fissate prima che i responsabili vedano risultati favorevoli. Altrimenti, i team di progetto possono ridefinire il successo dopo aver osservato le debolezze del sistema.

Una valutazione indipendente aiuta a gestire questo rischio. Gli sviluppatori comprendono naturalmente come ottenere buoni risultati dal proprio sistema. Gli utenti e i valutatori esterni hanno maggiori probabilità di scoprire istruzioni poco chiare e comportamenti inattesi.

Il red teaming aggiunge un’altra prospettiva. Il red teaming è un testing avversario strutturato che cerca debolezze, output dannosi o modi per aggirare i controlli.

Non dovrebbe trasformarsi in spettacolo. Alcuni prompt eclatanti possono generare pubblicità senza misurare i rischi che contano per una determinata agenzia.

I buoni red team lavorano a partire da un modello di minaccia, che identifica potenziali attaccanti, beni protetti, metodi probabili e conseguenze operative. Le loro conclusioni dovrebbero portare a correzioni, nuovi test e decisioni documentate.

I test sul campo sono altrettanto importanti perché i laboratori non possono riprodurre ogni comportamento umano. I dipendenti possono copiare documenti più grandi del previsto, porre domande ambigue o combinare gli output con informazioni non ufficiali.

Un sistema può anche modificare l’ambiente di lavoro intorno a sé. Il personale può smettere di verificare le fonti primarie, cambiare il modo in cui documenta le decisioni o affidarsi a linguaggio generato che oscura la responsabilità.

Questi effetti compaiono raramente in un benchmark. Emergono attraverso l’osservazione, le interviste agli utenti, la segnalazione degli incidenti e misurazioni ripetute.

Il monitoraggio in produzione deve quindi rilevare la deriva. Per deriva si intende il cambiamento nel tempo della relazione tra input, comportamento del modello e risultati attesi.

La causa potrebbe essere una nuova versione del modello, una diversa popolazione di utenti, una raccolta di recupero modificata o il mutamento delle condizioni reali. Ognuno di questi fattori può indebolire una valutazione precedente.

Il monitoraggio dovrebbe registrare più della semplice disponibilità del sistema. I team hanno bisogno di segnali relativi a output insoliti, controlli falliti, override degli utenti, reclami e qualità specifica dell’attività.

Hanno inoltre bisogno di un processo per gli incidenti. I dipendenti devono sapere dove segnalare un risultato sospetto, e i responsabili del programma devono avere l’autorità di limitare o sospendere il sistema.

Questa capacità conta soprattutto per gli agenti connessi. L’accesso secondo il principio del privilegio minimo consiste nel dare a un sistema soltanto le autorizzazioni necessarie per l’attività assegnata.

Un assistente di redazione non necessita dell’autorità per pubblicare. Un agente di pianificazione non necessita di un accesso illimitato ai fascicoli del personale.

I team dovrebbero testare ciò che accade quando il modello richiede un’azione al di fuori delle sue autorizzazioni. Il risultato previsto deve essere un fallimento controllato, non una soluzione improvvisata.

La valutazione dei dati merita la stessa attenzione. Le agenzie devono comprendere quali informazioni entrano in un modello, dove vengono elaborate, cosa viene conservato e chi può recuperarle.

La generazione aumentata dal recupero, un metodo che fornisce documenti selezionati a un modello, può migliorare la pertinenza. Può anche riprodurre materiale obsoleto, non autorizzato o contraddittorio.

La governance dei documenti diventa quindi parte del testing dell’AI. Una base di conoscenza ricercabile affidabile necessita di responsabilità chiare, controlli di accesso, materiale sorgente aggiornato e aggiornamenti tracciabili.

Il punto scettico è che nessun programma di valutazione può dimostrare che un modello generale sia sicuro in ogni condizione. I possibili input e le interazioni sono troppo ampi.

Le agenzie dovrebbero evitare affermazioni assolute come privo di pregiudizi, sicuro o privo di allucinazioni. Tali descrizioni vanno oltre ciò che un test circoscritto può dimostrare.

Una conclusione difendibile è più circoscritta. Le evidenze possono mostrare che un determinato sistema ha soddisfatto soglie definite per una particolare attività, versione, popolazione e ambiente.

Questa precisazione non è una debolezza. È il fondamento di una garanzia onesta.

I team federali devono inoltre pubblicare informazioni sufficienti per la supervisione senza esporre sistemi sensibili. Possono descrivere l’uso previsto, le categorie di valutazione, le limitazioni e i processi di monitoraggio, proteggendo al contempo i dettagli operativi.

La trasparenza rafforza la responsabilità perché consente al pubblico di distinguere tra un assistente controllato e un decisore automatizzato. Offre inoltre a ispettori e legislatori una base per porre domande precise.

Il maggiore rischio di implementazione è trasformare i test in una checklist. Un modulo completato non può sostituire evidenze realistiche.

I documenti di conformità sono importanti, ma dovrebbero rimandare a risultati dei test, registri degli incidenti, versioni dei modelli e responsabili identificabili. In caso contrario, le agenzie rischiano di produrre una vasta documentazione attorno a un sistema incerto.

Cosa dovrebbero osservare ora gli acquirenti federali di AI

La prossima fase sarà misurata dalla capacità delle agenzie federali di trasformare i principi di test in criteri di implementazione vincolanti ed evidenze continue.

Il primo segnale è il modo in cui le agenzie attuano l’approvazione basata sul rischio per l’AI con conseguenze rilevanti. I soli inventari non possono mostrare se i responsabili abbiano fermato, ristretto o riprogettato sistemi che non hanno superato la valutazione.

Occorre osservare documentazione pubblica che distingua l’assistenza a basso rischio dall’AI che incide su diritti, sicurezza, accesso o servizi essenziali. Categorie chiare rafforzerebbero l’argomento secondo cui un’adozione più rapida può coesistere con garanzie più rigorose.

L’assenza di tali categorie lo indebolirebbe. Le agenzie potrebbero dichiarare conformità applicando al contempo revisioni simili a rischi fondamentalmente diversi.

Il secondo segnale riguarda la capacità dei contratti di approvvigionamento di preservare i diritti di valutazione dopo l’acquisto. Gli acquirenti governativi necessitano di accesso agli avvisi sulle modifiche ai modelli, alla documentazione pertinente, al supporto per i test e a controlli sugli aggiornamenti.

Il linguaggio contrattuale dovrebbe inoltre chiarire le responsabilità in caso di incidente e la gestione dei dati. Senza tali condizioni, le agenzie possono diventare dipendenti dalle garanzie dei fornitori, che non riflettono il loro ambiente implementato.

Evidenze di requisiti contrattuali ripetibili mostrerebbero che il testing è stato spostato a monte, nella fase di acquisizione. Il continuo affidamento su affermazioni generiche sulle prestazioni suggerirebbe che il divario nell’implementazione permane.

Il terzo segnale è ciò che le agenzie comunicano dopo che i sistemi entrano in produzione. Evidenze utili includerebbero pratiche di monitoraggio, incidenti significativi, azioni correttive ed esempi di usi limitati o interrotti.

L’assenza di incidenti segnalati non dimostra necessariamente la sicurezza. Può indicare che i dipendenti non dispongono di canali di segnalazione o che le agenzie definiscono gli incidenti in modo troppo restrittivo.

I lettori dovrebbero prestare particolare attenzione ai sistemi che ottengono il permesso di agire. Il passaggio dal testo generato all’azione autonoma aumenta sia il potenziale beneficio sia il costo di un errore.

È qui che Google News e piattaforme di scoperta simili hanno un ruolo utile. Possono far emergere audizioni delle agenzie, interviste a specialisti, rapporti degli organismi di vigilanza e modifiche alle politiche che altrimenti rimarrebbero sparse.

L’aggregazione non è tuttavia verifica. I lettori dovrebbero seguire un titolo fino al reportage originale e confrontarne poi le affermazioni con politiche, audit e indicazioni tecniche.

Le evidenze attuali supportano una conclusione prudente. L’implementazione federale dell’AI si sta espandendo, mentre gli esperti stanno ancora sviluppando i metodi necessari per valutare i sistemi in condizioni realistiche.

Ciò non giustifica il congelamento di ogni progetto. Sostiene casi d’uso circoscritti, soglie misurabili, autorità umana, autorizzazioni ristrette e monitoraggio dopo il lancio.

La domanda decisiva non è più se le agenzie federali utilizzeranno l’AI. La utilizzano già e i casi d’uso dichiarati sono cresciuti in modo sostanziale.

La domanda è se ciascuna agenzia possa dimostrare perché un sistema specifico meriti l’autorità assegnatagli. Questa prova dovrebbe includere l’attività, le condizioni testate, le soglie di fallimento, il responsabile e la risposta quando il comportamento cambia.

Quando il prossimo titolo di Google News annuncerà il lancio federale di un sistema di IA, guardate oltre il nome del modello. Chiedetevi cosa è stato testato, chi lo ha valutato, quali problemi restano e se l'agenzia può arrestare il sistema in sicurezza.