En agosto, Ali Spittel resumió el cambio en una línea: "la verdad, no quiero usar tu agente; quiero que mi agente use tu producto" [1]. El post ya pasó las 700.000 visualizaciones. Hasta ahora, la industria respondió pensando en el alcance: publicar un servidor MCP, diseñar para la "agent experience" (AX) y hacer que las acciones se puedan descubrir.
Eso hace falta, y es la mitad fácil. Este artículo no trata de protocolos (MCP, A2A, REST) ni de cómo hacer herramientas cómodas para un agente. Trata de qué cambia en tu modelo de seguridad y de cumplimiento cuando lo que llama a tu producto es un modelo que nunca viste.
El modelo ya no es tuyo
Cuando lanzás tu propio asistente, elegís el modelo, escribís el system prompt, decidís las herramientas y ajustás los rechazos. Pienses lo que pienses de ese stack, es tuyo, y podés razonar sobre él.
Cuando el agente lo trae el cliente, cada una de esas palancas pasa al otro lado del cable. No sabés qué modelo es, qué versión, qué instrucciones recibió, a qué más está conectado, ni si la persona que está detrás es quien la API key dice que es. Mañana puede ser otro modelo.
Tratar la salida del modelo como entrada no confiable era una postura de diseño que algunos equipos adoptaban. Cuando cada cliente trae su agente, es simplemente la descripción de la situación. El modelo que llama a tu producto no es de confianza por definición.
Guardrails sobre un modelo que no corrés
Casi todas las herramientas de seguridad para agentes que existen hoy trabajan del lado del modelo: system prompts que dicen qué no hacer, filtros de salida, clasificadores, rechazos entrenados con fine-tuning, suites de evaluación que miden cómo se comporta el asistente.
Todas suponen que el modelo lo corrés vos. No podés agregar una línea a un system prompt que nunca ves. No podés hacer fine-tuning del modelo de un cliente, ni volver a correr tus evaluaciones cada vez que cambia de proveedor. Un filtro sobre su salida lo aplica él, o no.
Incluso donde esas herramientas se pueden usar, son probabilísticas. Bajan la probabilidad de una acción indebida; no la vuelven imposible. Para una empresa regulada el control tiene que ser demostrable, y "es muy improbable que nuestro asistente mueva plata sin autorización" es difícil de demostrar. Detrás del agente de un cliente, ni siquiera podés afirmar lo de "muy improbable".
Lo que queda por controlar: a qué puede llegar el agente
Si no podés gobernar el modelo, gobernás aquello a lo que puede llegar. La pregunta deja de ser "¿cómo hago para que el agente se porte bien?" y pasa a ser "¿qué puede hacer este agente, en qué condiciones, y qué prueba queda?".
Tunelo, un equipo sudafricano, documenta un buen ejemplo en su software para talleres mecánicos, GarageManager. El producto no trae IA propia: el taller conecta su propio agente, al que GarageManager llama AI Apprentice, por MCP o por REST, con un token que crea el taller. Leído como diseño de controles, tiene seis partes:
- Identidad acotada (¿quién es, y sobre qué?): un token que crea el taller, que vence a los 30 o 90 días, o nunca, y que se puede revocar en cualquier momento.
- Acciones declaradas (¿qué puede hacer?): más de treinta acciones con nombre, en tres niveles de acceso acumulativos; el más amplio suma el catálogo.
- Verbos prohibidos (¿qué no puede hacer nunca?): no puede emitir ni enviar nada a un cliente, registrar ni devolver un pago, aprobar un borrador (tampoco el suyo) ni borrar un cliente, un vehículo, una orden de trabajo, un presupuesto o una factura.
- Aprobación humana (¿qué pasos esperan a una persona?): una persona aprueba cada borrador que prepara, y sólo una persona emite o envía algo a un cliente.
- Límite de datos (¿qué no puede ver?): los precios de costo y los proveedores quedan ocultos salvo que el agente tenga acceso al catálogo.
- Registro (¿qué pasó, incluido lo que se rechazó?): queda registrada cada acción que ejecuta o intenta, también las rechazadas.
Nada de esto depende de qué modelo hay del otro lado.
También muestra el costo. Es el dominio de un solo producto, diseñado y construido a mano, acción por acción. Toda empresa que abra su producto a los agentes de sus clientes va a tener que hacer el mismo trabajo, con sus propias acciones, sus precondiciones y sus aprobaciones.
El registro lo escribe el auditado
De los seis controles, uno es más débil de lo que parece: el registro.
Un log que el proveedor escribe, guarda y puede editar es evidencia para el proveedor. Responde "¿qué dice nuestro sistema que pasó?". No responde la pregunta que tarde o temprano va a hacer el cliente, o su regulador: "¿cómo sé que este log está completo y no se modificó, sin tener que creerte?".
Con agentes de afuera esa pregunta se vuelve más exigente, no menos. Cuando el agente de un cliente hace algo dañino a través de tu producto, la primera discusión es sobre los hechos. ¿Lo pidió el agente? ¿Lo permitían tus reglas? ¿Qué versión de las reglas? ¿Se le preguntó a una persona? Si la única respuesta es una tabla de base de datos que controlás vos, sos a la vez el operador y el auditor de tu propia gobernanza.
Lo que responde esa pregunta es un registro que la otra parte pueda verificar por su cuenta: cada decisión encadenada en el momento en que se toma, para que un borrado o una edición se detecten, con checkpoints firmados que cualquiera puede comprobar offline y, cuando la clave de firma la tiene el cliente, sin confiar en el proveedor. Un rechazo tiene tanto lugar en ese registro como una aprobación, porque en una disputa lo que se bloqueó suele ser el hecho que más importa.
Por qué lo van a sentir primero los sectores regulados de América Latina
Un taller que pierde un borrador de presupuesto tiene una mala tarde. Una fintech cuya API deja que un agente desconocido mueva plata, cambie un beneficiario o presente un reclamo tiene un incidente, y quizás un llamado del regulador.
Las fintech y aseguradoras de América Latina están especialmente expuestas a este cambio. Con las finanzas abiertas ya es habitual que terceros regulados inicien pagos desde la cuenta de un cliente, con su consentimiento; la iniciación de pagos del Open Finance de Brasil, definida en 2020 por la Resolución Conjunta nº 1 del Banco Central y hoy operativa con Pix, es el caso más claro. Los agentes de los clientes son el próximo tercero, sólo que no están registrados, ni certificados, ni son predecibles.
La demanda va a aparecer como un cliente que pregunta por qué su asistente no puede pagar una factura desde tu app, y unos meses después como una pregunta de cumplimiento sobre qué pasó cuando uno lo hizo. Las empresas que respondan lo primero sin haber diseñado para lo segundo van a terminar cerrando la puerta otra vez.
Los controles van en una declaración
Los seis controles son los mismos en cualquier dominio. Sólo cambia el contenido: qué acciones existen, qué requiere cada una, cuáles esperan a una persona, qué queda fuera de alcance. Es una señal fuerte de que pertenecen a una declaración y no a código repartido entre endpoints.
Declaradas, las reglas las puede revisar cumplimiento antes de que corra nada, quedan versionadas y se pueden comparar cuando cambian. Toda escritura, venga de tu propio asistente, del agente de un cliente o de un cliente de API común, pasa por la misma barrera determinística. El modelo sólo propone; el contrato decide y el runtime lo hace cumplir. Y como las reglas tienen versión, una decisión puede indicar qué versión de las reglas la tomó.
Para este problema construimos Zarel: un runtime donde un agente sólo puede escribir lo que declara un contrato, y donde cada veredicto de esa barrera, también un rechazo, queda encadenado con la versión del contrato que lo decidió, bajo checkpoints firmados que se pueden verificar offline. Verificarlo sin confiar en nosotros requiere el despliegue en el que la clave de firma la tiene el cliente, que todavía no corrió en producción.
La mitad de este argumento que trata del registro está en Un recibo firmado son tres afirmaciones, no una; la de la barrera, en Una barrera también son tres afirmaciones.
Las citas están traducidas por el autor. Los originales, en inglés:
- "i really don't want to use your agent, i want to use my agent to use your thing." (Ali Spittel, agosto de 2026)
Nicolás Moreno construye Zarel: operaciones de IA gobernadas, donde la IA propone y el contrato dispone.