L'audizione del Consiglio di New York su OpenAI mette i laboratori di IA sotto giuramento

OpenAI parteciperà a un'audizione del Consiglio di New York insieme a tre importanti rivali, sotto giuramento, dopo che la maggior parte ha accettato di comparire soltanto quando i legislatori hanno minacciato di emettere mandati di comparizione. La sessione del 5 ottobre porterà Anthropic, Google, Meta e OpenAI davanti a tutti i 51 membri del Consiglio. È inoltre atteso a testimoniare l'ex ricercatore di Anthropic Jacob Coxon, dopo aver avvertito pubblicamente che un'IA avanzata potrebbe sfuggire al controllo umano.

L'audizione del Consiglio di New York su OpenAI non è semplicemente un altro tavolo di confronto sulle politiche. I membri del Consiglio stanno valutando proposte che potrebbero richiedere la validazione esterna dei modelli, premiare i whistleblower, stabilire responsabilità per danni prevedibili e imporre una rapida segnalazione degli incidenti. Tali misure trasformerebbero le ampie promesse sulla sicurezza in obblighi che aziende, validatori e soggetti che implementano i sistemi potrebbero dover documentare.

Il conflitto centrale contrappone la responsabilità alla governance volontaria. Le aziende di IA hanno pubblicato framework di sicurezza e accettato obblighi di test interni. I legislatori di New York City ora vogliono prove indipendenti, rimedi legali e testimonianze agli atti. L'audizione metterà alla prova la capacità dei principali laboratori di difendere i propri controlli del rischio quando le domande provengono da funzionari eletti anziché dai loro stessi valutatori.

L'audizione del Consiglio di New York su OpenAI ha un obiettivo più ampio

L'audizione sposta la sicurezza dell'IA dai documenti di policy aziendale a testimonianze pubbliche sotto giuramento.

Il Consiglio di New York City ha fissato l'audizione del Committee of the Whole alle 11:00 del 5 ottobre presso il City Hall. Un Committee of the Whole riunisce l'intero Consiglio, anziché assegnare la questione a una singola commissione permanente.

Il Consiglio descrive la sessione come un esame dei rischi posti dall'intelligenza artificiale. Il suo ordine del giorno dell'audizione elenca un punto di vigilanza e nove proposte legislative. Le proposte riguardano validazione dei modelli, whistleblower, privacy dei chatbot, segnalazione degli incidenti, responsabilità, pianificazione delle emergenze e dichiarazioni pubblicitarie.

Meta si è impegnata a inviare un rappresentante senior prima che il Consiglio minacciasse procedure coercitive. OpenAI e Google hanno accettato di partecipare dopo l'avvertimento relativo ai mandati di comparizione. Anthropic ha inizialmente rifiutato, poi ha confermato la propria presenza poco prima della scadenza minacciata.

Il Consiglio afferma che questa sarà la prima testimonianza pubblica sotto giuramento delle quattro aziende sui pericoli dell'IA e sulle possibili risposte legislative. Questa descrizione è importante. Proviene dal Consiglio, e l'audizione non ha ancora stabilito cosa ciascuna azienda ammetterà, contesterà o metterà agli atti.

Non si prevede che le aziende invitate mandino i propri amministratori delegati. Bloomberg ha riferito che funzionari responsabili delle politiche e della sicurezza rappresenteranno i laboratori. La loro identità, autorità e disponibilità a rispondere a domande tecniche determineranno il valore dell'audizione.

Anche SpaceXAI è diventata parte della controversia dopo non aver risposto all'invito iniziale del Consiglio. La presidente Julie Menin ha emesso un mandato di comparizione in virtù dell'autorità investigativa del Consiglio. Il Consiglio ha affermato di poter chiedere l'esecuzione presso la Corte Suprema dello Stato di New York se l'azienda non avesse rispettato l'ordine.

Un successivo rapporto locale ha affermato che SpaceXAI avrebbe dovuto partecipare. Questa potenziale aggiunta amplia l'elenco delle aziende coinvolte, ma non modifica il confronto principale. I legislatori vogliono sapere se gli sviluppatori di IA di frontiera possano dimostrare che le loro misure di sicurezza funzionano al di fuori di dimostrazioni controllate.

Coxon porta un tipo diverso di testimonianza. Secondo le notizie sulla sua uscita, in precedenza ha svolto ricerca sul pretraining presso OpenAI e Anthropic. Il pretraining è il processo su larga scala attraverso cui un modello apprende schemi da vasti dataset prima della successiva rifinitura.

Ha lasciato Anthropic a settembre e ha accusato i principali laboratori di assumere rischi inaccettabili. Secondo un resoconto sulla sua testimonianza, Coxon ha dichiarato che le persone che costruiscono sistemi avanzati ritenevano che l'IA potesse uccidere l'umanità prima della fine del decennio.

Si tratta di un'affermazione straordinaria, non di una previsione consolidata. Reuters ha inoltre dichiarato di non essere riuscita a verificare indipendentemente il resoconto di Bloomberg sulla prevista comparizione di Coxon. Il Consiglio ha citato separatamente le sue dimissioni nel spiegare perché aveva organizzato l'audizione più ampia.

Secondo quanto riferito, Coxon comparirà con l'ex ricercatore di Google DeepMind Alex Turner e Daniel Kokotajlo, ex ricercatore di OpenAI che guida l'AI Futures Project. La loro presenza potrebbe rendere la sessione più conflittuale di un'audizione composta soltanto da testimoni aziendali.

I rappresentanti delle aziende probabilmente descriveranno valutazioni, controlli sull'implementazione e procedure per gli incidenti. Ex insider possono contestare che tali misure di sicurezza affrontino i sistemi che i laboratori stanno correndo per costruire. I membri del Consiglio potranno quindi confrontare entrambe le versioni secondo le stesse regole pubbliche.

Questo confronto è il cambiamento immediato. I dibattiti sulla sicurezza dell'IA spesso separano le rassicurazioni aziendali dagli avvertimenti dei critici. New York City li sta riunendo nella stessa aula mentre valuta leggi che attribuiscono conseguenze a una validazione incompleta o a danni evitabili.

New York vuole prove prima dell'implementazione

La proposta più rilevante renderebbe la validazione indipendente una condizione per offrire o implementare modelli di IA coperti dalla normativa in città.

La proposta del Consiglio, elencata come T2026-2602 nell'ordine del giorno, vieterebbe di commercializzare, vendere o implementare un modello di IA a New York City senza la validazione di terzi. Richiederebbe inoltre una capacità tecnica che consenta a un operatore umano di spegnere il modello.

La validazione di terzi significa che un valutatore esterno esamina un sistema invece di basarsi soltanto sulla valutazione dello sviluppatore. La proposta identifica come aree rilevanti le prestazioni nei compiti, l'impatto disparato, la privacy e la sicurezza. Chiede inoltre ai validatori di verificare se la capacità di spegnimento umano funzioni.

I validatori dovrebbero rendere noti gli interessi collegati al modello. Dovrebbero inoltre comunicare se il sistema è stato validato o è pronto per l'implementazione. Il New York City Cyber Command definirebbe le norme di attuazione e i requisiti per i validatori.

Le sanzioni creerebbero incentivi per entrambe le parti del rapporto di valutazione. L'ordine del giorno indica che le sanzioni civili potrebbero raggiungere i $25.000, inclusa una sanzione fissa di $25.000 per ciascun caso di offerta o implementazione di un modello senza la validazione richiesta. Le validazioni falsificate potrebbero comportare lo stesso importo.

Le proposte di norme sull'IA vanno oltre la validazione. Una misura consentirebbe alle persone di presentare reclami al Department of Consumer and Worker Protection per violazioni relative all'IA coperte dalla normativa. L'agenzia dovrebbe generalmente indagare, salvo che un reclamo sia frivolo, falso o duplicativo.

Un denunciante potrebbe ricevere il 25 per cento dei proventi recuperati se la città perseguisse il caso utilizzando i fatti denunciati. Tale quota potrebbe salire al 50 per cento se i funzionari designassero il denunciante per notificare una violazione o avviare un'azione civile.

Questo meccanismo di incentivo cerca di risolvere un problema informativo. Gli esterni raramente sanno come sono state progettate le valutazioni interne, quali avvertimenti siano stati portati all'attenzione dei vertici o perché un'implementazione sia andata avanti. Dipendenti e collaboratori spesso hanno un accesso migliore, ma segnalare condotte scorrette può mettere a rischio le loro carriere.

Un altro disegno di legge chiarirebbe le protezioni per i whistleblower tra i dipendenti comunali e i contraenti coperti. Proteggerebbe le segnalazioni sullo sviluppo o l'uso dell'IA che i lavoratori ritengono ragionevolmente presentino un rischio sostanziale e specifico per la sicurezza pubblica.

Il pacchetto affronta anche gli incidenti legati ai contratti comunali. I contraenti e le agenzie cittadine dovrebbero notificare il Cyber Command entro 24 ore dalla scoperta di un incidente di sicurezza dell'IA soggetto a segnalazione. Il Cyber Command renderebbe poi pubblico l'evento segnalato entro ulteriori 24 ore.

Questo requisito è più ristretto di un obbligo generale di segnalazione per ogni fallimento di un modello. Si concentra sui contratti comunali coperti. Tuttavia, creerebbe un registro visibile che ricercatori, giornalisti, fornitori e residenti potrebbero confrontare nel tempo.

Un diritto privato di azione affronterebbe un'altra lacuna nell'applicazione delle norme. Ai sensi del T2026-2600, una persona potrebbe citare in giudizio un'azienda il cui modello disponibile in commercio abbia causato danni attraverso un uso doloso o improprio da parte di terzi. La domanda richiederebbe un danno prevedibile e misure di sicurezza inadeguate collegate a tale uso improprio.

La prevedibilità sarà contestata. Gli sviluppatori non possono impedire ogni prompt doloso o modifica successiva. Tuttavia, le aziende non possono nemmeno trattare un abuso prevedibile come imprevedibile semplicemente perché un'altra persona ha fornito l'istruzione finale.

La proposta colloca tale questione in tribunale anziché lasciarla esclusivamente ai team aziendali responsabili delle policy. Ciò crea pressione affinché siano conservati risultati delle valutazioni, previsioni sugli abusi, avvertimenti interni e decisioni di implementazione.

Altre misure regolerebbero le pratiche sui dati dei chatbot e la pubblicità relativa alla sicurezza. I fornitori di chatbot sarebbero soggetti a requisiti di privacy, sicurezza, trasparenza e accesso per gli utenti. I fornitori non potrebbero far intendere che un chatbot offra consulenza equivalente a quella di un professionista abilitato.

La pubblicità di un modello di IA dovrebbe indicare se è stato validato da terzi. Dichiarazioni sulla sicurezza materialmente false o fuorvianti potrebbero comportare sanzioni fino a $25.000.

Queste disposizioni trasformano il linguaggio sulla sicurezza in qualcosa di più vicino a una dichiarazione sulle caratteristiche del prodotto. Se uno sviluppatore pubblicizza un modello come sicuro, la città vuole che tale affermazione sia collegata a un processo di valutazione identificabile.

L'intero pacchetto resta legislazione proposta. L'audizione del 5 ottobre non è un voto finale e i disegni di legge potrebbero cambiare sostanzialmente. L'azione del Consiglio sarebbe inoltre seguita da questioni di attuazione, ricorsi legali, norme delle agenzie o decisioni del sindaco.

Questa incertezza non dovrebbe oscurare la direzione intrapresa. New York City si sta muovendo da una supervisione algoritmica circoscritta verso un esame più ampio dei modelli di IA di uso generale e delle aziende che li forniscono.

La sicurezza volontaria dell'IA incontra prove applicabili

La controversia centrale non riguarda se le aziende testino i loro modelli, ma chi definisce test adeguati e chi può verificarne il risultato.

OpenAI, Anthropic, Google e Meta conducono tutte valutazioni dei modelli. Pubblicano combinazioni diverse di system card, rapporti sulla sicurezza, politiche di responsible scaling, articoli di ricerca e restrizioni di implementazione.

Questi documenti forniscono prove utili. Lasciano però alle aziende un ampio controllo sulla progettazione dei test, sulla soglia di divulgazione, sulle tempistiche e sulla risposta a un risultato preoccupante.

La proposta di New York trasferirebbe parte di questa autorità a validatori indipendenti e funzionari cittadini. Questo cambiamento spiega perché l'audizione sia importante oltre New York. Mette in discussione un modello di governance costruito in larga misura su impegni volontari e trasparenza selettiva.

I test condotti dalle aziende possono procedere rapidamente e utilizzare accessi interni di cui un valutatore esterno non dispone. Gli sviluppatori di modelli comprendono i propri sistemi, infrastrutture e piani di implementazione meglio della maggior parte dei regolatori. Possono inoltre eseguire test durante lo sviluppo, prima che un rilascio pubblico crei pressione per difendere il risultato.

La revisione esterna offre un vantaggio diverso. Può mettere in discussione assunzioni divenute normali all'interno di un'azienda. Può confrontare le prove tra fornitori e chiedere se un'affermazione sulla sicurezza utilizzi standard coerenti.

Nessuno dei due approcci garantisce una supervisione affidabile. Un validatore indipendente potrebbe non avere accesso al modello, competenze tecniche o tempo sufficiente. Un test di conformità progettato male può premiare la burocrazia anziché una riduzione significativa del rischio.

Il requisito della proposta relativo ai conflitti di interesse riconosce una debolezza evidente. Un validatore pagato da uno sviluppatore potrebbe subire pressioni per approvare il sistema del cliente. La divulgazione aiuta, ma da sola non elimina la dipendenza finanziaria.

Il requisito dell’“interruttore di spegnimento” solleva un’altra questione difficile. La capacità di arresto umano sembra semplice, ma i prodotti di IA sono distribuiti tra servizi cloud, applicazioni, agenti e infrastrutture dei clienti.

Un fornitore centrale può disabilitare l’accesso al proprio modello ospitato. Non può necessariamente fermare ogni output copiato, artefatto esportato, integrazione locale o azione a valle già attivata da un utente.

La normativa avrà bisogno di una definizione precisa del sistema da spegnere. Dovrà inoltre distinguere un servizio disabilitato da un incidente contenuto. In caso contrario, gli sviluppatori potrebbero soddisfare un controllo formale senza affrontare i percorsi attraverso cui si verifica il danno.

Anche le prestazioni nei compiti dipendono dal contesto. Un modello che funziona bene in un benchmark potrebbe fallire in un ospedale, in un processo di selezione del personale, in un servizio legale o in un agente software autonomo. La validazione deve collegare le capacità generali del modello alla sua distribuzione prevista.

New York ha già incontrato questo problema attraverso la supervisione delle assunzioni automatizzate. La Local Law 144 limita l’uso, da parte di datori di lavoro e agenzie per il lavoro, degli strumenti automatizzati coperti per le decisioni occupazionali senza un recente audit sui pregiudizi e le comunicazioni richieste.

La città ha iniziato ad applicare tale regime nel luglio 2023. Le sue norme sugli audit delle assunzioni hanno creato un precedente importante, ma le proposte attuali sono più ampie.

La Local Law 144 si concentra su un uso occupazionale definito. T2026-2602, secondo il riepilogo del Consiglio, si applica ai modelli di IA commercializzati, venduti o distribuiti nella città. Questa formulazione solleva questioni molto più ampie in materia di ambito, giurisdizione e fattibilità tecnica.

Uno strumento ristretto ha utenti, decisioni e output identificabili. Un modello per finalità generali può supportare la programmazione, l’analisi di documenti, il servizio clienti, la ricerca, il lavoro creativo e azioni autonome. Il rischio cambia con ogni integrazione.

L’audizione dovrebbe quindi incalzare i testimoni su prove specifiche. A quale accesso al modello avrebbe diritto un validatore? Quali valutazioni devono avvenire prima della distribuzione? Con quale frequenza la validazione deve essere rinnovata dopo un aggiornamento del modello?

I membri del Consiglio dovrebbero anche chiedere chi sia responsabile quando uno sviluppatore fornisce il modello ma un’altra azienda costruisce l’applicazione. Una norma ampia potrebbe riguardare i fornitori di modelli, i distributori, gli implementatori o tutti e tre.

È qui che responsabilità e innovazione diventano un vero compromesso. Standard deboli lascerebbero passare affermazioni inaffidabili. Standard vaghi o eccessivamente ampi potrebbero scoraggiare distribuzioni utili senza produrre maggiore sicurezza.

I principali laboratori hanno un incentivo a sostenere regole tecnicamente informate e coerenti a livello nazionale. I legislatori cittadini hanno un incentivo ad agire quando gli standard federali appaiono inadeguati. L’audizione inserisce queste priorità concorrenti nello stesso verbale pubblico.

Le segnalazioni dei whistleblower richiedono più dei titoli di giornale

L’avvertimento di Coxon alza la posta politica, ma i legislatori hanno comunque bisogno di prove verificabili su sistemi, decisioni e fallimenti specifici.

Le affermazioni sui rischi esistenziali attirano attenzione perché il danno presunto è enorme. Possono però anche oscurare questioni più immediate relative a privacy, discriminazione, frodi, cybersicurezza e automazione non sicura.

Il pacchetto del Consiglio cerca di affrontare entrambi i livelli. La pianificazione delle emergenze e i requisiti di spegnimento dei modelli rispondono a fallimenti gravi. Privacy dei chatbot, informative pubblicitarie, regole contrattuali e rimedi privati affrontano danni che i residenti potrebbero incontrare prima.

La testimonianza di Coxon sarà più utile se passerà dalle affermazioni sulla probabilità ai dettagli operativi. I legislatori devono capire quali capacità lo preoccupano, quali prove hanno cambiato il suo giudizio e quali salvaguardie ritiene assenti nei laboratori attuali.

Dovrebbero anche distinguere le stime personali del rischio dalle conclusioni documentate delle aziende. L’avvertimento di un ex dipendente può rivelare un serio disaccordo. Non stabilisce in modo indipendente che si verificherà un esito catastrofico.

Lo stesso standard si applica alle testimonianze delle aziende. Le dichiarazioni sulla cultura della sicurezza non dimostrano che un modello abbia superato test avversariali significativi. Un quadro di scaling responsabile non dimostra che i dipendenti possano fermare un rilascio quando aumenta la pressione commerciale.

Il Consiglio dovrebbe chiedere a ogni azienda come un grave avvertimento interno attraversi l’organizzazione. Chi può ritardare la distribuzione? Quale dirigente può ribaltare quella decisione? Quale documentazione rimane dopo il disaccordo?

Le protezioni per i whistleblower sono importanti perché i canali formali di segnalazione possono fallire. I dipendenti potrebbero temere ritorsioni, la perdita di lavori futuri o conflitti legali sulle informazioni riservate. Tuttavia, i programmi di incentivi possono anche attirare segnalazioni deboli, duplicate o strategiche.

Il sistema di reclami proposto cerca di filtrare le segnalazioni frivole, falsificate e ripetute. Il suo successo dipenderà dalle competenze dell’agenzia e dalla capacità investigativa. I funzionari devono distinguere un giudizio tecnico impopolare da una violazione legale.

La ricompensa finanziaria merita una progettazione attenta. Una percentuale delle sanzioni recuperate può incoraggiare gli insider a segnalare informazioni che altrimenti i regolatori non vedrebbero. Può anche creare dispute su chi abbia fornito per primo i fatti decisivi.

Il Consiglio deve definire informazioni ammissibili, divulgazioni protette, regole di riservatezza e procedure per la gestione di prove sensibili sotto il profilo della sicurezza. La divulgazione pubblica non può diventare una via per far trapelare dati personali, pesi dei modelli o vulnerabilità sfruttabili.

Anche le aziende hanno il diritto di contestare accuse inesatte. Il giusto processo è importante quando un reclamo può attivare indagini, sanzioni, contenziosi o danni alla reputazione pubblica.

Questo non giustifica la segretezza. Significa che la città ha bisogno di un processo che protegga sia i whistleblower credibili sia l’integrità delle prove.

La domanda scettica è se un’amministrazione municipale possa gestire tale processo nell’intero settore dell’IA di frontiera. New York City dispone di esperienza normativa, agenzie tecniche, autorità di appalto e un grande mercato. Non controlla però la politica nazionale di ricerca, le esportazioni di chip o ogni distribuzione fuori dai suoi confini.

Un’ampia regolamentazione dei modelli potrebbe anche affrontare dispute giurisdizionali. Un modello cloud potrebbe essere addestrato altrove, ospitato in un altro stato, accessibile tramite un intermediario e usato da un residente di New York. Ogni collegamento crea una diversa teoria dell’autorità locale.

Queste difficoltà non rendono simbolica l’audizione. Le città acquistano tecnologia, regolano le imprese, proteggono i consumatori e fissano condizioni per le attività locali. Le dimensioni di New York consentono alle sue regole di influenzare le pratiche dei fornitori oltre i confini cittadini.

Tuttavia, l’influenza non equivale all’applicabilità. Il Consiglio deve mostrare come le agenzie rileverebbero un modello non validato, identificherebbero il soggetto responsabile e distinguerebbero un aggiornamento del modello da una nuova distribuzione.

Le aziende dovrebbero spiegare quali prove possono fornire senza esporre dettagli di sicurezza o segreti commerciali. I legislatori dovrebbero spiegare come i validatori esterni riceveranno accesso sufficiente per testare affermazioni importanti.

Se entrambe le parti resteranno al livello della catastrofe contro l’innovazione, l’audizione produrrà clip memorabili e poca chiarezza operativa. Se discuteranno di accesso agli audit, definizioni degli incidenti, autorità e prove, la sessione potrà migliorare le proposte di legge.

Questa distinzione conta anche per gli acquirenti aziendali. I team di procurement affrontano sempre più spesso affermazioni sulla sicurezza, affidabilità e conformità dei modelli. Un quadro di validazione credibile potrebbe ridurre le lacune informative.

Un quadro debole aggiungerebbe un altro certificato senza aiutare gli acquirenti a valutare il rischio. I dettagli relativi ad accesso, copertura dei test, indipendenza e valutazioni ripetute determinano quale risultato otterrà New York.

La pressione si estende oltre quattro aziende di IA

Le regole proposte riguarderebbero non solo gli sviluppatori di modelli, ma anche validatori, contraenti, implementatori, inserzionisti e organizzazioni che acquistano servizi di IA.

OpenAI, Anthropic, Google e Meta ricevono l’attenzione perché sviluppano modelli di rilievo. La normativa descritta nell’ordine del giorno raggiunge una catena più ampia di organizzazioni.

Un’azienda che offre un modello di IA a New York potrebbe aver bisogno di una prova della validazione. Un’impresa che distribuisce il modello potrebbe affrontare obblighi separati. Un validatore potrebbe diventare responsabile per una certificazione falsa.

I contraenti della città avrebbero bisogno di procedure per il rilevamento degli incidenti e di segnalazioni rapide. Le agenzie avrebbero bisogno di processi per inoltrare gli incidenti a Cyber Command. La città dovrebbe quindi pubblicare le informazioni con rapidità sufficiente a rispettare la tempistica proposta.

I fornitori di chatbot rivolti ai consumatori dovrebbero riesaminare le pratiche relative ad accesso ai dati, privacy, sicurezza e trasparenza. I team di marketing avrebbero bisogno di prove a sostegno delle affermazioni sulla sicurezza. I team legali dovrebbero valutare gli usi impropri prevedibili.

Questa distribuzione delle responsabilità è importante perché il rischio dell’IA raramente ricade su una sola organizzazione. Uno sviluppatore di modelli crea la capacità sottostante. Un’azienda di applicazioni definisce i flussi di lavoro. Un cliente fornisce dati e concede l’accesso ai sistemi.

Un agente autonomo aggiunge un ulteriore livello. Un agente è un software che utilizza un modello per pianificare e intraprendere azioni, spesso tramite strumenti esterni. Il suo comportamento dipende dal modello, dalle autorizzazioni disponibili, dalle istruzioni e dall’applicazione circostante.

Un modello può sembrare controllato in un’interfaccia di chat, ma diventare pericoloso quando è collegato a e-mail, database, sistemi di pagamento o repository software. La validazione deve quindi esaminare l’ambiente di distribuzione, non solo il modello di base.

La proposta del Consiglio sulla segnalazione degli incidenti riconosce questa realtà operativa per i contratti della città. Un evento soggetto a segnalazione potrebbe iniziare con un output del modello, ma diventare dannoso attraverso autorizzazioni di sistema o un monitoraggio debole.

Le organizzazioni che usano l’IA non dovrebbero aspettare la legislazione definitiva per esaminare questi percorsi. Possono identificare quali modelli accedono a dati sensibili, quali strumenti possono intraprendere azioni esterne e chi può revocare le autorizzazioni.

La documentazione è centrale in questo lavoro. I team hanno bisogno di registri delle versioni dei modelli, dei risultati delle valutazioni, delle decisioni sugli incidenti e delle modifiche alle salvaguardie. Senza tali registri, la responsabilità diventa un dibattito basato sulla memoria.

Anche i knowledge worker hanno un interesse diretto. Gli assistenti IA interagiscono sempre più con documenti interni, appunti delle riunioni, codice, ricerca e informazioni sui clienti. Gli utenti devono sapere quali dati entrano in un sistema e quali controlli regolano il recupero o la conservazione.

Una base di conoscenza IA ben mantenuta può aiutare i team a preservare il contesto e tracciare le decisioni. Non sostituisce la validazione dei modelli, i controlli di accesso o la risposta agli incidenti.

Per gli sviluppatori, l’audizione segnala che le affermazioni sulla sicurezza richiederanno sempre più artefatti. Dichiarare che un’applicazione ha delle protezioni non soddisferà un regolatore scettico. I team potrebbero aver bisogno di casi di test, registri delle valutazioni, registri di accesso e procedure di risposta.

Gli acquirenti aziendali dovrebbero osservare se le aziende accettano una base comune per i test indipendenti. Una base condivisa potrebbe semplificare il procurement. Standard divergenti potrebbero lasciare gli acquirenti a confrontare report incompatibili.

Le aziende affrontano inoltre pressioni strategiche diverse. OpenAI e Anthropic sottolineano lo sviluppo di modelli di frontiera e la ricerca sulla sicurezza. Google integra l’IA nella ricerca, nel cloud, nella produttività e nei servizi per i consumatori.

Meta sviluppa modelli gestendo al contempo grandi piattaforme social e sistemi pubblicitari. Queste differenze di business incidono sulla scala di distribuzione, sui modelli di accesso e sulle prove che ciascuna azienda può fornire.

L'audizione non dovrebbe appiattire tali differenze in un'unica risposta valida per l'intero settore. Dovrebbe stabilire quali obblighi si applichino trasversalmente ai modelli di business e quali richiedano regole specifiche per il contesto.

La precedente legge di New York sulle assunzioni offre sia un precedente sia un avvertimento. Un obbligo locale di audit può creare un mercato per la revisione esterna. Può anche generare dibattiti su definizioni, ambito di applicazione e sulla capacità degli audit di misurare i danni che preoccupano le persone coinvolte.

Le nuove proposte affronteranno queste questioni su scala più ampia. I modelli di uso generale cambiano spesso e supportano utilizzi che gli sviluppatori non possono prevedere pienamente. La convalida deve restare significativa dopo gli aggiornamenti, senza rendere ogni modifica minore legalmente ingestibile.

Il Consiglio ha presentato il pacchetto come favorevole sia all'innovazione sia alla sicurezza. Questo equilibrio dipenderà da definizioni e attuazione, non dallo slogan.

Un ambito chiaro potrebbe premiare gli sviluppatori che già documentano i propri controlli. Un ambito ambiguo potrebbe favorire le grandi aziende, in grado di assorbire i costi di conformità, mentre i fornitori più piccoli si ritirano.

Questa possibilità merita attenzione durante l'audizione. La responsabilità non dovrebbe trasformarsi in una barriera che solo le aziende più grandi possono permettersi. Né le preoccupazioni per la concentrazione del mercato dovrebbero diventare una scusa per test poco rigorosi.

Tre segnali mostreranno se l'audizione conta

L'importanza dell'audizione sarà misurata dalle prove che produrrà, dalle modifiche apportate ai disegni di legge e dagli standard che New York potrà effettivamente applicare.

Il primo segnale è la testimonianza stessa. Osservate se i rappresentanti delle aziende rispondono con metodi di valutazione concreti, procedure di escalation e soglie di distribuzione.

Le dichiarazioni generiche sull'AI responsabile riveleranno poco. Descrizioni specifiche di accesso indipendente, risultati dei red team, gestione degli incidenti e autorità di rilascio creerebbero un quadro che gli osservatori esterni possono valutare.

Coxon e altri ex ricercatori sono sottoposti allo stesso standard. Le loro testimonianze diventano più solide se identificano meccanismi, fallimenti di governance o decisioni che i legislatori possono esaminare. Le sole previsioni catastrofiche non diranno alla città come regolamentare.

Il secondo segnale è il processo di revisione legislativa. Il piano di testimonianza delle aziende afferma che il Consiglio desidera il contributo del settore sulle soluzioni proposte. Emendamenti sostanziali dimostrerebbero che l'audizione ha cambiato la comprensione dei legislatori.

Osservate la definizione di modello di AI, l'ambito della convalida da parte di terzi e il significato di distribuzione. Questi termini determinano se le norme riguardano un ristretto gruppo di sistemi o quasi tutti i servizi abilitati dall'AI.

Osservate anche la proposta relativa alla capacità di spegnimento. Una disposizione praticabile dovrebbe specificare chi la controlla, cosa disabilita, come viene testata e quali distribuzioni la richiedono.

L'incentivo per i whistleblower richiederà regole dettagliate su ammissibilità e riservatezza. Il diritto di azione privata richiederà un criterio difendibile per prevedibilità e misure di salvaguardia ragionevoli.

Il terzo segnale è il percorso di attuazione. Cyber Command e il Department of Consumer and Worker Protection assumerebbero responsabilità rilevanti nell'ambito delle proposte.

Il loro organico, l'accesso tecnico, l'autorità regolamentare e le procedure di applicazione conteranno quanto il testo normativo. Un obbligo privo di capacità investigativa lascerebbe la città dipendente dalle dichiarazioni delle aziende.

L'agenda del Consiglio continua a elencare le nuove proposte come elementi preconsiderati. I verbali e le azioni legislative non erano disponibili prima dell'audizione programmata. I lettori dovrebbero quindi considerare il pacchetto come un punto di partenza, non come legge già promulgata.

L'audizione del Consiglio comunale di New York su OpenAI avrà successo solo se ridurrà il divario tra promesse di sicurezza e controlli verificabili. Ciò significa chiedere quali prove esistano, chi possa ispezionarle e cosa accada quando un avvertimento viene ignorato.

Sviluppatori, acquirenti aziendali e utenti di AI dovrebbero seguire la testimonianza tenendo presenti queste domande. I testimoni divulgano misure di salvaguardia verificabili? I legislatori trasformano un linguaggio ampio in obblighi attuabili? Le agenzie ricevono l'autorità e le competenze necessarie per farli rispettare?

Le risposte mostreranno se New York stia costruendo un modello credibile di responsabilità o un altro livello di burocrazia per la conformità. Seguite il verbale dell'audizione, quindi confrontate ogni rassicurazione pubblica con le prove offerte sotto giuramento.