La conversación sobre IA en la empresa ha ganado un nuevo interlocutor: el regulador. El EU AI Act ya no es un texto legal en preparación —es un régimen que se aplica por tramos y que afecta directamente a cualquier organización que despliegue equipos de agentes con capacidad de decisión sobre procesos internos o externos.
Este recurso no es asesoría jurídica; es cómo lo mapeamos en implantaciones reales cuando un cliente pregunta «¿cómo se hace esto de forma cumplible desde el principio?». La regla es sencilla: si dejas el cumplimiento para después, lo pagas dos veces —una en re-trabajo, otra en auditoría.
01Qué es alto riesgo, y cuándo un equipo de agentes lo es
El AI Act clasifica los sistemas por riesgo. Un equipo de agentes suele caer en dos casillas: uso general —cuando asiste sin decidir— o alto riesgo cuando decide sobre acceso a servicios, contratación, valoración crediticia, evaluación de personas o cualquier proceso listado en el Anexo III.
El criterio operativo que usamos: si la decisión del agente afecta a un derecho o a un resultado material sin control humano intermedio, es alto riesgo. Si solo prepara la decisión y una persona la aprueba, el marco es más laxo pero la trazabilidad sigue siendo obligatoria.
- Alto riesgo: aprobación de crédito automatizada, priorización de currículums, detección de fraude sin revisión.
- Riesgo limitado: chatbots de atención al cliente, generación de contenido interno con supervisión.
- Riesgo mínimo: asistentes de redacción, sugerencias de código en IDE.
02Requisitos concretos que hay que traducir a plataforma
El texto legal habla de gestión de riesgos, gobernanza de datos, documentación técnica, transparencia, supervisión humana, precisión y ciberseguridad. En una implantación real, eso se traduce a decisiones concretas de arquitectura antes de escribir la primera línea de código del agente.
| Requisito AI Act | Decisión operativa |
|---|---|
| Gestión de riesgos | Registro de qué falla cada agente, cómo se detecta, cuándo escala |
| Gobernanza de datos | De qué fuentes lee cada agente, cómo se validan, qué retención |
| Documentación técnica | Cada versión firmada, con changelog y evaluación |
| Transparencia | El usuario final sabe que interactúa con un sistema, no con una persona |
| Supervisión humana | Puntos de aprobación explícitos según criticidad de la acción |
| Precisión y robustez | Evaluación continua contra baseline, no solo en el piloto |
| Ciberseguridad | Perímetro definido, permisos heredados, secretos rotados |
03Cómo mapea al modelo operativo
Un equipo de agentes cumplible se diseña desde tres capas: identidad, orquestación y observación. La identidad define qué puede tocar cada agente heredando permisos corporativos. La orquestación decide quién ejecuta qué y cuándo pide aprobación humana. La observación captura toda decisión y acción en trazas auditables.
El cumplimiento no es un módulo que se enchufa al final: es la manera en que están conectadas las tres capas. Si la trazabilidad depende de una integración a posteriori, ya has perdido.
04Evidencias auditables: qué guardar, dónde y con qué retención
El regulador no pregunta «¿tienes trazas?»; pregunta «¿puedes reconstruir por qué el agente hizo X en el momento Y con estos datos Z?». La diferencia es enorme. Las trazas de log genérico no bastan; hace falta linaje de decisión.
Contexto
Prompt completo, datos recuperados y sus fuentes
Decisión
Qué acción se seleccionó y qué alternativas se descartaron
Aprobación
Si hubo un humano en el bucle, quién y cuándo
Resultado
Efecto en el sistema y confirmación de éxito o error
Retención mínima para sistemas de alto riesgo: seis meses accesibles y hasta diez años en frío para acciones críticas. Formato: estructurado y consultable, no logs sueltos por servicio.
05Errores comunes en la asesoría legal genérica
- Confundir el AI Act con el RGPD. Uno regula el sistema, el otro los datos —los dos aplican en paralelo.
- Asumir que si el modelo es de un tercero (Anthropic, OpenAI) la responsabilidad se traslada. No es así: quien despliega es el «usuario» del sistema y responde por su uso.
- Documentar en Word y guardarlo en SharePoint. La documentación técnica exigida es viva y versionada, no un PDF una vez al año.
- Tratar «supervisión humana» como «que un humano pueda leer las trazas». Supervisión significa puntos de aprobación y capacidad de detener el sistema en tiempo real.
06Checklist ejecutivo: ocho preguntas antes de una auditoría
- ¿Sabemos en qué categoría de riesgo cae cada agente en producción?
- ¿Existe un responsable único de cumplimiento por sistema, no diluido en el equipo?
- ¿Podemos mostrar cada decisión con su contexto y su alternativa descartada?
- ¿Los puntos de aprobación humana están registrados y son testables?
- ¿La documentación técnica está versionada y accesible sin depender de una persona?
- ¿Los datos de entrenamiento o fine-tuning tienen linaje declarado?
- ¿Hay un plan escrito para incidentes: quién decide detener, cómo se notifica?
- ¿La evaluación de precisión y sesgo es continua o se hizo solo en el piloto?