El agente ya ejecutó y después pidió permiso: acciones irreversibles en el ERP funerario

Son las once de la noche de un sábado. El agente de inteligencia artificial que la compañía conectó al ERP recibe una instrucción de rutina: reprogramar la cremación del servicio 4471 para el primer turno del domingo, porque un familiar viaja desde el exterior. El agente consulta la agenda del crematorio, libera el turno de la tarde, agenda el de la mañana — y entonces descubre que el horno de la mañana está en mantenimiento programado y que no hay turno alternativo ese día.

Su respuesta final es impecable: «He detectado un conflicto en la disponibilidad del crematorio. Lo correcto habría sido confirmar la disponibilidad del nuevo turno antes de liberar el existente; debí haber solicitado confirmación.» Es un párrafo que cualquier comité de riesgos aprobaría. Está bien razonado, es honesto y llega exactamente catorce segundos tarde: el turno original ya está liberado, la sala ya se reasignó, y el aviso automático ya salió hacia el teléfono de la familia.

Este artículo trata ese modo de fallo, que tiene nombre propio en la literatura desde julio de 2026, y trata la decisión de arquitectura que se deriva de él. Es el complemento de nuestra guía de gobierno de agentes de IA en el ERP funerario —que establece qué operaciones deben llevar firma humana— y de el artículo sobre el fallo silencioso —el sistema que dice «listo» sin haber hecho nada—. Aquí tratamos el caso inverso y peor: el sistema que sí hizo algo que no se puede deshacer, y además informa que se contuvo.

1. El problema de negocio: en este sector, «deshacer» casi nunca existe

Toda la conversación sobre automatización con IA en las empresas asume, sin decirlo, que el peor caso es un error que se corrige. En la mayoría de los sectores esa suposición es razonable: un pedido mal capturado se edita, un correo mal enviado se aclara, un registro mal creado se borra. El costo de un fallo es el costo de repararlo.

En una compañía funeraria esa suposición se rompe todos los días, y se rompe de tres maneras distintas que conviene no confundir. Hay cosas que se deshacen. Hay cosas que solo se compensan. Y hay cosas que simplemente ocurrieron. Una cremación ejecutada pertenece a la tercera categoría. Un cuerpo trasladado a otra sede, también. Un acta emitida y entregada, un aviso enviado a una familia que acaba de perder a alguien, una inhumación en un lote equivocado del parque: todas pertenecen a la tercera categoría, y ninguna tiene un botón.

Lo que cuesta hoy no es hipotético, y no se mide en multas. Se mide en tres monedas que el comité de dirección conoce bien:

• La confianza de una familia, que no se recupera. Un error operativo en un servicio funerario ocurre en el peor día de la vida de alguien. No hay descuento comercial ni carta de disculpa que lo repare, y el daño reputacional en una ciudad mediana se propaga por una vía que ninguna campaña alcanza.
• La exposición jurídica sobre un acto con forma legal. Autorizar una cremación, expedir un documento del expediente o cambiar la titularidad de un lote no son movimientos de inventario: son actos con requisitos de firma y con consecuencias frente a terceros.
• El costo de reconstruir la verdad. Cuando algo sale mal y hay un agente en el circuito, la primera pregunta del comité es «¿quién autorizó esto?». Si la respuesta honesta es «el agente lo hizo y después dijo que no debía», la compañía descubre que su registro documenta la narración del agente, no la secuencia de efectos.

Y hay un cuarto costo, silencioso, que es el que más frena los proyectos: la parálisis por sobre-bloqueo. Ante la duda, muchas compañías terminan exigiendo aprobación humana para absolutamente todo lo que el agente toque — incluido consultar una agenda o preparar un borrador. El resultado previsible es que el operador aprueba a ciegas, en lote, sin leer. La literatura de autorización tiene un nombre para eso, fatiga de consentimiento, y es la razón por la que un diseño de todo-o-nada no protege: produce el ritual de la aprobación sin la aprobación.

2. La evidencia: el agente no distingue consultar de ejecutar

En julio de 2026, un equipo de la Universidad de Illinois Urbana-Champaign publicó AgentAbstain, un banco de pruebas diseñado para una pregunta muy concreta: ¿saben los agentes cuándo no actuar? No mide si resuelven la tarea. Mide si reconocen las situaciones en las que la respuesta correcta es negarse o pedir aclaración — y, sobre todo, mide cuándo lo reconocen.

El diseño es lo que hace el estudio útil para una decisión de arquitectura. Cada tarea viene en pares: una variante en la que el agente debe actuar y otra, casi idéntica, en la que debe abstenerse. Y la evaluación no se conforma con leer lo que el agente responde: combina el juicio sobre el texto final con una verificación determinista de la traza de llamadas, que revisa si el agente llegó a invocar una herramienta de las que producen efecto. Es decir: separa lo que el agente hizo de lo que el agente dice que hizo.

Las cuatro maneras de no actuar (y solo una sirve)

Cruzar «¿ejecutó?» con «¿avisó?» da cuatro celdas, y esa matriz es la aportación más práctica del estudio para quien diseña un sistema. Estas son las proporciones sobre el total de corridas de abstención válidas:

Abstención post-hoc: el agente actúa y afirma verbalmente haberse abstenido; el modo más peligroso, porque combina efectos secundarios irreversibles con una falsa garantía de contención.— AgentAbstain: Do LLM Agents Know When Not to Act?, arXiv:2607.10059 (11 de julio de 2026)

Ese 2,6 % es, honestamente, el número que menos dice: está diluido sobre todas las corridas, incluidas las puramente informativas donde no hay nada irreversible que romper. Los números que importan para un ERP son otros dos. Primero: en las corridas operacionales —las que sí modifican el estado del sistema— dos de los modelos evaluados producen abstención post-hoc en torno a una de cada diez (10,1 % y 8,6 %). Segundo, y es el dato de auditoría: 98 de los 115 casos post-hoc solo se detectan exigiendo que la revisión de la traza y la lectura del texto concuerden. Con la sola lectura del texto, la mayoría de estos fallos se registran como éxitos.

El estudio incluso le pone nombre al submecanismo: lo llama act-then-discover — «los modelos se comprometen de forma irreversible antes de notar el disparador». No es que el agente ignore la restricción; es que la encuentra en el orden equivocado.

El hallazgo que decide la arquitectura

Hasta aquí, un director razonable podría concluir que basta con elegir un modelo mejor y pedirle que sea prudente con lo grave. El estudio cierra esa puerta con dos resultados.

El primero es que saber actuar y saber contenerse son capacidades distintas. La precisión media al decidir actuar es del 80,6 %; al decidir abstenerse, del 59,1 %. Son veintiún puntos de diferencia. Y no es que una arrastre a la otra: la correlación entre acertar ambas variantes del mismo par promedia −0,10 entre los diecisiete modelos, negativa en quince de ellos. Un modelo que resuelve la variante de actuar es, si acaso, ligeramente menos propenso a abstenerse bien en ese mismo par. Incluso restringiendo a los casos que cada modelo sí sabe resolver, el agente mediano falla la abstención en el 41 % de las variantes.

De ahí se sigue la conclusión de arquitectura, que es toda la tesis de este artículo: si el modelo no distingue por sí mismo entre consultar y ejecutar, la distinción tiene que estar fuera del modelo — en el catálogo de herramientas, en la compuerta que autoriza cada llamada y en el diseño de las operaciones mismas. Los propios autores lo dicen sin rodeos al cerrar: escalar la capacidad de resolver tareas no cierra esta brecha, porque la contención calibrada es un objetivo distinto.

3. Los tres niveles de reversibilidad de un ERP funerario

Aquí está el error de diseño que vemos con más frecuencia, y no es de tecnología: es de clasificación. Casi todos los modelos de gobierno de agentes parten de una división binaria —«lectura» contra «escritura», o «reversible» contra «irreversible»— y esa división no describe un ERP. En un ERP funerario hay tres niveles, y el error caro es colapsar el segundo con el tercero.

El punto que casi nadie tiene escrito es el del nivel 1, y conviene decirlo con la precisión que usa el ERP. En un sistema documental serio, un documento transaccional recorre tres estados: borrador, emitido, anulado. La anulación es un estado hacia adelante, no un retroceso. El documento emitido no desaparece cuando se anula: queda con su número, su fecha y su trazabilidad, y la anulación queda como un segundo hecho. Contablemente eso es correcto y es exactamente lo que se quiere. Pero significa que llamar «reversible» a una factura emitida es un abuso del lenguaje que se paga cuando alguien diseña el permiso del agente pensando en un «control + Z» que no existe.

Conviene decir que esta no es una invención nuestra ni una particularidad del sector: es ingeniería de sistemas transaccionales estándar, y está escrita en las guías de arquitectura de los grandes proveedores de nube desde mucho antes de que hubiera agentes. La guía del patrón de transacción compensatoria de Microsoft lo formula casi con las mismas palabras que usamos arriba: define puntos de no retorno claros y pasos irreversibles; en flujos complejos hay operaciones que no se pueden deshacer de forma segura ni significativa —cita textualmente los efectos externos y los actos jurídicamente vinculantes—; identifica qué pasos son compensables y cuáles irreversibles; y diseña el flujo para que los pasos irreversibles ocurran solo después de que todas las validaciones críticas hayan pasado. La misma guía añade la regla de gobierno: cuando la decisión es de alto impacto o difícil de automatizar de forma fiable, incluye a una persona en ella.

Qué datos y qué objetos del ERP intervienen

En SFUN, la clasificación anterior cae sobre objetos concretos del sistema. Vale la pena nombrarlos porque el ejercicio deja de ser abstracto:

• Fallecido. Concentra la categoría de datos más protegida por cualquier régimen de la región: la causa de muerte (natural, violenta u otros) y el destino final (inhumación o cremación). El destino final no es un campo más: es el que define si el acto que viene es de nivel 2.
• Exequias. Su estado recorre «pendiente de programación → en progreso → programada → terminada → cancelada». Programar es nivel 1 mientras nadie haya sido notificado; a partir del aviso a la familia, es nivel 2 en la práctica aunque el sistema permita cambiar el campo.
• Contrato inicial y su autorización. La venta de previsión tiene su propio circuito de aprobación, con estados y motivos catalogados. Es el ejemplo más claro de operación que ya nació con compuerta.
• Documentos de venta y de recaudo. Facturas, entradas de pago, referencias de recaudo. Nivel 0 en borrador, nivel 1 al emitirse.
• Parque cementerio. Adjudicación de lote, bóveda o cenizario, y cambios de titularidad. Nivel 2 por su efecto jurídico a largo plazo, como ya tratamos en la guía de gestión de parques cementerio a escala.
• Traslados y cadena de custodia. Cada movimiento del cuerpo es nivel 2 por definición: el eslabón que se rompe no se repara, solo se documenta. Es el tema de la guía de cadena de custodia.

4. Cómo se arma la compuerta, paso a paso

La consecuencia práctica de todo lo anterior es que la compuerta va antes y va fuera del modelo. Estos son los cinco pasos, en el orden en que hay que hacerlos.

Paso 1. Clasifica el catálogo y publica la clase en la propia herramienta

El nivel de reversibilidad no puede vivir en un documento de Word: tiene que viajar con la herramienta, en su declaración, para que el cliente que la invoca lo vea sin preguntar. El protocolo MCP prevé esto con anotaciones por herramienta —si es de solo lectura, si es destructiva, si es idempotente— y su valor está justamente en llegar antes de la llamada.

Paso 2. Separa preparar de ejecutar, y haz que preparar sea gratis

Este es el paso que más rendimiento da y el que menos se implementa. Si la única forma de saber si una operación va a funcionar es ejecutarla, el agente la va a ejecutar. La solución es que el catálogo ofrezca, para cada operación de nivel 1 o 2, una operación gemela sin efecto: valida y reporta, pero no persiste. El agente puede llamarla cuantas veces quiera, y así el paso de descubrimiento —que es donde ocurre el act-then-discover— sucede en un terreno donde equivocarse no cuesta nada.

Hay una variante de este paso que merece nombre propio, porque es la que convierte el principio en una regla verificable: no ejecutes el acto irreversible hasta que el hecho del que depende sea firme, y haz que «firme» sea un estado del documento y no una casilla que el agente pueda marcar. En una funeraria eso significa que la cremación no se ejecuta mientras la autorización, la identificación y el certificado no estén en estado firme; y que el turno anterior no se libera mientras el nuevo no esté confirmado.

Un banco de pruebas publicado en septiembre de 2026 puso número a esa diferencia en un dominio vecino —conciliación de pagos entre el procesador, el libro mayor, el ERP y el extracto bancario, con mensajes que llegan tarde, duplicados o desordenados— y midió los resultados por el efecto económico realmente ejecutado, no por la respuesta del agente. Sobre 14.445 episodios y nueve políticas distintas, el contraste es el siguiente:

Dos advertencias de honestidad sobre esa tabla, y las hace el propio autor. La primera: los intervalos son anchos —el estudio pide expresamente que se lea la comparación entre políticas y no el número aislado—, y la comparación es la que aguanta: la ventaja de la compuerta sobre el bucle sin control es de unos 97 dólares por episodio, con un intervalo que excluye el cero. La segunda, y es la que más dice de este debate: los modelos de lenguaje evaluados descubrieron por su cuenta la estrategia de esperar la confirmación, sin que nadie se la indicara — y aun así perdieron alrededor del doble de dinero que la compuerta escrita a mano. Saber cuál es la estrategia correcta y ejecutarla de forma consistente no son la misma cosa, y esa distancia es exactamente lo que compra una compuerta determinista.

Paso 3. Autoriza por el valor del argumento, no por el nombre de la herramienta

Aquí está la distinción que casi todos los diseños se saltan. Que un agente pueda llamar a la herramienta de emitir un documento no dice nada sobre si puede emitirlo por ese monto, sobre ese contrato o en ese estado. Un trabajo de mayo de 2026 sobre autorización en MCP lo plantea exactamente así: los interruptores amplios de «permitir siempre» no consideran los argumentos peligrosos de la llamada y producen fatiga de consentimiento; la alternativa es un permiso con alcance, que autoriza lo seguro de forma automática y escala solo lo que se sale del rango.

El estudio incluye una prueba con usuarios reales, pequeña pero elocuente: de dieciséis participantes, quince prefirieron el permiso con alcance frente al esquema tradicional, y adoptaron ese tipo de permiso tres veces y media más que las concesiones a nivel de herramienta. Es la evidencia de que la compuerta fina no es más incómoda que la gruesa: es menos incómoda, porque deja de pedir permiso para lo que no lo necesita.

Y no es una idea de laboratorio: el sector de pagos ya la lleva a producción, con una forma que se traduce casi literalmente a nuestro caso. En el modelo de comercio con agentes de Stripe, lo que se le entrega al agente no es un permiso para pagar: es un credencial acotada de un solo uso que lleva escritas sus propias fronteras —importe máximo, moneda y fecha de expiración— y que además está dirigida a un vendedor concreto. Se puede revocar en cualquier momento antes de que se use, y su estado final es «desactivada», con el motivo registrado: consumida, expirada o revocada.

Paso 4. Verifica el efecto contra la traza, no contra el relato

Si algo deja claro la matriz de cuatro celdas es que el texto final del agente no es una fuente confiable sobre lo que el agente hizo. La verificación tiene que ser determinista y sobre la secuencia de llamadas: ¿se invocó alguna herramienta de nivel 1 o 2 en esta conversación, sí o no? Es una pregunta binaria, barata de responder y que no admite interpretación — y es la que descubre los casos en que el agente narra contención después de haber ejecutado.

Paso 5. Diseña el fallo para que sea accionable, no solo visible

Falta un eslabón, y es el que convierte un error en una duplicación. Cuando una llamada falla, el agente necesita saber qué hacer, no solo que falló. Una auditoría reciente sobre servidores MCP —pequeña y declaradamente ilustrativa: veintiún fallos inducidos en diez servidores— resume el problema en una frase: un cliente que recibe una marca de error sabe que algo salió mal, y aun así puede no tener ninguna base legible por máquina para decidir si corregir un argumento, autenticarse, esperar, elegir otra herramienta o detenerse.

5. El bucle: qué se revisa cada semana

Un control de este tipo no se instala, se mantiene — porque el catálogo de herramientas crece y porque cada versión del modelo cambia el comportamiento. El bucle mínimo que recomendamos cabe en una reunión corta:

1. Cada día, automático: lista de operaciones de nivel 2 ejecutadas en las últimas 24 horas y quién las firmó. La meta no es leerla: es que la lista de «sin firma identificada» esté vacía y que su longitud aparezca sola en el tablero.
2. Cada semana, quince minutos: revisión de los casos en que el agente ejecutó y después señaló un problema. Son pocos y son oro: cada uno describe una compuerta que faltaba antes de esa herramienta.
3. Cada semana: herramientas nuevas incorporadas al catálogo sin nivel asignado. Debe ser cero. Una herramienta sin clasificar es, por defecto, una herramienta de nivel 2 que nadie está vigilando.
4. Cada mes: revisión de los umbrales. Si un rango obliga a escalar más del 30 % de las llamadas, el rango está mal calibrado y está fabricando aprobación automática.
5. Con cada cambio de versión del modelo: volver a pasar el conjunto de casos límite propios. El comportamiento de contención no está garantizado entre versiones, y el estudio citado es precisamente la razón para no darlo por heredado.

6. Gobierno y límites: lo que nunca se automatiza

La lista siguiente no se negocia por conveniencia operativa. Está deliberadamente formulada como prohibiciones sobre el agente, no como recomendaciones al operador:

• Ejecutar o autorizar una cremación. El agente puede verificar que el expediente esté completo, que los documentos estén firmados y que el turno exista, y decirlo. La autorización la firma una persona identificada.
• Enviar cualquier comunicación a una familia sobre el estado del servicio. Un mensaje sobre un horario que cambió llega al teléfono de alguien que acaba de perder a un familiar. No es una notificación transaccional y no se trata como tal.
• Adjudicar un espacio del parque o cambiar una titularidad. Efecto jurídico a décadas. El agente prepara el expediente; no lo cierra.
• Registrar o modificar un movimiento de la cadena de custodia sin operador identificado. El valor del registro es que hay un nombre detrás de cada eslabón.
• Ampliar su propio alcance. Ninguna herramienta que cree usuarios, asigne roles o modifique permisos entra al catálogo del agente. Nunca, ni con aprobación.
• Decidir sobre una negativa de cobertura. El agente reúne y cita la cláusula; la decisión y su motivación son humanas, como tratamos en el artículo sobre la negativa motivada.

Conviene añadir una advertencia sobre el alcance de todo lo anterior, porque el sobre-prometer en esta materia se paga caro. Un trabajo de mayo de 2026 plantea —de forma explícitamente informal, y así hay que citarlo: sus autores lo llaman un argumento de imposibilidad, no un teorema— que ninguna política fija puede impedir todos los ataques basados en contexto sin bloquear también flujos legítimos: cualquier regla de «nunca hagas X» bloqueará casos válidos, y cualquier regla de «permite X» admitirá un contexto construido para que X parezca apropiado. La conclusión práctica no es rendirse. Es cambiar el objetivo de la conversación con el comité: no se compra «un agente que nunca se equivoca», se compra contención del radio de daño — permisos por valor, operaciones preparables sin efecto y firma humana en lo que no se deshace.

7. Qué existe hoy en SFUN y qué todavía no

Todo lo que sigue está verificado contra la rama principal del repositorio del producto. Lo presentamos separado en dos bloques a propósito, porque la parte que falta importa tanto como la que está.

Lo que ya está construido

Vale la pena detenerse en el umbral de autorización del servicio, porque es la pieza que menos se conoce y la que mejor ilustra la tesis: es una compuerta que lee el valor —cuánto lleva pagado el contrato, cuántos traslados se han consumido— y no solo el nombre de la operación. Existe en el ERP desde antes de que hubiera agentes, porque el problema no lo trajo la IA: la IA solo lo hizo urgente. Puedes ver cómo encaja en la operación completa en el módulo de gestión de servicios funerarios y en SFUN MCP.

Lo que todavía no existe (hoja de ruta, sin rodeos)

Lo decimos así, con los huecos por delante, por la misma razón de siempre: preferimos que un comité apruebe un proyecto sabiendo qué controles compra hoy y cuáles están en camino, antes que descubrirlo el día de la auditoría. Mientras tanto, los tres huecos tienen mitigación disponible y verificable: el interruptor de solo lectura, la exigencia de que las operaciones de nivel 2 pasen por el circuito de autorización del ERP y no por el agente, y la herencia estricta de permisos.

8. KPIs, con línea base y meta

La línea base honesta de casi toda compañía que empieza esto es cero: no es que los indicadores estén mal, es que no existen. Conviene escribirlo tal cual en el acta del comité y no maquillarlo.

9. Hoja de ruta de adopción

10. Los cinco errores más comunes

1. Pedirle al agente que confirme antes de actuar, y darlo por resuelto. Es la instrucción más natural del mundo y es exactamente lo que la evidencia dice que falla: el agente puede emitir la confirmación después del efecto y contarla como contención. La confirmación tiene que ser un mecanismo del sistema, no una promesa del modelo.
2. Confiar en que un modelo mejor será más prudente. Saber actuar y saber contenerse son capacidades distintas —veintiún puntos de diferencia—, y la correlación entre ambas es levemente negativa. Escalar el modelo no compra prudencia.
3. Colapsar el nivel 1 con el nivel 2. Tratar una factura emitida como si fuera una cremación produce sobre-bloqueo y fatiga de aprobación; tratar una cremación como si fuera una factura produce un titular. Son políticas distintas porque son problemas distintos.
4. Auditar el historial de conversaciones en lugar de la traza de llamadas. La mayoría de los casos de «ejecutó y dijo que se contuvo» solo se detectan cuando ambas señales tienen que concordar. Con la conversación sola, se registran como éxitos.
5. Dejar el reintento en manos del agente. Un fallo ambiguo en una operación con efecto no es un error: es un duplicado esperando ocurrir. Sin clave de idempotencia, no hay reintento automático.

Preguntas frecuentes

¿Un agente de IA puede programar o autorizar una cremación por su cuenta?

No, y no debería poder aunque técnicamente se pudiera configurar. Es una operación de nivel 2: no tiene estado de anulación, tiene requisitos de firma y sus consecuencias son físicas y jurídicas. El agente aporta valor real en el paso anterior —verificar que el expediente esté completo, que los documentos estén firmados, que el turno exista y que no haya conflicto de agenda— y ese trabajo de verificación es precisamente el que más tiempo consume hoy. La autorización la firma una persona identificada.

¿No basta con instruir al agente para que pida confirmación antes de hacer algo grave?

No basta, y esa es la conclusión central de este artículo. La instrucción es correcta y el agente incluso la cumple a menudo — pero puede cumplirla en el orden equivocado, ejecutando primero y advirtiendo después. Además, los modelos evaluados no se contienen más cuando la acción modifica el estado del sistema que cuando solo lo consulta: la diferencia medida es de un punto porcentual, estadísticamente indistinguible de cero. La confirmación tiene que ser un paso del sistema que ocurre antes de que la llamada llegue al ERP, no una conducta esperada del modelo.

¿Anular una factura en el ERP no es lo mismo que deshacerla?

No. En un ERP documental, la anulación es un estado hacia adelante: el documento emitido conserva su número, su fecha y su trazabilidad, y la anulación se registra como un hecho adicional. Contablemente es lo correcto, pero significa que el efecto ya ocurrió: el folio se consumió, el documento se transmitió a la autoridad tributaria en la mayoría de los países de la región y la nota de crédito correspondiente es un documento nuevo, no un borrado. Por eso lo clasificamos como nivel 1 —reversible solo con compensación— y no como reversible a secas.

¿Esto significa que no conviene conectar un agente de IA al ERP?

Al contrario: significa que conviene conectarlo bien. La enorme mayoría del valor de un agente sobre un ERP funerario está en operaciones de nivel 0 —consultar el estado de la operación del día, preparar borradores, cruzar cartera, armar el informe del comité, verificar que un expediente esté completo— donde el riesgo es bajo y la ganancia de tiempo es inmediata. El problema no es el agente: es exponerle un catálogo sin clasificar en el que consultar una agenda y liberar un turno de crematorio se ven exactamente igual.

¿Cómo sé si mi implementación actual tiene este problema?

Con una prueba de una hora. Toma el catálogo de herramientas que tu agente tiene expuestas y responde tres preguntas: ¿cuántas de ellas producen un efecto que no se puede deshacer? ¿Cuántas de esas tienen una gemela que permita verificar sin ejecutar? ¿Y puedes decir, mirando el registro del mes pasado y no la conversación, cuántas veces se invocó una de ellas y quién lo autorizó? Si la respuesta a la tercera pregunta es «habría que revisar los chats», ya tienes el diagnóstico.

¿Qué pasa si la llamada falla y el agente no sabe por qué?

Es el escenario que produce duplicados, y hay que diseñarlo explícitamente. Una marca de error dice que algo salió mal, pero no suele decir si conviene corregir un argumento, autenticarse, esperar o detenerse — y un agente sin esa señal reintenta. En operaciones de nivel 1 y 2 la regla es que no hay reintento automático sin una clave de idempotencia que garantice que el segundo intento no produce un segundo efecto; sin ella, el fallo se escala a una persona.

¿Esto aplica igual en todos los países de Latinoamérica?

El modelo de tres niveles sí: es una propiedad del sistema y de la operación, no de la jurisdicción. Lo que cambia por país son dos cosas concretas. La primera, qué tan irreversible es el nivel 1: donde la facturación electrónica está consolidada, el documento sale hacia la autoridad en el momento de emitirse, y eso endurece la clasificación. La segunda, el marco de datos personales y de decisiones automatizadas, que en varios mercados de la región ya obliga a informar a la persona afectada cuando un sistema automático decide sobre ella. La recomendación práctica es la de siempre: construye el control con el estándar más exigente que te aplique, no país por país.

En resumen

El agente del ejemplo inicial no era un mal agente. Razonó bien, detectó el conflicto y lo comunicó con claridad. Su único error fue de orden: descubrió el problema después de haber cruzado la línea. Y la evidencia disponible dice que ese orden no se corrige pidiéndoselo, ni escalando el modelo, porque el sistema no registra por sí mismo que una acción con efecto sea distinta de una consulta.

La distinción la pone la arquitectura. Clasifica el catálogo en tres niveles. Haz que preparar sea gratis y ejecutar sea explícito. Autoriza por el valor del argumento, no por el nombre de la herramienta. Verifica contra la traza, no contra el relato. Ninguno de los cuatro pasos requiere un modelo mejor, y los cuatro se pueden empezar esta semana.

Fuentes de este artículo

• AgentAbstain: Do LLM Agents Know When Not to Act? — Liu, Zhang, Kasprova, Rabbani, Zahraei, Zhang, Ebrahimpour-Boroojeny y Chandrasekaran, University of Illinois Urbana-Champaign. arXiv:2607.10059, versión del 11 de julio de 2026. Preprint sin revisión por pares. De aquí salen la matriz de cuatro modos, la abstención post-hoc, la brecha de veintiún puntos entre actuar y abstenerse, y el resultado de que la mutación de estado no cambia el comportamiento de contención.
• Options, Not Clicks: Lattice Refinement for Consent-Driven MCP Authorization — Li, Chen, Wang, Khabra, Shezan, Feng y Tian. arXiv:2605.11360, versión del 12 de mayo de 2026. Preprint. De aquí sale el argumento sobre el consentimiento binario, la fatiga de consentimiento y el estudio con dieciséis participantes sobre permisos con alcance.
• Can MCP Clients Decide What to Do After Failure? A Result-Only Actionability Audit — Rishabh Mehan. arXiv:2609.00072, versión del 31 de agosto de 2026. Preprint de autor único; su autor lo describe como un estudio ilustrativo pequeño y advierte que no permite estimar prevalencia. Lo citamos solo por la distinción entre un fallo visible y un fallo accionable.
• AI Agents May Always Fall for Prompt Injections — Abdelnabi y Bagdasarian. arXiv:2605.17634, versión del 17 de mayo de 2026. Preprint. El planteamiento de imposibilidad es explícitamente informal —sus autores lo llaman un argumento, no un teorema— y así lo citamos.
• FinalityBench: An Effect-Level Benchmark for Agent Decisions Under Delayed and Conflicting Financial Finality — Abhishek Sharma. arXiv:2609.04706, versión del 4 de septiembre de 2026. Preprint de autor único. De aquí salen las cifras de la compuerta de confirmación firme sobre 14.445 episodios. Su autor advierte que los intervalos son anchos y que la comparación entre políticas es más informativa que el valor puntual; así lo citamos.
• Tool Annotations, blog oficial del Model Context Protocol, 16 de marzo de 2026 — Ola Hungerford, Sam Morrow y Luca Chang. blog.modelcontextprotocol.io. De aquí sale la advertencia de que las anotaciones no son un mecanismo de imposición y de que las garantías reales deben vivir en controles deterministas.
• Shared payment tokens, documentación de producto de Stripe sobre comercio con agentes. docs.stripe.com. De aquí sale el ejemplo de credencial acotada por importe máximo, moneda, caducidad y contraparte, revocable y de un solo uso.
• Compensating Transaction pattern, Azure Architecture Center, Microsoft. learn.microsoft.com. De aquí sale la formulación de los puntos de no retorno, la distinción entre pasos compensables e irreversibles y la regla de ordenar el flujo para que lo irreversible ocurra al final.
• Código del producto SFUN, rama principal, consultado el 9 de septiembre de 2026: modo de solo lectura y anotaciones de herramienta del conector; catálogo de acciones con validación sin persistencia y creación de documentos en borrador; y los doctypes de verificación de autorización de servicios, umbral de autorización, exequias y fallecido.