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.
Antes, tres datos de contexto que conviene tener claros.
Lo esencial antes de empezar
A quién aplica. 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 de entrenamiento, validación y prueba: relevancia, representatividad, ausencia de errores y atención a posibles sesgos.[5:1]
Qué significa en la práctica: tienes que poder demostrar que tus datos —incluidos los de prueba— son adecuados y que miras activamente el sesgo. Aquí entran los datasets de evaluación bien construidos.
Artículo 11 — Documentación técnica
Requiere documentación detallada que demuestre que el sistema cumple los requisitos, elaborada antes de salir al mercado y mantenida actualizada.[5:2]
Qué significa en la práctica: la documentación tiene que apoyarse en evidencia real —resultados de pruebas, métricas— no en afirmaciones. Un reporte de evaluación es parte del insumo.
Artículo 12 — Registro (record-keeping)
Obliga al registro automático de eventos (logs) durante el funcionamiento del sistema, para garantizar trazabilidad a lo largo del ciclo de vida.[5:3]
Qué significa en la práctica: tienes que poder reconstruir qué hizo el sistema y cuándo. Un historial de evaluaciones —idealmente inmutable— contribuye directamente a esta trazabilidad.
Artículo 13 — Transparencia e información
Los sistemas deben diseñarse y documentarse de forma que usuarios, reguladores y auditores entiendan sus capacidades, límites y lógica de decisión. Incluye explicabilidad y divulgación de que se trata de una IA.[6]
Qué significa en la práctica: las puntuaciones de tus evaluaciones deben ser explicables —no un número opaco— y debe quedar claro qué mide cada una.
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.[7]
Qué significa en la práctica: este es uno de los artículos donde el testing aporta evidencia más directa. Verificar que tu agente deriva a un humano cuando corresponde —y medir con qué frecuencia lo hace bien— es demostrar supervisión humana en acción.
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 pruebas de fairness |
| 11 — Documentación técnica | Demostrar conformidad | Reportes de evaluación con métricas |
| 12 — Registro | Logs automáticos, trazabilidad | Historial inmutable de evaluaciones |
| 13 — Transparencia | Explicabilidad de capacidades y límites | Puntuaciones explicables por dimensión |
| 14 — Supervisión humana | Control humano y posibilidad de intervenir | Medición de la derivación correcta a un humano |
| 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: casi todo el cuerpo técnico del EU AI Act se satisface produciendo evidencia de evaluación. La norma define qué hay que demostrar; el testing es lo que produce la demostración.
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) 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 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
En la capa de evidencia. ArtificialQA conecta a tu agente de IA —por URL o por API, sin código— y produce exactamente las mediciones que el cuerpo técnico del reglamento pide: exactitud factual (Art. 15), pruebas de sesgo (Art. 10), derivación a un humano (Art. 14), puntuaciones explicables (Art. 13) y un historial de evaluaciones que aporta trazabilidad (Art. 12). Y como calibra a sus propios jueces de IA, los números que entrega resisten el escrutinio de una auditoría —que es, al final, de lo que se trata todo esto.
No es magia ni un atajo legal: ninguna herramienta te “certifica” el cumplimiento por sí sola, y la conformidad formal involucra también evaluación de conformidad, declaración UE y otros pasos que exceden al testing. Pero la evidencia medible 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. El testing produce la evidencia técnica que exigen los Artículos 9 a 15, pero la conformidad formal incluye además evaluación de conformidad, documentación y otros pasos. El testing es 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.
