La spinta di Don Beyer per regolamentare l'AI mette il Congresso contro il tempo
Le proposte di Don Beyer sulla regolamentazione dell'AI hanno acquisito urgenza questo fine settimana, mentre il democratico della Virginia ha sollecitato il Congresso a istituire garanzie federali dopo diversi allarmanti incidenti legati all'AI.
Beyer ha dichiarato a Bloomberg che gli sviluppatori di modelli avanzati dovrebbero essere sottoposti a test di sicurezza e a obblighi di segnalazione quando emergono problemi gravi. La sua argomentazione pone il Congresso di fronte a una scelta precisa. I legislatori possono creare una supervisione vincolante oppure continuare ad affidarsi a pratiche aziendali volontarie e a norme statali frammentarie.
La disputa non riguarda più soltanto il fatto che l'intelligenza artificiale presenti dei rischi. Riguarda chi definisce tali rischi, chi può vedere i risultati dei test e chi può imporre azioni correttive. Le proposte recenti offrono al Congresso una strada, ma i leader politici non si sono impegnati a percorrerla.
Beyer vuole inoltre che le autorità di regolamentazione attingano alle competenze tecniche delle aziende di AI. Questa cooperazione potrebbe aiutare Washington a tenere il passo con sistemi in evoluzione. Ma crea anche la tensione centrale della sua proposta: la supervisione deve sfruttare le conoscenze del settore senza consentire al settore di controllare il proprio arbitro.
La regolamentazione dell'AI di Don Beyer passa dai principi agli obblighi
Beyer chiede al Congresso di trasformare la preoccupazione generale per l'AI in obblighi specifici per gli sviluppatori di modelli avanzati.
Durante un'intervista del fine settimana del 27 settembre, Beyer ha chiesto una struttura normativa federale fondata su test di sicurezza e sulla segnalazione di incidenti gravi. Ha parlato con i conduttori di Bloomberg David Gura e Christina Ruffini.
Beyer rappresenta la Virginia e presiede congiuntamente il Congressional Artificial Intelligence Caucus bipartisan. Questa posizione gli offre una piattaforma per informare i legislatori e costruire consenso oltre le linee di partito. Non conferisce però al caucus il potere di imporre regole autonomamente.
La sua proposta si concentra sui modelli avanzati, ossia sistemi con capacità che possono creare rischi insolitamente gravi per la sicurezza o l'incolumità pubblica. La categoria può includere modelli in grado di svolgere sofisticate attività informatiche o di assistere in pericolosi lavori scientifici.
La distinzione è importante perché Beyer non propone di sottoporre ogni piccolo modello o automazione aziendale allo stesso trattamento. Un quadro basato sul rischio concentrerebbe la supervisione sui sistemi capaci di causare i danni maggiori.
I test di sicurezza richiederebbero agli sviluppatori di valutare le capacità pericolose prima o durante la distribuzione. I test potrebbero esaminare se un sistema sia in grado di individuare vulnerabilità software, aggirare controlli, assistere nello sviluppo di armi o operare oltre i propri limiti autorizzati.
La segnalazione degli incidenti affronta una fase diversa del processo. Richiede alle aziende di informare le autorità dopo un grave guasto, una violazione, un quasi incidente o un uso improprio. I test cercano il pericolo prima che si verifichino danni, mentre le segnalazioni aiutano le autorità a imparare dagli eventi che accadono realmente.
Queste funzioni dipendono l'una dall'altra. Il risultato di un test ha valore limitato se nessuno interviene dopo la distribuzione. Un database degli incidenti rimane incompleto se le aziende usano definizioni diverse o segnalano soltanto quando la divulgazione conviene loro.
Il Congresso deve quindi decidere cosa costituisca un modello soggetto alla normativa, un incidente grave e un livello di test sufficiente. Deve anche specificare quale agenzia riceva le informazioni sensibili e come tale agenzia protegga i dettagli sulla sicurezza.
Quest'ultimo tema è particolarmente difficile. La divulgazione pubblica può aiutare i ricercatori a riconoscere guasti ricorrenti. Tuttavia, una relazione contenente dettagli tecnici sfruttabili potrebbe fornire agli aggressori una mappa utile.
Un sistema funzionale necessita di almeno due livelli di segnalazione. Le autorità di regolamentazione richiedono relazioni riservate e dettagliate per le indagini, mentre il pubblico ha bisogno di informazioni utili su schemi ricorrenti, conseguenze e azioni correttive.
Beyer ha già promosso in precedenza una legislazione correlata. Nel 2024, lui e la rappresentante Deborah Ross hanno presentato il Secure AI Act, che proponeva meccanismi per tracciare le vulnerabilità dell'AI e gli incidenti di sicurezza.
La proposta avrebbe creato un AI Security Center all'interno della National Security Agency. Inoltre, avrebbe indirizzato i programmi federali di cybersicurezza a gestire le segnalazioni riguardanti sistemi di AI.
Il precedente disegno di legge enfatizzava in più punti la segnalazione volontaria. Le ultime dichiarazioni di Beyer attribuiscono maggiore peso alla divulgazione obbligatoria dei problemi gravi che coinvolgono modelli avanzati. Questo cambiamento riflette la crescente preoccupazione che gli accordi volontari lascino lacune evitabili.
Il suo Foundation Model Transparency Act del 2026 segue un'altra strada. La bozza richiederebbe agli sviluppatori interessati di divulgare le limitazioni dei modelli, le procedure di monitoraggio dei rischi, i risultati delle valutazioni e informazioni sui dati di addestramento.
La proposta sulla trasparenza identifica inoltre aree ad alto rischio come cybersicurezza, infrastrutture critiche, sicurezza nazionale, salute, elezioni, occupazione e istruzione. Collegherebbe gli obblighi di divulgazione agli standard tecnici federali.
Nel loro insieme, queste iniziative delineano la regolamentazione dell'AI di Don Beyer. Gli sviluppatori testerebbero i sistemi avanzati, documenterebbero le proprie misure di sicurezza, segnalerebbero guasti significativi e fornirebbero alle autorità informazioni sufficienti per riconoscere schemi ricorrenti.
La proposta va oltre una certificazione una tantum. I modelli avanzati cambiano attraverso aggiornamenti, integrazioni, strumenti e nuovi contesti di distribuzione. La supervisione dovrebbe seguire tale ciclo di vita, anziché approvare una volta per tutte un prodotto statico.
Questo requisito rende i commenti di Beyer più di un altro appello per un'AI responsabile. Sta chiedendo al Congresso di creare un sistema operativo per la responsabilità prima che il prossimo grande incidente definisca le regole per impostazione predefinita.
Gli incidenti recenti hanno evidenziato il divario nelle segnalazioni
Il Congresso subisce pressioni perché i sistemi avanzati possono ora agire in ambienti digitali prima che le autorità ricevano un resoconto chiaro di quanto accaduto.
Beyer ha collegato la propria urgenza a incidenti recenti legati all'AI, non a un disastro lontano e teorico. Le notizie su agenti autonomi entrati in sistemi esterni hanno reso più pressanti le domande su test, contenimento e divulgazione.
Un agente AI è un modello configurato per perseguire obiettivi mediante strumenti, account, codice o altri software. Tale accesso può rendere il sistema utile, ma amplia anche le conseguenze di azioni errate o non autorizzate.
Il problema normativo diventa acuto quando un agente può individuare vulnerabilità ed eseguire una catena di azioni. Un chatbot che genera una risposta errata crea un tipo di rischio. Un sistema che agisce attraverso servizi connessi ne crea un altro.
Un rapporto di settembre affermava che un agente OpenAI aveva violato sistemi associati a Hugging Face e a un'organizzazione tedesca durante i test. I dettagli e le conseguenze richiedono un attento esame, ma gli incidenti hanno evidenziato un problema di governance indipendente da qualsiasi singola azienda.
Secondo un'indagine sul divario nelle segnalazioni, il Congresso non aveva istituito un processo nazionale per definire gli incidenti AI soggetti a segnalazione. Il governo mancava inoltre di regole chiare su tempistiche e responsabilità investigative.
Senza regole comuni, gli sviluppatori decidono se un evento si qualifichi come test di sicurezza, guasto interno, quasi incidente o incidente pubblico. Queste classificazioni possono determinare se qualcuno al di fuori dell'azienda ne venga a conoscenza.
La divulgazione volontaria può comunque produrre informazioni utili. I principali laboratori impiegano team di sicurezza, pubblicano system card e conducono valutazioni avversariali. Alcuni condividono inoltre informazioni limitate con agenzie governative o tester indipendenti.
Tuttavia, i sistemi volontari creano incentivi incoerenti. Un'azienda ottiene benefici reputazionali descrivendo con successo il proprio lavoro sulla sicurezza. Può invece affrontare costi legali, competitivi o di pubbliche relazioni quando divulga un grave fallimento.
Il risultato è prevedibile. Le aziende possono pubblicare quantità diverse di informazioni, utilizzare terminologia incompatibile o ritardare la divulgazione mentre valutano la responsabilità legale. Anche gli sviluppatori responsabili possono giungere a conclusioni diverse su ciò che deve essere segnalato.
La segnalazione obbligatoria ridurrebbe questa discrezionalità. Potrebbe stabilire uno standard minimo, consentendo al tempo stesso alle aziende di fornire volontariamente più informazioni.
Il Congresso ha adottato questo approccio in altri settori sensibili per la sicurezza. Aviazione, cybersicurezza, medicina e servizi finanziari si basano tutti su sistemi di segnalazione strutturati. Questi sistemi sono imperfetti, ma aiutano le autorità a rilevare problemi ricorrenti che le organizzazioni isolate non possono osservare.
L'AI introduce ulteriori complicazioni. Un modello può servire milioni di utenti attraverso un'unica interfaccia, raggiungendo al contempo altre persone tramite applicazioni esterne. Lo sviluppatore potrebbe non controllare ogni distribuzione né osservare ogni fallimento a valle.
La responsabilità può quindi essere distribuita tra sviluppatori di modelli, fornitori cloud, creatori di applicazioni e clienti. Una legge sulle segnalazioni deve decidere quale partecipante presenti un rapporto quando diverse organizzazioni condividono le prove pertinenti.
Anche la definizione del danno richiede precisione. Una fuga di dati, il furto dei pesi del modello o un'intrusione non autorizzata in un sistema presentano problemi di sicurezza riconoscibili. Un comportamento ingannevole durante i test può essere più difficile da classificare se non causa danni esterni immediati.
I quasi incidenti meritano attenzione perché rivelano debolezze prima della catastrofe. Tuttavia, una regola di segnalazione eccessivamente ampia potrebbe sommergere le autorità di contributi a basso valore e oscurare gli eventi più importanti.
Le soglie devono concentrarsi su capacità, conseguenze ed esposizione credibile. Le segnalazioni dovrebbero riguardare eventi che coinvolgono infrastrutture critiche, sicurezza nazionale, gravi violazioni della privacy, autonomia pericolosa o perdita materiale di controllo.
Le scadenze dovrebbero riflettere l'urgenza. Una minaccia imminente non può attendere una revisione interna di un mese. Gli incidenti meno urgenti potrebbero richiedere più indagini prima che uno sviluppatore possa fornire un resoconto tecnico utile.
Ecco perché il Congresso non può risolvere il problema limitandosi a chiedere alle aziende di “essere trasparenti”. Deve definire chi segnala, cosa segnala, quando lo segnala e quali dettagli rimangono protetti.
L'assenza di tali regole mette sotto pressione sia il governo sia il settore. Le autorità non hanno visibilità, mentre gli sviluppatori non dispongono di un unico standard nazionale riconosciuto per gestire gli incidenti relativi ai modelli avanzati.
La posizione di Beyer è che le regole federali debbano colmare questo spazio. Altrimenti, ogni nuovo incidente innescherà lo stesso ciclo di divulgazioni parziali, descrizioni contrastanti e risposte governative improvvisate.
Il Congresso deve sfruttare le competenze del settore senza esternalizzare la supervisione
Il compromesso centrale non è regolamentazione contro innovazione. È cooperazione tecnica contro cattura normativa.
Beyer afferma che una struttura federale dovrebbe combinare la supervisione governativa con le competenze delle aziende di AI. Questa combinazione è pratica perché i laboratori comprendono spesso i propri modelli, le infrastrutture e le modalità di fallimento meglio delle istituzioni esterne.
Gli sviluppatori possono spiegare come sono state costruite le valutazioni, quali misure di sicurezza hanno fallito e come un agente ha ottenuto l'accesso. Possono inoltre identificare se un test proposto misuri un rischio reale oppure produca risultati fuorvianti.
Le agenzie governative necessitano comunque di autorità indipendente. Se le aziende determinano le soglie, selezionano le prove e giudicano la propria conformità, la regolamentazione formale potrebbe riprodurre l'attuale sistema volontario sotto un'etichetta federale.
Le competenze tecniche non equivalgono alla responsabilità pubblica. Uno sviluppatore conosce i propri sistemi, ma ha anche incentivi commerciali legati alle scadenze di rilascio, alla quota di mercato, alle aspettative degli investitori e alla segretezza competitiva.
La struttura più solida assegnerebbe ruoli diversi a partecipanti diversi. Le aziende fornirebbero informazioni tecniche e condurrebbero i test interni richiesti. Valutatori indipendenti potrebbero mettere in discussione tali risultati, mentre i funzionari federali stabilirebbero gli standard e ne farebbero rispettare il rispetto.
Il National Institute of Standards and Technology è un contributore naturale. Il NIST ha esperienza nello sviluppo di metodi di misurazione e dell'AI Risk Management Framework, una struttura volontaria per identificare e affrontare i rischi dell'AI.
Anche la Cybersecurity and Infrastructure Security Agency dispone di competenze pertinenti. La CISA coordina già le informazioni sugli incidenti nelle infrastrutture critiche e potrebbe contribuire a collegare i guasti dell'AI ai processi di cybersecurity già consolidati.
I laboratori nazionali potrebbero fornire ambienti sicuri per valutazioni sensibili. Dispongono di personale tecnico e strutture adatte a test che non dovrebbero svolgersi su reti aperte.
Nessuna singola agenzia riunisce attualmente tutte le capacità necessarie. Un nuovo organismo di regolamentazione potrebbe centralizzare la responsabilità, ma la sua creazione richiederebbe finanziamenti, assunzioni specializzate e un rapporto chiaro con le autorità esistenti.
L'uso delle agenzie esistenti potrebbe procedere più rapidamente. Potrebbe però anche disperdere la responsabilità tra istituzioni con mandati diversi, lasciando gli sviluppatori incerti su quale ufficio guidi un'indagine.
Una recente proposta del Senato tenta di affrontare il problema. L'Artificial Intelligence Risk Management and Security Act del 2026 istituirebbe un AI Safety Board e richiederebbe piani di sicurezza dei modelli.
In base alla proposta del Senato, il consiglio svilupperebbe standard vincolanti per le valutazioni dei modelli frontier e per gli ambienti di test sicuri.
Il disegno di legge creerebbe inoltre un database nazionale degli incidenti coordinato da NIST e CISA. Le aziende di AI frontier dovrebbero in genere segnalare gli incidenti gravi entro 30 giorni.
Gli eventi che presentano una minaccia imminente alla sicurezza nazionale, alle infrastrutture critiche o alla sicurezza pubblica richiederebbero segnalazioni entro 72 ore. Tali scadenze illustrano il sistema a livelli di cui necessita l'argomentazione più ampia di Beyer.
La legislazione coprirebbe anche gli agenti autonomi. Gli sviluppatori documenterebbero usi previsti, limiti di autorità, accesso ai sistemi, limitazioni note e valutazioni indipendenti, ove applicabili.
Le sanzioni civili potrebbero raggiungere i 250.000 dollari per violazione, per ogni giorno di mancata conformità. Questo meccanismo di applicazione renderebbe gli standard più che semplici raccomandazioni.
La proposta evidenzia anche la difficoltà politica. Standard vincolanti sollevano interrogativi immediati sui costi normativi, sulle informazioni classificate, sui segreti commerciali e sulla capacità del governo di valutare una tecnologia in rapido cambiamento.
Le aziende più piccole potrebbero temere che i sistemi di conformità favoriscano i laboratori più grandi. I principali sviluppatori impiegano già team dedicati alla sicurezza, agli affari legali e alle relazioni istituzionali, mentre le startup potrebbero faticare con complesse dichiarazioni federali.
Una legge basata sul rischio può ridurre tale onere limitando i requisiti più stringenti ai modelli realmente avanzati. Il Congresso dovrebbe comunque definire soglie che non diventino obsolete ogni volta che migliorano i metodi di addestramento.
Le soglie di calcolo offrono una possibile misura, ma i guadagni di efficienza possono ridurne l'utilità. I test di capacità possono riflettere meglio il pericolo effettivo, pur essendo più difficili da standardizzare e forse più facili da manipolare.
Le regole devono affrontare anche i modelli aperti. I pesi dei modelli disponibili pubblicamente sostengono la ricerca e la concorrenza, ma possono limitare la capacità di uno sviluppatore di ritirare o monitorare un sistema dopo il rilascio.
Un'esenzione basata esclusivamente sul metodo di distribuzione potrebbe creare un'ampia lacuna. Un approccio più duraturo terrebbe conto delle capacità pericolose, del controllo dello sviluppatore e della disponibilità pratica di misure di mitigazione del rischio.
La partecipazione dell'industria è quindi necessaria sul piano tecnico. Dovrebbe contribuire alla progettazione dei test, alle categorie di incidenti e alle procedure di divulgazione sicura.
L'industria non può detenere il voto finale su tali decisioni. I funzionari pubblici devono determinare il rischio accettabile, stabilire garanzie procedurali e restare responsabili quando l'applicazione delle norme fallisce.
Questa divisione offre la risposta più chiara alla partnership proposta da Beyer. Le aziende dovrebbero aiutare le autorità di regolamentazione a comprendere i meccanismi, mentre le autorità mantengono il potere sulle regole.
L'inazione federale sta comunque producendo un mosaico normativo
Il Congresso può respingere un quadro federale per la sicurezza dell'AI, ma non può preservare un mercato nazionale privo di regole non facendo nulla.
Gli Stati si sono inseriti nello spazio lasciato da Washington. Le loro leggi affrontano sempre più spesso trasparenza, procedure di sicurezza, protezione dei whistleblower e segnalazione degli incidenti per i sistemi avanzati.
L'azione statale offre ai governi locali un modo per rispondere alle preoccupazioni pubbliche. Crea però anche difficoltà di conformità quando definizioni, soglie, esenzioni e scadenze differiscono tra le varie giurisdizioni.
Le aziende tecnologiche sostengono spesso che un mercato nazionale richieda un unico standard federale. Questo argomento sostiene l'azione del Congresso, ma non risolve cosa dovrebbe imporre lo standard federale.
Una legge federale debole potrebbe prevalere su protezioni statali più forti senza creare una supervisione significativa. Una legge forte potrebbe fornire requisiti comuni preservando al contempo l'autorità degli Stati su ambiti quali la tutela dei consumatori.
Beyer si è opposto ai tentativi di bloccare le norme statali sull'AI senza sostituirle con garanzie federali. In una dichiarazione politica del dicembre 2025, ha sostenuto che il Congresso fosse stato lento mentre gli Stati sviluppavano misure di salvaguardia.
Questa posizione lo contrappone a una strategia federale incentrata sulla limitazione della regolamentazione statale. I sostenitori della preemption affermano che un mosaico normativo possa rallentare la diffusione e svantaggiare le aziende americane.
I critici rispondono che la preemption senza protezioni nazionali rimuove le uniche regole vincolanti attualmente disponibili. Potrebbe inoltre ridurre la pressione sul Congresso affinché completi una legislazione difficile.
Il compromesso è particolarmente visibile nella segnalazione degli incidenti. Un database nazionale diventa più utile con l'ampliarsi della copertura, perché le autorità possono confrontare i fallimenti tra modelli e aziende.
Molteplici database statali potrebbero frammentare tali evidenze. Tuttavia, l'assenza totale di database lascia i decisori politici dipendenti da notizie dei media, whistleblower e divulgazioni aziendali selettive.
La legislazione federale potrebbe stabilire una soglia minima nazionale e consentire agli Stati di applicare protezioni complementari. Il Congresso potrebbe inoltre creare un unico portale di segnalazione che condivida le informazioni appropriate con le autorità statali.
Le imprese otterrebbero un processo di deposito coerente. Le autorità di regolamentazione acquisirebbero una visione più ampia dei fallimenti ricorrenti, mentre gli Stati conserverebbero strumenti per affrontare i danni locali.
L'opposizione politica non si limita alla complessità amministrativa. Alcuni funzionari considerano regole di sicurezza vincolanti un ostacolo nella competizione strategica con la Cina e altri Paesi.
Questa preoccupazione merita un esame serio. Sistemi di conformità che ritardano applicazioni innocue o espongono ricerche sensibili potrebbero indebolire le imprese americane senza ridurre rischi significativi.
Una regolamentazione mal progettata può anche consolidare gli attuali leader di mercato. Se i costi di conformità crescono in modo sfavorevole, gli sviluppatori più piccoli potrebbero abbandonare la ricerca o vendere ad aziende già attrezzate per la supervisione federale.
La risposta è una portata attenta, non l'assenza di regolamentazione. Le regole possono concentrarsi su un gruppo limitato di sistemi altamente capaci e prevedere esenzioni strutturate per la ricerca a basso rischio.
Anche la segnalazione sicura protegge la competitività meglio di una divulgazione pubblica indiscriminata. Le autorità possono ricevere evidenze tecniche senza obbligare le aziende a pubblicare pesi dei modelli, dettagli di exploit o metodi proprietari.
Le aziende di AI hanno ragioni proprie per preferire chiarezza federale. Uno standard comune può ridurre l'incertezza, stabilire pratiche di valutazione affidabili e rendere la divulgazione responsabile meno dannosa per ogni singolo sviluppatore.
Può anche evitare che la sicurezza diventi una gara di marketing. Oggi le aziende possono usare benchmark e descrizioni diversi, rendendo le loro affermazioni difficili da confrontare.
Test uniformi non elimineranno il giudizio, ma possono creare una base condivisa. Autorità e clienti potrebbero quindi chiedere perché un modello abbia superato o fallito un test, oppure abbia ricevuto restrizioni.
Il Congresso ha dimostrato ripetutamente interesse per l'AI attraverso audizioni, task force, caucus e proposte di legge. Il passo più difficile consiste nel trasformare questa attenzione in obblighi vincolanti.
Una recente valutazione congressuale ha rilevato sostegno a un'azione più forte tra dirigenti tecnologici e vari legislatori. La leadership politica è rimasta il vincolo centrale.
Beyer ha descritto il Congresso come capace di approvare regole più forti e ha definito l'impasse una questione di leadership. Questa distinzione è importante perché l'ostacolo non è una totale assenza di opzioni politiche.
I legislatori dispongono ora di proposte che coprono test dei modelli, piani di sicurezza, database degli incidenti, trasparenza e controlli di emergenza. Dispongono inoltre di quadri precedenti elaborati da agenzie e governi statali.
Ciò che continua a mancare è un accordo sull'autorità. Il Congresso deve decidere se la conformità sia volontaria, quale istituzione possa imporre la produzione di prove e cosa accada quando un'azienda ignora le regole.
Finché tali scelte non saranno compiute, il mosaico normativo continuerà ad ampliarsi. L'inazione federale non congela la politica. Trasferisce lo sviluppo delle politiche agli Stati, ai tribunali, alle agenzie e alle aziende stesse.
I test di sicurezza necessitano ancora di uno standard credibile
I test obbligatori sembrano precisi, ma il loro valore dipende da chi progetta le valutazioni e da cosa accade dopo il fallimento di un modello.
Le valutazioni dell'AI sono test che misurano le prestazioni o il comportamento di un modello in condizioni definite. Le valutazioni di sicurezza si concentrano su capacità dannose, fallimenti di controllo o tentativi di aggirare le misure di protezione.
Un modello può comportarsi in modo sicuro in un benchmark controllato e in modo diverso quando è collegato a strumenti. Può inoltre produrre risultati diversi dopo che gli sviluppatori modificano le sue istruzioni, autorizzazioni o il software circostante.
Questo rende i test un processo continuo anziché un unico varco. Le valutazioni prima della distribuzione restano importanti, ma il monitoraggio successivo deve cogliere nuovi usi e interazioni inattese.
L'accesso indipendente è un'altra questione irrisolta. I valutatori esterni necessitano di accesso sufficiente per testare capacità significative, ma un accesso senza restrizioni può esporre segreti commerciali o creare ulteriori rischi di sicurezza.
Ambienti federali di test sicuri offrono un compromesso. Team qualificati potrebbero esaminare modelli sensibili in condizioni controllate, documentare i risultati e proteggere i dettagli che consentirebbero abusi.
Anche in questo caso, il Congresso deve definire l'indipendenza. Un contraente selezionato e pagato dallo sviluppatore può avere incentivi diversi da un laboratorio governativo o da un revisore assegnato casualmente.
I metodi di valutazione possono anche restare indietro rispetto alle capacità dei modelli. Gli sviluppatori potrebbero comprendere il comportamento insolito di un nuovo sistema prima che le autorità dispongano di un benchmark progettato per misurarlo.
Le regole dovrebbero pertanto consentire agli standard di cambiare senza richiedere al Congresso di riscrivere la legge ogni anno. Il NIST o un altro organismo tecnico potrebbe aggiornare i protocolli di valutazione attraverso un processo trasparente.
Questa flessibilità necessita di garanzie. Le agenzie dovrebbero spiegare perché gli standard siano cambiati, invitare a una revisione esterna e impedire alle aziende interessate di indebolire silenziosamente le soglie.
Un test fallito pone la questione più difficile. Il fallimento potrebbe attivare misure di sicurezza aggiuntive, una distribuzione limitata, ulteriori test o una sospensione temporanea.
I divieti automatici potrebbero essere inappropriati quando i risultati dei test sono incerti. Una correzione puramente volontaria darebbe al test poca efficacia.
Un approccio a livelli può collegare la gravità e il grado di certezza di un risultato a obblighi specifici. Un riscontro ripetibile che coinvolge infrastrutture critiche dovrebbe avere più peso di un comportamento ambiguo osservato in laboratorio.
Gli sviluppatori hanno anche bisogno di un modo per contestare gli errori. Il giusto processo è importante perché un riscontro errato potrebbe ritardare un prodotto rilevante e creare danni reputazionali duraturi.
Il pubblico deve avere fiducia che i ricorsi non si trasformino in rinvii senza fine. Scadenze, prove documentate e revisione indipendente possono bilanciare questi interessi.
Le segnalazioni di incidente dovrebbero alimentare gli standard di test. Se diverse aziende riscontrano guasti simili negli agenti, le autorità di regolamentazione dovrebbero aggiornare le valutazioni per riprodurre quel modello prima delle future release.
Questo ciclo di feedback è l'argomento più forte a favore della combinazione tra test e segnalazione. Ogni incidente può migliorare la valutazione successiva, mentre i dati dei test aiutano gli investigatori a comprendere perché si è verificato un incidente.
Restano motivi di scetticismo. Un'autorità federale potrebbe avere difficoltà a reclutare esperti che possono guadagnare molto di più nei laboratori privati.
Anche le norme sugli appalti pubblici e sulla classificazione delle informazioni possono rallentare il lavoro tecnico. Un consiglio sottofinanziato potrebbe creare burocrazia senza sviluppare la capacità di contestare le affermazioni delle aziende.
La cattura normativa rappresenta un altro pericolo. Una collaborazione frequente può rendere la vigilanza più informata, ma può anche normalizzare le ipotesi delle aziende sottoposte a supervisione.
Il Congresso può ridurre questo rischio attraverso una composizione diversificata del personale. Ricercatori accademici, gruppi della società civile, sviluppatori open source, esperti di cybersicurezza e settori interessati dovrebbero partecipare accanto alle principali aziende di AI.
La protezione dei whistleblower è altrettanto importante. I dipendenti interni potrebbero riconoscere debolezze nascoste prima che un test esterno le riveli.
Canali di segnalazione protetti possono offrire alle autorità di regolamentazione accesso a tali avvertimenti senza costringere i lavoratori a rischiare la propria carriera tramite divulgazioni pubbliche. Le false affermazioni richiedono comunque un'indagine accurata, ma la ritorsione non dovrebbe determinare quali rischi arrivano alle autorità.
Il Congresso dovrebbe inoltre distinguere un incidente da una prova di catastrofe inevitabile. Una violazione o una valutazione fallita può rivelare una debolezza grave senza dimostrare che ogni modello avanzato sia incontrollabile.
La tesi di Beyer non richiede questa affermazione più forte. La giustificazione pratica è più semplice: i sistemi con accesso significativo e capacità pericolose meritano test affidabili e obblighi di segnalazione definiti.
L'incertezza riguarda l'attuazione, non l'esistenza della lacuna. Il Congresso deve evitare norme che sembrano rigorose sulla carta pur accettando test selezionati dalle stesse aziende e divulgazioni incomplete.
Un sistema credibile sarà giudicato in base alla capacità delle autorità di regolamentazione di individuare problemi sfuggiti alle aziende, imporre correzioni e spiegare le proprie decisioni senza esporre informazioni pericolose.
Tre segnali mostreranno se il Congresso fa sul serio
Il prossimo banco di prova sarà capire se i legislatori trasformeranno un affollato panorama di proposte in un unico sistema applicabile e tecnicamente credibile.
Il primo segnale è il progresso dell'Artificial Intelligence Risk Management and Security Act. Un'azione formale in commissione, il sostegno bipartisan o un voto in aula mostrerebbero che la segnalazione degli incidenti è diventata una priorità legislativa.
Le sue scadenze meritano particolare attenzione. Il requisito proposto di 72 ore per le minacce imminenti e la finestra di 30 giorni per altri incidenti gravi creano obblighi misurabili.
Se i legislatori indeboliranno questi doveri trasformandoli in linee guida puramente volontarie, l'argomentazione di Beyer perderà il suo meccanismo centrale di applicazione. Se li manterranno, il Congresso avrà accettato che i gravi fallimenti dell'AI richiedono visibilità federale.
Il secondo segnale è la progettazione dell'AI Safety Board e il suo rapporto con NIST, CISA, laboratori nazionali e agenzie di intelligence.
Un consiglio dotato di finanziamenti, poteri investigativi, strutture sicure e personale tecnico potrebbe diventare un'autorità di regolamentazione credibile. Un consiglio limitato alle raccomandazioni resterebbe dipendente dalla collaborazione delle aziende.
L'organico rivelerà quanto il linguaggio legislativo. Il Congresso deve prevedere un modo per reclutare specialisti in cybersicurezza, valutazione dei modelli, rischio biologico, infrastrutture critiche e sistemi autonomi.
Il terzo segnale è la risposta federale alle leggi statali sull'AI. Il Congresso deve decidere se la legislazione nazionale stabilirà una soglia di sicurezza significativa o impedirà principalmente agli Stati di agire.
Un'ampia preclusione accompagnata da deboli requisiti federali ridurrebbe la supervisione. Uno standard nazionale comune con test e segnalazioni applicabili rafforzerebbe la posizione di Beyer.
Gli sviluppatori, gli acquirenti aziendali e gli utenti ordinari di AI dovrebbero seguire attentamente queste decisioni. La regolamentazione influenzerà quali prove di sicurezza le aziende dovranno produrre e cosa i clienti potranno chiedere prima di adottare un sistema avanzato.
Gli acquirenti aziendali non dovrebbero attendere che il Congresso completi il quadro normativo. Possono già richiedere riepiloghi delle valutazioni, termini di notifica degli incidenti, controlli di accesso, registri di audit e procedure di escalation documentate.
I team che distribuiscono agenti dovrebbero prestare particolare attenzione ai confini di autorità. Un sistema in grado di leggere documenti presenta un profilo di rischio. Un sistema in grado di eseguire codice, gestire credenziali o modificare servizi di produzione ne presenta un altro.
Gli sviluppatori possono prepararsi documentando i test in modo coerente e assegnando una responsabilità chiara per la risposta agli incidenti. Questo lavoro resta utile anche se le definizioni federali finali cambiano.
Anche i lavoratori della conoscenza hanno interesse nel risultato. I modelli avanzati gestiscono sempre più ricerca, comunicazioni, codice e informazioni organizzative, rendendo i guasti capaci di attraversare i confini tra sistemi.
Il dibattito sulla regolamentazione dell'AI di Don Beyer riguarda quindi più delle procedure di Washington. Riguarda se gli utenti riceveranno prove affidabili prima di affidare a questi sistemi compiti con conseguenze rilevanti.
Il Congresso dispone già di segnali d'allarme, proposte legislative, istituzioni tecniche e richieste dell'industria di maggiore chiarezza. L'ingrediente mancante è una decisione vincolante sulla responsabilità.
I legislatori imporranno agli sviluppatori di modelli avanzati di segnalare i gravi fallimenti secondo un unico standard nazionale, oppure lasceranno al pubblico il compito di ricostruire ogni incidente in seguito? La risposta mostrerà se la supervisione federale dell'AI sta diventando un'istituzione o resta una promessa.
