A esta altura el diagnóstico es consenso. Los modelos de lenguaje son probabilísticos. En un chatbot de consumo eso es una virtud; en un flujo de pagos, en la liquidación de un siniestro o en cualquier cosa que un regulador vaya a terminar leyendo, es un pasivo. La receta de siempre llega enseguida: envolver el modelo probabilístico en controles determinísticos.

La receta es correcta y no alcanza, porque lo difícil nunca fue ponerse de acuerdo en que hace falta determinismo. Lo difícil es ver por dónde el probabilismo vuelve a cruzar la línea que creías haber trazado. La falla más común en los sistemas agénticos regulados no es un control ausente. Es un control que también es probabilístico, disfrazado de determinístico.

Tres controles que son probabilísticos sin decirlo

Los tres aparecen en una reseña honesta del Agent Governance Toolkit de Microsoft escrita por Venkat Peri, que trabaja en infraestructura de IA agéntica para gestión patrimonial en Advisor360°. La reseña marca la debilidad de los dos primeros. En el tercero, la forma en que la reseña lo plantea queda del lado equivocado de la línea que traza este artículo, y el diseño del propio Peri queda del lado correcto.

Usar un LLM para clasificar la intención y tratar esa clasificación como una barrera de seguridad. El toolkit enfrenta el secuestro de objetivos con un clasificador semántico de intención, y Peri señala que ese clasificador "es, a su vez, una llamada a un LLM", así que "también es vulnerable a entradas adversariales" [1]. Si ponés un modelo delante del agente y a su veredicto le decís barrera de seguridad, armaste la barrera con una pieza probabilística que un atacante puede corromper. Es combatir probabilismo con probabilismo. Y justo con las entradas que importan, las fabricadas y las inyectadas, el guardián hereda la debilidad que tenía que cubrir.

Otorgar permisos según un puntaje de confianza calculado sobre el comportamiento. El mismo toolkit le asigna a cada agente un puntaje de 0 a 1000 según cómo se comporta, y el tramo en que cae ese puntaje define qué puede hacer. Peri lo considera una primitiva interesante y dice dónde falla: sin calibrar, "puede generar una falsa confianza en agentes que se portan bien y disparar restricciones excesivas sobre los legítimos" [2], de modo que necesita un ajuste propio de cada dominio antes de que alguien se apoye en él para autorizar. El ajuste achica el error, pero el número sigue siendo lo que era: una heurística calculada sobre lo que hace el propio agente. Apenas una decisión de autorización lo consulta (este agente es lo bastante confiable para hacer X), ese número queda metido en la cadena de autorización, y se equivoca justo cuando menos te lo podés permitir: un agente al que están manipulando puede portarse bien hasta el momento de la acción que importa.

Decidir si interviene una persona según la confianza del agente. El modelo tenía 0,7 de confianza, así que no se lo pasamos a nadie. La confianza del modelo es una señal que el modelo infiere sobre su propio estado, y acá carga con una responsabilidad de compliance: decidir cuándo tiene que intervenir una persona. La señal que decide si hay supervisión la produce justamente lo que la supervisión tiene que controlar. La reseña dice que el toolkit "no tiene una primitiva de flujo de trabajo con intervención humana" [3]. Su documentación, hoy, describe una: el anuncio de Microsoft habla de "flujos de aprobación con lógica de quórum" [4], y en el tutorial del toolkit una regla de política declara qué acciones requieren aprobación, y un pedido que nadie responde se rechaza al vencer el plazo. El punto de fondo de Peri se sostiene igual: algo tiene que decidir cuándo se le consulta a una persona. La reseña llama a esa capa Decision Gateway y la describe como "un juicio probabilístico que toma como entradas scores de confianza, la severidad de la consecuencia y el contexto" [5]. El diseño del propio Peri es más cuidadoso que esa frase. En el patrón Decision Gateway, qué acciones necesitan una persona se declara en la política del workflow (email.send y holdings.update con approval: required) antes de que se ejecute nada. En el confidence plane, una ejecución cuya confianza acumulada ya no se puede recuperar se corta y pasa a una persona. Ahí la confianza agrega un revisor, y nada en ninguno de los dos textos le permite sacar uno. Una señal de confianza del modelo nunca debería poder sacar a un revisor.

Los tres parecen controles, y los tres fallan igual: bajo presión adversarial o cuando cambia la distribución de los datos, la señal probabilística que tenía que protegerte es la que cede.

La línea no pasa entre IA y no IA

Hay que plantear bien la dicotomía, porque "¿determinístico o probabilístico?" es la pregunta equivocada. Los dos tienen lugar en el sistema. El componente probabilístico es extraordinario para un conjunto preciso de tareas (entender lenguaje, proponer acciones, hablar con una persona), y esas tareas no se las querés dar a una máquina de estados.

La pregunta de fondo es de qué puede hacerse cargo cada parte, y la línea que se sostiene separa responsabilidades: la comunicación y la propuesta pueden ser probabilísticas; la autoridad, la consecuencia y el compliance tienen que ser determinísticos y declarados.

El modelo puede proponer cualquier acción; si la acción se ejecuta lo decide una barrera determinística. El modelo puede redactar una redirección amable; un rechazo regulatorio es un texto fijo que define la política, no algo que se arma sobre la marcha. El modelo puede interpretar qué quiere un usuario; quién es ese usuario y qué puede tocar sale de un token firmado y de una base de datos. Hasta el "riesgo" va del lado determinístico: esta acción necesita una persona es una regla que alguien declara sobre la acción, y un score de riesgo que el modelo infiere en tiempo de ejecución es más probabilismo pidiendo que le crean.

Poné el componente probabilístico donde mejor trabaja y mantenelo lejos de todo lo que no puede variar.

Una prueba para cualquier control

Hay una prueba de una línea para saber si un control es real: ¿puede influirlo aquello en lo que no confiás?

Si lo que dice el modelo puede cambiar la decisión de un control, ese control es el modelo evaluándose a sí mismo. Un control real lee solo entradas que el modelo no puede fabricar: una identidad firmada criptográficamente, el estado confirmado de una base de datos, un valor que una persona declaró de antemano. Pasá tus "controles" por esa prueba y los que no lo son quedan afuera enseguida. La barrera con clasificador de intención, el puntaje de confianza y una escalada que la confianza del modelo puede saltear no la pasan; la autorización contra un token firmado, un texto de rechazo fijado por la política y una confirmación que una persona declaró sobre la acción, sí. Una señal del modelo igual puede volver más prudente al sistema (que vuelva a preguntar, o que rechace con palabras que no escribió) siempre que solo sume cautela y nunca otorgue un permiso.

Un evaluador separado no es lo mismo que un modelo que califica su propia salida, y los diseños de Peri usan uno. En What to ask your agentic AI vendor, los chequeos de compliance y de afirmaciones inventadas son barreras duras ("una sola detección de una afirmación fabricada o de una violación de compliance bloquea la salida" [6]), y un puntaje compuesto manda todo lo demás a entrega, a revisión de un curador o a rechazo. La prueba ordena ese diseño sin esfuerzo. Bloquear, rechazar y derivar a un curador solo suman cautela, así que pasan. Lo que la prueba señala es el otro camino: un puntaje que libera una salida sin que nadie más la mire. Para la comunicación, es una concesión razonable. Para cualquier cosa que cargue autoridad, consecuencias o una decisión de compliance, es una señal probabilística que otorga el permiso.

La mayoría de estas fallas sobreviven porque nadie le hizo al control la pregunta obvia.

Por qué en contextos regulados pesa más

Un control probabilístico que acierta el 98% de las veces sirve para un producto de consumo. En un contexto regulado, el 2% es la auditoría, y el modelo casi siempre acertaba no es un argumento que quieras llevarle a un regulador.

La regulación pide más que precisión: pide controles que puedas demostrar. La Regla 3110 de FINRA exige un sistema de supervisión "razonablemente diseñado para lograr el cumplimiento" [7], y en el artículo sobre proveedores Peri la lee así: "la Regla 3110 de FINRA (Supervisión) exige controles demostrables; un capability envelope es uno de ellos, un system prompt no" [8]. Las herramientas estadísticas tienen su lugar en un entorno de control, y revisar una muestra de casos es una de ellas. Pero el control que decide qué puede hacer un agente tiene que poder responder cuando alguien pregunta qué va a hacer con la próxima entrada. Una regla declarada responde con la regla y con el registro de haberla aplicado. Un control probabilístico solo puede responder con una tasa, por buena que sea, y casi siempre acierta es una estadística cuando lo que pidió el examinador era una demostración.

La disciplina

El instinto de agregarle barandas a un modelo probabilístico es correcto en la intención y peligroso en la práctica, porque las barandas armadas con piezas probabilísticas heredan la propiedad de la que querías escapar. La disciplina es más acotada y más difícil que "agregar controles": decidir de qué puede hacerse cargo cada parte, darle al componente probabilístico el trabajo para el que realmente es la mejor herramienta, y no dejar que nada probabilístico, por bien que le vaya en los benchmarks, se haga cargo de algo que tiene que salir igual cada vez. Trazar esa línea es una decisión; que no se mueva a medida que se suman controles es la mayor parte del trabajo.

Las citas están traducidas por el autor. Los originales, en inglés:

  1. Peri, reseña del toolkit: "is itself an LLM call" y "is also susceptible to adversarial inputs".
  2. Peri, reseña del toolkit: "can produce false confidence in well-behaved agents and trigger overly aggressive restrictions on legitimate ones".
  3. Peri, reseña del toolkit: "It does not have a HITL workflow primitive."
  4. Microsoft, anuncio del toolkit: "Approval workflows with quorum logic".
  5. Peri, reseña del toolkit: "a probabilistic judgment that takes confidence scores, consequence severity, and context as inputs".
  6. Peri, What to ask your agentic AI vendor: "a single detection of a fabricated claim or compliance violation blocks the output".
  7. FINRA, Regla 3110(a): "reasonably designed to achieve compliance".
  8. Peri, What to ask your agentic AI vendor: "FINRA Rule 3110 (Supervision) requires demonstrable controls; a capability envelope is one of those, a system prompt is not."

Nicolás Moreno construye Zarel: operaciones de IA gobernadas, donde la IA propone y el contrato dispone.