El 29 de setembre de 2025, el governador de Califòrnia, Gavin Newsom, va signar el projecte de llei del Senat 53, la Llei de Transparència en la Intel·ligència Artificial de Frontera (TFAIA), convertint Califòrnia en la primera jurisdicció dels EUA a imposar obligacions vinculants de seguretat, transparència i notificació d'incidències als desenvolupadors dels sistemes d'IA més intensius des del punt de vista computacional. La llei va entrar en vigor l'1 de gener de 2026 i, durant els darrers sis mesos, ha transformat silenciosament la manera com els laboratoris d'IA més grans i una llista creixent de desenvolupadors de models de nivell mitjà documenten el risc, publiquen marcs de governança i informen els reguladors sobre escenaris de risc catastròfic.
Si la vostra organització entrena, ajusta (fine-tunes) o modifica substancialment models de fundació —o opera grans clústers de computació dels quals depenen altres desenvolupadors—, la SB 53 és ara la llei d'IA més transcendent que heu d'entendre als Estats Units. Aquesta guia recorre qui està cobert, què s'ha de publicar, com funciona el termini de 15 dies per a la notificació d'incidents crítics, quines obligacions s'apliquen als denunciants (whistleblowers) i com traduir l'estatut en un programa de compliment operatiu.
Què regula realment la SB 53
A diferència de les lleis d'IA en l'àmbit laboral que s'estan estenent estat per estat (com la Llei Local 144 de Nova York o la Llei d'IA de Colorado), la SB 53 no regula les eines de contractació algorítmica, els models de concessió de crèdit o els sistemes de selecció de llogaters. S'adreça a una categoria molt més estreta: models de fundació de frontera entrenats a escales computacionals extraordinàries i els escenaris de risc catastròfic que se'n poden derivar.
La llei se situa a la intersecció de dues tradicions reguladores. De la llei de seguretat dels productes, manlleva la idea que les empreses han de publicar avaluacions de risc i notificar a les autoritats quan es materialitzen els incidents. De la llei de regulació financera, manlleva la idea que els actors més grans tenen càrregues de divulgació més pesades que els més petits. El resultat és un règim esglaonat construït al voltant de dos llindars.
El llindar de computació de 10^26 FLOPs
Un "model de frontera" segons la SB 53 es defineix com un model de fundació entrenat utilitzant més de 10^26 operacions d'enters o de coma flotant, inclosa la computació acumulada de l'ajust precís i les modificacions posteriors. Aquest llindar està deliberadament alineat amb el disparador d'informes de l'ara rescindida Ordre Executiva federal 14110 i el nivell d'IA de propòsit general de la Llei d'IA de la UE, de manera que la majoria dels grans laboratoris dels EUA ja saben si el superen.
El que de vegades es passa per alt és que l'estatut compta la computació acumulada de les modificacions derivades. Si agafeu un model base que va ser entrenat a prop del llindar i continueu el preentrenament, feu un ajust precís d'aprenentatge per reforç o fusioneu els pesos amb un altre model, podeu empènyer un derivat a l'estat de frontera encara que cap execució d'entrenament individual hagi superat els 10^26 FLOPs. Catalogar cada model base, cada ajust precís, cada destil·lació i cada fusió de pesos —i fer el seguiment dels FLOPs que ha consumit cada pas— és ara una disciplina de comptabilitat essencial.
El llindar d'ingressos de 500 milions de dòlars per a grans desenvolupadors de frontera
Un "gran desenvolupador de frontera" és un desenvolupador de frontera l'entitat i els afiliats del qual han obtingut més de 500 milions de dòlars en ingressos bruts anuals l'any natural anterior. La prova d'ingressos és consolidada: se sumen les empreses matrius, les filials i els afiliats sota control comú. Una petita startup d'IA que hagi tancat una ronda de finançament de mil milions de dòlars però que hagi obtingut 40 milions de dòlars en ingressos reals no és un gran desenvolupador de frontera; un conglomerat tecnològic que cotitza en borsa amb una petita divisió d'IA que creua el llindar de FLOPs gairebé segur que ho és.
L'estratificació és important perquè els grans desenvolupadors de frontera tenen les obligacions més feixugues: publicar un marc d'IA de frontera, realitzar avaluacions de risc catastròfic, presentar resums de risc d'ús intern trimestrals a l'Oficina de Serveis d'Emergència de Califòrnia (Cal OES) i mantenir un canal intern anònim per a denunciants. Els desenvolupadors de frontera més petits —aquells que estan per sobre del llindar de FLOPs però per sota del llindar d'ingressos— encara han de publicar informes de transparència i informar sobre incidents de seguretat crítics, però no estan subjectes al règim complet del marc.
Què heu de publicar: El Marc d'IA de Frontera
Cada gran desenvolupador de frontera ha de publicar un marc d'IA de frontera al seu lloc web i mantenir-lo actualitzat. La revisió anual és obligatòria, i qualsevol modificació material ha de provocar una actualització en un termini de 30 dies des del canvi.
Un marc defensable aborda, com a mínim:
- Llindars de risc catastròfic i mètodes d'avaluació. Quines capacitats —assistència en armes químiques, biològiques, radiològiques o nuclears; atacs a infraestructures crítiques a gran escala; escenaris de pèrdua de control d'agents autònoms— consideraria el desenvolupador que creuen un llindar catastròfic? Com posarà a prova el desenvolupador aquestes capacitats abans del desplegament?
- Estratègies de mitigació de riscos. Mitigacions concretes abans del desplegament: entrenament de denegació, amortiment de capacitats, restriccions de desplegament, accés monitoritzat, llançaments esglaonats i monitoratge post-desplegament.
- Avaluacions de tercers. Quins equips vermells (red teams) externs, avaluadors i auditors avaluaran el model, i com s'incorporaran les seves conclusions?
- Protocols de ciberseguretat per als pesos del model no publicats. Controls contra amenaces internes, mòduls de seguretat de maquinari, segmentació de xarxa i registre d'accessos que protegeixen els pesos abans del desplegament contra el robatori.
- Procediments de resposta a incidents de seguretat crítics. Qui decideix si un incident és notificable, com s'inicia el termini de 15 dies i com es coordina l'empresa amb Cal OES.
- Mecanismes de governança interna. Supervisió a nivell de consell d'administració, el rol de l'oficial de seguretat de la IA, vies d'escalada i la cadència de les revisions de seguretat.
- Alineació amb estàndards. Mapatge explícit amb el Marc de Gestió de Riscos d'IA del NIST (AI RMF 1.0) i la norma ISO/IEC 42001, que l'estatut tracta com a bases fonamentals.
El marc no és un document de màrqueting. És un artefacte de cara al regulador que el Fiscal General pot utilitzar per avaluar si els compromisos públics de l'empresa coincideixen amb la seva pràctica interna. Redactar-lo amb el mateix rigor que una divulgació de factors de risc de la SEC o una descripció del sistema SOC 2 és la postura correcta.
Informes de transparència abans de cada desplegament
Tots els desenvolupadors de frontera — no només els grans — han de publicar un informe de transparència abans de desplegar un model de frontera nou o modificat substancialment. L'informe de transparència és un document específic del model, separat de l'entorn de treball, que ha d'incloure:
- Nom de l'empresa, lloc web i mecanisme de contacte per a problemes de seguretat
- La data de llançament del model i una llista dels idiomes i modalitats de sortida admesos
- Usos previstos i restriccions d'ús aplicables
- Per als grans desenvolupadors, un resum de les avaluacions de riscos catastròfics i els resultats, incloent-hi si i com hi van participar avaluadors externs
Una "modificació substancial" inclou millores de capacitats importants, addicions de noves modalitats i canvis significatius en la combinació de dades d'entrenament. Les versions de pegats i els ajustos fins de seguretat rutinaris generalment no requereixen un nou informe de transparència, però els casos dubtosos s'han de documentar amb una justificació escrita per si el Fiscal General pregunta més tard per què no es va publicar cap informe.
El termini de 15 dies per a la notificació d'incidents crítics
La càrrega de compliment que més ha sorprès els assessors jurídics interns és el termini de notificació d'incidents. Els desenvolupadors de frontera han de notificar a l'Oficina de Serveis d'Emergència de Califòrnia (Cal OES) qualsevol incident de seguretat crític en un termini de 15 dies des de la seva descoberta, amb un termini més estricte de 24 hores si l'incident representa una amenaça imminent per a la seguretat pública.
L'estatut defineix un incident de seguretat crític de manera àmplia:
- Accés no autoritzat o robatori de pesos del model no publicats
- Materialització d'un risc catastròfic
- Pèrdua del control del desenvolupador sobre un model desplegat
- Comportament del model enganyós o evasiu que derrota les salvaguardes
Construir un procés intern defensable significa respondre a tres preguntes abans que es produeixi cap incident:
- Qui decideix? Un únic directiu designat (sovint el cap de seguretat de la IA o un adjunt delegat) hauria de tenir l'autoritat per iniciar el rellotge de notificació, amb criteris d'escalada documentats.
- Què activa el termini? El detonant és la "descoberta". La documentació interna ha de registrar exactament quan es va descobrir un incident, per qui i mitjançant quin sistema de monitoratge, perquè la finestra de 15 dies es calcula a partir d'aquest moment.
- Com es transmet l'informe? La Cal OES manté un procés confidencial de recepció per a les presentacions dels desenvolupadors. L'equip de notificació ha d'assajar el flux de treball de tramesa — inclosa la transmissió xifrada de detalls tècnics sensibles — molt abans que es produeixi qualsevol incident real.
Per als grans desenvolupadors de frontera, l'obligació va més enllà de la notificació reactiva d'incidents. Cada tres mesos (o segons un altre calendari raonable), els grans desenvolupadors han de transmetre a la Cal OES un resum de qualsevol avaluació de riscos catastròfics derivada de l'ús intern dels seus models de frontera. Aquesta cadència trimestral és exclusiva de la SB 53 i és la primera vegada que un estatut dels EUA obliga els laboratoris d'IA a informar sobre les troballes de risc d'ús intern en curs a una agència de la branca executiva.
Proteccions per a denunciants i el canal intern anònim
La SB 53 afegeix al règim general de protecció de denunciants de Califòrnia un conjunt de proteccions específiques per a la IA que s'apliquen als "empleats coberts" — aquells les funcions dels quals inclouen avaluar, gestionar o abordar el risc de danys catastròfics dels models de frontera.
Els desenvolupadors de frontera no poden impedir que un empleat cobert reveli informació, ni prendre represàlies contra ell per fer-ho, a:
- El Fiscal General de Califòrnia
- Una autoritat reguladora federal
- Un supervisor directe o un altre supervisor amb autoritat per investigar
- Un altre empleat cobert les funcions del qual incloguin l'avaluació de riscos
Les revelacions protegides cobreixen tant (a) la creença raonable que les activitats del desenvolupador representen un perill específic i substancial per a la salut o la seguretat pública derivat d'un risc catastròfic, com (b) la creença raonable que el desenvolupador ha vulnerat la mateixa SB 53.
Els grans desenvolupadors de frontera també han de mantenir un canal de denúncia interna anònim. L'estatut exigeix:
- Un flux de treball que permeti als empleats coberts presentar revelacions anònimes sobre preocupacions de riscos catastròfics
- Actualitzacions mensuals de l'estat de la investigació a l'empleat denunciant
- Informes trimestrals als directius i administradors que resumeixin les revelacions i els resultats, excloent de l'audiència de l'informe les persones nominatives acusades d'actes il·lícits
Els tribunals poden adjudicar honoraris d'advocat als demandants que guanyin accions per represàlies. De manera crítica, l'estatut inverteix la càrrega de la prova: quan un empleat cobert demostra que una activitat protegida va ser un factor contribuent a una acció adversa, el desenvolupador té la càrrega de provar que l'acció s'hauria produït per motius legítims independents.
La definició de risc catastròfic
El centre de gravetat de la SB 53 és la seva definició de "risc catastròfic". L'estatut el defineix com un risc previsible i material que un model de frontera contribueixi materialment a la mort o a lesions greus de més de 50 persones, o a més d'1.000 milions de dòlars en danys o pèrdua de propietat, a través d'un dels tres mecanismes causals:
- Assistència en armament. Contribució material a la creació, desplegament o ús d'una arma química, biològica, radiològica o nuclear, o a una ciberarma que causi un dany comparable.
- Conducta nociva incontrolada. Conducta del model amb una supervisió humana limitada que, si fos comesa per un humà, constituiria un delicte greu que requereix intencionalitat.
- Pèrdua de control. Pèrdua del control del desenvolupador sobre el model de manera que aquest realitzi una conducta materialment nociva.
La definició estableix exclusions importants. Els riscos basats en informació que ja és pública, els danys derivats d'una activitat federal lícita i els danys on la contribució del model no sigui material queden fora de l'abast. Aquesta exclusió és el que evita que els riscos de les aplicacions quotidianes — biaix en el cribratge de currículums, consells mèdics al·lucinats, infracció dels drets d'autor — activin el règim de riscos catastròfics. Aquests danys són reals, però s'aborden mitjançant altres lleis, no per la SB 53.
Sancions civils i aplicació
El Fiscal General de Califòrnia té l'autoritat d'aplicació exclusiva. Les sancions civils poden arribar a 1 milió de dòlars per infracció, escalades segons la gravetat de la conducta. No existeix un dret d'acció privat sota la pròpia SB 53, tot i que les disposicions sobre represàlies contra informants (whistleblowers) són exigibles de manera independent mitjançant accions civils presentades pels empleats perjudicats.
A la pràctica, el risc d'aplicació es concentra en tres àrees:
- Jocs amb els llindars. Les empreses que estructuren les execucions d'entrenament per mantenir-se just per sota dels 10^26 FLOPs mentre ofereixen capacitats clarament de classe frontier s'enfrontaran a l'escrutini. El llenguatge de còmput acumulat de l'estatut fa que aquesta estratègia sigui fràgil.
- Escletxes en el marc de treball. Un marc de treball que llisti polítiques sense evidència d'implementació serà més fàcil d'atacar que un que vinculi cada compromís a artefactes operatius, responsables nominats i registres d'auditoria.
- Retards en la notificació d'incidents. No complir amb el termini de 15 dies, o el termini de 24 hores per a amenaces imminents, és el tipus d'infracció neta i documentable que els reguladors històricament persegueixen amb agressivitat.
Creació d'un pla d'implementació de 90 dies
Per a una organització que encara no ha posat en marxa un programa per a la SB 53, la següent seqüència funciona bé:
Dies 1 al 30: Anàlisi d'abast i de mancances.
- Catalogar cada model fundacional entrenat, ajustat (fine-tuned), fusionat o modificat substancialment, amb el còmput acumulat estimat per a cadascun.
- Determinar si els ingressos consolidats (incloent-hi totes les filials) van superar els 500 milions de dòlars en l'any natural anterior.
- Formar un Grup de Treball de Compliment i Seguretat de la IA transversal amb membres d'enginyeria, seguretat, legal, comunicació i RRHH.
- Mapejar les pràctiques actuals amb el NIST AI RMF 1.0 i l'ISO/IEC 42001 per identificar mancances.
Dies 31 al 60: Redacció i governança.
- Redactar el marc de treball d'IA de frontera com un document amb versions i publicable públicament.
- Construir la metodologia d'avaluació de riscos catastròfics, incloent-hi avaluacions de capacitats, modelatge d'amenaces i els criteris per declarar un model amb capacitats frontier en un domini perillós.
- Implementar els controls de ciberseguretat per als pesos no publicats, amb registres d'accés documentats i monitoratge d'amenaces internes.
- Establir el canal de denúncia intern anònim i el flux de treball per a les actualitzacions d'estat mensuals i les sessions informatives trimestrals del consell.
Dies 61 al 90: Preparació operativa.
- Realitzar un exercici teòric de resposta a incidents que simuli el descobriment d'un incident de robatori de pesos i una materialització de risc catastròfic, i després practicar els fluxos de notificació de 15 dies i 24 hores.
- Formar els empleats coberts sobre els drets dels informants i el canal anònim.
- Publicar l'informe de transparència per a qualsevol model en la línia de desplegament, amb una referència creuada al marc de treball d'IA de frontera.
- Calendaritzar les entregues trimestrals del resum de riscos catastròfics a la Cal OES i la revisió anual del marc de treball.
Coordinació amb altres règims de privadesa i IA
La SB 53 no actua sola. Els equips de compliment haurien de comparar-la amb:
- El Marc de Gestió de Riscos d'IA del NIST, al qual l'estatut fa referència explícita i que proporciona gran part de l'estructura de governança substantiva.
- El nivell d'IA d'ús general de la Llei d'IA de la UE, on la superposició de documentació és substancial i un únic marc intern harmonitzat pot satisfer ambdues.
- La Llei d'IA de Colorado i la Llei de Governança Responsable de la IA de Texas, que regulen les obligacions dels desplegadors per a la presa de decisions d'IA d'alt risc i que poden aplicar-se als vostres clients posteriors.
- La Llei de Privadesa del Consumidor de Califòrnia i les properes regles de l'Agència de Protecció de la Privadesa de Califòrnia sobre tecnologia de presa de decisions automatitzada, que s'entrecreuen amb el desplegament de models però funcionen independentment de la SB 53.
- Els compromisos voluntaris de l'Institut de Seguretat de la IA federal i qualsevol legislació federal de preempció futura, que podria canviar la base de compliment.
Els registres de compliment precisos i les traces d'auditoria clares són essencials en tots aquests règims, i la mateixa disciplina de documentació que dóna suport a la presentació d'informes financers dóna suport a la presentació d'informes de governança d'IA. Els marcs de treball d'IA de frontera, les avaluacions de riscos catastròfics, els registres d'incidents i els registres d'investigació d'informants s'han de conservar durant almenys cinc anys i emmagatzemar-se d'una manera que sobrevisqui a la rotació de directius i a la reestructuració corporativa.
Mantingueu els vostres registres financers i de compliment preparats per a auditories
Tant si esteu publicant un marc de treball d'IA de frontera, calendaritzant les entregues trimestrals a la Cal OES o preparant-vos per a una consulta del Fiscal General, la disciplina subjacent és la mateixa: registres clars, controlats per versions i auditables. El mateix enfocament de text pla i control de versions que els equips natius d'IA utilitzen per a les seves bases de codi funciona de meravella per als seus llibres de comptes. Beancount.io ofereix comptabilitat en text pla que us proporciona total transparència i control sobre les vostres dades financeres: sense caixes negres, sense dependència d'un proveïdor i una traça d'auditoria neta que combina naturalment amb la disciplina de governança que els reguladors esperen actualment. Comenceu gratis i descobriu per què els desenvolupadors i els professionals de les finances s'estan passant a la comptabilitat en text pla.