Cuando el agente se equivoca: tres fallos reales
Sobreajuste a un comunicado, correlación espuria y una orden que nadie esperaba. Tres episodios donde el agente cumplió sus reglas y aun así el resultado fue caro.
Hay una tentación cómoda cuando un agente autónomo pierde dinero: culpar a la ejecución. Revisar latencias, mirar el log de órdenes, comprobar si el enrutador hizo lo suyo. Pero los tres casos que recogemos aquí no fallaron en la ejecución. Fallaron en el diseño de las reglas que el agente estaba siguiendo al pie de la letra. Eso es más incómodo de asumir, porque obliga a mirar el modelo, no el cableado.
Primer fallo: el comunicado que se leyó al revés
Un emisor publicó un comunicado con una frase ambigua sobre "revisión de prioridades operativas". El módulo de lenguaje del agente clasificó el tono como positivo, extrajo la entidad correcta y disparó una señal de compra dentro de los límites vigentes. El mercado, en cambio, leyó el mismo texto como un aviso de recorte y vendió. La posición se abrió en el lado equivocado y tardó varios minutos en deshacerse.
Lo llamativo no es que el modelo se equivocara, sino que lo hizo con confianza alta. El sobreajuste a un vocabulario concreto de comunicados anteriores hizo que la ambigüedad se resolviera hacia el lado que el entrenamiento premiaba. Nadie revisó el texto antes de la orden porque el sistema estaba diseñado precisamente para no necesitar esa revisión.
Segundo fallo: la correlación que solo existía en el laboratorio
Dos activos mostraban una correlación estable durante la ventana de entrenamiento. El agente la usó como cobertura implícita: si uno se movía, el otro amortiguaba. En la sesión real, esa relación se rompió en cuestión de segundos y ambos activos cayeron en la misma dirección. La exposición neta quedó al doble de lo previsto sin que ningún umbral se cruzara.
Es el error clásico de confundir una regularidad estadística con una relación causal. El agente no tenía forma de saber que la correlación era espuria, porque su universo de datos no incluía el contexto que la había generado. La salvaguarda posterior fue sencilla: verificar correlaciones en ventanas móviles cortas antes de aceptarlas como base de cobertura.
Tercer fallo: la orden que llegó a un libro vacío
El agente envió una orden de tamaño razonable según sus reglas de riesgo. El problema fue el instante: el libro tenía una fracción de la liquidez habitual y el resto se ejecutó a precios muy alejados del esperado. La orden era defendible en teoría y costosa en la práctica. El deslizamiento se comió el margen previsto para toda la operación.
Aquí el fallo no fue de lectura ni de modelo, sino de secuencia. El agente comprobaba liquidez, pero con un retardo que en condiciones normales era irrelevante y en ese momento no lo era. La solución que adoptaron los equipos fue doble: verificación de liquidez inmediatamente antes del envío y un tamaño máximo condicionado al estado del libro en ese milisegundo concreto.
Lo que se revisó después
En los tres casos el agente actuó dentro de sus reglas. Eso desplaza la pregunta desde "¿por qué hizo eso?" hacia "¿por qué las reglas permitían hacerlo?". Las salvaguardas que se generalizaron tras estos episodios fueron tres: límites por contraparte para no concentrar exposición en un solo libro, verificación de liquidez previa con ventana mínima, y revisión humana obligatoria de operaciones que se salen del patrón habitual de la sesión.
Ninguna de las tres elimina el error. Lo que hacen es acotar el daño cuando ocurre y dejar rastro suficiente para reconstruir qué pasó. Un agente que se equivoca dentro de un sistema bien instrumentado es un incidente. Un agente que se equivoca sin trazabilidad es un problema que nadie sabe explicar después.
Este análisis forma parte de una serie sobre agentes autónomos en mercados de alta frecuencia. Si te interesa cómo se construyen las reglas antes de que fallen, conviene empezar por cómo un agente lee titulares antes que el mercado.