El 65% de las empresas que ponen agentes de IA en producción ya han sufrido un incidente causado por ellos. No es una estadística sobre la tecnología. Es una estadística sobre el ownership.
El patrón detrás del incidente
Casi ningún incidente de agentes viene de que el modelo “se equivocó”. Viene de que el agente tenía permiso para hacer algo que nadie pensó en limitar:
- Un agente de soporte con acceso de escritura a la base de datos de producción, no solo de lectura.
- Un agente de reconciliación que reintenta una acción financiera sin idempotencia.
- Un agente que encadena tres herramientas y la tercera nunca fue auditada porque “solo era un fallback”.
En los tres casos el modelo funcionó exactamente como se le pidió. El problema es el perímetro que dibujó el equipo alrededor de él.
Demo vs. producción
Una demo de agente se evalúa por si resuelve la tarea. Un agente en producción se evalúa por lo que pasa cuando algo sale mal a mitad de una cadena de acciones. Esa es la pregunta que casi nadie hace antes del primer deploy:
// La pregunta equivocada
did_the_agent_complete_the_task === true;
// La pregunta correcta
can_this_agent_take_an_irreversible_action_without_a_human_or_a_hard_check_in_the_loop ===
false;Qué cambia cuando el diseño es serio
Diseñar sistemas agénticos para entornos reales significa tratar cada herramienta que el agente puede invocar como una superficie de riesgo, no como una feature. Eso implica:
- Scopes explícitos por herramienta, no un token con acceso total.
- Acciones irreversibles (enviar, pagar, borrar, publicar) siempre detrás de una confirmación o de una regla dura.
- Logs que permiten reconstruir por qué el agente decidió lo que decidió, no solo qué devolvió.
El agente no es el riesgo. El riesgo es tratarlo como si fuera determinístico cuando no lo es.