El EU AI Act genera mucha ansiedad. Los equipos leen el texto, ven 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 su mayor 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, es traducir el lenguaje regulatorio en decisiones de ingeniería.
Así es cómo hacerlo.
En 30 segundos
El EU AI Act no se resuelve con un documento legal, se resuelve con controles operativos por request. Si puedes mapear riesgo, evidencia y supervisión a runtime, puedes ejecutar sin drama.
Qué te llevas en este artículo:
- Cómo clasificar casos de uso de forma práctica
- Qué controles exige realmente el alto riesgo
- Una matriz directa para pasar de teoría a implementación
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:
Riesgo inaceptable, prohibido directamente. Vigilancia biométrica en tiempo real en espacios públicos, sistemas de puntuación social, IA que explota vulnerabilidades para manipular el comportamiento. Si estás construyendo uno de estos, tienes problemas mayores que el compliance.
Alto riesgo, la categoría que requiere más trabajo. Incluye sistemas de IA usados en infraestructura crítica, decisiones de empleo, decisiones de crédito, sanidad, aplicación de la ley, control de fronteras y administración de justicia. Si tu sistema toca cualquiera de estas áreas, la ley impone requisitos significativos.
Riesgo limitado, 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.
Riesgo mínimo, todo lo demás. Filtros de spam, listas de reproducción con IA, la mayoría de las herramientas B2B. En gran medida no regulado más allá de la ley existente.
La mayoría de los 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.
Matriz rápida: tipo de sistema y obligaciones mínimas
| Tipo de sistema | Riesgo habitual | Obligaciones mínimas recomendadas |
|---|---|---|
| Chatbot informativo general | Limitado / mínimo | Transparencia de IA, logging básico, guardrails de contenido |
| Asistente en soporte con datos personales | Limitado / alto (según uso) | Gestión de PII, audit trail por request, políticas por tenant |
| Sistema de scoring o recomendación en empleo/finanzas | Alto | Gestión de riesgos, evidencia estructurada, supervisión humana, controles de override |
| Asistente clínico con datos de salud | Alto | Controles de PHI/PII, revisión humana, trazabilidad completa, gobierno de datos estricto |
Qué requiere realmente el alto riesgo
Para sistemas de alto riesgo, el EU AI Act requiere seis cosas que se mapean limpiamente a controles de ingeniería:
1. 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: un proceso documentado para identificar qué puede salir mal, y controles que aborden cada riesgo.
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.
2. Gobernanza de datos Los datos de entrenamiento deben ser relevantes, representativos y libres de errores que podrían crear resultados discriminatorios. Para sistemas que usan modelos de terceros, esto se traslada a asegurar que los inputs que envías son apropiados y que estás usando los modelos para sus propósitos previstos.
Traducción de ingeniería: Validación de inputs. Gestión de PII. Documentación de qué modelos usas y para qué.
3. Documentación técnica Documentación detallada del diseño del sistema, capacidades, limitaciones y uso previsto.
Traducción de ingeniería: Documentación de arquitectura. Model cards para cada modelo que uses. Capacidades documentadas y casos de uso explícitamente fuera de alcance.
4. Logging y registro El sistema debe registrar eventos con suficiente detalle para permitir investigación a posteriori y demostrar compliance.
Traducción de ingeniería: Audit trail estructurado. Cada request registrada con timestamp, inputs (o hashes), outputs, reglas evaluadas, decisiones tomadas.
5. 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.
6. 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.
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, 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.
Una request que procesa datos de salud necesita evaluarse contra HIPAA y los requisitos del EU AI Act. Una request que hace una recomendación relacionada con contratación necesita marcarse como alto riesgo y registrarse con detalle adicional. Una request que un revisor humano necesita examinar tiene que generar una alerta, no solo un registro de auditoría.
Puntos de partida prácticos
Si estás intentando pasar de "deberíamos mirar el compliance con el EU AI Act" a "tenemos controles en lugar", por aquí puedes empezar:
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.
Semana 2: Audita tu logging actual. Para casos de uso de alto riesgo, ¿tienes un audit trail completo? ¿Puedes responder "¿cómo era esta request, qué devolvió el modelo y qué ocurrió como resultado?"
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 de requests.
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 útil mecanismo de reflexión.
Si tienes dudas de clasificación, asume temporalmente el nivel más exigente y recorta después con evidencia.
El Checklist
Para cada caso de uso de IA en tu sistema:
- Nivel de riesgo clasificado (inaceptable / alto / limitado / mínimo)
- Para alto riesgo: proceso de gestión de riesgos documentado
- Validación de inputs y gestión de PII en lugar
- Audit trail estructurado registrando cada request con suficiente detalle
- Transparencia hacia el usuario en lugar (declaración de IA, documentación de capacidades)
- Mecanismo de supervisión humana existente (controles de administrador, circuit breakers)
- Documentación técnica cubre diseño, capacidades y limitaciones
Qué hacer esta semana
- Clasifica cada caso de uso con un owner técnico responsable.
- Define controles mínimos por nivel de riesgo en una tabla interna.
- Valida en logs que cada request deja evidencia suficiente para auditoría.
El EU AI Act 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, deberías estar haciéndolo de todos modos.