La legislación de IA europea ya está en vigor. ¿Puedes responder estas cinco preguntas?
El EU AI Act lleva en vigor desde agosto de 2024. Las prácticas prohibidas expiraron en agosto de 2025. Las obligaciones para IA de alto riesgo entran en vigor en agosto de 2026. Si despliegas sistemas de IA en Europa — o procesas datos de ciudadanos europeos — el reloj ya está corriendo.
La mayoría de las organizaciones siguen tratando el AI Act como un documento de cumplimiento para leer y firmar. Lo han asignado a legal, lo han marcado como "en revisión" y han seguido adelante. Es el enfoque equivocado.
El AI Act no es principalmente un texto legal. Es un conjunto de obligaciones operativas. Y la forma más rápida de saber si realmente cumples — no sobre el papel, sino operativamente — es responder cinco preguntas concretas sobre cada sistema de IA que gestionas.
Si no puedes responder las cinco, tienes trabajo pendiente antes de agosto.
Por qué estas cinco preguntas
El reglamento tiene más de 180 artículos. Pero enterrada en las disposiciones de gestión de riesgos, las obligaciones de transparencia, los requisitos de supervisión humana y el marco de responsabilidad hay una estructura subyacente consistente: los sistemas de IA deben ser gobernables. No solo seguros en abstracto — activamente gobernables por personas identificables, con procesos definidos, comportamiento auditable y una cadena de responsabilidad clara.
Esa estructura se reduce a cinco preguntas. No son mías — son las que cualquier regulador, auditor o abogado hará primero cuando algo salga mal. Deberías poder responderlas antes de que algo salga mal.
Pregunta 1: ¿A qué datos accede y qué datos puede cambiar?
Parece obvio. Rara vez lo es.
En la práctica, la mayoría de los equipos que despliegan sistemas de IA tienen una respuesta razonable para "¿qué datos lee?" (datos de entrenamiento, datos de entrada, quizás un corpus de recuperación), pero una respuesta mucho más difusa para "¿qué datos puede escribir, modificar o provocar cambios?"
Los sistemas agénticos empeoran esto. Un agente que envía correos electrónicos, actualiza registros de CRM, llama a APIs o modifica configuraciones tiene acceso de escritura a sistemas reales. Las disposiciones de gobernanza de datos del AI Act (artículos 10 y 13) exigen documentar la procedencia de los datos de entrenamiento, el alcance de los datos de entrada y — crucialmente — qué estado del sistema puede modificar el sistema de IA.
Qué significa el cumplimiento: un mapa de datos mantenido por cada despliegue de IA. Fuentes de entrada (con controles de acceso documentados), destinos de salida (con permisos de escritura documentados) y una distinción clara entre rutas de lectura y escritura.
El gap más común: se han documentado las entradas pero no lo que ocurre aguas abajo de las salidas de la IA. Si tu IA recomienda algo y un humano hace clic en aprobar, ¿el clic del humano cuenta como la escritura? Legalmente: a veces sí, a veces no. Necesitas saber cuál es tu caso.
Pregunta 2: ¿Quién lo supervisa?
El AI Act requiere supervisión humana para sistemas de IA de alto riesgo (artículo 14). No "los humanos pueden revisar los resultados si quieren." Supervisión humana definida — un rol nombrado con responsabilidad de monitorizar el comportamiento del sistema, revisar decisiones marcadas y la autoridad para anular o detener.
Esta pregunta tiene dos capas:
Supervisión operativa: ¿quién monitoriza el sistema día a día? ¿Quién recibe la alerta cuando la tasa de errores sube? En la mayoría de las organizaciones, esto es una función de guardia de ingeniería. Está bien, pero tiene que ser explícito. "El equipo lo monitoriza" no es suficiente — el equipo no es una entidad legal y no tiene autoridad.
Supervisión de gobernanza: ¿quién tiene autoridad para modificar los parámetros del sistema, reentrenar el modelo o apagarlo? Para industrias reguladas esto se mapea en estructuras de gobernanza existentes (comités de riesgo, responsables de cumplimiento). Para startups a menudo no se mapea en nadie, lo que es un problema.
Qué significa el cumplimiento: para cada sistema de IA, un individuo nombrado o rol con responsabilidades de supervisión documentadas y la autoridad real (acceso, herramientas, proceso) para ejecutarlas. No un RACI que apunta a "Ingeniería" — una persona, o un rol claramente definido, con responsabilidad real.
La Oficina de IA y las autoridades nacionales de vigilancia del mercado — AESIA en España — son la capa supervisora por encima de tu gobernanza interna. No son abstractas. Están construyendo activamente capacidad de aplicación.
Pregunta 3: ¿Dónde guarda la información?
El RGPD y el AI Act se superponen significativamente aquí. Las obligaciones de transparencia y los requisitos de gobernanza de datos del AI Act presuponen que puedes responder dónde se persisten las entradas del modelo, las salidas y los estados intermedios.
Esto se complica rápidamente para sistemas que usan proveedores de modelos de terceros, generación aumentada por recuperación con bases de datos vectoriales externas, modelos ajustados hospedados por proveedores cloud, o arquitecturas multi-agente donde un agente traspasa contexto a otro.
Qué significa el cumplimiento: residencia de datos documentada para cada almacén persistente que toca el sistema de IA. Esto incluye: datos de entrada, datos de salida, historial de conversaciones o estado de sesión si se retiene, embeddings en una base de datos vectorial, datos de entrenamiento de fine-tuning, registros de auditoría.
Para IA de alto riesgo, los datos deben retenerse de forma que permita auditoría post-hoc. Necesitas poder reconstruir qué hizo el sistema con qué datos, para una decisión específica, en una fecha específica.
La pregunta del proveedor cloud: si usas un proveedor de LLM con sede en EEUU sin residencia de datos en la UE, la cuestión de adónde van los datos en tránsito está viva. La mayoría de los equipos de ingeniería nunca han leído los addenda de tratamiento de datos de sus contratos.
Pregunta 4: ¿Quién responde si se equivoca?
El marco de responsabilidad del AI Act, combinado con la pendiente Directiva de Responsabilidad de IA, está diseñado para responder esto a nivel macro. Pero la pregunta práctica es interna: antes de que el regulador pregunte, ¿lo sabe tu organización?
Hay tres roles de responsabilidad en la estructura del AI Act:
Proveedor: la organización que desarrolla o pone en el mercado un sistema de IA. Si ajustas un modelo, construyes un producto sobre un modelo o desarrollas una herramienta de IA para que otros la usen, probablemente eres proveedor.
Responsable del despliegue: la organización que pone un sistema de IA en uso en un contexto específico. Si usas el producto de un proveedor de IA dentro de tus operaciones empresariales, eres responsable del despliegue.
La mayoría de las organizaciones son tanto proveedores (de sus propias herramientas de IA) como responsables del despliegue (de IA de terceros). La división de obligaciones entre ellos importa: los proveedores son responsables de la seguridad de diseño fundamental del sistema; los responsables del despliegue son responsables del contexto de despliegue apropiado y la supervisión.
Qué significa el cumplimiento: asignación documentada de obligaciones entre tu organización y tus proveedores de IA. Tus contratos enterprise deberían especificar quién es el proveedor de referencia para cada sistema.
El gap real: la mayoría de las organizaciones no ha tenido todavía la conversación de responsabilidad con sus proveedores de IA. El contrato se firmó, la clave API está en producción y nadie ha asignado formalmente quién responde ante el regulador.
Pregunta 5: ¿Cómo se apaga si empieza a funcionar mal?
Esta es la pregunta que más equipos encuentran difícil de responder, no porque el mecanismo no exista, sino porque nunca se ha diseñado explícitamente.
El artículo 9 (gestión de riesgos) y el artículo 14 (supervisión humana) juntos requieren que los sistemas de IA de alto riesgo tengan procedimientos definidos para detener la operación cuando se superan los umbrales de seguridad o precisión. Esto no es "puedes apagar el servidor." Significa:
- Detección: ¿cómo sabes que se está comportando mal? ¿Qué métrica, alerta o proceso de revisión hace aflorar el problema?
- Clasificación: ¿qué constituye "funcionar mal" para este sistema específico? ¿Deriva del modelo? ¿Disparidad demográfica en los resultados? ¿Tasa de error que supera el umbral?
- Autorización: ¿quién tiene autoridad para decidir detener?
- Ejecución: ¿qué significa detener? ¿Matar la API? ¿Volver a una versión anterior? ¿Cambiar a un proceso manual de respaldo?
- Comunicación: ¿quién recibe notificación cuando se produce una detención? Para sistemas de alto riesgo en ciertas categorías, la notificación de incidentes a la Oficina de IA es obligatoria.
Qué significa el cumplimiento: un runbook — no un interruptor de apagado teórico, sino un procedimiento documentado probado al menos una vez, con propietarios nombrados en cada paso.
Por qué la mayoría de los equipos fallan aquí: el sistema se desplegó incrementalmente. Nunca hubo una sesión de diseño de "¿cuál es el plan de apagado?". El interruptor existe en principio (apagar el servidor) pero las capas de detección y autorización no existen.
El patrón detrás de las cinco preguntas
Léelas juntas: acceso/modificación de datos, supervisión, almacenamiento, responsabilidad, apagado. No son cinco requisitos independientes. Son cinco facetas de una sola pregunta: ¿es gobernable este sistema de IA?
La gobernanza requiere que alguien pueda observar el sistema (preguntas 1, 3), que alguien tenga autoridad sobre él (preguntas 2, 4) y que esa autoridad pueda ejercerse en la práctica (pregunta 5). Si falta cualquiera de las cinco, el bucle de gobernanza está roto.
El EU AI Act está operacionalizando esto en ley porque el enfoque voluntario no funcionó. Los principios sin aplicación no cambian el comportamiento. El Acto es aplicación.
Qué haría este trimestre
Si despliegas sistemas de IA en Europa, o cualquier cosa que toque datos europeos, la secuencia práctica:
-
Inventaría tus despliegues de IA. No solo los productos de IA que vendes — toda la IA que usas internamente. Herramientas de selección de RRHH, bots de atención al cliente, detección de fraude, motores de recomendación. El Acto se aplica a los sistemas que usas, no solo a los que construyes.
-
Para cada sistema, responde las cinco preguntas. Escríbelas. "Todavía no lo hemos decidido" es una respuesta — significa que tienes una brecha.
-
Para cualquier cosa en las categorías de alto riesgo (Anexo III del Acto: biometría, infraestructura crítica, empleo, educación, aplicación de la ley, control fronterizo, administración de justicia, servicios esenciales) — prioriza. Agosto de 2026 es el plazo límite, e implementar supervisión humana conforme, registro de auditoría y gestión de riesgos lleva tiempo.
-
Ordena tus contratos con proveedores. ¿Quién es el proveedor de referencia? ¿Qué capacidades de auditoría proporciona el proveedor?
-
Construye el runbook para la pregunta 5. De las cinco, es la más operativa y la menos probable que exista. Constrúyela antes de necesitarla.
El AI Act no es regulación perfecta. Pero las cinco preguntas son ingeniería responsable independientemente de la regulación — son lo que el despliegue responsable de sistemas con consecuencias siempre ha requerido. El Acto simplemente lo está haciendo obligatorio.
¿Desplegando sistemas de IA en producción en Europa y necesitas capacidad de ingeniería que ya opere con estos controles de gobernanza incorporados? Habla con nosotros — nuestros equipos nearshore construyen sistemas de IA con registro de auditoría, hooks de supervisión humana y runbooks de cumplimiento como práctica estándar.
