El EU AI Act genera mucha ansiedad. Los equipos leen el texto, encuentran frases como "sistema de IA de alto riesgo", "evaluación de conformidad" y "obligaciones de monitorización post-comercialización", y rápidamente llaman a su asesoría legal.
Esa ansiedad es comprensible pero en gran parte está fuera de lugar. El EU AI Act, en su esencia, pide cosas que cualquier sistema de IA serio en producción debería estar haciendo de todos modos. El reto no es entender qué se requiere, sino traducir el lenguaje regulatorio en decisiones de ingeniería.
Empieza con la clasificación de riesgo
Lo primero que pide el EU AI Act es: ¿en qué categoría cae tu sistema de IA? La ley define cuatro niveles de riesgo, y cuál aplica a tu sistema determina casi todo lo demás.
Riesgo inaceptable está directamente prohibido. Vigilancia biométrica en tiempo real en espacios públicos, sistemas de puntuación social, IA que explota vulnerabilidades psicológicas para manipular el comportamiento. Si estás construyendo uno de estos, tienes problemas mayores que el compliance.
Alto riesgo es donde vive la mayor parte del trabajo de compliance. Incluye sistemas de IA usados en infraestructura crítica, decisiones de empleo, evaluaciones de crédito, sanidad, aplicación de la ley, control de fronteras y administración de justicia. Si tu sistema toca alguno de estos dominios, la ley impone requisitos significativos en materia de documentación, logging, supervisión humana y gestión de riesgos.
Riesgo limitado aplica a sistemas que interactúan con usuarios de maneras que requieren transparencia. Los chatbots deben declarar que son IA. Los deepfakes requieren etiquetado. Los requisitos aquí son manejables y en gran parte ya se consideran buenas prácticas.
Riesgo mínimo cubre todo lo demás: filtros de spam, recomendaciones con IA, la mayoría de herramientas B2B de propósito general. En gran medida no regulado más allá de la legislación existente.
La mayoría de sistemas de IA enterprise que manejan dominios sensibles (sanidad, finanzas, legal, RRHH) caen en la categoría de alto riesgo. Ahí es donde está el trabajo, y en eso se centra este artículo.
Qué requiere realmente el alto riesgo
Para sistemas de alto riesgo, el EU AI Act define seis requisitos que se mapean limpiamente a controles de ingeniería cuando se despoja el lenguaje regulatorio.
Sistema de gestión de riesgos
Identificación y mitigación continua de riesgos a lo largo del ciclo de vida del sistema. En la práctica, significa un proceso documentado para identificar qué puede salir mal y controles que aborden cada riesgo identificado.
Traducción de ingeniería: Threat modeling para tu pipeline de IA. ¿Cuáles son las formas en que este sistema podría causar daño? Documéntalas. Construye controles que las aborden. Revisa y actualiza la documentación cuando el sistema cambia.
Gobernanza de datos
Los datos de entrenamiento deben ser relevantes, representativos y libres de errores que podrían producir resultados discriminatorios. Para sistemas que usan modelos de terceros, esto se traslada a asegurar que los inputs que envías son apropiados y que usas los modelos para sus propósitos previstos.
Traducción de ingeniería: Validación de inputs. Gestión de PII antes de que las requests salgan de tu infraestructura. Documentación de qué modelos usas, para qué propósitos y con qué limitaciones conocidas.
Documentación técnica
Documentación detallada del diseño del sistema, capacidades, limitaciones y casos de uso previstos. Es tanto un requisito de compliance como un mecanismo útil de reflexión: los equipos que documentan bien sus sistemas de IA tienen menos sorpresas operativas.
Traducción de ingeniería: Documentación de arquitectura. Model cards para cada modelo que uses. Documentación explícita de lo que el sistema está diseñado para hacer y qué está explícitamente fuera de alcance.
Logging y registro
El sistema debe registrar eventos con suficiente detalle para permitir investigación a posteriori y demostrar compliance. "Detalle suficiente" significa que puedes reconstruir qué pasó, por qué y cuál fue el resultado.
Traducción de ingeniería: Audit trail estructurado. Cada request registrada con timestamp, inputs o hashes, outputs, reglas evaluadas, decisiones tomadas y la versión de política activa en ese momento.
Transparencia hacia los usuarios
Los usuarios deben ser informados de que están interactuando con un sistema de IA y recibir suficiente información para entender sus capacidades y limitaciones.
Traducción de ingeniería: Declaraciones en la UI. Mensajes de error que expliquen cuándo el sistema no puede ayudar. Documentación accesible para los usuarios sobre cómo funciona el sistema.
Supervisión humana
Los sistemas de alto riesgo deben diseñarse para permitir supervisión humana, incluyendo la capacidad de anular o apagar el sistema.
Traducción de ingeniería: Circuit breakers. Controles de administrador para deshabilitar features o restringir outputs. Rutas de escalado para casos extremos que el sistema no puede manejar adecuadamente.
La capa de runtime es donde vive el compliance
Aquí está la visión que cambia cómo piensas sobre el compliance con el EU AI Act: la mayoría de estos requisitos no tratan sobre cómo construyes el modelo. Tratan sobre cómo lo operas.
Gestión de riesgos, logging, supervisión, gobernanza de datos: todas son preocupaciones operativas. Ocurren en runtime, en cada request. Esto significa que el compliance no es un ejercicio de certificación puntual. Es algo que tu pipeline hace o no hace en cada request que fluye por él.
| Tipo de sistema | Riesgo habitual | Obligaciones mínimas |
|---|---|---|
| Chatbot informativo general | Limitado / mínimo | Transparencia de IA, logging básico, guardrails |
| Asistente en soporte con datos personales | Limitado / alto | Gestión de PII, audit trail por request, políticas por tenant |
| Sistema de scoring para empleo o finanzas | Alto | Gestión de riesgos, evidencia estructurada, supervisión humana |
| Asistente clínico con datos de salud | Alto | Controles PHI, revisión humana, trazabilidad completa |
Puntos de partida prácticos
Semana 1. Clasifica tus casos de uso de IA por nivel de riesgo. Sé honesto sobre cuáles tocan dominios de alto riesgo. Documenta la lista. Si la clasificación es incierta, asume temporalmente el nivel más exigente y recorta después con evidencia.
Semana 2. Audita tu logging actual. Para casos de uso de alto riesgo, ¿puedes responder: cómo era esta request, qué devolvió el modelo y qué ocurrió como resultado? Si no, ese es el hueco que hay que cerrar primero.
Semana 3. Implementa controles de input. Para casos de uso de alto riesgo, añade detección de PII, escaneo de prompt injection y evaluación de políticas de compliance al pipeline antes de que las requests lleguen a ningún modelo.
Semana 4. Documenta todo. Qué modelos usas, para qué propósitos, con qué limitaciones. Esta documentación es tanto un requisito de compliance como un mecanismo útil de reflexión para el equipo.
Lo que realmente pide el EU AI Act
La regulación no intenta impedirte construir IA. Intenta asegurar que los sistemas de IA que operan en dominios de alto riesgo están diseñados y operados de forma responsable. La mayoría de lo que requiere (logging, supervisión, documentación, gestión de riesgos) deberías estar haciéndolo de todos modos si operas IA en producción a cualquier escala significativa.
Los equipos que lo gestionan bien son los que tratan el compliance como una disciplina operativa y no como un ejercicio legal. Instrumentan sus pipelines, documentan sus sistemas y revisan sus controles regularmente. La regulación les da un marco y una fecha límite. La disciplina es suya construirla.