Un asesor escribe una pregunta en un agente de gestión patrimonial. El clasificador la asocia a una skill y el agente responde: con fluidez, con datos reales, y con un problema regulatorio apenas la respuesta queda en un log. Parecía algo que el agente podía contestar, y el agente no tenía ningún mandato para contestarlo.

Con esa escena abre Intent Classification isn't a Quality Gate, de Venkat Peri, y el diagnóstico que sigue es certero. Un clasificador de intención responde ¿con cuál de nuestras skills conocidas coincide esta entrada? Es acotado, seguro de sí e indiferente a una pregunta anterior: si el agente debería ocuparse de esa entrada en primer lugar. Lo que propone Peri es un chequeo acotado y barato que corre antes del ruteo. Un modelo chico lee la entrada contra una rúbrica de lo que el agente tiene que rechazar, y devuelve pass, o fail con un motivo. El diagnóstico es correcto, y el patrón también.

Quiero discutir un solo punto donde esa capa, tal como está propuesta, se equivoca. Es el punto donde más hay en juego, y está dentro de la regla que más sensata suena.

Lo que no está en discusión

Un chequeo de alcance antes del ruteo de intención es la arquitectura correcta. Tiene que ser barato, y hay que entenderlo como lo que es. Peri lo deja claro: el chequeo de entrada "no es una frontera de seguridad" [1]. La frontera de confianza real es la autorización (quién es el usuario, qué tiene derecho a ver, qué va a permitir el servicio de más abajo), y vive en el camino de los datos, aplicada por la capa de servicios. En palabras de Peri, "un clasificador basado en un prompt no tiene por qué cargar con ese peso" [2].

En todo eso estoy de acuerdo. El desacuerdo está en la regla siguiente: sesgar con fuerza hacia dejar pasar [3].

La asimetría de costos detrás de "dejar pasar", y dónde se invierte

El argumento para sesgar el chequeo hacia dejar pasar se apoya en una asimetría de costos. Un falso positivo bloquea a un usuario legítimo, que reformula, vuelve a quedar bloqueado y deja de confiar en el agente. Un falso negativo deja pasar la consulta al ruteo, donde o coincide con una skill y produce una mala respuesta, o no coincide y se deriva a otra salida. Peri calcula ese costo en una pasada de ruteo: "Recuperable" [4]. Bloquear a un usuario real cuesta más que admitir a uno malo, así que el sesgo va hacia admitir, y la rúbrica lo escribe dos veces, empezando por ante la duda, dejá pasar [3].

Para la pertinencia temática, es correcto. Para una categoría está mal, y es justo la que viene con un regulador detrás.

Peri la nombra primero: la violación de una política del dominio, como el asesoramiento de inversión en un agente patrimonial o una opinión que depende de la jurisdicción en un agente legal. Son pedidos que parecen tener respuesta, y el agente no tiene mandato para responderlos. El artículo marca incluso algo que a la mayoría de los equipos se les escapa: la supervisión alcanza a una respuesta dirigida al asesor tanto como a una dirigida al cliente. "El uso interno no es un puerto seguro" [5]. Las reglas de FINRA son tecnológicamente neutrales y se aplican a una herramienta de IA generativa igual que a cualquier otra (Regulatory Notice 24-09).

La categoría, entonces, es la correcta. El problema es el valor por defecto que hereda. En una violación de política del dominio, un falso negativo cuesta mucho más que una pasada de ruteo, y no tiene nada de recuperable: es una respuesta prohibida que va a tener que pasar una auditoría que no va a pasar. Si el chequeo duda de si un pedido es asesoramiento de inversión, dejarlo pasar es la respuesta equivocada.

En esta categoría la asimetría se da vuelta, y un falso negativo sale mucho más caro que un falso positivo. Un sesgo parejo hacia dejar pasar deja poco protegida justo a la categoría donde más hay en juego. Son dos problemas distintos con la misma forma, y necesitan dos niveles con valores por defecto distintos.

La distinción que habilita el segundo nivel

Cuando rechazás una pregunta fuera de tema (no te puedo ayudar con recetas de cocina, pero te muestro tu cartera), el rechazo es comunicación. Su trabajo es ayudar al usuario con lo que quiera hacer después, y sale mejor si se redacta en contexto. Que lo escriba el modelo. La rúbrica de Peri hace eso: el modelo que chequea devuelve {"pass": false, "feedback": "<one friendly sentence>"}, y el artículo trata esa oración como texto para el usuario, que tiene que ser "amable, específico y accionable" [6]. Para ese tipo de rechazo, es lo correcto.

Cuando el rechazo es en un límite regulatorio, es otra cosa. Su contenido lo fija la política, y el contexto de la conversación no lo puede cambiar. Es la postura de compliance a la vista: una salida de control que, casualmente, se muestra como texto.

El modelo, entonces, puede clasificar la entrada, pero no debería redactar el rechazo. Hay dos motivos. Una salida de control que cambia según el contexto dejó de ser una salida de control, y un modelo al que se le pide redactar un rechazo puede, en los casos límite que más importan, terminar metiendo en el rechazo lo mismo que tenía prohibido decir. Ya tratamos al modelo como una interfaz de comunicación y dejamos la ejecución en otro lado. Acá vale la misma división: la comunicación la escribe el modelo, las salidas de control son determinísticas, y un rechazo regulatorio es una salida de control.

Cómo es el nivel duro en código

En Zarel este nivel ya está implementado en el runtime. El contrato de un agente patrimonial declara el límite:

treatment:
  topic_scope:
    hard_refusals:
      confidence_threshold: 0.60
      categories:
        - name: investment_advice

y el texto del rechazo vive en el plano de política e i18n, nunca en el modelo:

topic_refusals:
  investment_advice:
    control_message: No puedo brindar asesoramiento ni recomendaciones de inversión.
      Puedo ayudarte con registros de cuenta, información histórica, documentos
      y flujos de trabajo operativos.

De ahí salen cuatro propiedades, y el runtime hace cumplir cada una en código. El único modelo que interviene es el clasificador que etiqueta la entrada.

Sesgo a rechazar. La asimetría se invirtió, así que el valor por defecto también. El umbral se fija bajo, y el schema del contrato no acepta uno mayor a 0,7: cuando el clasificador nombra una categoría prohibida, alcanza con una confianza moderada para rechazar, y si la nombra sin darle un puntaje, también rechaza.

Falla cerrado si no hay veredicto. Cuando el clasificador da error o el proveedor no responde, un filtro de pertinencia temática sigue por el camino normal. Un filtro regulatorio no puede hacer eso. No lo pudimos clasificar, así que lo respondimos es el comportamiento equivocado para un límite del que sos legalmente responsable. Sin veredicto, el nivel duro devuelve un rechazo genérico de límite regulado, y como el umbral tiene techo, un tenant no lo puede subir tanto como para apagar el nivel. Además corre antes de que el filtro temático se haga a un lado por un flow activo, así que una pregunta regulada en medio de un flow se encuentra con el mismo límite.

Redacción determinística. El rechazo sale del plano de política, traducido y fijo. Misma categoría, mismo idioma, mismas palabras, siempre, y el modelo que clasificó la entrada nunca toca el texto. Eso un auditor lo puede comprobar; el modelo redactó un rechazo no le deja nada para comprobar.

Registrado como evento de control. Cada rechazo duro se escribe en una tabla de auditoría propia antes de que salga la respuesta, con la categoría, el motivo, un hash de la entrada y una copia enmascarada; el texto original nunca se guarda.

Este nivel tiene un límite: sigue sin ser tu frontera de seguridad. La formulación de Peri es la correcta: "Si un usuario pregunta por datos a los que no debería poder acceder, la respuesta no es 'el clasificador lo rechazó'. La respuesta es 'el servicio no devolvió los datos'" [7]. La autorización vive en el camino de los datos. El nivel duro gobierna lo que el agente va a decir sobre un tema prohibido; lo que el agente tiene permitido hacer se decide en otro lado.

Hay un segundo límite, y lo nombra el texto siguiente de Peri. En Your Intent Classifier is Solving the Wrong Problem, la pregunta ¿cómo funciona una backdoor Roth conversion? [8] puede ser curiosidad, una decisión a punto de ejecutarse o una consulta en nombre de un padre o una madre, y nada en el texto dice cuál. Ningún clasificador resuelve eso, y este no lo intenta. El contrato describe qué cubre la categoría (en el contrato patrimonial: recomendaciones de compra o venta, asesoramiento de idoneidad, guía de asignación, predicciones de precios, asesoramiento personalizado), y al clasificador se le pregunta si el mensaje cae adentro. Un nivel sesgado a rechazar va a seguir rechazando, en el margen, alguna pregunta que era pura curiosidad: es el costo que acepta para no contestar las que no lo eran. Tampoco vuelve segura la pregunta ambigua. Lo que el nivel deja pasar lo responde el modelo, y ahí la receta de Peri es la correcta: armar la respuesta alrededor de los factores de decisión del dominio, porque "la arquitectura se trata de que la respuesta sobreviva cuando el modelo entiende mal al usuario" [9].

Por qué el nivel duro no tiene perillas

Una vez que tenés esto, la tentación es hacerlo todo configurable por categoría: que falle abierto acá, que lo redacte el modelo allá, una perilla de confianza en cada una. No lo hagas. El valor de "duro" es que significa una sola cosa: falla cerrado, determinístico, sin excepciones. Si una categoría marcada como "dura" se puede configurar para fallar abierta, un auditor ya no puede confiar en la palabra. La flexibilidad va donde no puede desgastar la garantía: en qué categoría es dura, nunca dentro de la garantía.

Lo que está en juego

Peri cierra con lo que pide la primera revisión: el registro de auditoría de cada consulta fuera de alcance que el agente respondió. Una capa sesgada a dejar pasar registra sus rechazos, pero los pedidos dudosos que dejó pasar son los que terminan en ese registro, y los rechazos que registró son oraciones que escribió un modelo. El diseño más completo de Peri no depende solo del chequeo de entrada: en What to ask your agentic AI vendor, los chequeos de compliance y de afirmaciones inventadas sobre cada salida son barreras duras, y "una sola detección de una afirmación fabricada o de una violación de compliance bloquea la salida" [10]. Es una segunda red, y buena. También es un modelo que lee una respuesta que ya existe, mientras que un límite se declara antes de que se escriba cualquier respuesta. Un nivel determinístico responde por cada pedido que rechazó, por construcción: un evento registrado y fijado por la política, con una categoría, un motivo y un texto fijo, versionado con el contrato, que un regulador puede leer. Lo que el clasificador no detecta sigue sin detectarse, y por eso el nivel está sesgado a rechazar.

La demo pública de este contrato todavía no está arriba. Escribinos si querés ver cómo responde a "¿debería pasar mi cartera a acciones tecnológicas?" con el texto de la política, palabra por palabra.

La clasificación de intención decide qué hacer con una pregunta. La capa anterior, como dice Peri, decide "si el agente debería siquiera ocuparse de la pregunta" [11]. Para la mayoría de los agentes, esa segunda decisión puede ser una conjetura indulgente y conversacional. Para los que operan dentro de un límite regulatorio, tiene que ser un control determinístico, con una categoría declarada, palabras fijas y un registro de cada rechazo.

Este es el caso del rechazo regulado dentro de una línea más amplia: la comunicación y la propuesta pueden ser probabilísticas, pero la autoridad, la consecuencia y el compliance tienen que ser determinísticos y declarados. El argumento general está en No se combate el probabilismo con probabilismo.

Las citas están traducidas por el autor. Los originales, en inglés, de Intent Classification isn't a Quality Gate salvo donde se indica:

  1. "is not a security boundary".
  2. "a prompt-based classifier has no business carrying that weight".
  3. "bias toward pass, hard" y, en la rúbrica, "when in doubt, pass".
  4. "Recoverable."
  5. "Internal use is not a safe harbor."
  6. "kind, specific, and actionable".
  7. "If a user asks a question about data they should not be able to access, the answer is not “the classifier refused.” The answer is “the service did not return the data.”"
  8. Your Intent Classifier is Solving the Wrong Problem: "how does a backdoor Roth conversion work?".
  9. Your Intent Classifier is Solving the Wrong Problem: "architecture is about the response surviving when the model gets the user wrong".
  10. What to ask your agentic AI vendor: "a single detection of a fabricated claim or compliance violation blocks the output".
  11. "whether the question is one the agent should engage at all".

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