← Blog
● 27 de mayo, 2026 Cumplimiento · 15 min

EU AI Act: lo que todo operador de agentes necesita saber antes del 2 de agosto de 2026, en lenguaje claro

El 2 de agosto de 2026 — sesenta y siete días desde la publicación de este post — la EU AI Act empieza a aplicar sus dientes reales. Hasta ese día, la mayor parte de la ley estuvo en papel. Desde ese día en adelante, la categoría de obligaciones de mayor riesgo se vuelve aplicable con penalties de hasta €15 millones o 3% del revenue anual global (lo que sea mayor), y las peores infracciones cargan penalties de hasta €35 millones o 7%. La ley aplica a cualquiera cuyo sistema IA alcance a una persona en la Unión Europea, sin importar dónde el operador esté basado — un operador chico en Buenos Aires o San Francisco corriendo un agente que sirve a un usuario UE está, técnicamente, in scope. Este post es la versión de la ley que nos hubiera gustado que alguien escribiera para nosotros cuando la leímos por primera vez: cada término técnico explicado, cada requisito mapeado a una cosa concreta que tenés que hacer, sin legalismos, y un checklist de una página al final.

Qué es la ley, en tres frases

La EU AI Act es la primera ley en el mundo que regula los sistemas IA basándose en el nivel de riesgo que representan para las personas. No prohíbe la IA; ordena los sistemas IA en cuatro tiers y adjunta obligaciones distintas a cada uno. A mayor riesgo, más documentación, supervisión y accountability la ley exige a quienes construyen y deployan el sistema.

Pensalo como la regulación de alimentos: una panadería que vende muffins tiene obligaciones más livianas que una farmacia de hospital, pero ambas tienen reglas. La Act hace lo mismo para IA. Un chatbot que recomienda recetas vive en un tier distinto que un algoritmo que puntúa la solicitud de préstamo de alguien, aunque ambos técnicamente involucran "una IA tomando una decisión".

Quién está in scope

La Act usa dos roles clave que se tratan de forma distinta. Vamos a pasar mucho tiempo con estas dos palabras porque son la única terminología legal que genuinamente le importa al operador.

Provider = la entidad que construye y pone el sistema IA en el mercado bajo su propio nombre. En nuestro mundo, si generás un agente en Agent Builder y lo shippeás a una contraparte bajo tu propia marca, vos sos el provider de ese agente. Anthropic, OpenAI y Google son providers de los modelos subyacentes; vos sos el provider del agente construido encima.

Deployer = la entidad que usa un sistema IA. Si tu cliente usa tu agente para filtrar a sus postulantes de empleo, tu cliente es el deployer; vos seguís siendo el provider. Los dos roles pueden ser la misma entidad (vos lo construís y lo usás para tu propio negocio) o entidades distintas (vos construís, ellos usan).

El alcance de la Act es extraterritorial — el mismo truco que GDPR usó en 2018. El trigger no es dónde estás basado; el trigger es si el output de tu sistema IA se usa en la UE, o si las personas usando tu sistema están en la UE. Un operador en Argentina corriendo un agente que sirve a clientes europeos está in scope. Un operador en California cuyo output del agente alcanza a un usuario UE está in scope. La única forma de estar seguramente out of scope es no tener ningún touchpoint UE — y la mayoría de los operadores sí lo tienen, porque la UE tiene muchísimos clientes.

Los cuatro tiers de riesgo, con ejemplos

Todo en la Act se apoya en una clasificación de cuatro tiers. Entender los tiers te dice qué obligaciones aplican a tu agente.

Tier 1 — Riesgo inaceptable (prohibido). Una lista chica de prácticas que la UE decidió que son incompatibles con derechos fundamentales y prohíbe enteramente. Social scoring de ciudadanos por gobiernos. Identificación biométrica en tiempo real por la policía en espacios públicos (con excepciones angostas). Manipulación conductual cognitiva que explota vulnerabilidades. Reconocimiento de emociones en lugares de trabajo y escuelas (con excepciones por seguridad). Policía predictiva basada solo en profiling. Si tu agente hace cualquiera de estos, es ilegal en la UE. La mayoría de los operadores nunca van a tocar este tier.

Tier 2 — High risk (alto riesgo). La categoría que absorbe la mayoría de las obligaciones sustantivas de la Act y la categoría que la mayoría de los operadores de agentes necesita leer con cuidado. Vamos a pasar la sección entera siguiente sobre ella. Ejemplos sacados del Annex III de la Act (la lista enumerada oficial): herramientas de reclutamiento y RRHH, educación (admisiones, calificaciones), scoring crediticio y solvencia, identificación biométrica, soporte a fuerzas del orden, migración y control fronterizo, procesos judiciales y democráticos, acceso a servicios públicos esenciales, y gestión de infraestructura crítica.

La pregunta decisoria sobre si un agente cae en este tier no es "¿es poderoso?", es "¿toca uno de los casos de uso de la lista?". Un modelo frontera corriendo en la laptop de un investigador no es high-risk por sí solo. El mismo modelo usado para puntuar solicitudes de préstamo sí lo es.

Tier 3 — Riesgo limitado (obligaciones de transparencia). Cualquier sistema IA que interactúa con una persona física o genera contenido tiene obligaciones bajo el Artículo 50. Los chatbots deben revelar que son IA. Las imágenes, audio, video y texto generados por IA deben marcarse de forma legible por máquina como generados por IA (los deepfakes específicamente deben etiquetarse cuando no se usan para propósitos legítimos). Los sistemas de reconocimiento de emociones y categorización biométrica deben informar a las personas expuestas. Las obligaciones son más livianas que high-risk pero igual son obligatorias; un agente que miente sobre ser humano no es compliant.

Tier 4 — Riesgo mínimo. Todo lo demás. Filtros de spam, IA en videojuegos, sistemas de recomendación. La Act no impone obligaciones específicas sobre este tier; solo alienta códigos voluntarios de conducta.

Una categoría separada — General-Purpose AI (GPAI) — aplica a los modelos fundacionales subyacentes (los Claude, GPT, Gemini) y a cualquiera que construye encima. Los providers de GPAI tienen su propio set de obligaciones alrededor de documentación, resúmenes de datos de entrenamiento, y evaluaciones de seguridad. La mayoría de los operadores no son providers de GPAI; son providers de sistemas high-risk o de riesgo limitado construidos encima del GPAI de alguien más.

Las siete obligaciones concretas para sistemas high-risk

Si tu agente cae en el tier high-risk, la Act exige siete cosas. Vamos a traducir cada una desde el lenguaje legal a un artefacto concreto que tenés que producir.

1. Sistema de gestión de riesgo

El texto legal: tenés que establecer un proceso continuo y documentado para identificar, estimar y mitigar riesgos previsibles a lo largo del lifecycle del sistema.

Qué significa en la práctica: un documento escrito, mantenido al día, que lista qué podría salir mal con tu agente, qué tan probable es cada cosa, qué estás haciendo al respecto, y quién es responsable. No una auditoría una sola vez; un registro vivo. Pensalo como un bug tracker de software, pero para riesgos de IA en lugar de bugs de código. Entradas de ejemplo: "el agente alucina código tributario incorrecto → probabilidad media → mitigación: revisión humana en outputs por encima de $1.000 de impacto fiscal". "El agente falla en documentos no-castellano → probabilidad alta → mitigación: detectar idioma y rechazar procesar los no soportados".

2. Gobernanza de datos

El texto legal: los datos de entrenamiento, validación y testing deben cumplir criterios de calidad para relevancia y representatividad, y deben examinarse por sesgos.

Qué significa en la práctica: si entrenás o fine-tuneás tu propio modelo, tenés que poder describir de dónde vinieron los datos, cómo los sampleaste, y qué sesgos chequeaste. Si estás usando el modelo de otra persona (el caso común para la mayoría de operadores), la obligación es mucho más liviana — tenés que poder describir los datos que le metés al sistema, documentar cualquier corpus de retrieval-augmented generation (RAG) que tu agente usa, y mostrar que tus test cases cubren las poblaciones sobre las cuales el agente va a usarse efectivamente.

3. Documentación técnica

El texto legal: documentación detallada previa al mercado demostrando compliance, mantenida al día.

Qué significa en la práctica: un documento (la Act lo llama "technical file") que cualquier regulador UE puede pedir ver. Debería describir qué hace tu agente, qué modelos usa, a qué herramientas tiene acceso, cuáles son los flujos de input/output, qué testing hiciste, qué medidas de mitigación de riesgo tenés implementadas, y cómo alguien puede usarlo correctamente. Pensalo como el "manual del operador + ficha de seguridad" de tu agente. Para la mayoría de los operadores de agentes, esto es un documento de 10-20 páginas, refrescado trimestralmente.

4. Logging automático

El texto legal: los sistemas IA high-risk deben registrar automáticamente eventos relevantes para identificar riesgos o modificaciones.

Qué significa en la práctica: cada acción significativa del agente debe loguearse — el input que la disparó, qué herramientas llamó, qué produjo, cuándo ocurrió, en nombre de quién. Los logs deben retenerse suficiente tiempo como para soportar investigaciones post-hoc (la práctica de la industria es seis meses mínimo, más larga si operás en finanzas o salud). Agent Builder shippea esto por defecto para cada agente en tu flota; si operás fuera de Agent Builder, lo tenés que cablear.

5. Transparencia hacia los deployers

El texto legal: instrucciones que permitan a los deployers entender las capacidades y limitaciones.

Qué significa en la práctica: tenés que darle a quien sea que esté usando tu agente (tu cliente, la persona que enchufa tu agente a su workflow) documentación clara de qué hace bien el agente, qué hace mal, y para qué no debería usarse. Un "fact sheet" de una página que shippea con el agente. Una lista corta de "no usar para X, Y, Z". Un resumen de modos de error típicos.

6. Supervisión humana

El texto legal: el sistema debe diseñarse para permitir supervisión humana efectiva, incluyendo la capacidad de monitorear la operación, intervenir, anular y desactivar el sistema.

Qué significa en la práctica: un humano en el loop — o al menos un humano con la capacidad de meterse en el loop — para decisiones de alto stake. No necesariamente un humano aprobando cada output, pero un camino claro para que el humano vea qué hizo el agente, anule una decisión que el agente tomó, y apague el agente. La Act explícitamente exige que el humano sea capaz de hacer esto sin disrupción al workflow. Un agente sin botón de apagado no es compliant.

7. Exactitud, robustez, y ciberseguridad

El texto legal: el sistema debe alcanzar niveles apropiados de exactitud y ser resiliente contra errores, fallas e intentos de manipulación no autorizada.

Qué significa en la práctica: tres cosas empaquetadas juntas. Exactitud: métricas declaradas de performance que podés defender con evidencia (no "este agente es genial" sino "este agente alcanza un F1 score de 0.84 sobre el test set documentado"). Robustez: el sistema tolera el tipo de variación de input que va a encontrar en el mundo real — mayúsculas, errores tipográficos, imágenes de baja calidad, información parcial. Ciberseguridad: el sistema es resistente a intentos de manipulación no autorizada, lo que en tierra de agentes incluye prompt injection, envenenamiento de datos, y ataques de supply-chain contra las herramientas que el agente usa. Mañana publicamos el post de threat-model que profundiza en esto.

La capa de transparencia del Artículo 50 (aplica incluso a sistemas de riesgo limitado)

Incluso si tu agente no es high-risk, si le habla a una persona o genera contenido, tenés obligaciones de transparencia.

Los penalties, en concreto

Tres tiers de penalty mapean a tres clases de violación.

Estructura de penalties (el mayor de los dos):

  Prácticas prohibidas (violaciones Tier 1)
    €35.000.000  O  7% del revenue anual global

  Obligaciones high-risk violadas (violaciones Tier 2)
    €15.000.000  O  3% del revenue anual global

  Información engañosa a las autoridades
    €7.500.000   O  1% del revenue anual global

Los números están deliberadamente fijados para ser más grandes que los máximos de GDPR (4% del revenue), porque la UE ve la no-compliance del AI Act como más consecuente que la no-compliance de protección de datos. También están deliberadamente escalados al revenue, no al profit, de modo que muerden incluso a startups en pérdida.

Para un operador del tamaño de un negocio chico — €1M de revenue anual — la cifra del 3% sale a €30.000. No catastrófico, pero suficiente como para que no quieras ser el test case. Para un operador medio en €100M de revenue, el mismo porcentaje son €3M. Para Salesforce con $35B+, estás mirando el tipo de penalty que sale en la primera plana.

El checklist del operador de una página

Esta es la versión que imprimiríamos y pegaríamos a la pared. Cada ítem mapea a una de las siete obligaciones high-risk o la capa de transparencia.

Checklist de compliance del EU AI Act — para el operador de agentes

[ ] 1. Inventario de IA
        Para cada agente que operás, podés nombrar: qué hace,
        qué modelo(s) usa, a qué herramientas tiene acceso,
        quién lo construyó, quién lo deploya.

[ ] 2. Clasificación Annex III por agente
        Para cada agente, decisión documentada: ¿es high-risk?
        Si sí, ¿qué categoría del Annex III? Si no, ¿cuál fue
        el razonamiento? Tenelo escrito.

[ ] 3. Registro de riesgo
        Documento vivo. Riesgos previsibles, probabilidad,
        mitigación, owner. Refrescado trimestralmente mínimo.

[ ] 4. Technical File
        10-20 páginas por agente high-risk. Arquitectura,
        modelos, fuentes de datos, testing, mitigaciones,
        instrucciones de uso.

[ ] 5. Logging automático prendido
        Cada acción significativa logueada. Retención >= 6
        meses (más para industrias reguladas). W3C Trace
        Context.

[ ] 6. Instrucciones para el deployer
        Fact sheet de una página por agente: capacidades,
        limitaciones, lista de no-usar-para, modos de error
        conocidos.

[ ] 7. Camino de supervisión humana
        Para cada agente high-risk: humano documentado que
        puede monitorear / intervenir / anular / desactivar.
        Ningún agente en producción sin botón de apagado.

[ ] 8. Métricas de performance
        Resultados documentados de exactitud, robustez y
        testing de ciberseguridad. Defendibles con evidencia.

[ ] 9. Revelaciones de transparencia
        Cada chatbot le dice al usuario que es IA. Cada output
        generado por IA está marcado. Los deepfakes están
        etiquetados.

[ ] 10. Conformity Assessment (para high-risk)
         Auto-evaluación para la mayoría de categorías;
         evaluación de tercera parte para algunas. Marcado CE
         sobre el sistema. Registro en la base de datos UE.

[ ] 11. Matriz Provider/Deployer
         Asignación escrita: para cada agente, quién es el
         provider, quién es el deployer, quién carga qué
         obligaciones.

[ ] 12. Plan de respuesta a incidentes
         Cómo descubrís, documentás, y reportás incidentes
         serios a la autoridad nacional relevante dentro del
         timeline requerido.

Si podés tildar los doce antes del 2 de agosto de 2026, estás en una posición defendible. Si no podés tildar los doce, priorizá: Inventario (ítem 1), Clasificación (ítem 2), Registro de riesgo (ítem 3), Logging (ítem 5), Supervisión humana (ítem 7), y Transparencia (ítem 9) son los que cargan peso. El resto es papelería que podés construir en los meses después del deadline, mientras los primeros seis estén en su lugar.

Cómo Agent Builder mapea a las obligaciones

El pitch de ventas honesto: la razón por la que venimos escribiendo hace un mes sobre protocolos (MCP, A2A, AP2, x402, ERC-8004) es que los protocolos mismos le dan al operador la mayor parte de las capacidades técnicas que el AI Act exige. El mapeo es directo.

El logging (Obligación 4) es automático. Cada llamada MCP, cada mensaje A2A, cada mandate AP2, cada pago x402 lo loguea Agent Builder con propagación de W3C Trace Context. La retención de 6 meses está prendida por defecto; 12 meses está a un toggle.

La transparencia (Artículo 50) shippea por defecto. Cada agente generado por Agent Builder revela su naturaleza IA al inicio de una interacción. Los outputs se taggean con el estándar SynthID donde el modelo subyacente lo soporta. Los outputs estilo deepfake están gated detrás de opt-in explícito del operador con watermarking enforzado.

La supervisión humana (Obligación 6) es el dashboard. El dashboard multi-agente que shippeamos le permite a un humano monitorear cualquier agente, intervenir en cualquier task, anular cualquier decisión y desactivar cualquier agente — exactamente las cuatro affordances que la Act exige.

La documentación técnica (Obligación 3) se auto-genera. La exportación de Agent Builder produce un borrador de Technical File para cada agente: modelo usado, herramientas conectadas, flujos de datos, resultados de testing, entradas del registro de riesgo. El trabajo del operador es revisar y agregar la narrativa contextual; el contenido estructurado ya está rellenado.

La ciberseguridad (parte de la Obligación 7) se sienta sobre aislación microVM. Cada ejecución de herramienta corre en un entorno sandboxeado. La prompt injection tiene defensas dedicadas (ver el post de threat-model de mañana). El provenance de supply-chain de los servers MCP está trackeado.

Las piezas que el operador de Agent Builder igual tiene que hacer por sí mismo: el Inventario de IA (es tu inventario), la Clasificación del Annex III (solo el operador conoce el caso de uso), las instrucciones del lado del deployer (vos las escribís, el catálogo incluye templates), el conformity assessment (auto-atestiguado para la mayoría de agentes; proveemos el template), la Matriz Provider/Deployer (específica del operador). Estas son las cosas que ninguna plataforma puede hacer por vos porque dependen de tu contexto específico de deployment.

Qué hacer esta semana

Si tenés 67 días y no arrancaste, este es el orden en el que abordaríamos esto.

Semana 1 (hoy hasta domingo): Hacé el Inventario de IA. Solo una planilla. Una fila por agente. Columnas: nombre, qué hace, modelo usado, herramientas conectadas, quién lo construyó, quién lo usa, dónde están los usuarios. Si no sabés qué tenés, nada más importa.

Semana 2: Clasificá cada agente. Para cada fila del inventario, preguntá: "¿el agente está tomando decisiones en alguna de las categorías del Annex III (reclutamiento, educación, crédito, biometría, servicios públicos, empleo, fuerzas del orden, infraestructura)?". Si sí, el agente es high-risk y las siete obligaciones aplican. Si no, estás en el tier de riesgo limitado con solo obligaciones de transparencia del Artículo 50. Anotá la respuesta. El acto de anotar la clasificación es lo que la ley exige.

Semana 3-4: Para cada agente high-risk, arrancá el Technical File. Usá el borrador auto-generado de Agent Builder si estás en Agent Builder. Agregá el contexto narrativo. Hacé que un humano revise el output durante al menos las primeras tres semanas de operación y documentá lo que vio. El Technical File está vivo, no es un write-up de una sola vez.

Semana 5-6: Prendé el logging si no está prendido todavía, verificá la retención. Escribí las instrucciones cara al operador para cada agente (el fact sheet de una página). Armá el camino de supervisión humana con reglas de escalación documentadas.

Semana 7-8: Conformity assessment. Marcado CE. Registro en la base de datos UE. Estos son los ítems formales de papelería que no podés hacer hasta que las obligaciones subyacentes estén en su lugar, por eso van últimos.

Semana 9: Hacé que un humano real lea tu trabajo y encuentre los gaps. Idealmente un abogado que leyó la Act, pero a falta de eso, cualquiera con disciplina que no estuvo involucrado en construir los agentes. Los ojos frescos van a agarrar las obligaciones que te perdiste.

Cierre — la verdad poco glamorosa

La EU AI Act no es la pieza de legislación más emocionante jamás escrita. Es, sin embargo, la más consecuente para cualquiera corriendo agentes IA en la próxima década. El deadline es real, los penalties son reales, y los operadores que la traten como un ejercicio de papelería van a arrepentirse de ese encuadre la primera vez que una autoridad nacional les pida ver su Technical File.

Los operadores con los que trabajamos que se la están tomando en serio dijeron todos lo mismo: una vez que hacés el inventario y la clasificación, el resto del trabajo no es pesado — es mayormente documentación de cosas que igual deberías estar haciendo. Registro de riesgo, logging automático, supervisión humana, revelaciones de transparencia. Son las prácticas de un operador serio independientemente de la regulación. La Act solo te obliga a anotarlas.

Si corrés agentes a través de Agent Builder, arrancás desde una posición donde la implementación técnica de la mayoría de las obligaciones ya está hecha. El trabajo del operador es escribir la documentación que dice "esto es lo que mi deployment de esta tecnología hace efectivamente, estos son los riesgos que consideré, así es como lo superviso". Ese es el trabajo de los próximos 67 días.

El texto oficial de la Act está en digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. El FAQ oficial está en ai-act-service-desk.ec.europa.eu/en/faq. Leé ambos. Si operás a cualquier escala significativa, hablá con un abogado que específicamente lea trabajo del AI Act. Los €15M de penalty no son el tipo de error que se arregla después.

Mañana publicamos el post de threat-model de seguridad que va profundo en la Obligación 7 (ciberseguridad) — los tipos de ataques contra los que los operadores de agentes tienen que defenderse hoy, y los que esperamos ver en los próximos dieciocho meses. Leé ese también; los dos posts son mitades de la misma conversación.