Cumplimiento de la SB 53 de California: Una guía práctica sobre la Ley de Transparencia en la IA de Frontera

El 29 de septiembre de 2025, el gobernador de California, Gavin Newsom, firmó el Proyecto de Ley del Senado 53, la Ley de Transparencia en la Inteligencia Artificial de Frontera (TFAIA, por sus siglas en inglés), convirtiendo a California en la primera jurisdicción de EE. UU. en imponer obligaciones vinculantes de seguridad, transparencia y reporte de incidentes a los desarrolladores de los sistemas de IA con mayor intensidad computacional. La ley entró en vigor el 1 de enero de 2026 y, en los últimos seis meses, ha remodelado silenciosamente la forma en que los laboratorios de IA más grandes y una lista creciente de desarrolladores de modelos de nivel medio documentan los riesgos, publican marcos de gobernanza e informan a los reguladores sobre escenarios de riesgo catastrófico.

Si su organización entrena, ajusta (fine-tuning) o modifica sustancialmente modelos fundacionales —o si opera grandes clústeres de cómputo en los que confían otros desarrolladores—, la SB 53 es ahora la ley de IA más trascendental que debe comprender en los Estados Unidos. Esta guía detalla quiénes están cubiertos, qué deben publicar, cómo funciona el plazo de 15 días para el reporte de incidentes críticos, qué obligaciones de denuncia de irregularidades (whistleblower) se aplican y cómo traducir el estatuto en un programa de cumplimiento operativo.

Qué regula realmente la SB 53

A diferencia de las leyes de IA aplicadas al empleo que se están extendiendo estado por estado (como la Ley Local 144 de Nueva York o la Ley de IA de Colorado), la SB 53 no regula las herramientas de contratación algorítmica, los modelos de suscripción de crédito o los sistemas de selección de inquilinos. Se dirige a una categoría mucho más estrecha: los modelos fundacionales de frontera entrenados a escalas computacionales extraordinarias y los escenarios de riesgo catastrófico que pueden derivarse de ellos.

La ley se sitúa en la intersección de dos tradiciones regulatorias. Del derecho de seguridad de productos, toma prestada la idea de que las empresas deben publicar evaluaciones de riesgo y notificar a las autoridades cuando se materializan los incidentes. Del derecho regulatorio financiero, toma la idea de que los actores más grandes soportan cargas de divulgación más pesadas que los más pequeños. El resultado es un régimen estratificado construido en torno a dos umbrales.

El umbral de cómputo de 10^26 FLOPs

Un "modelo de frontera" bajo la SB 53 se define como un modelo fundacional entrenado utilizando más de 10^26 operaciones de números enteros o de punto flotante, incluyendo el cómputo acumulado de ajustes finos y modificaciones posteriores. Este umbral está deliberadamente alineado con el disparador de reporte de la ahora rescindida Orden Ejecutiva federal 14110 y el nivel de IA de propósito general de la Ley de IA de la UE, por lo que la mayoría de los grandes laboratorios de EE. UU. ya saben si lo superan.

Lo que a veces se pasa por alto es que el estatuto cuenta el cómputo acumulado de las modificaciones derivadas. Si se toma un modelo base que fue entrenado cerca del umbral y se continúa con el preentrenamiento, se realiza un ajuste fino por aprendizaje reforzado o se fusionan los pesos con otro modelo, se puede empujar un derivado al estatus de frontera aunque ninguna ejecución de entrenamiento individual haya superado los 10^26 FLOPs. Catalogar cada modelo base, cada ajuste fino, cada destilación y cada fusión de pesos —y rastrear los FLOPs consumidos en cada paso— es ahora una disciplina de registro contable esencial.

El umbral de ingresos de 500 millones de dólares para grandes desarrolladores de frontera

Un "gran desarrollador de frontera" es un desarrollador de frontera cuya entidad y filiales obtuvieron más de 500 millones de dólares en ingresos brutos anuales en el año calendario anterior. La prueba de ingresos es consolidada: se suman las empresas matrices, las subsidiarias y las filiales bajo control común. Una pequeña startup de IA que recaudó una ronda de financiación de mil millones de dólares pero obtuvo 40 millones de dólares en ingresos reales no es un gran desarrollador de frontera; un conglomerado tecnológico que cotiza en bolsa con una pequeña división de IA que cruza el umbral de FLOPs casi con seguridad lo es.

La estratificación importa porque los grandes desarrolladores de frontera tienen las obligaciones más pesadas: publicar un marco de IA de frontera, realizar evaluaciones de riesgo catastrófico, presentar resúmenes trimestrales de riesgo de uso interno a la Oficina de Servicios de Emergencia de California (Cal OES) y mantener un canal interno anónimo para informantes. Los desarrolladores de frontera más pequeños —aquellos por encima del umbral de FLOPs pero por debajo del umbral de ingresos— aún deben publicar informes de transparencia e informar incidentes de seguridad críticos, pero no están sujetos al régimen completo del marco de gobernanza.

Qué debe publicar: El Marco de IA de Frontera

Cada gran desarrollador de frontera debe publicar un marco de IA de frontera en su sitio web y mantenerlo actualizado. La revisión anual es obligatoria, y cualquier modificación material debe activar una actualización dentro de los 30 días posteriores al cambio.

Un marco defendible aborda, como mínimo:

Umbrales de riesgo catastrófico y métodos de evaluación. ¿Qué capacidades —asistencia en armas químicas, biológicas, radiológicas o nucleares; ataques a infraestructuras críticas a gran escala; escenarios de pérdida de control de agentes autónomos— consideraría el desarrollador como el cruce de un umbral catastrófico? ¿Cómo probará el desarrollador esas capacidades antes del despliegue?
Estrategias de mitigación de riesgos. Mitigaciones concretas previas al despliegue: entrenamiento de rechazo, atenuación de capacidades, restricciones de despliegue, acceso monitoreado, lanzamientos escalonados y monitoreo posterior al despliegue.
Evaluaciones de terceros. ¿Qué equipos rojos externos, evaluadores y auditores evaluarán el modelo y cómo se incorporarán sus hallazgos?
Protocolos de ciberseguridad para pesos de modelos no publicados. Controles contra amenazas internas, módulos de seguridad de hardware, segmentación de red y registro de acceso que protejan los pesos previos al despliegue contra el robo.
Procedimientos de respuesta a incidentes de seguridad críticos. Quién decide si un incidente es reportable, cómo se inicia el reloj de 15 días y cómo se coordina la empresa con Cal OES.
Mecanismos de gobernanza interna. Supervisión a nivel de junta directiva, el rol del oficial de seguridad de IA, rutas de escalada y la cadencia de las revisiones de seguridad.
Alineación con estándares. Mapeo explícito con el Marco de Gestión de Riesgos de IA del NIST (AI RMF 1.0) e ISO/IEC 42001, que el estatuto trata como bases fundamentales.

El marco no es un documento de marketing. Es un artefacto de cara al regulador que el Fiscal General puede utilizar para evaluar si los compromisos públicos de la empresa coinciden con su práctica interna. Redactarlo con el mismo rigor que una divulgación de factores de riesgo de la SEC o una descripción del sistema SOC 2 es la postura correcta.

Informes de transparencia antes de cada despliegue

Cada desarrollador de vanguardia —no solo los grandes— debe publicar un informe de transparencia antes de desplegar un modelo de vanguardia nuevo o sustancialmente modificado. El informe de transparencia es un documento específico del modelo, independiente del marco de trabajo, que debe incluir:

Nombre de la empresa, sitio web y mecanismo de contacto para inquietudes de seguridad
La fecha de lanzamiento del modelo y una lista de idiomas compatibles y modalidades de salida
Usos previstos y restricciones de uso aplicables
Para los grandes desarrolladores, un resumen de las evaluaciones de riesgo catastrófico y los resultados, incluyendo si participaron evaluadores externos y cómo lo hicieron

Una "modificación sustancial" incluye mejoras importantes en las capacidades, adiciones de nuevas modalidades y cambios significativos en la mezcla de datos de entrenamiento. Las versiones de parches y los ajustes rutinarios de seguridad (fine-tunes) generalmente no requieren un nuevo informe de transparencia, pero los casos limítrofes deben documentarse con una justificación escrita en caso de que el Fiscal General pregunte posteriormente por qué no se publicó ningún informe.

El plazo de 15 días para el reporte de incidentes críticos

La carga de cumplimiento que más ha sorprendido a los asesores jurídicos internos es el cronograma de reporte de incidentes. Los desarrolladores de vanguardia deben notificar a la Oficina de Servicios de Emergencia de California (Cal OES) sobre un incidente de seguridad crítico dentro de los 15 días posteriores a su descubrimiento, con un plazo más estricto de 24 horas si el incidente representa una amenaza inminente para la seguridad pública.

El estatuto define ampliamente un incidente de seguridad crítico:

Acceso no autorizado o robo de pesos del modelo no publicados
Materialización de un riesgo catastrófico
Pérdida del control del desarrollador sobre un modelo desplegado
Comportamiento del modelo engañoso o evasivo que anule las salvaguardias

Construir un proceso interno defendible significa responder a tres preguntas antes de que ocurra un incidente:

¿Quién decide? Un solo oficial designado (a menudo el director de seguridad de IA o un adjunto designado) debe tener la autoridad para iniciar el plazo de reporte, con criterios de escalada documentados.
¿Qué inicia el plazo? El "descubrimiento" es el detonante. La documentación interna debe capturar exactamente cuándo se descubrió un incidente, por quién y a través de qué sistema de monitoreo, porque la ventana de 15 días se calcula a partir de ese momento.
¿Cómo se transmite el reporte? Cal OES mantiene un proceso de recepción confidencial para las presentaciones de los desarrolladores. El equipo de reporte debe ensayar el flujo de trabajo de envío —incluyendo la transmisión encriptada de detalles técnicos sensibles— mucho antes de que ocurra cualquier incidente real.

Para los grandes desarrolladores de vanguardia, la obligación va más allá del reporte reactivo de incidentes. Cada tres meses (o de acuerdo con otro cronograma razonable), los grandes desarrolladores deben transmitir a Cal OES un resumen de cualquier evaluación de riesgo catastrófico derivada del uso interno de sus modelos de vanguardia. Esta cadencia trimestral es exclusiva de la SB 53 y es la primera vez que un estatuto de los EE. UU. obliga a los laboratorios de IA a reportar hallazgos de riesgo de uso interno continuo a una agencia del poder ejecutivo.

Protecciones para denunciantes y el canal interno anónimo

La SB 53 añade, sobre el régimen general de denunciantes de California, un conjunto de protecciones específicas para la IA que se aplican a los "empleados cubiertos": aquellos cuyas funciones incluyen evaluar, gestionar o abordar el riesgo de daño catastrófico de los modelos de vanguardia.

Los desarrolladores de vanguardia no pueden impedir que un empleado cubierto divulgue información, ni tomar represalias contra él por hacerlo, ante:

El Fiscal General de California
Una autoridad regulatoria federal
Un supervisor directo u otro supervisor con autoridad para investigar
Otro empleado cubierto cuyas funciones incluyan la evaluación de riesgos

Las divulgaciones protegidas abarcan tanto (a) la creencia razonable de que las actividades del desarrollador presentan un peligro específico y sustancial para la salud o seguridad pública debido a un riesgo catastrófico, como (b) la creencia razonable de que el desarrollador ha violado la propia SB 53.

Los grandes desarrolladores de vanguardia también deben mantener un canal de reporte interno anónimo. El estatuto exige:

Un flujo de trabajo que permita a los empleados cubiertos enviar divulgaciones anónimas sobre inquietudes de riesgo catastrófico
Actualizaciones de estado mensuales al empleado denunciante sobre la investigación
Sesiones informativas trimestrales a los oficiales y directores que resuman las divulgaciones y los resultados, excluyendo a las personas señaladas de cometer irregularidades de la audiencia de la sesión

Los tribunales pueden otorgar honorarios de abogados a los demandantes que tengan éxito en acciones por represalias. Fundamentalmente, el estatuto traslada la carga de la prueba: cuando un empleado cubierto demuestra que la actividad protegida fue un factor contribuyente para una acción adversa, el desarrollador asume la carga de probar que la acción habría ocurrido por razones legítimas e independientes.

La definición de riesgo catastrófico

El centro de gravedad de la SB 53 es su definición de "riesgo catastrófico". El estatuto lo define como un riesgo previsible y material de que un modelo de vanguardia contribuya sustancialmente a la muerte o lesiones graves de más de 50 personas, o a más de 1,000 millones de dólares en daños o pérdidas de propiedad, a través de uno de tres mecanismos causales:

Asistencia con armas. Contribución material a la creación, despliegue o uso de un arma química, biológica, radiológica o nuclear, o a un ciberarma que cause un daño comparable.
Conducta dañina no controlada. Conducta del modelo con supervisión humana limitada que, si fuera cometida por un humano, constituiría un delito grave que requiere dolo.
Pérdida de control. Pérdida del control del desarrollador sobre el modelo de tal manera que este incurra en una conducta materialmente dañina.

La definición establece exclusiones importantes. Los riesgos basados en información que ya es de acceso público, los daños derivados de actividades federales legales y los daños donde la contribución del modelo no es material quedan fuera del alcance. Esta exclusión es lo que evita que los riesgos de las aplicaciones cotidianas —sesgo en la selección de currículos, consejos médicos alucinados, infracción de derechos de autor— activen el régimen de riesgo catastrófico. Esos daños son reales, pero se abordan mediante otras leyes, no por la SB 53.

Sanciones civiles y cumplimiento

El Fiscal General de California tiene la autoridad de cumplimiento exclusiva. Las sanciones civiles pueden alcanzar el millón de dólares por infracción, escalando según la gravedad de la conducta. No existe un derecho de acción privado bajo la propia SB 53, aunque las disposiciones sobre represalias contra denunciantes son independientemente exigibles a través de acciones civiles presentadas por los empleados agraviados.

En la práctica, el riesgo de cumplimiento se concentra en tres áreas:

Manipulación de umbrales. Las empresas que estructuren sus ejecuciones de entrenamiento para mantenerse justo por debajo de 10^26 FLOPs mientras ofrecen capacidades claramente de clase frontera se enfrentarán a un escrutinio riguroso. El lenguaje del estatuto sobre el cómputo acumulado hace que esta estrategia sea frágil.
Brechas en el marco de trabajo. Un marco que enumere políticas sin evidencia de su implementación será más fácil de atacar que uno que vincule cada compromiso con artefactos operativos, propietarios designados y registros de auditoría.
Retrasos en el reporte de incidentes. Incumplir el plazo de 15 días, o el plazo de 24 horas para amenazas inminentes, es el tipo de infracción clara y documentable que los reguladores históricamente persiguen con agresividad.

Creación de un plan de implementación de 90 días

Para una organización que aún no ha puesto en marcha un programa SB 53, la siguiente secuencia funciona adecuadamente:

Días 1 al 30: Análisis de alcance y de brechas.

Catalogar cada modelo fundacional entrenado, ajustado (fine-tuned), fusionado o sustancialmente modificado, con el cómputo acumulado estimado para cada uno.
Determinar si los ingresos consolidados (incluyendo todas las filiales) superaron los 500 millones de dólares en el año natural anterior.
Formar un Grupo de Trabajo de Seguridad y Cumplimiento de IA interfuncional con miembros de ingeniería, seguridad, legal, comunicaciones y recursos humanos.
Contrastar las prácticas actuales con el NIST AI RMF 1.0 e ISO/IEC 42001 para identificar brechas.

Días 31 al 60: Redacción y gobernanza.

Redactar el marco de IA de frontera como un documento con control de versiones y de publicación pública.
Construir la metodología de evaluación de riesgos catastróficos, incluyendo evaluaciones de capacidad, modelado de amenazas y los criterios para declarar un modelo como capaz de frontera en un dominio peligroso.
Establecer los controles de ciberseguridad para los pesos no publicados, con registros de acceso documentados y monitoreo de amenazas internas.
Establecer el canal anónimo de denuncia interna y el flujo de trabajo para actualizaciones de estado mensuales e informes trimestrales a la junta directiva.

Días 61 al 90: Preparación operativa.

Realizar un ejercicio de simulacro (tabletop) de respuesta a incidentes que simule el descubrimiento de un robo de pesos y la materialización de un riesgo catastrófico, para luego practicar los flujos de reporte de 15 días y 24 horas.
Capacitar a los empleados cubiertos sobre los derechos de los denunciantes y el canal anónimo.
Publicar el informe de transparencia para cualquier modelo en la línea de despliegue, con una referencia cruzada al marco de IA de frontera.
Programar las presentaciones trimestrales del resumen de riesgos catastróficos ante Cal OES y la revisión anual del marco de trabajo.

Coordinación con otros regímenes de IA y privacidad

La SB 53 no actúa de forma aislada. Los equipos de cumplimiento deben mapearla contra:

El Marco de Gestión de Riesgos de IA del NIST (AI RMF), al que el estatuto hace referencia explícita y que proporciona gran parte del andamiaje sustantivo de gobernanza.
El nivel de IA de propósito general de la Ley de IA de la UE, donde el solapamiento de la documentación es sustancial y un único marco interno armonizado puede satisfacer ambos.
La Ley de IA de Colorado y la Ley de Gobernanza Responsable de IA de Texas, que regulan las obligaciones de los implementadores para la IA de toma de decisiones de alto riesgo y pueden aplicarse a sus clientes intermedios.
La Ley de Privacidad del Consumidor de California (CCPA) y las próximas normas de la Agencia de Protección de la Privacidad de California sobre tecnología de toma de decisiones automatizada, que se cruzan con el despliegue de modelos pero operan de forma independiente a la SB 53.
Los compromisos voluntarios del Instituto de Seguridad de IA federal y cualquier legislación federal de prioridad futura que pudiera cambiar la base de cumplimiento.

Los registros de cumplimiento precisos y las pistas de auditoría claras son esenciales en todos estos regímenes; y la misma disciplina de documentación que sustenta los informes financieros respalda los informes de gobernanza de IA. Los marcos de IA de frontera, las evaluaciones de riesgos catastróficos, los registros de incidentes y los registros de investigación de denunciantes deben conservarse durante al menos cinco años y almacenarse de manera que sobrevivan a la rotación de ejecutivos y a las reestructuraciones corporativas.

Mantenga sus registros financieros y de cumplimiento listos para auditoría

Ya sea que esté publicando un marco de IA de frontera, programando presentaciones trimestrales ante Cal OES o preparándose para una consulta del Fiscal General, la disciplina subyacente es la misma: registros claros, con control de versiones y auditables. El mismo enfoque de texto plano y control de versiones que los equipos nativos de IA utilizan para sus bases de código funciona de maravilla para sus libros contables. Beancount.io ofrece contabilidad en texto plano que le brinda total transparencia y control sobre sus datos financieros: sin cajas negras, sin dependencia de proveedores y con una pista de auditoría limpia que se alinea naturalmente con la disciplina de gobernanza que los reguladores ahora esperan. Comience gratis y vea por qué los desarrolladores y profesionales de las finanzas se están pasando a la contabilidad en texto plano.