Tu Agente está Empezando a Comportarse de Forma Extraña
- Fecha: 21 September, 2026
Por qué el verdadero trabajo con la IA empieza después de la demo: pruebas, observabilidad, retroalimentación continua y gestión de todo su ciclo de vida.
Todos conocemos la historia.
Un programador crea una herramienta para un caso de uso muy concreto. El equipo de QA la prueba boca abajo, al revés y en condiciones que ninguna persona razonable intentaría jamás. Y pasa todas las pruebas.
Entonces el usuario comienza a usarlo.
Los usuarios empiezan a utilizarla de maneras que nadie había previsto. La incorporan a procesos para los que no fue diseñada, la aplican a problemas inesperados y le piden tareas que nunca figuraron entre los requisitos originales. Un buen ejemplo es el chatbot de atención al cliente de McDonald's que, de forma totalmente imprevista, acabó generando códigos de acceso para ayudar a usuarios que se habían quedado sin tokens en otro servicio.
Los agentes de IA no son inmunes a esto. De hecho, pueden resultar aún más convincentes cuando se equivocan.
¿Alguna vez has interactuado con un agente que estaba equivocado con una seguridad impresionante? El tipo de error que te hace detenerte y preguntarte: ¿Cómo se le pasó esto a QA?
Enhorabuena. Tu agente de IA ha llegado a producción.
Por desgracia, la producción tiene usuarios.
El agente que deslumbró durante la demo puede seguir mostrando métricas impecables y tiempos de respuesta excelentes mientras, sin levantar ninguna alarma, se desvía de su comportamiento esperado.
Técnicamente, nada está «caído».
Y aun así, todo el que usa el sistema sabe que algo no va bien.
Bienvenido a la IA en producción.
El mundo cambió. Tu agente no.
Los agentes de IA operan dentro de organizaciones donde todo a su alrededor cambia: los datos, las API, los permisos, los modelos, los flujos de trabajo y el comportamiento de los usuarios.
Eso genera varios tipos distintos de rarezas en producción:
- Deriva de conocimiento: El agente recupera información que antes era correcta, pero que ya no lo es.
- Deriva de herramientas: La API sigue existiendo, pero ya no se comporta como el agente espera.
- Deriva de permisos: El agente pierde acceso a algo que necesita, o gana acceso a algo que no debería tener.
- Deriva de modelo y prompt: Un cambio en apariencia menor produce un comportamiento inesperadamente distinto.
- Deriva de flujo de trabajo: El agente sigue fielmente un proceso que la empresa cambió hace tres meses y se olvidó de comunicárselo al robot.
- Deriva de uso: Los humanos hacen algo que nadie, al diseñar el sistema, pensó que harían.
Ese sexto tipo merece una atención especial.
Y entonces llegan los humanos
Los usuarios combinarán varias intenciones en una sola solicitud, inventarán flujos de trabajo que tú nunca diseñaste, forzarán casos límite y usarán el sistema para cosas para las que nunca estuvo pensado.
También lo corregirán, encontrarán formas de sortearlo y, a veces, le enseñarán hábitos que tú no querías que aprendiera.
Esa creatividad humana no es necesariamente un problema. De hecho, el uso en producción es una de las fuentes de información más ricas de las que dispone un equipo de ingeniería de IA. Tus usuarios se convierten, en la práctica, en tu mayor batería de pruebas.
Por desgracia, no abren tickets en Jira.
En sistemas con memoria persistente, estado, recuperación de información y orquestación, esas interacciones importan porque elementos de un uso anterior pueden influir en lo que ocurre después.
Pero acumular experiencia no es lo mismo que aprender.
La memoria sin retroalimentación es acumulación, no aprendizaje
Una de las suposiciones más peligrosas en la IA de producción es pensar que, como un agente tiene memoria, de algún modo mejorará de forma natural con el tiempo.
La memoria por sí sola solo genera acumulación.
La mejora requiere un bucle de retroalimentación diseñado para ello.
Un botón de pulgar arriba o abajo no lo es. Los registros o la telemetría tampoco. Esos mecanismos producen señales; la pregunta importante es qué ocurre con esas señales después.
Existe un bucle de retroalimentación real cuando la retroalimentación impulsa una acción de ingeniería:
Observar → Evaluar → Corregir → Validar → Mejorar
Si los usuarios reciben repetidamente malos resultados de recuperación, quizá haya que cambiar la estrategia de recuperación. Si el agente elige sistemáticamente la herramienta equivocada, puede que el problema esté en la definición de la herramienta o en la lógica de enrutamiento. Si los usuarios descubren un nuevo caso límite, esa interacción debería convertirse en un nuevo escenario de evaluación.
Y si la gente está constantemente anulando al agente, eso no es solo frustración. Son datos operativos.
Un botón de pulgar abajo que nadie revisa no es más que un pequeño buzón digital de quejas.
Puede que tu panel de monitorización te esté mintiendo
La monitorización tradicional puede decirte si el servicio está disponible, si la API funciona bien, si la latencia es aceptable y si se produjo una excepción.
Un agente de IA puede pasar todas esas comprobaciones y aun así funcionar mal.
Por eso la observabilidad de la IA tiene que ir más allá de la salud de la infraestructura y abarcar el comportamiento del agente, la calidad de sus respuestas y el resultado de negocio.
Si un usuario te dice: «El agente dijo algo raro ayer», tu equipo de ingeniería debería poder reconstruir el recorrido completo: la solicitud del usuario, la memoria y el contexto disponibles, el resultado de la recuperación, la decisión de enrutamiento, la selección de la herramienta, su ejecución, la respuesta y el resultado. En otras palabras, tienes que poder recrear la escena del crimen.
«Dijo algo raro ayer» no es una estrategia de observabilidad.
El trazado te permite identificar dónde se desvió el comportamiento, en lugar de limitarte a descubrir que la respuesta final fue mala.
Convierte lo raro en una prueba
El uso en producción debería mejorar de forma continua el conjunto de evaluación.
Los escenarios usados antes del lanzamiento no deberían quedar congelados para siempre. Los usuarios expondrán casos que no anticipaste, y el negocio creará situaciones que no se podían prever cuando el sistema se diseñó por primera vez.
Toda interacción suficientemente extraña debería, por tanto, convertirse en candidata a una prueba de regresión.
Raro una vez es un incidente.
Raro dos veces es un patrón.
¿Raro tres veces? Enhorabuena, puede que tengas una funcionalidad.
El chiste importa menos que el principio: la producción debería ampliar continuamente tu comprensión de cómo el sistema puede acertar y de cómo puede fallar.
Los usuarios que exponen tus fallos más extraños a menudo están señalando requisitos que no sabías que tenías.
Versiona todo lo que te pueda traicionar
Los sistemas agénticos pueden cambiar de comportamiento incluso cuando el código de la aplicación no cambia.
Los modelos, los prompts, los índices de recuperación, las definiciones de herramientas, las reglas de orquestación, las políticas de memoria, las barreras de seguridad y los datos de evaluación pueden, todos ellos, alterar el rendimiento.
Eso hace que la trazabilidad sea esencial.
Si no puedes identificar qué cambió, no puedes determinar con fiabilidad qué se rompió.
Revertir también se complica. Puede que necesites volver a un modelo anterior, restaurar un prompt previo, deshacer una configuración de recuperación, cambiar la definición de una herramienta, revertir un cambio de orquestación o intervenir en la memoria persistente y el estado del sistema.
Por eso la IA en producción exige disciplina operativa en todos los componentes que dan forma al comportamiento, no solo en el código de la aplicación.
¿Quién es el responsable de esto ahora?
Las organizaciones dedican una energía enorme a decidir quién construirá el agente. Dedican bastante menos tiempo a decidir quién será responsable de él tras el lanzamiento.
Alguien tiene que revisar la retroalimentación y el rendimiento de las evaluaciones. Alguien tiene que saber cuándo las fuentes de conocimiento quedan obsoletas o cuándo cambian las integraciones. Alguien tiene que tener la autoridad para aprobar cambios en los prompts, las herramientas, los modelos y la orquestación. Alguien tiene que definir cuándo el agente debe detenerse, escalar a un humano o, eventualmente, ser retirado.
Sin esa responsabilidad definida, la IA en producción se convierte rápidamente en responsabilidad de todos y, por tanto, de nadie.
Desplegar un agente sin una responsabilidad clara es un poco como soltar un mapache dentro de la empresa.
Puede que sea inteligente. Puede que sea sorprendentemente capaz. Puede incluso que logre cosas impresionantes.
Pero alguien tiene que seguir siendo responsable de lo que hace.
El despliegue no es el final de un proyecto de IA.
El despliegue es el comienzo de la operación.
La IA en producción es un ciclo de vida
Los sistemas agénticos necesitan mecanismos continuos para detectar comportamientos extraños, diagnosticarlos, corregirlos, evitar que se repitan y, finalmente, retirar lo que ya no sirve al negocio.
Eso significa que las pruebas, las evaluaciones, la observabilidad, el trazado, la revisión humana, el versionado, la reversión, la gobernanza y la responsabilidad pertenecen todos al mismo ciclo de vida.
Con el tiempo, algunos agentes deberían desaparecer.
Un flujo de trabajo puede quedar obsoleto. Una funcionalidad puede volverse redundante. Los costes de mantenimiento pueden superar el valor que aporta. Una capacidad más nueva puede sustituir por completo al agente original.
Mantener un agente con vida solo porque alguien lo construyó en su día no es una estrategia operativa.
Un retiro planificado es considerablemente mejor que una lenta deriva hacia el caos.
Basta ya de desplegar la IA y olvidarse de ella
La siguiente fase de la madurez de la IA empresarial no se va a definir solo por quién sabe construir agentes.
Se va a definir por quién sabe operarlos.
Eso exige mucho más que escribir prompts o elegir un modelo. Exige arquitectos, ingenieros, equipos de seguridad, líderes de negocio y usuarios finales que entiendan cómo se comportan estos sistemas una vez que entran en una organización viva.
El objetivo no debería ser simplemente construir más agentes.
Debería ser construir organizaciones capaces de mantenerlos útiles, seguros, observables y alineados a lo largo del tiempo.
Es probable que tu agente de IA no esté embrujado.
Simplemente se te olvidó operarlo.
