Agentes de IA: la arquitectura que separa el piloto de la producción

Hay un patrón que se repite con una regularidad casi aburrida. El piloto de IA funciona espectacularmente en la demo, el directorio aprueba, y seis meses después el proyecto está detenido. No porque el modelo fuera malo, sino porque la demo nunca tuvo que lidiar con un usuario que pide lo mismo tres veces, un sistema externo caído a mitad de una transacción, o un mes en que el consumo de tokens se multiplicó por veinte.

La distinción que importa no es «chatbot» versus «agente». Es si el sistema solo produce texto o si además ejecuta acciones con consecuencias: emitir una nota de crédito, modificar un despacho, escribirle a un cliente. En el momento en que hay consecuencias, deja de ser un proyecto de IA y pasa a ser un sistema transaccional que además usa IA. El estándar de ingeniería que corresponde es el segundo.

Los siete controles

1. 1

   Permisos acotados por herramienta

   Cada capacidad del agente es una credencial distinta, con el mínimo privilegio necesario y auditable por separado. Un agente de atención que puede consultar el estado de un pedido no debe compartir credenciales con uno que puede anularlo. El error clásico es darle al agente las llaves de un usuario administrador «para la etapa de pruebas» y nunca revertirlo.

2. 2

   Idempotencia en toda acción con efecto

   Los reintentos son inevitables: se cae la red, expira un token, el usuario insiste. Sin claves de idempotencia, un reintento emite la segunda nota de crédito. Esta es la falla que más daño causa en producción y la que menos aparece en las demos, porque en la demo nada falla.

3. 3

   Confirmación humana en lo irreversible

   Clasifique las acciones por reversibilidad, no por complejidad. Consultar es libre; modificar es registrable; borrar, pagar o comunicarse con un cliente externo requiere confirmación explícita de una persona. Esta frontera se define en la arquitectura, no se deja a criterio del modelo en tiempo de ejecución.

4. 4

   Control de acceso dentro de la búsqueda

   Si el agente consulta una base de conocimiento, el filtro de permisos tiene que aplicarse en la consulta, antes de que el contenido llegue al modelo. Filtrar después es inútil: el dato ya entró al contexto y el modelo puede parafrasearlo. Es la vía más común de filtración de información interna en sistemas de IA.

5. 5

   Evaluación antes de cada despliegue

   Un conjunto de casos representativos, con respuestas esperadas, que corre automáticamente ante cualquier cambio de prompt, modelo o herramienta. Sin esto, cada ajuste es un despliegue a ciegas y la única forma de detectar una regresión es que la reporte un cliente.

6. 6

   Límites de gasto y de iteraciones

   Topes explícitos de tokens por conversación, de iteraciones por tarea y de costo diario, con corte automático. Un agente en un bucle de razonamiento puede consumir el presupuesto de un mes en una tarde, y lo hará un sábado.

7. 7

   Trazas completas de cada decisión

   Registre la entrada, el contexto recuperado, las herramientas invocadas con sus parámetros, la salida y el costo. Cuando un cliente reclame por lo que el agente le dijo o hizo, esta traza es la única forma de saber qué pasó, corregirlo y demostrar diligencia.

Cómo decidir si un caso de uso está listo

No todos los procesos convienen como primer agente. Antes de comprometer presupuesto, nosotros evaluamos cuatro condiciones; si alguna falta, el caso de uso casi siempre se transforma en un piloto que no escala.

Lo que sí cambia con el tiempo

Las capacidades de los modelos avanzan rápido y seguirán haciéndolo, por lo que anclar una arquitectura a un proveedor o a una versión específica es una decisión que envejece mal. Lo que recomendamos es aislar el modelo detrás de una interfaz propia: que el sistema dependa de una capacidad («clasificar este caso», «redactar esta respuesta») y no de un proveedor concreto.

Los siete controles de arriba, en cambio, no han cambiado y no dependen de qué modelo se use. Son los mismos principios de sistemas distribuidos que ya conocíamos —mínimo privilegio, idempotencia, observabilidad, límites de recursos— aplicados a un componente nuevo que, a diferencia de los anteriores, es no determinista. Esa es la única novedad real, y es suficiente para justificar tratarlo con más rigor, no con menos.