Agentes de IA en producción: la arquitectura importa más que el prompt

Construir la demo de un agente de IA lleva una tarde: un buen prompt, un par de herramientas y una conversación que impresiona. Ponerlo frente a clientes reales es otra historia. El modelo no es determinista, puede equivocarse con total seguridad y, a diferencia de un chat, ahora tiene herramientas que leen datos, escriben en sistemas y a veces mueven dinero.

Por eso la pregunta de arquitectura no es «¿qué prompt hace que el modelo acierte?», sino «¿qué puede hacer el sistema cuando el modelo se equivoca?». Estas son las decisiones que más pesan cuando un agente pasa de la demo a producción.

“Un buen agente no es el que nunca se equivoca. Es el que, cuando se equivoca, no puede causar un daño grave.”

1. El modelo propone, el sistema decide

Trata la salida del modelo como una propuesta, nunca como una orden. Si el agente quiere reprogramar una cita o emitir un reembolso, genera una solicitud estructurada y el código determinista la valida contra las reglas reales: que el horario exista, que el monto esté dentro del límite y que el usuario tenga permiso.

Esta separación tiene una ventaja enorme: las reglas que importan se prueban como cualquier otro código, y cambiar de modelo o de prompt no las pone en riesgo.

2. Herramientas con contratos estrechos

Una herramienta genérica como «ejecutar consulta» o «llamar a cualquier API» es cómoda en la demo y peligrosa en producción. Diseña herramientas por intención, con entradas tipadas y el mínimo permiso necesario:

• agendar_cita(servicio, fecha) en lugar de escribir directamente en la tabla de citas.
• Las entradas se validan con un esquema antes de ejecutar nada.
• Cada herramienta tiene solo los permisos de su tarea: leer el catálogo no da acceso a pagos.
• Las operaciones que escriben aceptan una clave de idempotencia, porque los agentes también reintentan.

Clasificar las herramientas ayuda a decidir el resto: las de solo lectura, las que escriben algo reversible y las que hacen algo irreversible. Cada grupo merece un nivel de control distinto.

3. Pon a una persona donde el error es caro

Para acciones irreversibles o de alto valor, el agente prepara y una persona aprueba. No uses la «confianza» del modelo para decidir cuándo escalar, porque no es una señal fiable. Usa reglas explícitas: un monto máximo, ciertas categorías de solicitud o un cliente que ya pidió hablar con alguien.

Diseña también la entrega. Quien recibe el caso debe ver el contexto, lo que el agente intentó y por qué escaló. Un traspaso que obliga a empezar de cero destruye la experiencia que el agente había construido.

4. Todo lo externo es entrada no confiable

Un agente lee correos, documentos, páginas web y respuestas de herramientas. Cualquiera de esos textos puede contener instrucciones escritas para manipularlo, lo que se conoce como prompt injection. Hoy no existe un filtro que lo resuelva por completo, así que la defensa es de arquitectura:

• Separa las instrucciones del sistema de los datos que el agente procesa.
• No combines en un mismo agente la lectura de contenido no confiable con herramientas cuyo mal uso no puedas tolerar.
• Valida en el servidor cualquier acción que se derive de ese contenido, como en el primer punto.

5. Evals antes de cambiar el prompt o el modelo

En software tradicional nadie cambia una función crítica sin tests. Con agentes pasa todo el tiempo: se ajusta el prompt para arreglar un caso y se rompen otros tres sin que nadie lo note. La respuesta es un conjunto de evaluaciones:

• Casos reales, anonimizados, con el resultado que se espera de cada uno.
• Casos difíciles y adversariales: ambigüedad, datos faltantes e intentos de manipulación.
• Métricas de la tarea, como una cita bien agendada o una consulta bien derivada, y no de si la respuesta suena bien.
• Una ejecución automática cada vez que cambian el prompt, el modelo o las herramientas.

6. Observabilidad, límites y costes

Cada ejecución del agente debería dejar una traza completa: la entrada, las llamadas a herramientas, las respuestas, la latencia y los tokens consumidos. Sin eso, depurar un error de producción es adivinar.

Pon límites explícitos: un número máximo de pasos por tarea, tiempos de espera para cada herramienta y un presupuesto de coste por conversación. Cuando se alcanza un límite, el sistema tiene un plan B: un flujo más simple o una persona.

7. Empieza por un flujo acotado

El agente que lo hace todo es la forma más rápida de no poder medir nada. Empieza con un flujo concreto, con un resultado verificable y un plan B claro, como responder preguntas frecuentes con fuentes o agendar una cita. Cuando ese flujo tiene evals, trazas y métricas estables, el siguiente cuesta mucho menos.

Checklist de arquitectura

• Las acciones del modelo pasan por una validación determinista.
• Cada herramienta tiene un contrato estrecho, permisos mínimos e idempotencia.
• Las acciones irreversibles requieren aprobación humana según reglas explícitas.
• El contenido externo se trata como no confiable.
• Hay evals que se ejecutan en cada cambio de prompt, modelo o herramienta.
• Cada ejecución deja una traza y tiene límites de pasos, tiempo y coste.

Si estás evaluando llevar un agente a producción en tu empresa, revisa la consultoría de agentes IA. Y si quieres dirigir agentes de código con este mismo criterio, lee cómo usar la IA para programar como un senior.