Ver como PDF

Los desarrolladores de IA de frontera como OpenAI, Google, Anthropic, xAI y otros tienen obligaciones de seguridad y protección bajo la SB 53 de California, la Ley RAISE de Nueva York, la SB 315 de Illinois y la parte de la Ley de IA de la UE referida a la IA de frontera. Estas leyes establecen requisitos de notificación de incidentes, normas de evaluación de modelos, mitigaciones de seguridad y protección, prácticas de gobernanza interna y protecciones para denunciantes. Este documento resume las disposiciones clave de esas leyes, pero no sustituye al texto legal oficial.

Ley Alcance Riesgos Obligaciones Calendario
SB 53 de CA Empresas que entrenan un modelo con >10^26 FLOPs y (para la mayoría de las obligaciones) con >500 M USD de ingresos anuales Muerte o lesiones a >50 personas o >1 000 M USD en daños mediante:
- Armas QBRN
- Ataques cibernéticos, asesinato, agresión, extorsión o robo autónomos
- Pérdida de control		 Marco público, informe público al publicar el modelo, informes trimestrales de uso interno, informes de incidentes, protecciones para denunciantes 1 de enero de 2026: entrada en vigor
Ley de IA de la UE, detalles en el Código de buenas prácticas Empresas que entrenan un modelo con >10^25 FLOPs (con excepciones por encima y por debajo de ese umbral) "impacto significativo" mediante:
- Armas QBRN
- Pérdida de control
- Ciberataques
- Manipulación dañina		 Evaluación y mitigación de riesgos, incluidas evaluaciones, seguridad, monitoreo y notificación de incidentes (Código de buenas prácticas: también marcos e informes al publicar el modelo, y gobernanza interna) 2 de agosto de 2025: las empresas deben cumplir
2 de agosto de 2026: la Oficina de IA puede aplicar la ley
Ley RAISE de NY Igual que la SB 53 de CA Igual que la SB 53 de CA Igual que la SB 53 de CA, pero con un marco más detallado y notificación de incidentes más rápida 1 de enero de 2027: entrada en vigor
SB 315 de IL Igual que la SB 53 de CA Igual que la SB 53 de CA Igual que la SB 53 de CA, pero con notificación de incidentes más rápida y auditorías anuales independientes por terceros que confirmen el cumplimiento procedimental 1 de enero de 2027: entrada en vigor
1 de enero de 2028: entran en vigor los requisitos de marco y de auditoría

Panorama general

La SB 53 de California se aplica a los desarrolladores que han entrenado o comenzado a entrenar al menos un modelo usando ≥10^26 FLOPs, con un nivel más estricto de requisitos para los desarrolladores “grandes” que además tuvieron ingresos brutos anuales superiores a 500 M USD en el año calendario anterior.1 La ley establece requisitos de notificación de incidentes, estándares de transparencia y protecciones para denunciantes. El texto completo de la SB 53 puede consultarse aquí.2

El Código de buenas prácticas de IA de uso general de la UE desarrolla la Ley de IA de la UE y explica qué pasos puede dar un proveedor de un modelo de IA de uso general3 para cumplirla. El capítulo sobre seguridad y protección del Código contiene requisitos para los proveedores de modelos de IA de frontera, y entre sus firmantes están OpenAI, Anthropic, Google y xAI. Cubre la evaluación de modelos, las mitigaciones de seguridad y protección, la gobernanza interna y el seguimiento y notificación de incidentes. Se espera que los firmantes cumplan con el Código desde agosto de 2025, y la Oficina de IA comenzará a aplicar las normas en agosto de 2026. El texto de la Ley de IA de la UE puede consultarse aquí y el Código de buenas prácticas está aquí.

Toda empresa de IA de frontera que haya usado o prevea usar >10^25 FLOPs de cómputo para entrenar un modelo que esté o vaya a introducirse en el mercado de la UE debe cumplir los requisitos de seguridad y protección de la Ley de IA de la UE. Sin embargo, la Oficina de IA tiene discrecionalidad para eximir de esos requisitos a un modelo por encima del umbral de cómputo, o para determinar que un modelo está cubierto aunque esté por debajo del umbral. Las empresas de IA de frontera que se nieguen a firmar el Código deben demostrar el cumplimiento por medios alternativos adecuados.4

La Ley RAISE de Nueva York es otra regulación estatal de seguridad que cubre a los desarrolladores de IA de frontera. Entrará en vigor el primer día de 2027. La RAISE exige notificaciones de incidentes más rápidas que la SB 53 — 72 horas en lugar de 15 días — y marcos de IA de frontera más detallados que los requeridos por la ley de California. Por lo demás, ambas leyes son bastante similares. Debido a esa similitud, este documento no analiza la RAISE por separado. El texto completo de la Ley RAISE puede consultarse aquí.

La SB 315 de Illinois, la Ley de Medidas de Seguridad en Inteligencia Artificial, es la tercera regulación estatal de seguridad que cubre a los desarrolladores de IA de frontera. Su rasgo más distintivo es que exige a cada gran desarrollador contratar cada año a un tercero para que audite de forma independiente su cumplimiento, y publicar un resumen de alto nivel de los hallazgos de la auditoría junto con una copia redactada del informe del auditor. La SB 315 entra en vigor el primer día de 2027, aunque su marco de IA de frontera y sus requisitos de auditoría independiente no se aplican hasta el 1 de enero de 2028 — un año completo más tarde, y después de que tanto la SB 53 como la RAISE hayan entrado en vigor.5 Otras disposiciones distintivas a tener en cuenta son que los grandes desarrolladores no pueden operar un modelo de frontera en Illinois sin una declaración de divulgación registrada ante el estado6; y que la SB 315 hace de la regulación de los modelos de IA de frontera una función exclusiva del Estado, desplazando las normas locales de Illinois.7

Por lo demás, la SB 315 es bastante similar a la ley de California; las secciones siguientes señalan los principales puntos en los que va más allá. El texto completo de la SB 315 puede consultarse aquí.

Riesgos

Tanto las leyes estatales de EE. UU. como el Código de buenas prácticas cubren riesgos catastróficos provenientes de la IA, pero los riesgos cubiertos difieren algo. La SB 53 exige a los grandes desarrolladores de IA de frontera evaluar y mitigar riesgos relacionados con:8

  • Armas químicas, biológicas, radiológicas y nucleares (QBRN)
  • Sistemas de IA que realicen ciberataques de manera autónoma
  • Sistemas de IA que cometan, de manera autónoma, asesinato, agresión, extorsión o robo
  • Sistemas de IA que evadan el control de sus desarrolladores o usuarios.

El Código de buenas prácticas exige a los firmantes evaluar y mitigar riesgos relacionados con:9

  • Armas QBRN
  • Pérdida de control
  • Ciberofensiva
  • Manipulación dañina.

Marcos

Las leyes estatales de EE. UU. obligan a cada gran desarrollador de IA de frontera a publicar un “marco de IA de frontera” en su sitio web. Ese documento debe describir el enfoque del desarrollador para evaluar riesgos catastróficos, colaborar con terceros, proteger los pesos del modelo y más.10 Los compromisos que un desarrollador asume en su marco de IA de frontera son jurídicamente vinculantes. Si no cumple con su propio marco, puede ser multado con hasta un millón de dólares por infracción bajo la SB 53, y de forma similar bajo las otras leyes estatales.11

El Código de buenas prácticas exige a cada firmante redactar un “marco de seguridad y protección” y compartirlo con la Oficina de IA. El marco debe describir cómo evaluará y mitigará los riesgos sistémicos, cómo determina si el riesgo sistémico es aceptable, cómo asigna internamente la responsabilidad de la evaluación y mitigación de riesgos, y más.12 Luego debe implementar su marco y actualizarlo según corresponda.13 También debe publicar un resumen del marco cuando sea necesario para evaluar o mitigar el riesgo sistémico, y se le anima (aunque no se le obliga) a comunicar el marco claramente a su personal.14

Auditorías independientes

SB 315: A partir del 1 de enero de 2028,15 cada gran desarrollador de frontera debe contratar cada año a un tercero independiente para auditar si ha cumplido con los requisitos de marco de la ley. Se trata de una auditoría de cumplimiento procedimental, es decir, verifica si el desarrollador siguió los procesos que la ley exige — si redactó, publicó y cumplió efectivamente su marco de IA de frontera y publicó los informes de transparencia requeridos, incluidos los resúmenes de las evaluaciones de riesgo catastrófico realizadas conforme a su marco de IA de frontera — pero no si los modelos son seguros.16

Para asegurar una evaluación justa, el auditor debe ser competente en seguridad de modelos de frontera, seguir las normas de auditoría generalmente aceptadas y no tener ningún interés financiero en el desarrollador, y su remuneración no puede estar vinculada a los hallazgos de la auditoría.17 El desarrollador, por su parte, debe proporcionar todos los materiales razonablemente necesarios para la auditoría. Sin embargo, los desarrolladores pueden imponer protocolos de seguridad, como revisiones en sus instalaciones, restricciones de copia y acuerdos de confidencialidad, para proteger secretos comerciales, la ciberseguridad, la seguridad pública y la seguridad nacional.18

El informe de auditoría debe indicar entonces si el desarrollador ha cumplido sustancialmente con los requisitos de marco de la ley, explicar cualquier desviación material y las razones detrás de ella, ofrecer recomendaciones sobre cómo corregirla y evaluar los controles internos del desarrollador.19

Además, el desarrollador debe conservar una copia sin redactar durante todo el tiempo que el modelo esté desplegado, más cinco años. Dentro de los 30 días posteriores a la recepción del informe, el desarrollador debe publicar un resumen y una copia redactada en su sitio web y enviar la versión redactada a la Agencia de Gestión de Emergencias de Illinois y al Fiscal General.20

Notificación de incidentes

SB 53: Los desarrolladores de frontera deben notificar los incidentes críticos de seguridad a la Oficina de Servicios de Emergencia de California. Una vez descubierto el incidente, el desarrollador dispone de un tiempo limitado para presentar el informe.21

Tipo de incidente Plazo de notificación
Muerte o lesión por pérdida de control, materialización de un riesgo catastrófico, acceso no autorizado a los pesos del modelo que provoque muerte o lesión, o subversión engañosa de los controles del desarrollador por parte de un modelo 15 días
Incidentes que planteen riesgo inminente de muerte o lesiones graves 24 horas

Además, los grandes desarrolladores de frontera están obligados a compartir con la Oficina de Servicios de Emergencia sus evaluaciones de riesgo catastrófico derivadas del uso interno de IA, mediante resúmenes trimestrales.22 Bajo la RAISE y la SB 315, Nueva York e Illinois canalizarán de forma similar los informes de incidentes a sus respectivos organismos estatales, y ambas exigen que los incidentes críticos de seguridad se notifiquen dentro de 72 horas en lugar de los 15 días de la SB 53.23

Código de buenas prácticas: Los firmantes deben monitorear los incidentes graves, documentarlos y notificarlos a la Oficina de IA.24 Los plazos de notificación dependen del tipo de daño:

Tipo de incidente Plazo de notificación
Interrupción grave de infraestructura crítica 2 días
Brecha de ciberseguridad grave, incluida la exfiltración de pesos del modelo 5 días
Muerte de una persona 10 días
Daño grave a la salud, los derechos fundamentales, la propiedad o el medio ambiente 15 días

Para los incidentes no resueltos, los firmantes deben presentar informes intermedios al menos cada cuatro semanas y un informe final dentro de los 60 días posteriores a la resolución. Los informes deben incluir análisis de causa raíz, descripción de la cadena de eventos, cualquier patrón detectado en el seguimiento posterior a la comercialización y medidas correctivas tomadas o recomendadas. Los firmantes también deben facilitar la notificación de incidentes por parte de los responsables del despliegue y usuarios posteriores, informándoles de los canales de notificación disponibles. La documentación debe conservarse durante al menos cinco años.

Seguridad

SB 53: Cada gran desarrollador de frontera debe describir sus prácticas de ciberseguridad en el marco de IA de frontera que publique, explicando cómo previene la modificación o transferencia no autorizada de los pesos de modelos de frontera.25 El desarrollador está obligado por ley a seguir las prácticas de seguridad anunciadas y puede enfrentarse a multas si no lo hace.

Código de buenas prácticas: Los firmantes se comprometen a definir un objetivo de seguridad que indique frente a qué tipos de actores de amenaza protegerán sus modelos de frontera de accesos o robos. Como mínimo, el objetivo de seguridad debe incluir la defensa contra amenazas externas no estatales y amenazas internas (incluida la autoexfiltración del modelo).26

Luego, el firmante debe implementar las medidas adecuadas para cumplir su objetivo de seguridad, que podrían incluir medidas más estrictas para modelos en etapas más avanzadas del ciclo de vida de desarrollo.27

Evaluación de modelos

El Código de buenas prácticas indica que el equipo de evaluación de un firmante debe disponer de recursos apropiados y suficientes para evaluar los riesgos que plantean los modelos del firmante. Según corresponda a la evaluación de riesgos sistémicos, los evaluadores deberían contar con:28

  • Acceso adecuado al modelo, que puede incluir activaciones, logits, cadenas de razonamiento (CoT) y versiones con barreras mínimas (a veces llamadas “helpful only”) si existen, siempre que ese acceso amplio sea compatible con la seguridad del modelo,
  • Información adecuada, que puede incluir la especificación del modelo, el prompt del sistema, los datos de entrenamiento y los resultados previos,
  • Tiempo de acceso adecuado antes de la publicación del modelo, recomendándose un mínimo de veinte días hábiles de acceso, y
  • Cómputo, personal y recursos de ingeniería adecuados.

Un desarrollador debería contratar a evaluadores externos independientes para cada nuevo modelo de frontera y, al menos cada seis meses a partir de entonces, para sus modelos más capaces,29 y a esos evaluadores externos se les deberían proporcionar recursos adecuados como los enumerados arriba.30

Informes sobre el modelo

Leyes estatales de EE. UU.: Antes o simultáneamente con la implementación de un nuevo modelo de frontera o de una versión sustancialmente actualizada de un modelo existente, un gran desarrollador de frontera debe publicar un “informe de transparencia” sobre ese modelo. Ese informe debe resumir las evaluaciones de riesgo catastrófico que el desarrollador realizó para cumplir con su marco de IA de frontera, los resultados de esas evaluaciones, en qué medida participaron evaluadores externos en la evaluación del modelo y cualquier otro paso que el desarrollador haya dado para cumplir con su marco.31

Esas evaluaciones de riesgo divulgadas y las medidas de cumplimiento del marco quedan luego sujetas a verificación bajo el requisito de auditoría independiente anual de la SB 315.

Código de buenas prácticas: Antes de introducir en el mercado de la UE un modelo de IA de uso general con riesgo sistémico, un firmante debe presentar un “informe de modelo de seguridad y protección” a la Oficina de IA.32 Ese informe debe describir la arquitectura, las capacidades y el funcionamiento previsto del modelo; justificar por qué los riesgos sistémicos son aceptables; documentar los procesos del firmante para la identificación, análisis y mitigación de riesgos sistémicos; describir cualquier participación de evaluadores externos independientes; y detallar las mitigaciones de seguridad y protección implementadas. Cuando sea necesario para evaluar o mitigar riesgos sistémicos, el firmante también debe publicar una versión resumida del informe, con las omisiones permitidas.33

Gobernanza interna

SB 53: Un desarrollador de frontera debe facilitar la notificación interna de evidencia de que las actividades del desarrollador plantean un riesgo específico y sustancial para la salud o la seguridad públicas derivado de un riesgo catastrófico, o de que el desarrollador ha violado la SB 53. Debe existir un proceso razonable mediante el cual el personal de gestión de riesgos pueda presentar tales informes de manera anónima y lograr que sean puestos en conocimiento de los líderes de la empresa.34

Código de buenas prácticas: Los firmantes están obligados a proporcionar recursos humanos, financieros y computacionales adecuados, así como acceso adecuado a la información, a quienes tienen responsabilidad sobre la supervisión, la propiedad, el soporte, el monitoreo y el aseguramiento del riesgo sistémico.35 Además, los firmantes se comprometieron a promover una cultura interna saludable de riesgo, por ejemplo:36

  • Permitiendo la comunicación interna abierta y la impugnación de las decisiones de riesgo,
  • Manteniendo canales para comunicar preocupaciones, y
  • Manteniendo al personal de gestión de riesgos independiente e incentivado a estimar correctamente el riesgo.

Protecciones para denunciantes

SB 53: Los empleados con sede en California con responsabilidad sobre la evaluación o gestión de riesgos tienen protecciones especiales para denunciantes. Están protegidos contra represalias si comunican información que tienen motivos razonables para creer que demuestra que las acciones de su empleador plantean un peligro específico y sustancial para la salud o la seguridad públicas a través de un riesgo catastrófico. El empleado puede notificar esta información al Fiscal General de California, a autoridades federales, a supervisores o a colegas con autoridad de gestión de riesgos. Cada desarrollador de frontera debe dar a los empleados relevantes un aviso claro sobre sus protecciones como denunciantes.37

Asimismo, todos los empleados con sede en California están protegidos contra represalias si comunican información que tienen motivos razonables para creer que demuestra que su empleador no ha cumplido con la SB 53 (o con cualquier otra ley federal o estatal).38 Ejemplos de incumplimiento de la SB 53 podrían incluir declaraciones falsas o engañosas sobre riesgos catastróficos hechas por un desarrollador o violaciones de la política de seguridad publicada por el desarrollador. Los empleados pueden presentar evidencia de tales incumplimientos a una agencia gubernamental o de aplicación de la ley, a un supervisor, o a un colega con autoridad para investigar o corregir el problema.

SB 315: Las disposiciones de Illinois sobre denunciantes reflejan la prohibición de represalias de la SB 53 y su prohibición de contratos que supriman la divulgación, pero añaden vías de notificación propias de Illinois. En concreto, un empleado responsable de evaluar, gestionar o abordar el riesgo de incidentes críticos de seguridad (“empleado cubierto”) puede acudir al Fiscal General (principalmente mediante la línea de derechos laborales, la Workplace Rights Hotline), a la Agencia de Gestión de Emergencias de Illinois y su Oficina de Seguridad Nacional, a una autoridad federal, a una persona con autoridad sobre el empleado cubierto (por ejemplo, su superior) o a otro empleado cubierto con autoridad para actuar sobre la cuestión.39 La SB 315 también modifica la Ley de Denunciantes de Illinois para prohibir las represalias por la divulgación de buena fe de cualquier infracción de la ley; esa disposición no nombra a ningún destinatario permitido, por lo que podría proteger la divulgación a la prensa o al público.40 Estos derechos deben comunicarse claramente a los empleados cubiertos mediante un aviso colocado en el lugar de trabajo o una notificación escrita anual, y estas protecciones se suman a la Ley de Denunciantes de Illinois, sin limitarla.41

Código de buenas prácticas: Los firmantes se comprometieron a promover una cultura interna saludable de riesgo, por ejemplo, no tomando represalias contra empleados que reporten información sobre riesgos sistémicos a las autoridades competentes.42 Y los empleados cuyos contratos se rijan por el derecho de la UE tendrán protecciones exigibles contra represalias bajo la Directiva de la UE sobre denuncia de irregularidades.43 Los firmantes se comprometen a informar anualmente a sus trabajadores sobre la política de protección de denunciantes del firmante.44

Los denunciantes que quieran contactar a la Oficina de IA pueden enviar informes mediante su herramienta de denuncia en línea.

Antes de hacer una divulgación

Consultar a un abogado antes de hacer una divulgación a autoridades externas o de usar canales internos de reporte puede ayudar a asegurar que la divulgación esté legalmente protegida. Muchos abogados especializados en denuncia ofrecen consultas pro bono. Las House Whistleblower Support Organizations, el AIWI Contact Hub y el LASST AI Safety Whistleblower Legal Defense Fund son recursos para encontrar asesoría legal. LASST también ofrece apoyo económico para pagar honorarios de abogados y otros gastos legales.

Texto regulatorio completo: SB 53 · Código de buenas prácticas · Ley RAISE · SB 315

Publicación actualizada el 28 de julio de 2026

  1. Cal. Bus. & Prof. Code §22757.11(h-j). ↩

  2. Específicamente, la SB 53 añadió las Secciones 22757.10-16 al Código de Negocios y Profesiones de California, la Sección 11546.8 al Código de Gobierno y la Sección 1107 al Código Laboral. ↩

  3. La Ley de IA de la UE (Artículo 3(63)) define un modelo de IA de uso general como “un modelo de IA… que muestra una generalidad significativa y es capaz de realizar de manera competente una amplia gama de tareas distintas… excepto los modelos de IA que se utilizan para actividades de investigación, desarrollo o creación de prototipos antes de su introducción en el mercado.” ↩

  4. Véase la Ley de IA de la UE, Artículo 55. “Los proveedores de modelos de IA de uso general que no se adhieran a un código de buenas prácticas aprobado o no cumplan una norma armonizada europea deberán demostrar que cumplen sus obligaciones por medios alternativos adecuados para su evaluación por parte de la Comisión.” ↩

  5. SB 315 de Illinois, §§ 10, 18. Conforme a la Sección 18(a), un gran desarrollador de frontera debe tener una declaración de divulgación registrada para operar un modelo de frontera en Illinois a partir del 1 de enero de 2027; el marco de IA de frontera (Sección 10(a)) y la auditoría independiente anual (Sección 10(d)) se aplican a partir del 1 de enero de 2028. ↩

  6. SB 315 de Illinois, § 18. Un gran desarrollador de frontera debe presentar (y renovar anualmente) una declaración de divulgación y pagar tasas de administración prorrateadas para operar un modelo de frontera en Illinois a partir del 1 de enero de 2027; la Agencia puede imponer una sanción civil de 1 000 USD por día a un desarrollador que opere sin una divulgación vigente o que presente información falsa. ↩

  7. SB 315 de Illinois, § 35. La regulación de los modelos de frontera de inteligencia artificial es un poder y una función exclusivos del Estado (una denegación y limitación de las facultades de autonomía local). ↩

  8. Cal. Bus. & Prof. Code, §22757.11(c). ↩

  9. Código de buenas prácticas de la UE, Apéndice 1.4. ↩

  10. Véase el Cal. Bus. & Prof. Code, §22757.12(a) para la lista completa de temas que debe cubrir un marco de IA de frontera. ↩

  11. Cal. Bus. & Prof. Code, §22757.15(a). Establece sanciones civiles de hasta 1 000 000 USD por infracción para un gran desarrollador de frontera que no publique o transmita los documentos requeridos, haga declaraciones prohibidas, no notifique un incidente o no cumpla con su propio marco. ↩

  12. Véase el Código de buenas prácticas de la UE Medida 1.1 para una descripción completa del contenido requerido de un marco de seguridad y protección. ↩

  13. La implementación está cubierta por el Código de buenas prácticas de la UE Medida 1.2, y las actualizaciones del marco por la Medida 1.3. ↩

  14. Véase el Código de buenas prácticas de la UE Medida 10.2 (publicación de una versión resumida del Marco) y Medida 8.3(1) (comunicación del Marco al personal como parte de una cultura saludable de riesgo). ↩

  15. O 90 días después de que el desarrollador califique por primera vez como gran desarrollador de frontera, si esa fecha es posterior. ↩

  16. SB 315 de Illinois, § 10(d). Dado que una ficha del modelo debe divulgar tanto las evaluaciones de riesgo catastrófico que exige el marco de un gran desarrollador de frontera como sus resultados, § 10(c)(2)(A)-(B), (c)(4), las evaluaciones mismas son obligatorias. El tercero realiza una “auditoría del cumplimiento de los requisitos de esta Sección”, y el informe describe “si el gran desarrollador de frontera ha cumplido sustancialmente los requisitos de esta Sección”, § 10(d), (d)(2)(A) (es decir, el marco de IA de frontera y los informes de transparencia de la Sección 10). Como la ley en ningún punto ordena al auditor evaluar la seguridad real de un modelo, la auditoría es procedimental: verifica si los desarrolladores siguieron los procesos exigidos, no la seguridad sustantiva. ↩

  17. SB 315 de Illinois, § 10(d). ↩

  18. SB 315 de Illinois, § 10(d)(1). ↩

  19. SB 315 de Illinois, § 10(d)(2). Enumera el contenido obligatorio del informe de auditoría: una determinación de cumplimiento, las desviaciones materiales con su justificación y recomendaciones, una evaluación de los controles internos, el personal de auditoría, los procedimientos sobre conflictos de interés, la metodología y la firma de certificación del auditor principal. ↩

  20. SB 315 de Illinois, § 10(d)(3)–(4). El informe sin redactar se conserva durante el despliegue del modelo más cinco años; dentro de 30 días se publican un resumen de alto nivel y el informe redactado, y el informe redactado se transmite a la Agencia y al Fiscal General, quienes pueden solicitar acceso. No obtener la auditoría es una infracción sujeta a las sanciones civiles descritas. ↩

  21. Cal. Bus. & Prof. Code, §22757.13(c). Exige la notificación dentro de los 15 días posteriores al descubrimiento, o dentro de las 24 horas si el incidente plantea un riesgo inminente de muerte o lesión física grave. ↩

  22. O presentando resúmenes en otro calendario razonable acordado con la OES. Véase Cal. Bus. & Prof. Code, §22757.12(d). ↩

  23. Ley RAISE de Nueva York, § 1422(3), y SB 315 de Illinois, § 15(c). Cada una exige la notificación en 72 horas de un incidente crítico de seguridad al organismo estatal designado correspondiente (el Departamento de Servicios Financieros de Nueva York; la Agencia de Gestión de Emergencias de Illinois y su Oficina de Seguridad Nacional, y el Fiscal General), y la divulgación en 24 horas a una autoridad apropiada, incluida cualquier agencia de aplicación de la ley o de seguridad pública con jurisdicción, cuando un incidente plantee un riesgo inminente de muerte o lesión física grave. ↩

  24. Código de buenas prácticas de la UE, Compromiso 9. ↩

  25. Cal. Bus. & Prof. Code, §22757.12(a). ↩

  26. Para el objetivo de seguridad y su implementación, véase el Código de buenas prácticas de la UE, Medida 6.1. Para la definición de autoexfiltración como amenaza interna, véase el Apéndice 4.4. ↩

  27. “Los Firmantes implementarán mitigaciones de seguridad apropiadas para cumplir con el Objetivo de Seguridad.” Código de buenas prácticas de la UE Medida 6.2. ↩

  28. Código de buenas prácticas de la UE, Apéndice 3.4. ↩

  29. Código de buenas prácticas de la UE, Apéndice 3.5. Los firmantes no están obligados a contratar a un evaluador externo cuando publican un nuevo modelo que se considera “similarmente seguro o más seguro” (véase el Código de buenas prácticas de la UE, Apéndice 2). ↩

  30. Código de buenas prácticas de la UE, Apéndice 3.5. ↩

  31. Cal. Bus. & Prof. Code §22757.12. ↩

  32. Código de buenas prácticas de la UE, Compromiso 7. ↩

  33. Código de buenas prácticas de la UE, Medida 10.2. ↩

  34. Cal. Lab. Code, §1107.1(e). ↩

  35. Código de buenas prácticas de la UE, Medida 8.2. ↩

  36. Véase el Código de buenas prácticas de la UE Medida 8.3 para todos los elementos de esta lista. ↩

  37. Cal. Lab. Code, §1107.1. ↩

  38. Cal. Lab. Code, §1102.5. ↩

  39. SB 315 de Illinois, § 20(c)–(d). Los informes pueden presentarse a través de la Workplace Rights Hotline del Fiscal General; los desarrolladores deben dar un aviso claro colocándolo en el lugar de trabajo o mediante notificación escrita anual. ↩

  40. SB 315 de Illinois, § 90 (que modifica 740 ILCS 174/15). La nueva subsección (e) prohíbe las represalias por la divulgación de buena fe de cualquier infracción de la ley. A diferencia de las subsecciones (a)-(c), que protegen la divulgación a un destinatario determinado (por ejemplo, un organismo público o un supervisor), la subsección (e) no especifica ninguno, lo que podría dejar la divulgación a la prensa o al público dentro de sus términos. ↩

  41. SB 315 de Illinois, § 20(f). La Sección no menoscaba ni limita la aplicabilidad de la Ley de Denunciantes de Illinois. ↩

  42. Véase el Código de buenas prácticas de la UE, Medida 8.3(7). ↩

  43. Véase el Artículo 87 de la Ley de IA de la UE. Para un análisis más amplio, véase “Whistleblowing and the EU AI Act” de Koivula y Koch. ↩

  44. Véase el Código de buenas prácticas de la UE, Medida 8.3(6). ↩