El decreto de la Ley de IA de Italia convierte la gobernanza de IA en evidencia de auditoría

Cualquier organización que opere un sistema de IA de alto riesgo en Italia debe asumir ahora que un inspector puede examinar cómo se prueba ese sistema, y puede llegar sin previo aviso. El Decreto Legislativo n.º 179/2026 otorga a la agencia nacional de ciberseguridad de Italia la facultad de hacer exactamente eso, y las preguntas que seguirán serán sobre los datos, no sobre la arquitectura del modelo.

El decreto se publicó en el Diario Oficial el 8 de octubre de 2026 y entró en vigor el 23 de octubre de 2026. Es el segundo paso en la implementación en dos fases de la Ley de IA de la UE en Italia, tras la Ley n.º 132 del 23 de septiembre de 2025. La periodista de IAPP Alessandra Tramonte resumió el nuevo marco, incluyendo la designación de AgID como autoridad notificadora y ACN como la principal autoridad de supervisión del mercado y punto de contacto único con las instituciones de la UE.

Para un CISO o responsable de cumplimiento, el significado práctico es sencillo. Las obligaciones de gobernanza de IA que antes vivían en documentos de políticas ahora tienen responsables con facultades de investigación. Esos responsables preguntarán qué datos tocó un sistema de IA, quién lo autorizó y si puedes demostrarlo. Ese es un problema de gobernanza de datos de IA antes que un problema de modelo, y es la razón por la que este decreto importa para cualquiera que intercambie contenido sensible con sistemas de IA.

Puntos Clave

1. Italia ya tiene responsables nombrados para la Ley de IA.

AgID actúa como autoridad notificadora para los organismos de evaluación de la conformidad, y ACN como la principal autoridad de supervisión del mercado y punto de contacto único con las instituciones de la UE.

2. Las inspecciones pueden ocurrir sin aviso previo.

ACN puede inspeccionar las pruebas en el mundo real de sistemas de IA de alto riesgo de forma remota o presencial, y no está obligada a anunciar la visita con antelación.

3. El decreto designa autoridades y procedimientos.

No crea nuevas obligaciones bajo la Ley de IA, así que los deberes sustantivos siguen viniendo de la propia Ley de IA y de la Ley italiana 132.

4. Quedan varios detalles abiertos.

Actos de implementación sin plazos, un grupo sandbox aún no constituido y el calendario del Digital Omnibus de la UE implican que el panorama completo seguirá cambiando.

5. La calidad de la evidencia decide los resultados de las auditorías.

Las autoridades regulan los datos, no los modelos, así que las organizaciones que puedan mostrar quién accedió a qué datos, bajo qué autoridad y con qué registro pasarán las inspecciones más rápido.

Qué Establece el Decreto Legislativo n.º 179/2026

Italia optó por implementar la Ley de IA de la UE en dos fases. El primer paso fue la Ley n.º 132 del 23 de septiembre de 2025, publicada en la Gazzetta Ufficiale n.º 223 el 25 de septiembre de 2025 y en vigor desde el 10 de octubre de 2025. Esa ley estableció principios nacionales y delegó al gobierno la adopción de decretos de implementación. El segundo paso es el Decreto Legislativo n.º 179 del 7 de octubre de 2026, adoptado bajo la delegación del artículo 24 de la Ley 132.

El decreto consta de 54 artículos. Según el texto consolidado en Normattiva, apareció en la Serie General de la Gazzetta Ufficiale como número 234 el 8 de octubre de 2026 y entró en vigor quince días después, el 23 de octubre de 2026. Un decreto separado sobre el uso policial de IA, el Decreto Legislativo n.º 160/2026, entró en vigor el 30 de septiembre de 2026, así que el marco de IA en Italia está llegando por partes en vez de en un solo acto.

Conviene ser preciso sobre qué es este decreto. Es un instrumento institucional y procedimental. Asigna quién supervisa, quién notifica, quién inspecciona, quién sanciona y cómo se gestionan las reclamaciones. No reescribe los deberes que la Ley de IA impone a proveedores y usuarios. Un equipo de cumplimiento que lea el decreto como un nuevo reglamento para sistemas de IA se equivoca. Un equipo que lo lea como el momento en que la aplicación nacional se volvió real, lo interpreta correctamente.

Esa distinción es clave para la planificación. Tus obligaciones sobre sistemas de alto riesgo, transparencia y supervisión humana siguen derivando de la Ley de IA. Lo que cambió el 23 de octubre es que las autoridades italianas ahora tienen roles y facultades definidos para comprobar si las cumples.

Quién Tiene la Autoridad: AgID y ACN

El decreto reparte la supervisión entre dos organismos principales, y entender esa división te dice quién hará qué preguntas.

La Agencia para Italia Digital, conocida como AgID, es la autoridad notificadora. Según el artículo 4, gestiona la designación de los organismos de evaluación de la conformidad, las organizaciones que verifican los sistemas de IA de alto riesgo frente a la Ley de IA. El artículo 13 otorga a AgID un rol de supervisión sobre esos organismos. AgID puede restringir, suspender o retirar una designación, lo que significa que un organismo de evaluación que no cumpla puede perder su estatus. Para los proveedores, eso eleva el listón de calidad de las evaluaciones que adquieren, porque un certificado de un organismo que luego pierde su designación es un activo más débil.

La Agencia Nacional de Ciberseguridad, conocida como ACN, es la autoridad de supervisión del mercado según el artículo 5 y el punto de contacto único con las instituciones de la UE según el artículo 6. Es una concesión sustancial de poder a un organismo de ciberseguridad. Como explica el análisis de NicFab, la decisión sitúa la supervisión de la IA cerca del aparato de ciberresiliencia de Italia, que ya trabaja con operadores de servicios esenciales bajo la directiva NIS 2.

Los supervisores sectoriales mantienen un papel. El artículo 17 involucra al Banco de Italia, CONSOB e IVASS para instituciones financieras, así que un banco o aseguradora puede esperar que su supervisor actual siga presente. El regulador de privacidad, el Garante, se limita al alcance del artículo 74(8) de la Ley de IA según el artículo 5(1)(c) del decreto. En otras palabras, el Garante mantiene un ámbito definido en vez de convertirse en el supervisor general de IA.

Para una multinacional, esto significa un punto de entrada italiano para la mayoría de las cuestiones sobre la Ley de IA, con supervisores sectoriales añadidos para industrias reguladas. Las organizaciones que ya trabajan con programas de GDPR reconocerán el patrón de una autoridad principal más reguladores especializados, y deberían mapear cada relación antes de una inspección, no durante.

Inspecciones Sin Aviso y Qué Examinan

La disposición más relevante para los operadores es el artículo 15. Da a ACN la facultad de realizar inspecciones de forma remota o presencial, incluso sin aviso previo, y extiende ese poder a las pruebas en el mundo real de sistemas de IA de alto riesgo. El decreto se apoya en el artículo 24(2)(m) de la Ley 132, que ya preveía ese poder de inspección en la delegación. El artículo 15(3) deja los detalles procedimentales a un decreto de la Presidencia del Consejo de Ministros, adoptado a propuesta de ACN, así que los detalles están aún por definirse.

Piénsalo: una inspección sin aviso de pruebas en el mundo real implica datos reales, a menudo personales, fluyendo por un sistema que aún no está en el mercado. Un inspector querrá ver el plan de pruebas, los datos usados, las protecciones aplicadas y los registros que prueban que esas protecciones funcionaron. No habrá una semana para preparar esa evidencia. O los registros existen y son recuperables, o no lo son.

Otros artículos definen cómo inician los procedimientos. El artículo 16 establece los detonantes, y el artículo 18 prevé un canal de reclamaciones, lo que significa que una persona afectada puede activar la supervisión sin esperar a que ACN actúe por iniciativa propia. El artículo 14 añade una obligación de registro gestionada por ACN para sistemas de alto riesgo usados en infraestructuras críticas, los que entran en el punto 2 del Anexo III de la Ley de IA. Los operadores de infraestructuras críticas, por tanto, enfrentan tanto un registro nacional como facultades de inspección sobre las pruebas de esos mismos sistemas.

El patrón es consistente en todos estos artículos. El decreto da a las autoridades los medios para hacer preguntas rápidamente, cuando la evidencia está fresca. Las organizaciones que dependen de reunir evidencia de auditoría a posteriori encontrarán difícil ese modelo.

Sanciones y el Dinero Detrás de la Supervisión

El artículo 23 fija los topes de las sanciones. Reproduce los máximos del artículo 99 de la Ley de IA, que llegan a 35 millones de euros o el 7% de la facturación anual mundial para las infracciones más graves, 15 millones de euros para el siguiente nivel y 7,5 millones de euros por aportar información incorrecta. El decreto añade una franja nacional propia, una sanción menor de 1 millón de euros o el 0,5% de la facturación vinculada a las obligaciones de los artículos 27 y 86 de la Ley de IA. Estas cubren las evaluaciones de impacto sobre derechos fundamentales para ciertos usuarios y el derecho a una explicación de decisiones individuales.

El diseño de la financiación merece atención. Los ingresos de las multas impuestas por ACN y AgID se priorizan para esas agencias. Un organismo de supervisión que se financia en parte con sus propias sanciones tiene un incentivo estructural para ampliar su capacidad de inspección. Al mismo tiempo, el artículo 54 declara la neutralidad financiera, es decir, no hay nuevo gasto público, lo que el Garante señaló como en tensión con el artículo 70(3) de la Ley de IA, que exige que las autoridades nacionales tengan recursos adecuados. Si ACN y AgID tendrán suficiente personal para inspeccionar a gran escala es, por tanto, una cuestión abierta.

Un punto requiere atención. El decreto no contiene una cláusula que indique cuándo entran en vigor sus sanciones, ni menciona el Reglamento (UE) 2026/1744, el Digital Omnibus de la UE sobre IA. Cualquiera que te diga exactamente cuándo empiezan a aplicarse las multas está llenando un vacío del texto con una suposición. La interpretación prudente es que los poderes institucionales están activos desde el 23 de octubre de 2026, y que el momento de las sanciones para obligaciones concretas depende de las fechas subyacentes de la Ley de IA.

Qué Queda Por Resolver

Varios elementos del marco aún no están terminados, y un plan de preparación debe tenerlos en cuenta.

Las disposiciones del sandbox regulatorio en los artículos 26 a 31 describen un Grupo Operativo Conjunto que aún no se ha constituido, y el decreto no fija plazo para ello. Varios actos de implementación, incluidos los detalles sobre las inspecciones de pruebas en el mundo real, tampoco tienen plazo. El artículo 41 declara nulas las decisiones laborales tomadas únicamente por medios automatizados, y el consentimiento no es una excepción, lo que supone una posición nacional más estricta que los empleadores que usan cribado o programación automatizada deben revisar con atención.

El mayor elemento en movimiento está a nivel de la UE. El Reglamento (UE) 2026/1744, el Digital Omnibus sobre IA, se publicó en el Diario Oficial el 24 de julio de 2026 y entró en vigor el 27 de julio de 2026. El análisis de Cooley explica cómo retrasa los plazos clave de la Ley de IA. Las obligaciones de alto riesgo para sistemas del Anexo III pasan al 2 de diciembre de 2027, y las del Anexo I al 2 de agosto de 2028, mientras que los requisitos de transparencia del artículo 50 aplican desde el 2 de agosto de 2026.

Estas fechas cambian el ritmo de las obligaciones sustantivas, pero no eliminan el cambio institucional en Italia. Las autoridades existen, los poderes de inspección existen y las pruebas en el mundo real de sistemas de alto riesgo pueden ocurrir antes de que las obligaciones formales apliquen a los sistemas en el mercado. Toma el retraso como tiempo para fortalecer la capacidad de evidencia, no como permiso para esperar. Las fuentes que aún citan un plazo de alto riesgo en agosto de 2026 son anteriores al Omnibus y no deben guiar tu planificación.

Por Qué los Reguladores Supervisan los Datos, No los Modelos

Los directivos suelen imaginar la regulación de IA como un escrutinio de algoritmos. Un inspector sentado en tu oficina hará preguntas diferentes. Preguntará qué datos personales y sensibles entraron en el sistema, quién aprobó ese acceso, si el acceso coincidía con el propósito declarado y qué registro lo prueba. Un modelo es difícil de inspeccionar desde fuera. El rastro de datos a su alrededor, no.

Por eso los principios de confianza cero para IA generativa se traducen tan directamente en preparación para auditorías. Un sistema de IA es, desde la perspectiva del control, otro actor que solicita datos. Necesita una identidad, un alcance definido, una decisión de autorización por cada solicitud y un registro de lo que ocurrió. Las organizaciones que ya aplican esos controles para personas y aplicaciones los extienden a la IA con poco esfuerzo. Las que dejan que las herramientas de IA accedan a carpetas compartidas, archivos de correo y repositorios mediante cuentas de servicio amplias descubren que no pueden responder a la primera pregunta del inspector.

La misma lógica explica por qué el enfoque del decreto en las pruebas en el mundo real es relevante. Las pruebas son la fase en la que los equipos más se ven tentados a avanzar rápido con datos reales y controles laxos, ya que el sistema aún no está en producción. Es también la fase que un inspector italiano puede examinar ahora sin aviso. El entorno de control sobre los datos de prueba debe cumplir el mismo estándar que en producción, y la evidencia debe ser igual de recuperable.

La protección de datos y la gobernanza de IA también convergen en la práctica. Un enfoque de confianza cero para la privacidad de datos en IA ya exige minimización, limitación de propósito y registro de accesos, que son los mismos artefactos que solicitaría una inspección bajo la Ley de IA. Una empresa que ya ha hecho este trabajo para GDPR está más cerca de estar lista de lo que piensa. Una empresa que trata la IA como algo fuera de su programa de gobernanza de datos, no lo está.

Cómo Afecta el Decreto Según el Rol

El decreto no impacta igual a todas las organizaciones, y una conversación útil sobre preparación empieza preguntando dónde se sitúa tu empresa. Los tres escenarios siguientes son ilustrativos, no extraídos de ningún caso concreto.

Pensemos en un proveedor que construye un sistema de IA de alto riesgo para uso en infraestructuras críticas. Esta organización enfrenta la exposición más directa. Su sistema puede necesitar registrarse ante ACN según el artículo 14, su organismo de evaluación de conformidad está sujeto a la supervisión de AgID y cualquier prueba en el mundo real está abierta a inspección. El proveedor necesita registros de pruebas, documentación de gobernanza de datos y una justificación defendible de cómo eligió y supervisó su organismo de evaluación.

Pensemos ahora en un usuario, por ejemplo un banco que utiliza una herramienta de IA para apoyar decisiones de crédito. Aquí el Banco de Italia o CONSOB puede ser el supervisor relevante según el artículo 17, y la relación de supervisión existente del banco marca la conversación. Las preguntas se centrarán en cómo el banco controla los datos que consume la herramienta, cómo supervisa los resultados y si sus registros muestran a una persona responsable de cada decisión. Un banco que ya cumple expectativas exigentes de evidencia TIC y de terceros lleva ventaja, siempre que esos registros incluyan la herramienta de IA.

Por último, un empleador que usa cribado o programación automatizada. El artículo 41 declara nulas las decisiones laborales tomadas únicamente por medios automatizados y establece que el consentimiento no resuelve el problema. Es una norma nacional estricta, y convierte la revisión humana en el flujo de trabajo en un requisito legal, no solo una cortesía. Un empleador en esta situación debe verificar que una persona con verdadera autoridad revise cada decisión y conservar registros que lo prueben. El rastro de auditoría de esa revisión es en sí mismo un artefacto de gobernanza de datos.

En los tres escenarios se aplica la misma base: conoce qué datos alcanzan tus sistemas de IA, vincula cada acceso a una persona responsable y conserva un registro que resista cuando otra persona lo examine.

Por Qué la Calidad de la Evidencia Importa Más Que el Volumen de Políticas

Muchos programas de cumplimiento miden el progreso por la cantidad de políticas escritas. Los regímenes de inspección lo miden de otra forma. Un inspector que lea una política de IA bien redactada hará la pregunta obvia: ¿cómo sabes que se siguió la política? La respuesta está en los registros operativos, no en la política.

Esta brecha entre la política escrita y la prueba operativa es donde la mayoría de las organizaciones están expuestas. Una política puede decir que las herramientas de IA solo pueden acceder a repositorios aprobados, pero la configuración técnica permite acceso amplio mediante una credencial compartida. Una política puede decir que los datos sensibles requieren aprobación humana, pero ningún sistema registra quién aprobó qué. Cuando un inspector compara la afirmación con el registro, la brecha se convierte en hallazgo.

Cerrar la brecha requiere controles que apliquen la política automáticamente y registren la decisión de aplicación. Cuando las reglas de acceso las aplica el sistema en cada solicitud, el registro muestra tanto la regla como su aplicación, y la política deja de ser aspiracional. Esta es la lógica detrás de la gobernanza de datos basada en políticas, donde el enfoque de Data Policy Engine aplica reglas al intercambio de contenido de forma consistente y deja un registro de cada decisión.

También cambia la economía de la preparación para auditorías. Si la evidencia es un subproducto de la operación normal, una solicitud de inspección se convierte en una tarea de recuperación. Si la evidencia debe reconstruirse desde sistemas dispersos, cada inspección se convierte en un proyecto. Con poderes de inspección sin aviso ya vigentes en Italia, la diferencia entre esos dos estados es la diferencia entre una tarde tranquila y una crisis.

La Evidencia Que Pedirá un Inspector

Si un inspector de ACN pidiera revisar hoy las pruebas de un sistema de IA de alto riesgo, la solicitud probablemente se reduciría a unas pocas categorías de evidencia. Preparar esto de antemano convierte una inspección estresante en un simple intercambio de documentos.

• Identidad del actor. Qué sistema de IA, agente o integración accedió a los datos, y qué persona o responsable de negocio lo autorizó.
• Alcance del acceso. A qué repositorios, carpetas y registros podía acceder el sistema, y a cuáles accedió, con la política que permitió cada operación.
• Clasificación de los datos. Si se trataba de contenido personal, confidencial o regulado, y cómo lo gestionó el sistema.
• Cadena de custodia. Un registro que muestre qué ocurrió con los datos tras ser accedidos por el sistema de IA, incluyendo cualquier compartición posterior. Una cadena de custodia documentada convierte esto en una consulta, no en una reconstrucción.
• Evidencia de integridad. Prueba de que los registros no fueron alterados a posteriori. Los registros que un administrador puede editar tienen poco valor ante un inspector.
• Gestión de incidentes. Cómo se detectaron y escalaron anomalías, respaldado por un proceso de respuesta a incidentes que cubra eventos relacionados con IA.

La mayoría de las organizaciones pueden producir algunos de estos artefactos para personas y aplicaciones, pero muchas menos pueden hacerlo para sistemas de IA, y menos aún de forma unificada. La evidencia dispersa entre la plataforma de IA, el sistema de archivos, el proveedor de identidad y un SIEM debe ensamblarse manualmente, y eso lleva días. Una inspección sin aviso no permite días.

La calidad importa tanto como la completitud. Un registro de auditoría unificado que documente cada operación con identidad, decisión de política y resultado es una evidencia más sólida que un conjunto de registros específicos de plataforma que no coinciden en fechas ni nombres. Los inspectores valoran la evidencia que pueden verificar y que cuenta una historia coherente. Descuentan la que llega tarde, incompleta o en formatos contradictorios.

Dónde Encajan los Agentes de IA en los Mismos Controles

Los agentes de IA añaden un matiz. Un agente puede encadenar acciones, llamar herramientas y extraer datos de sistemas más rápido de lo que una persona puede revisar cada paso. La respuesta adecuada no es un régimen separado y más laxo para agentes. Los agentes deben estar gobernados junto a los usuarios humanos, bajo el mismo modelo de identidad, autorización y auditoría, con la regla añadida de que toda acción de un agente debe rastrearse hasta una persona responsable.

Ese principio encaja con la forma en que se está adoptando el Model Context Protocol, o MCP. MCP conecta asistentes de IA con fuentes de datos y herramientas empresariales, lo que es útil y también crea una nueva vía hacia contenido sensible. Sin controles, una integración MCP puede permitir que un asistente lea contenido que el usuario solicitante nunca debería ver. El Kiteworks Secure MCP Server aborda ese riesgo aplicando control de acceso basado en roles y atributos y autenticación OAuth a las solicitudes MCP, con cada solicitud registrada en el plano de control de Kiteworks.

La paridad humana es la prueba que conviene aplicar a cada implementación de agentes. Si un empleado humano no podría abrir un archivo, el agente que actúe en su nombre tampoco debería poder. Si una acción humana se registra con identidad y marca de tiempo, la del agente también. Si una persona necesita un motivo de negocio documentado para exportar un registro, el agente igual. Bajo este modelo, un inspector que pregunte por el acceso a datos de un agente recibe el mismo tipo de respuesta que si preguntara por un empleado.

Este enfoque también contiene el coste de cumplimiento de la adopción de agentes. En vez de construir un marco de control a medida para cada nueva herramienta de IA, los equipos de seguridad amplían los controles existentes en la capa de datos, usando control de acceso basado en roles y control de acceso basado en atributos, para cubrir una nueva clase de solicitante.

Cómo Kiteworks Apoya la Preparación para Auditorías en el Acceso a Datos de IA

Kiteworks no posee una certificación de la Ley de IA de la UE, y ningún proveedor puede hacer que una organización cumpla el decreto por sí solo. Lo que Kiteworks ofrece es control y evidencia sobre cómo los sistemas de IA acceden a contenido sensible, la capa que examinarán los inspectores.

Kiteworks Compliant AI gobierna el acceso de IA en la capa de datos. Cada solicitud de IA se autentica mediante OAuth 2.0 con una identidad vinculada a la persona que la autorizó, así que la responsabilidad no se diluye en una cuenta de servicio compartida. El control de acceso basado en atributos se evalúa a nivel de operación, lo que significa que la decisión de política aplica a lo que el sistema intenta hacer con un contenido específico, no solo a si puede conectarse. El contenido se protege con cifrado validado FIPS 140-3 y la actividad se registra en un rastro de auditoría resistente a manipulaciones que puede enviarse a un SIEM para correlacionar con otros eventos de seguridad. Descubre más sobre el cumplimiento FIPS 140-3 y cómo se aplica a la protección de datos.

Comparado con las categorías de evidencia anteriores, este diseño ayuda a demostrar identidad del actor, alcance del acceso y decisiones a nivel de operación mediante un solo registro. El rastro resistente a manipulaciones responde a la cuestión de integridad de la evidencia, y la integración con SIEM cubre la gestión de incidentes. Como el control se sitúa en la ruta de intercambio de datos y no dentro de un solo producto de IA, el mismo registro puede cubrir varias herramientas de IA, lo que importa si tu organización usa más de una.

Las organizaciones de servicios financieros, donde el Banco de Italia, CONSOB e IVASS mantienen un rol supervisor bajo el decreto, verán que DORA y marcos similares ya exigen evidencia sólida de terceros e ICT. Una capa común de datos para el acceso de IA permite que un solo conjunto de registros sirva a varios reguladores. Los organismos públicos que implementan IA pueden aplicar el mismo enfoque al lado del intercambio de datos de ese trabajo.

El límite honesto es que los controles de producto no sustituyen las decisiones de gobernanza. Aún tienes que clasificar tus sistemas de IA, decidir cuáles son de alto riesgo, definir los propósitos permitidos y asignar responsables. La tecnología hace que esas decisiones sean aplicables y demostrables. No puede tomarlas por ti.

Un Plan Práctico de Preparación para CISOs y CCOs

Un decreto que entra en vigor mientras los actos clave de implementación siguen sin escribir premia a las organizaciones que se preparan para el tipo de supervisión probable en vez de esperar cada detalle. La siguiente secuencia funciona independientemente de cómo se resuelvan los puntos abiertos.

1. Haz inventario de sistemas de IA y sus rutas de datos. Enumera cada sistema de IA, agente e integración en uso o en pruebas, incluyendo los introducidos por unidades de negocio individuales. Para cada uno, registra a qué datos puede acceder y por qué vía.
2. Clasifica según la Ley de IA. Determina cuáles pueden ser de alto riesgo, incluyendo los de infraestructuras críticas bajo el punto 2 del Anexo III, ya que estos llevan una obligación nacional de registro a través de ACN según el artículo 14.
3. Vincula cada actor de IA a una persona responsable. Sustituye cuentas de servicio compartidas por identidades vinculadas a un autorizador nombrado, para que cada acción se rastree hasta alguien que pueda explicarla.
4. Lleva las decisiones de acceso a la capa de datos. Aplica la política en cada operación sobre contenido sensible, no solo en el límite de la aplicación, y aplica la misma política a agentes y personas.
5. Unifica el rastro de auditoría. Dirige los registros de acceso de IA a un registro resistente a manipulaciones y envíalo a tu SIEM para que inspectores y tus propios equipos vean el mismo registro.
6. Ensaya una solicitud sin aviso. Realiza un simulacro donde un inspector pide la evidencia de pruebas de un sistema de alto riesgo en un día. Mide cuánto tardas y corrige las brechas que detecte el ejercicio.
7. Mapea reguladores y sigue los puntos abiertos. Documenta qué autoridad o supervisor sectorial aplica y mantente atento al decreto sobre modalidades de inspección, el grupo sandbox y cualquier guía del Omnibus.

Para organizaciones que mueven datos entre países, una revisión de soberanía de datos debe incluirse en el primer paso, ya que las pruebas de IA que envían datos italianos a un modelo alojado en otro lugar plantean cuestiones tanto de la Ley de IA como de transferencias.

Italia ha hecho de la supervisión de IA una cuestión de autoridades nombradas, facultades de inspección y sanciones, y la evidencia que buscarán está en tu capa de datos. Para ver cómo un registro unificado y resistente a manipulaciones del acceso a datos de IA puede apoyar tu preparación, agenda una demo con Kiteworks.

Recursos adicionales

• Artículo del Blog
  Estrategias Zero‑Trust para una protección asequible de la privacidad en IA
• Artículo del Blog
  Cómo el 77% de las organizaciones falla en la seguridad de datos de IA
• eBook
  Brecha en la gobernanza de IA: Por qué el 91% de las pequeñas empresas juega a la ruleta rusa con la seguridad de datos en 2025
• Artículo del Blog
  No existe «–dangerously-skip-permissions» para tus datos
• Artículo del Blog
  Los reguladores ya no preguntan si tienes una política de IA. Quieren pruebas de que funciona.