La SB 53 de California se lee como una matriz de obligaciones

El 29 de septiembre de 2025, el gobernador Gavin Newsom firmó la SB 53, denominada Transparency in Frontier Artificial Intelligence Act. La ley californiana creó obligaciones sobre marcos de seguridad, informes de modelos, incidentes críticos y denunciantes. No impuso una licencia previa general ni convirtió en responsable al desarrollador por cualquier daño relacionado con IA.

Su alcance no cabe en una frase como “regula los modelos grandes”. El texto distingue entre modelo fundacional, modelo frontera, desarrollador frontera y gran desarrollador frontera; asigna obligaciones diferentes a cada sujeto; define daños concretos; permite redacciones; y reserva la sanción civil a incumplimientos enumerados. Leerla bien exige una matriz, no un adjetivo.

La firma es el hecho; el texto aprobado es la regla

El anuncio del gobernador presentó la norma como la primera legislación estatal estadounidense de seguridad para IA frontera y la relacionó con un informe previo de expertos. Ese comunicado explica la posición del Ejecutivo. Las obligaciones, definiciones y excepciones están en la ley.

El texto oficial de la SB 53 es la fuente que debe acompañar cada afirmación jurídica. La ficha mínima contiene sección, sujeto obligado, conducta, plazo, excepción y autoridad. Si una frase no puede volver a ese punto, probablemente mezcla resumen político e instrumento legal.

Este artículo ofrece una lectura documental, no asesoramiento jurídico. Una empresa debe analizar hechos, estructura societaria, actividad en California y normativa concurrente con profesionales competentes.

El primer filtro combina modelo, cómputo y desarrollador

Un modelo fundacional, para la ley, se entrena con datos amplios, produce salidas generales y puede adaptarse a tareas diversas. Se convierte en “modelo frontera” cuando su entrenamiento usa más de diez elevado a veintiséis operaciones enteras o de coma flotante. El cálculo incluye la ejecución original y el ajuste fino, aprendizaje por refuerzo u otras modificaciones materiales que aplique el desarrollador.

El umbral mide cómputo acumulado bajo una definición legal; no cuenta parámetros ni certifica capacidad peligrosa. Un sistema puede quedar fuera por cómputo y merecer controles por su uso. Otro puede entrar aunque una evaluación concreta muestre poco riesgo. Cobertura regulatoria y evaluación técnica responden a preguntas diferentes.

Un desarrollador frontera es quien entrenó o inició el entrenamiento de ese modelo y usó o pretende usar al menos el cómputo correspondiente. Un “gran” desarrollador frontera supera, junto con sus afiliadas, 500 millones de dólares de ingresos brutos en el año natural anterior. La suma con afiliadas evita mirar una filial aislada.

No todas las obligaciones pertenecen solo a los grandes

Todo desarrollador frontera debe publicar, antes o al mismo tiempo que despliega un modelo frontera nuevo o sustancialmente modificado, un informe de transparencia con web, canal de contacto, fecha de lanzamiento, idiomas, modalidades, usos previstos y restricciones generales. Un system card o model card puede cumplir si contiene la información.

El gran desarrollador añade resúmenes de evaluaciones de riesgo catastrófico, resultados, participación de terceros y pasos seguidos bajo su marco. Además debe escribir, aplicar, cumplir y publicar un marco de IA frontera que describa umbrales de capacidad, mitigaciones, revisión previa al despliegue o uso interno extenso, evaluación externa, ciberseguridad, incidentes y gobierno interno.

Decir que “solo las empresas de más de 500 millones informan sobre sus modelos” sería demasiado estrecho. Decir que “toda startup debe publicar el marco exhaustivo de los grandes” sería demasiado amplio. La matriz separa el informe básico del informe ampliado y del marco corporativo.

Publicar un marco crea un compromiso verificable

El gran desarrollador debe revisar el marco al menos una vez al año. Si lo modifica materialmente, debe publicar la nueva versión y justificar el cambio en treinta días. También debe informar cómo incorpora estándares nacionales, internacionales y prácticas de consenso del sector, sin que la ley declare suficiente nombrarlos.

Puede redactar información para proteger secretos comerciales, ciberseguridad, seguridad pública, seguridad nacional o cumplir otras leyes. Pero debe describir carácter y justificación de la redacción hasta donde permitan esas razones y conservar la versión completa durante cinco años. “Transparencia” no significa publicación íntegra; significa una regla de publicación con excepciones y conservación.

La empresa no puede hacer declaraciones materialmente falsas o engañosas sobre riesgo catastrófico, su gestión o, si es grande, cumplimiento del marco. La ley exceptúa una declaración de buena fe razonable dadas las circunstancias. La prueba no es si el resultado fue perfecto, sino también qué se sabía, qué proceso se prometió y qué se hizo.

Riesgo catastrófico tiene cantidad, causalidad y conducta

La definición exige un riesgo previsible y material de que desarrollo, almacenamiento, uso o despliegue contribuya materialmente, en un solo incidente, a muerte o lesión grave de más de cincuenta personas, o a más de mil millones de dólares en daño o pérdida de propiedad. Además debe intervenir una conducta enumerada.

Las conductas son asistencia de nivel experto para crear o liberar un arma química, biológica, radiológica o nuclear; actuación sin supervisión humana significativa que sea ciberataque o equivalga a determinados delitos; o evasión del control del desarrollador o usuario. La pérdida de valor bursátil queda excluida del daño patrimonial.

También hay exclusiones: información ya accesible de forma sustancialmente similar fuera de un modelo fundacional; actividad legal del Gobierno federal; y daño combinado con otro software cuando el modelo no contribuyó materialmente. Un resumen que omita causalidad, incidente único y exclusiones vuelve el alcance más amplio que la ley.

Incidente crítico no equivale a cualquier vulnerabilidad

La definición cubre acceso, modificación o extracción no autorizados de pesos de un modelo frontera cuando producen muerte o lesión corporal; daño que materializa un riesgo catastrófico; pérdida de control que causa muerte o lesión; y engaño del modelo contra el desarrollador fuera de una evaluación, destinado a eludir controles o vigilancia y que muestra un aumento material del riesgo catastrófico.

Por tanto, el simple robo de pesos no entra automáticamente en esta categoría por “aumentar el riesgo”. El texto exige en esa rama que produzca muerte o lesión. Confundirla con la rama de engaño traslada una condición de un supuesto a otro y cambia una obligación jurídica.

El desarrollador frontera debe informar a la Oficina de Servicios de Emergencia dentro de quince días desde que descubre el incidente. Si descubre un riesgo inminente de muerte o lesión física grave, debe comunicarlo en veinticuatro horas a una autoridad apropiada según su naturaleza. Puede presentar informes corregidos cuando aparece nueva información.

El canal público no vuelve públicos todos los expedientes

La Oficina debe establecer un mecanismo para que desarrolladores o público comuniquen posibles incidentes, revisar los enviados por desarrolladores y puede revisar los del público. También recibe de grandes desarrolladores resúmenes confidenciales de evaluaciones sobre riesgos del uso interno.

Los informes de incidentes, evaluaciones internas y determinadas denuncias de empleados quedan exentos de la California Public Records Act. La Oficina debe limitar acceso a personal con necesidad específica. Hay supervisión gubernamental sin una promesa de expediente íntegramente abierto.

Una auditoría de aplicación separa entradas recibidas, informes revisados, acciones y publicación agregada permitida. Contar denuncias no mide su gravedad; publicar solo totales no permite evaluar tiempos. La ley distribuye transparencia y confidencialidad según el tipo de información.

La protección al denunciante tiene creencia y destinatarios

La norma impide contratos, políticas o represalias que bloqueen a empleados cubiertos cuando tienen causa razonable para creer que la actividad presenta un peligro específico y sustancial para salud o seguridad por riesgo catastrófico, o que vulnera la ley. Permite comunicar a la Fiscalía General, autoridad federal y determinadas personas internas con poder para investigar o corregir.

El gran desarrollador debe ofrecer un proceso interno anónimo para comunicaciones de buena fe y actualizar mensualmente al denunciante sobre investigación y acciones. No toda discrepancia técnica queda convertida en denuncia protegida: importan sujeto, creencia, contenido, destinatario y conducta empresarial.

La ficha de un caso debe conservar fecha, hechos observados, base de la creencia, canal usado y respuesta, evitando difundir secretos innecesarios. La protección existe precisamente porque la evidencia puede estar dentro; su uso responsable requiere precisión.

Sanción y CalCompute tienen límites propios

El gran desarrollador que no publique o transmita un documento exigido, haga determinadas declaraciones falsas, no informe un incidente o incumpla su propio marco puede afrontar hasta un millón de dólares por infracción, según gravedad. Solo la Fiscalía General puede recuperar esa sanción civil bajo este capítulo. El máximo no es una multa automática para cualquier fallo del modelo.

La SB 53 también creó un consorcio para desarrollar un marco de un futuro clúster público llamado CalCompute. Debe procurar ubicarlo en la Universidad de California y presentar el marco antes del 1 de enero de 2027, pero esas disposiciones operan solo si existe apropiación presupuestaria. La ley planifica la infraestructura; no certifica que ya estuviera construida.

El Departamento de Tecnología debe revisar anualmente desde 2027 si las definiciones siguen reflejando técnica, literatura y estándares, y recomendar cambios. No puede reescribir por sí solo el umbral mediante esa revisión: entrega recomendaciones a la Legislatura.

La matriz convierte el resumen en comprobación

Las columnas son sujeto, modelo, umbral, obligación, momento, documento, excepción, autoridad y sanción. Las filas separan marco anual, informe de despliegue, evaluación interna, incidente, denuncia y CalCompute. Cada casilla apunta a una sección y conserva el verbo exacto: deberá, podrá, se anima o queda exento.

La capacidad transferible es aplicar esa matriz a cualquier norma tecnológica. Antes de afirmar que una ley “obliga a las empresas”, identifique a cuáles; antes de citar un plazo, asócielo al hecho que lo activa; antes de llamar incidente a un evento, compruebe cada elemento; antes de anunciar una sanción, identifique infracción y ejecutor.

La SB 53 introdujo transparencia y rendición de cuentas sobre un conjunto definido de modelos y desarrolladores. Su importancia no autoriza a exagerarla. El rigor está en conservar fronteras: qué cubre, quién responde, qué debe publicar, qué puede ocultar por motivos enumerados y qué evidencia permitirá comprobar el cumplimiento.