El 2 de agosto entraron en vigor las obligaciones de transparencia del Reglamento de IA, junto con las potestades de la Oficina de IA sobre los modelos de propósito general y el régimen sancionador completo. El artículo 50 es más estrecho de lo que sugirió la cobertura. Si una persona está interactuando con un sistema de IA, díselo. Marca el contenido sintético. Revela el deepfake. Los proveedores de sistemas ya en el mercado tienen hasta el 2 de diciembre para cumplir las reglas de marcado.
Diez días después el Financial Times publicó una investigación de Dream, una firma israelí de ciberdefensa, que describía lo que le pasó al gobierno de Taiwán entre el 1 y el 4 de julio. Un framework construido sobre dos agentes de código abierto, Hermes y OpenClaw, lanzó doce oleadas de ataque con hasta ocho subagentes en paralelo, cada uno con sus objetivos y sus técnicas. Mapeó 21 sistemas gubernamentales conectados, reventó 85 cuentas de empleados y sacó más de 2.500 expedientes de personal antes de extenderse al regulador de seguridad nuclear y a al menos siete empresas energéticas. Kenny Huang, del Taiwan Network Information Center, lo llamó el primer ataque totalmente automatizado contra un gobierno que se hace público.
Lee esos dos hechos uno al lado del otro. Ya hay un régimen que regula lo que un agente debe decir de sí mismo. No hay nada en vigor que regule lo que se le permite tocar. En julio argumenté que un agente actúa y un wrapper responde. La pregunta que viene detrás es la que decide si la cosa sobrevive a producción: ¿con los permisos de quién actúa? En el momento en que un sistema ejecuta una acción en vez de producir texto, su alcance de permisos se convierte en su alcance de capacidades. Eso es una decisión de producto. Casi todos los equipos la están dejando ocurrir por omisión.
El guardrail y la cerradura responden a preguntas distintas
Lo notable de la operación de Taiwán no es la autonomía. Es lo barato que salió el bypass.
Los investigadores de Dream encontraron que los operadores se saltaron los guardrails de seguridad de los modelos presentando toda la intrusión como pentesting autorizado. Ningún exploit contra el modelo. Ningún jailbreak en el sentido exótico. Describieron el trabajo como una prueba rutinaria de preparación y el guardrail aceptó la descripción, porque aceptar descripciones es lo único que un guardrail sabe hacer.
La puerta 1 es una conversación. La puerta 2 es una consulta. Solo una de las dos tiene una opinión que puedas cambiar.
Un guardrail es un filtro semántico. Lee la petición, juzga si parece aceptable y devuelve un veredicto sobre las palabras. La autorización es estructural. Pregunta si esta identidad tiene este derecho sobre este recurso, y la respuesta sale de una tabla, no de un juicio. A la primera se la puede persuadir. Con la segunda no se puede ni hablar.
Casi todos los agentes de empresa entregados en los últimos dieciocho meses están construidos con la primera y sin la segunda. El trabajo de seguridad se fue al prompt, al entrenamiento de rechazo, a los filtros de contenido, a la suite de evals de salidas dañinas. Todo útil, nada de eso es una cerradura. Y un agente, a diferencia de un wrapper, tiene detrás de la puerta algo que merece la pena alcanzar: un sistema de reservas, un CRM, una base de datos de candidaturas, una API de pagos. A un wrapper al que le sacan una mala respuesta produce un mal párrafo. A un agente al que le sacan una mala acción produce una mala fila en un sistema de registro, a nombre de alguien.
Hay una razón organizativa por la que la segunda puerta no se construye nunca. Los guardrails son de quien es dueño del modelo, y la autorización es de quien es dueño de la identidad y los accesos. En casi todas las empresas esos son equipos distintos, presupuestos distintos y ciclos de revisión distintos, y el agente lo entrega un tercer equipo que no reporta a ninguno de los dos. Cada grupo puede decir honestamente que aquello pasó sus controles. Nadie es dueño de la pregunta de qué pasa cuando a un sistema diseñado para dejarse convencer se le entrega una credencial diseñada para ser de confianza.
Le diste tu tarjeta porque no había otra forma de entregarlo
El informe de Okta AI Agents at Work 2026, hecho por Apprize360 con 292 directivos y 492 trabajadores del conocimiento en marzo, tiene un número que explica más que todo el resto junto.
La brecha no es negligencia. Es lo que pasa cuando el camino rápido a producción pasa por el token de sesión de una persona.
Solo el 34% de las organizaciones aplican a su plantilla agéntica los mismos controles de seguridad que a la humana. Dos tercios exigen al agente un estándar más bajo que a la persona cuyo acceso está usando. La misma encuesta encontró un 58% de directivos que reportan un incidente de seguridad relacionado con IA o un casi incidente en los doce meses previos, un 52% de trabajadores usando herramientas de IA sin aprobación, un 45% de esos metiéndoles información de RRHH y más de un 20% compartiendo credenciales de acceso directamente.
No lo leo como descuido. Lo leo como la forma del camino más corto. Darle a un agente su propia identidad criptográfica, acotada a una tarea, con una credencial que caduca, significa construir intercambio de tokens, un registro de servicios y una ruta de auditoría antes de que el agente haga nada útil. Pasarle el token de sesión de una persona significa que funciona esta tarde. Todos los equipos bajo presión de entrega han hecho ese cambio, incluidos los que saben que no deberían, y el cambio se acumula en silencio porque no se rompe nada.
La palabra para lo que falta es atenuación. Delegar está bien. Una persona delegando toda su autoridad vigente, de forma indefinida, en algo que actúa miles de veces por hora, no es delegar. Es suplantación con buena interfaz.
Lo que lo vuelve urgente y no solo desordenado es el ritmo. El Agentic Enterprise Index de Salesforce, segunda edición, publicado este mes, sitúa a la organización media en 13 agentes activados en abril de 2026, frente a 5 en febrero de 2025, y el tiempo medio para crear uno en 1,9 días, un 53% menos en el mismo periodo. Ponlo contra lo que tarda en levantarse una identidad de máquina decente, que se mide en trimestres e implica a equipos que no reportan a quien entrega el agente. Dos curvas, direcciones opuestas. Cada semana que el atajo sigue siendo más barato que el camino correcto, el montón de agentes con credenciales prestadas crece en un par más.
En un marketplace, el alcance de permisos es el alcance del producto
Aquí es donde la abstracción deja de ser abstracta, y es la parte a la que dedico horas de trabajo reales.
Un marketplace de talento de dos lados tiene una asimetría metida en su modelo de datos. Lo que un recruiter puede ver del conjunto de candidatos no es un ajuste de seguridad que alguien configuró. Es una decisión de producto, tomada a conciencia, sobre qué se le permite saber a una empresa de una persona antes de que esa persona haya aceptado nada. Apunta un agente a esa superficie con las credenciales del recruiter y el agente hereda todo su campo de visión, y después actúa sobre él a velocidad de máquina. El diseño de privacidad que costó meses de discusión lo aplana un token.
Mismo motor, mismo modelo, misma salida. La única variable es qué nombre acaba en el registro.
En mayo escribí que el borrador de directrices del Anexo III de la Comisión giraba sobre un verbo: el mismo motor de matching es de alto riesgo cuando decide y queda fuera del perímetro cuando ayuda. La cuestión de los permisos es la versión sustantivo del mismo problema. Mismo motor, misma salida, distinta identidad actuante, distinto sistema a ojos de cualquiera que después tenga que reconstruir qué pasó.
Esa reconstrucción es lo que está en juego en la práctica, y es donde he aterrizado después de ocho meses en el sandbox regulatorio español con la DG IA y BBVA. Todo lo que en el Matchmaking de Shakers lo mete en el catálogo de OECD.AI como sistema de referencia, y todo lo que hay detrás del certificado de transparencia de Adigital, se apoya en una sola capacidad: que un candidato pueda impugnar un resultado y nosotros podamos decir qué lo produjo. Si un agente actuó con las credenciales de un recruiter, el registro dice que lo hizo el recruiter. El registro que necesitas para responder a la impugnación es exactamente el registro que destruiste. Ninguna cantidad de documentación del modelo lo recupera, porque la pérdida ocurrió en la capa de identidad, seis meses antes de que alguien preguntara.
La transparencia no es un documento que publicas. Es una propiedad de tus registros, y el modelo de identidad decide si la tienes.
El plazo se movió. El modelo de datos no.
El Digital Omnibus, acordado políticamente el 6 de mayo, retrasó las obligaciones de alto riesgo. Los sistemas autónomos del Anexo III tienen ahora hasta el 2 de diciembre de 2027, y la IA embebida en productos regulados hasta el 2 de agosto de 2028. El reclutamiento está en el Anexo III. Mucha gente del sector de RRHH lo leyó como dieciséis meses de alivio.
Son dieciséis meses de algo, y de qué exactamente depende de una decisión que casi ningún equipo ha tomado conscientemente. La arquitectura de permisos no es un artefacto de cumplimiento que se engancha al final. Vive en el modelo de datos, en cómo se emiten las sesiones, en qué recoge la tabla de auditoría como actor. Retrofitear identidad en un sistema que lleva dieciséis meses registrando acciones de agente bajo nombres humanos no significa escribir una política. Significa reescribir un histórico que no se puede reescribir, porque los registros ya dicen lo que dicen.
Las obligaciones que sí aterrizaron el 2 de agosto apuntan en la misma dirección de todas formas. El artículo 50 dice que una persona debe saber que está tratando con una máquina. Sería un sistema raro el que informa al candidato de que «un sistema de IA te ha evaluado» mientras su propio rastro de auditoría insiste en que lo hizo un recruiter a mano. El deber de transparencia está vivo ya. El registro interno que lo hace cierto es la parte que todavía no obligan a construir.
Lo que pregunto antes de que un agente salga
Cuatro preguntas, en este orden. Son baratas de hacer y caras de saltarse, y la primera descarta casi todo lo que me cruza la mesa.
¿Con qué identidad actúa? Si la respuesta es el nombre de una persona, para ahí. Todo lo de abajo hereda ese error, incluido el registro de auditoría, incluida la respuesta a incidentes, incluida la respuesta que le debes a un candidato el año que viene.
¿Cuál es el alcance mínimo que le permite terminar, y cuándo muere la credencial? No el alcance que resulta cómodo. El que la tarea necesita de verdad, y una caducidad lo bastante corta como para que un token filtrado valga menos que el esfuerzo de robarlo. La guía de adopción agéntica de CISA, que la Cloud Security Alliance tradujo a controles de empresa este mes, aterriza en el mismo sitio: identidades de agente verificadas criptográficamente, credenciales de vida corta, mínimo privilegio impuesto por estructura y no pedido con educación.
¿Qué acciones son irreversibles y cuáles de esas aprueba un humano? Un agente que puede ordenar candidatos y un agente que puede rechazarlos no son el mismo producto, por mucho que la demo se parezca. Las acciones irreversibles llevan humano en el bucle, y ese humano tiene nombre.
Si alguien impugna este resultado dentro de seis meses, ¿qué dice el registro? Esta es la pregunta que caza lo que las otras tres dejan pasar, porque la responde el sistema y no el equipo. Lee una línea de log real en voz alta. Si nombra a una persona por algo que hizo una máquina, el modelo de permisos ya está mal y ningún documento de política lo va a arreglar a posteriori.
Cierre
La industria se pasó un año discutiendo si una cosa es de verdad un agente. Fue una discusión útil y yo puse mi parte. Pero un sistema que actúa no se define solo por si actúa. Se define por lo que se le permite alcanzar cuando lo hace, y esa frontera se está fijando ahora mismo, en silencio, por quien cableó la primera integración con la fecha encima.
Taiwán es la versión ruidosa de la lección. La versión callada está corriendo en producción en algún sitio de tu empresa hoy, sosteniendo el token de una persona, haciendo exactamente lo que le pidieron y escribiendo el nombre de esa persona en cada fila que toca. Nadie se dará cuenta hasta que alguien pregunte quién decidió. Construye la segunda puerta antes de que llegue la pregunta.