Qué necesita de verdad un agente de IA antes de llegar a producción
Una demo en la que un modelo invoca una herramienta es el trabajo de un fin de semana. Poner lo mismo delante de clientes, con acceso a sistemas que manejan dinero o datos personales, es otro problema de ingeniería, y casi nada de él es ingeniería de prompts.
Decide qué se le permite hacer
El instinto es dar acceso amplio al agente y limitarlo en el prompt. Es al revés: un prompt es una petición, no un límite de permisos. Acota las credenciales a la tarea y la pregunta de si al modelo se le puede convencer de algo peligroso deja de ser interesante.
En la práctica esto significa una identidad separada y de corta vida por tarea, con exactamente las herramientas que esa tarea necesita y sin acceso permanente a nada más.
Haz reversibles las acciones con consecuencias
Clasifica cada acción del agente en tres cajones: segura siempre, segura si se puede deshacer, y requiere una persona. En la mayoría de sistemas basta con que el cajón del medio sea de verdad reversible —un borrado lógico, un estado de borrador, un cambio en cola— para que todo el conjunto dé mucho menos miedo.
Evalúalo como software, no como una demo
Que el comportamiento no sea determinista no te libra de probar; cambia cómo es la prueba. Monta un conjunto reservado de casos reales con resultados esperados y ejecútalo en cada cambio de prompt, de herramientas o de versión del modelo.
Sin eso comparas anécdotas. Y el comportamiento se desplaza: una subida de versión del modelo puede cambiar en silencio cómo se trata un caso límite que nadie recuerda que era importante.
Reconoce cuándo la respuesta no es un agente
Muchos problemas descritos como agénticos son un flujo con un único paso incierto. Si la secuencia de acciones se conoce de antemano, una tubería convencional que llama a un modelo para la parte ambigua es más barata de construir, más barata de operar y mucho más fácil de razonar cuando se porta mal.
