EU AI Act para equipos técnicos: qué exige en testing y evidencia
Qué exige el EU AI Act en materia de testing y evidencia, explicado para los equipos técnicos que tienen que cumplirlo.
El Reglamento de IA de la Unión Europea (EU AI Act) suele leerse como un texto legal denso, pensado para abogados. Pero buena parte de lo que exige para los sistemas de alto riesgo no es trabajo jurídico: es trabajo de ingeniería y de QA. Risk management, logging, pruebas de exactitud, supervisión humana, robustez. Esta guía traduce esa parte (los Artículos 9 a 15, el corazón técnico de la norma) a lo que un equipo técnico tiene que poder hacer y demostrar. Es, en la práctica, la cara obligatoria de la IA responsable: lo que hay que poder probar, no solo declarar.
Antes, tres datos de contexto que conviene tener claros.
Lo esencial antes de empezar
A quién aplica. Es un reglamento de la Unión Europea, pero no aplica solo a empresas europeas: alcanza a cualquier proveedor, esté donde esté, si pone su sistema de IA en el mercado de la UE o si el resultado de ese sistema se usa ahí, aunque la empresa no tenga oficinas ni vínculo comercial formal con Europa. Es un alcance parecido al del RGPD (el Reglamento General de Protección de Datos, la ley europea de privacidad, conocida en inglés como GDPR). Dentro de ese universo, las obligaciones más exigentes recaen sobre los sistemas de IA de alto riesgo, los del Anexo III: infraestructura crítica, educación, empleo, acceso a servicios esenciales (incluido el crédito), aplicación de la ley, migración, entre otros.[1] Si tu IA toma o influye en decisiones en alguno de esos terrenos, probablemente entres en esta categoría.
Para cuándo. La fecha de aplicación para sistemas de alto riesgo del Anexo III es el 2 de agosto de 2026.[2] Importante y en movimiento: en noviembre de 2025 la Comisión Europea propuso, mediante el paquete “Digital Omnibus”, flexibilizar algunos plazos (con un acuerdo político alcanzado en mayo de 2026), pero al momento de escribir esto la medida seguía en proceso legislativo y los analistas recomiendan planificar como si agosto de 2026 fuera la fecha firme.[3]
Qué pasa si no cumples. Las sanciones escalan por tramos: hasta 35 millones de euros o el 7% de la facturación global anual para las infracciones más graves (prácticas prohibidas), y montos menores para incumplimientos de alto riesgo o información incorrecta.[4] Las autoridades también pueden retirar el sistema del mercado europeo.
Con eso en mente, el recorrido por los siete artículos técnicos.
Artículo 9: Sistema de gestión de riesgos
Exige un proceso continuo y sistemático de identificación, análisis, evaluación y control de riesgos a lo largo de todo el ciclo de vida del sistema, incluido el monitoreo posterior al despliegue.[5]
Qué significa en la práctica: no es un documento que se redacta una vez. Es un proceso vivo en el que identificas los riesgos de tu IA (por ejemplo, que alucine en un dominio crítico o que discrimine), los mides, los mitigas y vuelves a medir. La evaluación sistemática de calidad es, literalmente, el motor de este artículo.
Artículo 10: Datos y gobernanza de datos
Pide medidas de calidad sobre los datos usados para desarrollar el sistema: relevancia, representatividad, ausencia de errores y atención a posibles sesgos. Esto aplica a los datos de entrenamiento, validación y prueba, cuando el sistema efectivamente entrena un modelo con esos datos.[5:1]
Qué significa en la práctica: si tu empresa construye su agente sobre un modelo ya entrenado (GPT, Claude, u otro) sin entrenar el suyo propio, que es el caso de la mayoría de los agentes conversacionales hoy, la norma misma reconoce esa diferencia: el Artículo 10(6) aclara que en esos casos las exigencias de calidad aplican solo a los datos de prueba, no a datos de entrenamiento que la empresa ni siquiera tiene. En la práctica, para buena parte de quienes testean con ArtificialQA, el Art. 10 se reduce casi enteramente a esto: tener datasets de prueba bien construidos, representativos y con atención al sesgo.
Artículo 11: Documentación técnica
Exige una documentación técnica completa, que el Anexo IV desglosa en nueve secciones, elaborada antes de salir al mercado y mantenida actualizada durante toda la vida del sistema. Dos de esas secciones son directamente sobre pruebas: una pide las métricas de exactitud y robustez junto con los registros y reportes de cada prueba, fechados y firmados por los responsables; otra pide un sistema de monitoreo posterior al mercado que recolecte y analice el desempeño de forma activa durante toda la vida útil del sistema, con umbrales que disparen una corrección. Las otras siete secciones (descripción general, proceso de desarrollo, gestión de riesgos, cambios de versión, estándares aplicados y la declaración de conformidad) son responsabilidad del equipo que construye y documenta el sistema.[5:2]
Qué significa en la práctica: la documentación técnica no se completa una sola vez antes del lanzamiento. Necesita reportes de prueba fechados y firmados, y un proceso vivo de monitoreo continuo en producción, aunque el grueso del documento es trabajo del equipo de desarrollo, no de testing.
Artículo 12: Registro (record-keeping)
Obliga a que el propio sistema registre automáticamente los eventos de su funcionamiento real, sin intervención humana, durante toda su vida útil, para poder reconstruir qué hizo y cuándo ante una revisión.[5:3]
Qué significa en la práctica: esto es un requisito de ingeniería sobre el sistema en producción, el registro automático de las conversaciones y decisiones reales. Es distinto del historial de pruebas que arma un equipo de QA, y uno no reemplaza al otro: probablemente haga falta tener los dos.
Artículo 13: Transparencia e información
Exige que el sistema venga acompañado de instrucciones de uso claras para quien lo despliega: capacidades, límites, los niveles de exactitud con sus métricas (que remiten al Artículo 15), robustez, ciberseguridad y las medidas de supervisión humana. Es un documento que redacta y firma el proveedor del sistema.[6]
Qué significa en la práctica: ese documento necesita números reales para completarse, no estimaciones. Las métricas de exactitud, robustez y desempeño por grupo que arroja tu evaluación son un insumo para ese documento, no lo reemplazan ni lo redactan.
Artículo 14: Supervisión humana
Establece que los sistemas operen bajo control humano significativo: las personas que supervisan deben entender el sistema, poder intervenir y anular decisiones para prevenir o mitigar riesgos. La norma es específica en un punto: esa persona tiene que poder monitorear la operación del sistema y detectar anomalías o un desempeño inesperado, y mantenerse alerta ante la tendencia a confiar de más en lo que dice la IA.[7]
Qué significa en la práctica: acá hay dos ángulos de testing distintos. Uno es verificar que el propio agente deriva a un humano en los casos donde hacerlo es una medida de riesgo, no solo una preferencia del cliente (consultas sensibles, decisiones que el sistema no debería tomar solo), y medir con qué frecuencia lo hace bien. El otro es darle al humano responsable de supervisar el sistema información real y periódica de cómo viene respondiendo en cada corrida, para que pueda monitorear, detectar anomalías y decidir si interviene. Sin esa información, la supervisión humana que pide la norma queda en el papel.
Artículo 15: Exactitud, robustez y ciberseguridad
Exige que los sistemas alcancen niveles apropiados de exactitud, robustez y ciberseguridad a lo largo de su vida útil, resistan errores y ataques adversarios, y (dato clave) que los niveles y métricas de exactitud se declaren en las instrucciones de uso.[8]
Qué significa en la práctica: tienes que medir la exactitud de tu sistema y poder declararla con un número defendible. También probar su robustez ante entradas inesperadas o adversarias. Si la exactitud se degrada con el tiempo, debe detectarse y corregirse, lo que conecta de nuevo con el monitoreo continuo.[9]
El mapa completo: requisito → qué tienes que poder demostrar
| Artículo | Exige | Evidencia que lo respalda |
|---|---|---|
| 9: Gestión de riesgos | Proceso continuo de identificar/medir/mitigar | Evaluaciones sistemáticas y repetidas en el tiempo |
| 10: Datos | Calidad y atención al sesgo | Datasets de prueba (y solo de prueba, si no hay entrenamiento propio) |
| 11: Documentación técnica | Nueve secciones, dos sobre pruebas y monitoreo | Reportes de prueba fechados/firmados y corridas programadas en el tiempo |
| 12: Registro | Logs automáticos del sistema en producción | Requisito de ingeniería aparte, fuera del alcance de ArtificialQA |
| 13: Transparencia | Instrucciones de uso con niveles de exactitud declarados | Métricas que alimentan ese documento, sin redactarlo |
| 14: Supervisión humana | Control humano y posibilidad de intervenir | Derivación por riesgo, más reportes que sostienen el monitoreo del supervisor |
| 15: Exactitud y robustez | Niveles declarados, resistencia a fallos | Métricas de precisión y pruebas de robustez |
La lectura transversal de la tabla es la que importa: buena parte del cuerpo técnico del EU AI Act (sobre todo los Artículos 9, 10, 14 y 15) se satisface en gran medida produciendo evidencia de evaluación. Otros (11 y 13) se alimentan de esa evidencia, sin agotarse en ella. Y al menos uno (12) es un requisito de ingeniería aparte. La norma define qué hay que demostrar; el testing es una pieza central de esa demostración, no la única.
Una distinción que evita gastar de más
Cuando un equipo se enfrenta al EU AI Act por primera vez, suele confundir dos cosas que son distintas:
- Las plataformas de gobernanza (GRC, sigla en inglés de governance, risk and compliance: gobernanza, riesgo y cumplimiento) gestionan políticas, inventarios de sistemas, flujos de aprobación y documentación. Te ayudan a organizar el cumplimiento y a saber qué deberías probar.
- Las plataformas de evaluación generan la evidencia técnica: las mediciones de exactitud, alucinaciones, sesgo, robustez y derivación que los Artículos 9 a 15 exigen.
No son competidoras; son capas. Pero conviene no comprar una esperando que haga el trabajo de la otra. Una plataforma de GRC no va a medir si tu agente alucina; una plataforma de evaluación no va a gestionar tu registro de políticas.
Dónde encaja ArtificialQA
No en los siete artículos por igual. ArtificialQA conecta a tu agente de IA (por URL o por API, sin código) y cubre con solidez cuatro de los siete: ayuda a organizar qué probar por cada riesgo identificado como parte del sistema de gestión de riesgos del Artículo 9, no solo como evidencia posterior; prueba el sesgo y la exactitud de los datos sobre los datasets de prueba del Artículo 10; verifica la derivación a un humano por riesgo y aporta el historial que sostiene el monitoreo continuo del supervisor humano que pide el Artículo 14; y mide la exactitud y robustez que pide el Artículo 15.
En otros dos, aporta una parte, no el todo: sus reportes fechados alimentan dos de las nueve secciones de la documentación técnica del Artículo 11 (métricas de prueba y monitoreo post-mercado), y sus métricas de exactitud y desempeño son un insumo para las instrucciones de uso del Artículo 13, aunque ese documento lo redacta y firma el proveedor del sistema.
Hay uno que queda fuera: el registro automático del sistema en producción que pide el Artículo 12 es un requisito de ingeniería sobre el sistema en vivo, distinto del historial de pruebas de un equipo de QA.
Sus evaluadores de IA vienen calibrados de fábrica, contra el criterio de expertos humanos, así que los números que entrega resisten el escrutinio de una auditoría. Pero eso no alcanza para todo: ninguna herramienta te “certifica” el cumplimiento por sí sola, y la conformidad formal involucra también evaluación de conformidad, declaración UE, el registro automático del propio sistema y otros pasos que exceden al testing. Medir, revisar esos resultados y ajustar (el proceso continuo que exige el Artículo 9) es el cimiento sobre el que se construye todo lo demás, y es, justamente, la parte que un equipo técnico puede empezar a producir hoy, sin esperar a que se aclare cada detalle regulatorio.
Preguntas frecuentes
¿El EU AI Act me aplica si no estoy en Europa? Puede aplicarte si tu sistema de IA se usa o tiene efectos en el mercado de la UE, independientemente de dónde esté tu empresa. Verifica tu caso con asesoría legal.
¿Qué es un sistema de IA de “alto riesgo”? Son los sistemas listados en el Anexo III (usados en áreas como crédito, empleo, educación, salud o servicios esenciales) sobre los que recaen las obligaciones técnicas más exigentes (Artículos 9 a 15).
¿Cuándo entran en vigor las obligaciones de alto riesgo? La fecha de referencia es el 2 de agosto de 2026, aunque una propuesta de la UE (“Digital Omnibus”) podría flexibilizar ciertos plazos. Conviene verificar el estado vigente y planificar como si la fecha siguiera firme.
¿El testing alcanza para cumplir el EU AI Act? No por sí solo, y no cubre los siete artículos por igual. La evaluación sistemática (probar el sistema y puntuar sus resultados contra un criterio) produce la evidencia técnica que exigen sobre todo los Artículos 9, 10, 14 y 15, alimenta parte de lo que piden los Artículos 11 y 13, y no cubre el registro automático del Artículo 12. La conformidad formal incluye además evaluación de conformidad, documentación y otros pasos. El testing y la evaluación son el cimiento, no el edificio completo.
¿Cuáles son las sanciones por incumplir? Escalan por tramos, hasta 35 millones de euros o el 7% de la facturación global anual para las infracciones más graves, con montos menores para otros incumplimientos. Las autoridades también pueden retirar el sistema del mercado.
Product Manager de ArtificialQA en QAlified, con más de 15 años en testing y automatización de software. Trabaja en la intersección entre calidad e IA: diseña y evalúa enfoques para probar sistemas no deterministas y asegurar su comportamiento en producción.
