Cinco decisiones que el modelo de un agente de IA nunca debe tomar. Todo lo demás, sí
Taxbit, Okta, AWS y una arquitectura de referencia de Microsoft coinciden: el modelo propone; los sistemas deterministas deciden identidad, umbrales, importes, orden y registro.
Escuche este artículo · 4 min
Narración completa del artículo, generada con IA.
Las revisiones de diseño de agentes de IA tienden a discutir sobre lo que no importa. Los equipos debaten qué modelo es lo bastante preciso, como si la precisión fuera el control. En los diseños en producción publicados en las últimas semanas, la precisión no es lo que mantiene seguro al agente. Lo que lo mantiene seguro es una lista corta de decisiones que el modelo no puede tomar nunca.
Esa lista está convergiendo. Esta es nuestra versión, y es una opinión, no un hecho: cinco decisiones que pertenecen a sistemas deterministas, con el modelo libre para hacer todo lo demás.
Las cinco
| Quién decide | Ejemplo de diseños en producción | |
|---|---|---|
| 1. De quién es la autoridad que se usa | La sesión autenticada, vinculada en el código | Taxbit vincula la identidad a las herramientas antes de que se ejecute el modelo |
| 2. Si una salida es lo bastante buena para actuar | Una regla con un umbral | El patrón de Microsoft: una regla decide si un diagnóstico es lo bastante específico para contratar |
| 3. Cuánto | Límites y aprobaciones en el sistema de registro | Pagos solo mediante límites aprobados y un adaptador al sistema de finanzas |
| 4. En qué orden | Un flujo de trabajo definido | Step Functions ejecuta los pasos; el agente elige el momento |
| 5. Qué es el registro | El sistema que ejecuta, con referencias | Evidencia enlazada por referencias de work item e identificadores de correlación |
1. De quién es la autoridad que usa
El modelo puede decidir abrir un ticket. No debe decidir a qué cuenta pertenece ese ticket. El asistente en producción de Taxbit vincula la identidad del usuario a cada herramienta desde el servicio que hace la llamada, así que no hay ningún parámetro que el modelo pueda rellenar con el identificador de otra persona. Okta y AWS van más allá entre aplicaciones: cada token nombra al usuario y al agente, y solo un administrador decide qué agente puede actuar en nombre de quién.
Pregunta de revisión: ¿hay algún esquema de herramienta que permita al modelo aportar un identificador de usuario, de tenant o de cuenta?
2. Si su propia salida es lo bastante buena
Una arquitectura de referencia de Microsoft publicada el 7 de noviembre lo dice sin rodeos: la confianza del modelo no es una probabilidad calibrada y no es autorización de negocio. En su ejemplo de mantenimiento de vivienda, una regla, y no el modelo, decide si un diagnóstico de reparación es lo bastante específico para contratar a un proveedor.
Pregunta de revisión: cuando el agente actúa de forma automática, ¿qué comprobación determinista decide que la entrada es lo bastante completa, y falla en cerrado?
3. Cuánto
Los importes son el terreno donde los errores se vuelven caros. En esa misma arquitectura, los pagos pasan solo por límites aprobados, aprobaciones y un adaptador al sistema de finanzas; el modelo nunca autoriza un pago. El modelo puede proponer un reembolso de cierto valor. El límite pertenece al sistema que es dueño del dinero.
Pregunta de revisión: para cada acción con una cantidad, ¿dónde se aplica el máximo y puede el modelo verlo o cambiarlo?
4. En qué orden
Los procedimientos tienen un orden por razones que alguien tuvo que defender en su momento: elegibilidad antes de la aprobación, aprobación antes del pago. Mostramos cómo AWS deja que los agentes inicien flujos de trabajo de Step Functions mientras el flujo de trabajo conserva los pasos. El agente elige cuándo; el flujo de trabajo decide qué va después de qué.
Pregunta de revisión: ¿hay algún procedimiento regulado o aprobado que el modelo esté reensamblando a partir de llamadas individuales a la API?
5. Qué es el registro
Cuando algo sale mal, el registro debe venir del sistema que ejecutó la acción, no del relato que hace el modelo de ella. El diseño de Microsoft enlaza la evidencia mediante referencias de work item e identificadores de correlación en lugar de copiar prompts y fotos a los logs. Es el principio que llamamos prueba desde fuera del modelo.
Pregunta de revisión: si un auditor pregunta por qué ocurrió una acción, ¿puede responder sin leer la conversación?
Qué le queda al modelo
Esto no es un alegato a favor de agentes débiles. Todo lo demás queda en el modelo: entender la petición, elegir qué herramienta y qué flujo de trabajo, reunir evidencia, redactar, explicar y proponer una acción con sus razones. Ahí está la mayor parte del valor.
El patrón afina una tesis que sostenemos desde octubre: el razonamiento se está volviendo portátil, la autoridad para comprometer no. Lo que añaden las últimas semanas es un límite más nítido. La autoridad no es una sola decisión sino cinco, y cada una tiene un dueño natural fuera del modelo. Una revisión de diseño que compruebe esas cinco atrapará más riesgo real que una que compare puntuaciones de benchmark.