Contexto técnico
No me atrajo el meme de "agentic oops" en sí, sino las reacciones en el hilo. Rápidamente se hizo evidente lo principal: el problema no era que el agente se equivocara, sino que la infraestructura no estaba preparada en absoluto para el error.
Cuando hago integración de IA o construyo automatización con IA, hace tiempo que me rijo por una regla básica y desagradable: el agente, tarde o temprano, hará clic donde no debe. No porque se haya "vuelto loco", sino porque se le dieron permisos excesivos, un perímetro de acceso deficiente o una conexión ciega a producción.
Y aquí es donde termina la magia y comienza la aburrida ingeniería que luego salva el negocio. Las copias de seguridad no deben residir en la misma cuenta, en la misma región y, mucho menos, junto a la producción por el simple hecho de que "es más cómodo".
Lo mínimo que considero profesional: una cuenta de backup separada, otra región y, preferiblemente, otra jurisdicción para los datos críticos. Además, una regla que establezca que el sistema de backup extrae los datos del entorno en vivo, y no al revés, para que el entorno en vivo no pueda sobrescribir o eliminar las copias de seguridad.
Si el equipo es pequeño o carece de ingenieros de infraestructura sólidos, una base de datos gestionada es casi siempre más barata que el heroísmo. Un PostgreSQL autoalojado suena romántico hasta la primera noche en que tienes que restaurar la base de datos bajo carga y descubres que nadie ha probado el procedimiento de restauración completo.
Otro punto que no pasaría por alto en los sistemas de agentes: la observabilidad de las acciones del agente. No solo los registros de consultas al modelo, sino un rastro de auditoría a nivel de "qué quería hacer el agente", "con qué token", "en qué entorno", "con qué resultado" y dónde se activó el interruptor de emergencia (kill switch).
¿Qué cambia esto para el negocio y la automatización?
Ganarán aquellos que construyan la automatización con IA como un sistema con limitaciones, no como una demo con esteroides. Perderán aquellos que le dieron al agente acceso a producción y consideran la copia de seguridad como una simple casilla de verificación en el panel de la nube.
La primera consecuencia es simple: el coste de una mala arquitectura aumenta. una sola acción fallida del agente puede eliminar no solo una tarea, sino una cadena de datos, informes, sincronización de CRM y operaciones de clientes de una sola vez.
Segundo: la recuperación se convierte en parte del producto, no en un complemento. Yo no liberaría a un agente de IA en un entorno crítico sin una restauración de prueba, roles de acceso separados y un escenario de rollback claro.
En Nahornyi AI Lab, precisamente desglosamos estos puntos débiles: dónde se necesita un stack gestionado, dónde un entorno separado, y dónde es mejor no permitir que el agente acceda a los datos directamente. Si sientes que tu automatización con IA ya es útil pero se sostiene por pura suerte, revisemos la arquitectura y construyamos una solución sin sorpresas bonitas pero muy caras.