La legislación de IA europea ya está en vigor. ¿Puedes responder estas cinco preguntas?
El EU AI Act está en vigor desde agosto de 2024. La prohibición de las prácticas vetadas ya se aplica. Las obligaciones para la IA de alto riesgo llegan en agosto de 2026. Si despliegas sistemas de IA en Europa — o despliegas cualquier cosa que procese datos de ciudadanos europeos — el reloj ya corre.
La mayoría de las organizaciones sigue tratando el AI Act como un documento de cumplimiento que leer y dar por bueno. Lo han asignado a legal, lo han marcado como "en revisión" y han pasado a otra cosa. Es el enfoque equivocado.
Yo no leo el AI Act desde el asiento jurídico — lo leo desde el de ingeniería, que es donde las obligaciones tienen que ejecutarse de verdad. Y visto desde ahí, no es principalmente un texto legal. Es un conjunto de obligaciones operativas. La forma más rápida de saber si realmente cumples — no sobre el papel, sino en la operación — es responder cinco preguntas concretas sobre cada sistema de IA que tienes en marcha.
Si no puedes responder las cinco, tienes trabajo pendiente antes de agosto.
Por qué estas cinco preguntas
El reglamento supera el centenar de artículos, más una pila de anexos. 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 en 2025-2026 tiene 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 que cambien?"
Los sistemas agénticos lo agravan. Un agente que envía correos, actualiza registros del 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 — esto es lo crucial — qué estado del sistema pueden modificar las salidas de la IA.
Qué aspecto tiene 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 de escritura. Para los sistemas de alto riesgo, esto tiene que ser auditable, no solo afirmado.
La brecha más común: se ha documentado lo que entra, 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 exige supervisión humana para los sistemas de IA de alto riesgo (artículo 14). No "los humanos pueden revisar los resultados si quieren". Supervisión humana definida — un rol con nombre, responsable de monitorizar el comportamiento del sistema y de revisar las decisiones marcadas, y con autoridad para anularlo o detenerlo.
Esta pregunta tiene dos capas:
Supervisión operativa: ¿quién monitoriza el sistema en el día a día? ¿Quién recibe la alerta cuando se dispara la tasa de errores? ¿Quién revisa los casos límite? 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? En las industrias reguladas esto encaja en estructuras de gobernanza existentes (comités de riesgo, responsables de cumplimiento). En las startups a menudo no encaja en nadie, y eso es un problema.
Qué aspecto tiene el cumplimiento: para cada sistema de IA, una persona o un rol con nombre, 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 son la capa supervisora por encima de tu gobernanza interna. No son abstractas. La CNIL en Francia, la BNetzA en Alemania, la AESIA en España — estos organismos están construyendo activamente su 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ápido en sistemas que usan proveedores de modelos de terceros, generación aumentada por recuperación con bases de datos vectoriales externas, modelos ajustados alojados por proveedores cloud, o arquitecturas multiagente donde un agente traspasa contexto a otro.
Qué aspecto tiene 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 del fine-tuning, registros de auditoría.
Para la IA de alto riesgo (decisiones de empleo, scoring crediticio, acceso a servicios, aplicación de la ley), los datos deben retenerse de forma que permita una auditoría a posteriori. Necesitas poder reconstruir qué hizo el sistema con qué datos, para una decisión específica, en una fecha específica. Si dependes de un proveedor que no ofrece ese nivel de registro, tienes una brecha de cumplimiento.
La pregunta del proveedor cloud: si usas un proveedor de LLM con sede en EEUU (OpenAI, Anthropic, Google) sin residencia de datos en la UE, la cuestión de adónde van los datos en tránsito sigue abierta. La mayoría de los contratos enterprise incluye anexos de tratamiento de datos que intentan resolverla. La mayoría de los equipos de ingeniería no los ha leído nunca.
Pregunta 4: ¿Quién responde si se equivoca?
El marco de responsabilidad del AI Act, combinado con la Directiva de Responsabilidad de IA aún pendiente, 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 un sistema de IA o lo pone en el mercado. 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 concreto. Si usas el producto de un proveedor de IA dentro de tus operaciones, eres responsable del despliegue.
Operador: en algunos contextos, un híbrido — una organización que a la vez configura un modelo y lo despliega.
La mayoría de las organizaciones son las dos cosas: proveedoras (de sus propias herramientas de IA) y responsables del despliegue (de la IA de terceros). El reparto de obligaciones importa: los proveedores responden de la seguridad de diseño fundamental del sistema; los responsables del despliegue, del contexto de despliegue apropiado y de la supervisión.
Qué aspecto tiene el cumplimiento: una 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 de cada sistema. Si un proveedor dice "nosotros solo somos infraestructura" y tú estás construyendo un producto de IA encima, el proveedor eres tú — con obligaciones de proveedor.
La brecha real: la mayoría de las organizaciones todavía no ha tenido la conversación sobre responsabilidad con sus proveedores de IA. El contrato se firmó, la clave de API está en producción y nadie ha asignado formalmente quién responde ante el regulador.
Pregunta 5: ¿Cómo lo apagas si empieza a comportarse mal?
Esta es la pregunta que más cuesta responder a los equipos, 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) exigen, juntos, que los sistemas de IA de alto riesgo tengan procedimientos definidos para detener la operación cuando se superan los umbrales de seguridad o de 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 "comportarse mal" para este sistema concreto? ¿Deriva del modelo? ¿Disparidad demográfica en las salidas? ¿Tasa de error por encima del umbral? ¿Inyección de prompts maliciosos en producción?
- Autorización: ¿quién tiene autoridad para decidir la detención?
- Ejecución: ¿qué significa detener? ¿Cortar la API? ¿Volver a una versión anterior? ¿Desactivar una funcionalidad concreta? ¿Pasar a un proceso manual de respaldo? La respuesta es distinta para cada sistema.
- Comunicación: ¿a quién se notifica cuando se produce una detención? ¿A los usuarios? ¿Al regulador? (Para sistemas de alto riesgo en ciertas categorías, la notificación de incidentes a la Oficina de IA es obligatoria.)
Qué aspecto tiene el cumplimiento: un runbook — no un interruptor de apagado teórico, sino un procedimiento documentado y probado al menos una vez, con responsables con nombre en cada paso.
Por qué la mayoría de los equipos falla aquí: el sistema se desplegó de forma incremental. 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, así que en la práctica el sistema seguiría comportándose mal hasta que alguien lo notara y lo escalara por canales informales.
El patrón detrás de las cinco preguntas
Léelas juntas: acceso y 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 y 3), que alguien tenga autoridad sobre él (preguntas 2 y 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á llevando esto a la ley porque el enfoque voluntario no funcionó. Los principios sin mecanismos de aplicación no cambian el comportamiento. El reglamento es el mecanismo de aplicación.
Qué haría yo 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 cribado de RRHH, bots de atención al cliente, detección de fraude, motores de recomendación. El reglamento se aplica a los sistemas que usas, no solo a los que construyes.
-
Para cada sistema, responde las cinco preguntas. Ponlas por escrito. "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 reglamento: biometría, infraestructuras críticas, empleo, educación, aplicación de la ley, control fronterizo, administración de justicia, servicios esenciales) — prioriza. Agosto de 2026 es el plazo firme, e implementar una supervisión humana conforme, el registro de auditoría y la gestión de riesgos lleva tiempo.
-
Pon en orden tus contratos con proveedores. ¿Quién es el proveedor de referencia? ¿Qué obligaciones de tratamiento de datos ha asumido el proveedor? ¿Qué capacidades de auditoría ofrece?
-
Construye el runbook de la pregunta 5. De las cinco, es la más operativa y la que menos probablemente exista ya. Constrúyelo antes de necesitarlo.
El AI Act no es una regulación perfecta. Algunas definiciones están en disputa, algunos umbrales son arbitrarios y la guía de implementación todavía está saliendo de la Oficina de IA. Pero las cinco preguntas son buena ingeniería al margen de la regulación — son lo que el despliegue responsable de sistemas con consecuencias ha exigido siempre. La ley solo lo convierte en obligatorio.
¿Estás 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 squads nearshore construyen sistemas de IA con registro de auditoría, mecanismos de supervisión humana y runbooks de cumplimiento como práctica estándar, no como un añadido posterior.
