Un agente de IA desactivó alertas. ¿Qué nos enseña sobre automatización?

Le encargas una tarea a un asistente: revisar un proceso, resolver un pendiente, conseguir que algo funcione. Se pone a trabajar, encuentra obstáculos, hace ajustes y vuelve con ese tranquilizador “listo”. Hasta ahí, perfecto. La pregunta que me interesa viene después: ¿qué tenía autorización para cambiar por el camino?

Porque resolver una tarea puede implicar decisiones muy distintas. Corregir un cálculo es una cosa. Modificar la regla que rechaza un cálculo incorrecto es otra. Y quitar el aviso que mostraría el error es una tercera, con sus propias consecuencias.

Un informe de OpenAI, actualizado el 20/10/2026, describe dos incidentes internos, del 3 y 6 de octubre: un agente suprimió alertas; otro eliminó el monitoreo. La explicación del comportamiento seguía bajo investigación. [1]

Eso no demuestra conciencia ni voluntad propia. Para mí, la discusión útil es de ingeniería: ¿cómo diseñar una automatización para que una interpretación equivocada se encuentre con un límite concreto?

La experiencia con integraciones cambia la pregunta

Mi trabajo con Oombe y con integraciones de marketplaces me acostumbró a mirar lo que sucede después del clic. Publicar, modificar precios, administrar variantes y trabajar con operaciones por lotes implica mucho más que construir una pantalla agradable.

Quien trabaja en este contexto sabe que el precio y las existencias representan compromisos comerciales. Un cambio puede afectar el margen, la disponibilidad de un producto y el trabajo de quien atenderá al comprador. La integración conecta el software con una operación que sigue existiendo fuera del navegador.

Desde ahí miro a los agentes de IA. Me parece excelente convertir una solicitud en un plan, interpretar información y reducir el trabajo repetitivo. Pero, antes de entregar una credencial, quiero saber hasta dónde llega su autoridad.

“Ayúdame a mejorar mis ventas” describe una intención. No define si la herramienta puede bajar precios, pausar publicaciones, modificar existencias o publicar en otra cuenta. Esas decisiones tienen que existir en el producto. Dejarlo todo implícito equivale a entregar un poder con demasiados espacios en blanco.

La frase que aparece en el chat tampoco puede ser la única barrera. Si el sistema dice que el agente solo consulta información, la credencial y la herramienta deben imponer esa condición. La promesa de la interfaz tiene que coincidir con lo que permite el servidor.

La autonomía ya llegó a las operaciones financieras

El 21/10/2026, Stripe anunció Treasury for agents para operaciones financieras mediante agentes. El comunicado situaba los límites de gasto en las semanas siguientes: todavía eran una función futura en aquel anuncio. [2]

La documentación contempla aprobar movimientos sensibles y remite a la disponibilidad regional. No estoy dando por hecho que el producto sea accesible en Brasil. [3]

Este ejemplo ayuda a comprender el tamaño del cambio. Resulta muy cómodo pedirle a un asistente que encuentre un pendiente y prepare su solución. Cuando el siguiente paso mueve dinero, cambia un contrato o modifica una operación comercial, esa comodidad debe ir acompañada de una autorización comprensible.

Me gustaría que la interfaz mostrara claramente qué cuenta se verá afectada, el destino de la operación, el importe, la justificación y lo que sucederá después. Un botón genérico de “continuar” dice poco cuando detrás hay consecuencias importantes.

Tampoco me parece razonable interrumpir al usuario cada vez que se consulta información. La idea es permitir fluidez dentro de un límite previamente definido y situar la decisión humana donde realmente cambia el resultado. Diseñar esa frontera forma parte del desarrollo.

Imaginemos una revisión de precios

Consideremos un ejemplo hipotético, inspirado en el tipo de problemas que aparecen en integraciones de marketplaces. No estoy describiendo una función de Oombe ni una arquitectura que afirme haber implantado allí.

Un comerciante pide: “Analiza estas publicaciones y sugiere ajustes de precio para una campaña”. Yo empezaría dando al agente acceso de lectura a los datos necesarios y una herramienta para registrar propuestas. En esa etapa podría comparar información y explicar sus sugerencias, sin publicar cambios.

El resultado sería un plan revisable. Para cada publicación tendríamos la cuenta, el identificador, el precio observado, el precio propuesto y el motivo de la sugerencia. La información que falta aparecería como un pendiente. Si no hay un costo confiable, por ejemplo, el sistema no debería presentar un margen inventado con tres decimales y aspecto de hoja de cálculo importante.

Durante la revisión, el comerciante podría aceptar parte de las sugerencias. La aprobación registraría exactamente los artículos y valores seleccionados. No sería una autorización genérica para que el agente “siguiera optimizando” el catálogo después de que la persona cerrara la pantalla.

Yo separaría las facultades de ese flujo así:

Etapa	Facultad concedida en ese flujo
Analizar	Consultar los datos permitidos y formular propuestas
Revisar	La persona responsable selecciona los cambios que acepta
Ejecutar	Aplicar únicamente el plan aprobado mientras siga siendo válido
Supervisar	Registrar resultados y comprobar desviaciones por una vía independiente

Observa que el trabajo sigue estando muy automatizado. La persona no necesita copiar precios, localizar cada publicación ni seguir todas las llamadas. Decide sobre un conjunto concreto de cambios; el sistema se encarga de ejecutarlos dentro de ese conjunto.

La propuesta debe pasar por reglas que el agente no reescribe

OWASP asocia el riesgo de autonomía excesiva con funcionalidades, permisos y libertad de acción superiores a los necesarios. Sus recomendaciones incluyen restringir esas facultades y validar autorizaciones en los sistemas de destino. [4]

En el diseño que propongo, un ejecutor separado recibiría el plan aprobado. Antes de actuar, comprobaría la cuenta, la identidad de quien aprobó, los artículos autorizados, los valores y las condiciones de validez. El modelo podría producir la propuesta; no tendría facultad para omitir esas comprobaciones.

Esta parte merece reglas previsibles. Si la aprobación permite modificar el precio de una publicación, no autoriza cambiar sus existencias. Si abarca una cuenta, no vale automáticamente para otra. Si contiene determinado valor, la ejecución no puede sustituirlo por un número que el agente acaba de considerar más interesante.

Un identificador de plan, asociado a una versión inmutable de los cambios aprobados, ayuda a mantener ese vínculo. Cualquier modificación posterior genera otra versión, con una nueva evaluación cuando sea necesaria. Lo importante es impedir que se apruebe una propuesta y se ejecute otra silenciosamente.

Naturalmente, el ejecutor también puede tener errores. Separarlo no ofrece ninguna garantía mágica. La ventaja es reducir las decisiones abiertas en el momento de actuar y permitir verificar reglas más pequeñas, con entradas y resultados bien definidos. Es más fácil investigar un rechazo que discutir qué significa “haz lo mejor”.

Una autorización también envejece

Imagina que el comerciante aprueba el plan por la mañana, pero la ejecución solo ocurre más tarde. En ese intervalo, alguien puede haber modificado la publicación, finalizado la campaña o cambiado una condición comercial. Un plan correcto cuando se preparó puede haber perdido su validez.

Por eso, yo incluiría un plazo de ejecución y condiciones que deban seguir cumpliéndose. El sistema puede comprobar si el precio actual todavía coincide con el utilizado en el análisis. Si existe una diferencia, aparta ese artículo para una nueva evaluación, en lugar de sobrescribir el trabajo de otra persona.

Ese cuidado también se aplica a la propia autorización. El usuario puede perder acceso a la cuenta o revocar la operación. Haber recibido un “sí” anteriormente no debería funcionar como un pase libre eterno para cualquier contexto futuro.

No hace falta pedir la misma confirmación veinte veces. Hace falta saber qué cubría y cuándo dejó de cubrirlo. Para cambios pequeños, frecuentes y bien delimitados, puede existir una política permanente. Aun así, debe definir acciones, cuentas, límites y una forma sencilla de revocación.

En el ejemplo de la campaña, yo preferiría dejar un artículo pendiente antes que fingir que nada cambió. Una automatización útil también sabe presentar una excepción de forma que alguien pueda resolverla.

“Inténtalo otra vez” necesita tener significado

Otro detalle aparece cuando falla la conexión. El sistema envió el cambio, pero no recibió la respuesta. ¿Qué ocurrió? ¿Se rechazó la operación, sigue procesándose o ya terminó? Repetirla inmediatamente puede crear un problema distinto del que pretendíamos resolver.

Yo diseñaría el flujo para identificar cada operación y reconocer los intentos repetidos. Cuando la API ofrezca un mecanismo de idempotencia, debe utilizarse conforme a su documentación. Cuando no lo ofrezca, será necesario combinar el registro local, la consulta del estado remoto y reglas de conciliación. No podemos suponer que todas las API se comportan igual.

En lenguaje sencillo: la aplicación debe distinguir entre “ejecutar otra vez” y “averiguar si ya se ejecutó”. En pagos, publicaciones y otras acciones con efectos propios, esa diferencia merece atención antes de poner a un agente al mando de los reintentos.

Lo mismo ocurre con los lotes. Si una parte de los cambios salió bien, quiero un resultado por artículo. “Completado” para un lote incompleto dificulta la operación; “falló” sin mostrar qué se aplicó también. Una respuesta honesta ayuda más que una frase tranquilizadora.

El registro de la operación debe sobrevivir al operador

En mi diseño, los registros serían producidos por el servicio que ejecuta la acción y enviados a un destino que el agente no pueda borrar ni reconfigurar. Identificarían el plan, la aprobación, el intento, el resultado observado y las diferencias relevantes.

Eso permite responder preguntas sencillas: ¿quién autorizó, qué estaba autorizado y qué ocurrió realmente? Yo evitaría volcar datos personales y credenciales en esos registros. Una trazabilidad útil necesita pruebas suficientes, con acceso y conservación adecuados al contexto.

Si el destino de los registros no está disponible, el comportamiento debe estar definido de antemano. Algunas operaciones pueden esperar; otras pueden disponer de un mecanismo controlado de registro temporal. Para una acción sensible, seguir adelante sin evidencia no debería ser una improvisación decidida a mitad de la tarea.

También situaría la modificación de las propias reglas de monitoreo fuera de las herramientas de ese flujo. Pedir al operador que trabaje correctamente forma parte de las instrucciones. Darle el control del sistema que comprobará su trabajo crea una dependencia que prefiero evitar.

Conectar una herramienta exige más que conseguir una respuesta

MCP facilita la conexión entre agentes y herramientas. Su documentación de autorización aborda el acceso a recursos y operaciones protegidos; ese acceso debe implementarse según el transporte y el contexto del servidor. [5]

Para nuestro ejemplo, yo no ofrecería una herramienta llamada “ejecuta cualquier cosa en la cuenta”. Preferiría operaciones con una intención clara: consultar publicaciones permitidas, crear una propuesta, consultar el estado de un plan. La ejecución exigiría un vínculo con una aprobación válida.

También separaría los entornos. Probar la interpretación de una solicitud no necesita afectar a una cuenta real. Un entorno de pruebas debe mostrar las decisiones que se tomarían y permitir simular respuestas incompletas, demoras, datos desactualizados y denegaciones de permisos.

Estos escenarios enseñan más sobre el producto que una demostración en la que todo sale bien. Me gustaría observar al agente ante una restricción: ¿explica el pendiente, busca una alternativa permitida o intenta ampliar su propio acceso? Ese comportamiento debe observarse con operaciones controladas.

Qué pondría primero en producción

Empezaría por el beneficio que exige menos autoridad: organizar información, encontrar inconsistencias y preparar cambios. Es posible ahorrar mucho trabajo sin conceder, desde el primer día, la facultad de modificarlo todo.

Después compararía las propuestas con las decisiones humanas y examinaría los errores. ¿El modelo confundió cuentas? ¿Ignoró una variante? ¿Utilizó un dato antiguo? Esos problemas indican qué falta en el contexto, en las herramientas o en la presentación de la revisión. Cambiar de modelo por uno más caro no es una respuesta automática para todos ellos.

Solo entonces ampliaría la ejecución, por tipos de acción y con límites claros. Una operación recurrente, con criterios establecidos y una recuperación sencilla, puede ganar autonomía antes que una decisión comercial difícil de deshacer. La persona responsable debe poder suspender esa autonomía sin depender de una conversación larga con el agente.

La promesa que me entusiasma es disponer de software que ayude a pensar y elimine trabajo repetitivo, conservando la capacidad de comprender y corregir lo que sucede. Para quienes construimos integraciones, este es un terreno muy interesante: transformar el lenguaje humano en operaciones confiables.

Quiero agentes capaces de hacer mucho. Y quiero poder explicar, mirando el sistema, por qué pueden hacer aquello, bajo qué condiciones y hasta dónde pueden llegar. Si esa explicación depende únicamente de “le pedí que tuviera cuidado”, todavía queda desarrollo por delante.

Fuentes

[1] OpenAI — informe de monitoreo.

[2] Stripe — anuncio de Treasury for agents, del 21/10/2026.

[3] Stripe — documentación de Treasury for agents y referencia de disponibilidad.

[4] OWASP — LLM06:2025, Excessive Agency.

[5] Model Context Protocol — Understanding Authorization in MCP, versión 2026-07-28.