Auditorías de IA en Illinois a partir de 2028: análisis del primer estado de EE. UU.

La entrada del calendario ya no es un panel de conferencia. Es una dependencia de lanzamiento. Illinois ha trasladado el cumplimiento de seguridad de la IA desde el terreno conocido de la documentación interna al mundo menos indulgente de las auditorías independientes. Eso importa porque la auditabilidad no es algo que un equipo pueda añadir por encima a un modelo después del lanzamiento. Los registros, los historiales de evaluación, los flujos de trabajo de incidentes, las aprobaciones de gobernanza y las pruebas de proveedores tienen que existir antes de que un tercero pueda verificarlos. La pregunta práctica no es si a los reguladores les gustan los marcos de seguridad. Es si tu proceso de producto puede demostrar que uno funcionó cuando importaba.

Qué promulgó realmente Illinois

Según Skadden, el gobernador de Illinois, JB Pritzker, firmó la Ley de Medidas de Seguridad de la Inteligencia Artificial el 6 de julio de 2026, convirtiendo a Illinois en el tercer estado, después de California y Nueva York, en imponer obligaciones de transparencia, seguridad y presentación de informes a los grandes desarrolladores de IA. Skadden dice que Illinois va más allá al exigir que los desarrolladores contraten a un tercero independiente para auditar el cumplimiento cada año. DLA Piper describe de forma similar a Illinois como el primer estado en exigir auditorías de terceros de modelos de IA, mientras que Governing informó anteriormente que el proyecto de ley exigiría a los principales desarrolladores de IA divulgar riesgos, informar incidentes de seguridad y someterse a auditorías independientes anuales.

La versión de titular es sencilla: Illinois es el primero en verificación externa. La versión jurídica es más estrecha y más útil: los grandes desarrolladores cubiertos de modelos frontera enfrentan auditorías anuales independientes de cumplimiento, además de una obligación de marco público que comienza el 1 de enero de 2028. Si tu memorando de cumplimiento dice solo que la tarjeta del modelo está terminada, se está perdiendo el punto.

Quién está en el carril de cumplimiento

Skadden dice que la Ley se centra en un marco de IA frontera y se aplica a un gran desarrollador frontera. A partir del 1 de enero de 2028, ese desarrollador debe redactar, implementar, cumplir y publicar de forma visible en su sitio web un marco que describa su enfoque para gestionar riesgos catastróficos. Skadden también dice que el marco debe revisarse al menos una vez al año, y que cualquier modificación material debe publicarse con una justificación dentro de los 30 días. Crowell & Moring presenta la misma ley como obligaciones de transparencia y seguridad para sistemas de IA frontera, y dice que Illinois se unió a California y Nueva York en la adopción de estándares para los sistemas de IA más potentes. Ese es un límite útil para los constructores que no entrenan modelos frontera pero dependen de ellos. Puede que no seas el objetivo legal directo, pero compras tiene una memoria larga y un cuestionario corto.

Qué cambia para los constructores

Cooley describe AISMA como un paso de la transparencia a la verificación. Su análisis contrasta marcos anteriores, incluida la TFAIA de California, la Ley RAISE modificada de Nueva York y partes de la Ley de IA de la UE, que por lo general exigen a los desarrolladores evaluar y divulgar cómo identifican, evalúan y gestionan los riesgos de la IA. Illinois añade la parte incómoda: un tercero independiente tiene que comprobar si el proceso realmente funciona como se describe. Traducido al trabajo de producto, eso significa que las pruebas de cumplimiento tienen que diseñarse dentro del sistema. La lista de verificación de lanzamiento necesita responsables para las evaluaciones de riesgo, las tarjetas de modelo o sistema, las rutas de reporte de incidentes, las actualizaciones del marco público y la cooperación con auditorías. Un contrato con un proveedor que toque un modelo frontera debería pedir entrega de documentación, aviso de incidentes y apoyo de auditoría, no porque todos los clientes estén regulados directamente, sino porque las obligaciones reguladas viajan a través de las compras.

DLA Piper señala que AISMA se parece a California y Nueva York en las obligaciones de transparencia, con la excepción destacada de las disposiciones de auditoría. Esa excepción es donde los equipos de producto deberían dedicar tiempo. Un marco público es un documento. Una auditoría es un documento más pruebas, marcas de tiempo, personas, controles y alguna que otra reunión incómoda.

Dónde divergen ahora las jurisdicciones

La comparación de Cooley es el problema que reconocerán los constructores: California, Nueva York y partes de la Ley de IA de la UE enfatizan la evaluación, la divulgación, los marcos de gobernanza, los informes de transparencia, las tarjetas de modelo, las evaluaciones de riesgo y el reporte de incidentes. Illinois mantiene gran parte de esa arquitectura y luego añade verificación independiente. Crowell & Moring dice que, incluso sin acción federal, California, Nueva York e Illinois han creado lo que es, en esencia, un marco nacional para la seguridad y la transparencia de la IA. Eso no significa que las reglas sean idénticas. Significa que un gran desarrollador que atiende a clientes de EE. UU. puede tener que satisfacer la expectativa operativa más estricta incluso donde otro estado se conforma con controles autoinformados.

El centro de gravedad del cumplimiento se está moviendo de lo que un desarrollador dice que hace a lo que un auditor puede verificar que hizo. Para los lectores que construyen con sistemas frontera, el siguiente paso útil es aburrido e inmediato: mapear qué pruebas ya crea tu ciclo de vida de desarrollo actual, qué pruebas desaparecen en hilos de chat y qué pruebas podría inspeccionar realmente un tercero. Para 2028, las empresas interesantes no serán las que digan que dan la bienvenida a las reglas. Serán aquellas cuyo proceso de lanzamiento ya deje un rastro de auditoría.