SB1047 era una cattiva idea. Ma l'ultimo SB53 del Sen. Wiener è sulla strada giusta, ed è importante riconoscere i progressi. Ecco il mio ragionamento. Il mio approccio alla regolamentazione di tecnologie nuove come i modelli è: non sappiamo come definire una mitigazione e una garanzia "buone", ma lo sapremo quando—e se—lo vedremo. Ci sono due implicazioni. #1. Non dovremmo prescrivere soglie di rischio o standard di cura per lo sviluppo dei modelli. Non possiamo concordare sui rischi che contano, su come misurarli o su quanto sia troppo. L'unica guida per sviluppatori, regolatori e tribunali è un insieme di pratiche nascenti determinate principalmente da aziende a codice chiuso che si affidano a paywall per fare il lavoro pesante. Farlo potrebbe frenare l'innovazione aperta esponendo gli sviluppatori a responsabilità vaghe o elevate per il rilascio diffuso. Questo era SB1047 in poche parole, insieme a ~5 equivalenti che ha ispirato in tutto il paese in questa sessione, come il RAISE Act a NY. Dovremmo evitare questo approccio. Queste proposte sono—in aspetti ristretti ma cruciali—troppo oltre le loro possibilità. Eppure: #2. Dobbiamo far luce sulle pratiche del settore per comprendere meglio la diligenza, o la mancanza di essa, applicata da diverse aziende. Se gli sviluppatori devono impegnarsi a una politica di sicurezza e protezione, mostrare il loro operato e lasciare una traccia cartacea, possiamo valutare meglio la solidità delle loro affermazioni, monitorare i rischi emergenti e decidere su future interventi. Questo è l'AI Act dell'UE e il Codice di Pratica finale in poche parole, che sia OpenAI che Mistral hanno sostenuto, ed è anche l'ultima versione del SB53 di @Scott_Wiener. Se dobbiamo regolare lo sviluppo dei modelli, questo è fondamentalmente l'approccio migliore: regolare la trasparenza—non le capacità, le mitigazioni o il rischio accettabile. Darebbe almeno a una giurisdizione statunitense l'autorità di supervisione di Bruxelles, e eviterebbe effetti indesiderati sullo sviluppo aperto. Per essere chiari, ci sono ancora iceberg davanti: > Complessità. Che si tratti di Big Tech o meno, questi sono obblighi di documentazione e reporting gravosi. Parlando tatticamente, più è complesso, più vulnerabile diventerà questo progetto di legge. > Incentivi. La segnalazione pubblica obbligatoria delle valutazioni di rischio volontarie crea un incentivo perverso per gli sviluppatori a testare meno i loro modelli e a chiudere un occhio sui rischi difficili. Permettere agli sviluppatori di divulgare i loro risultati a revisori o agenzie piuttosto che pubblicamente potrebbe aiutare a promuovere una maggiore franchezza nelle loro valutazioni interne. > Cavallo di Troia. La cultura iperattiva di modifica e emendamento della California può rendere difficile esaminare questi progetti di legge. Se SB53 si trasforma in un progetto di legge sugli standard di cura come SB1047 o RAISE, dovrebbe essere respinto per le stesse ragioni di prima. Più decorazioni vengono aggiunte a questo albero di Natale, più il progetto di legge diventa controverso. > Ampiezza. Il progetto di legge lancia una rete ampia con definizioni espansive di rischio catastrofico e capacità pericolosa. Per un progetto di legge "di reporting obbligatorio / pratiche volontarie", funzionano. Se questo progetto di legge fosse un progetto di legge sugli standard di cura, sarebbero inattuabili. In sintesi: cappello a Sen. Wiener per aver coinvolto e risposto in modo ponderato ai feedback nell'ultimo anno. È rinfrescante vedere un progetto di legge che costruisce effettivamente su critiche precedenti. Ci sono ancora molti percorsi che questo progetto di legge potrebbe prendere—e si è evoluto ben oltre la proposta originale di whistleblowing—ma la traiettoria è promettente.