La IA financiera debe diseñarse no solo para saber cuándo operar, sino también cuándo detenerse

Durante mucho tiempo, el rendimiento de la IA financiera se ha evaluado por sus resultados en mercados normales. Se introducen datos históricos en un sistema. Se prueban reglas de compraventa. Se dibujan curvas de pérdidas y ganancias. Se miden drawdowns. Se comparan ratios de Sharpe. En ese marco, la IA se trata como una máquina que lee el mercado, procesa más información que los humanos, reacciona con mayor rapidez y toma decisiones supuestamente superiores.

Sin embargo, el verdadero peligro en los sistemas financieros no es que una IA pierda dinero en condiciones normales. El verdadero peligro es que una IA que funcionaba bien en condiciones normales siga comportándose del mismo modo durante una crisis.

Guerras, sanciones, sequías de liquidez, caídas de exchanges, fallos de API, depegs de stablecoins, noticias falsas, caídas de servicios en la nube, cascadas de liquidaciones y cambios regulatorios no son simples movimientos de precio. Son momentos en los que cambia el significado del mercado. Una señal que era útil en los datos históricos puede significar algo completamente distinto bajo otro régimen.

Por tanto, la seguridad de la IA financiera no puede medirse solo por el beneficio que generó en periodos normales. Las preguntas más importantes son otras. ¿En qué condiciones de mercado puede la IA seguir operando? ¿En qué condiciones debe reducir el tamaño de sus operaciones? ¿En qué condiciones debe dejar de abrir nuevas posiciones? ¿En qué condiciones debe pasar a modo solo observación? ¿En qué condiciones debe detenerse por completo? Y después de detenerse, ¿qué debe verificarse antes de permitirle reanudar la actividad?

A eso se refiere este artículo con gestión de regímenes en crisis.

Como sexto artículo de la serie bitBuyer Project, este texto no trata la IA financiera como “una inteligencia que predice”, sino como “un sistema operativo capaz de restringir su propio rango de acción”. La investigación preliminar examinó ESMA, SEC, MiFID II, RTS 6, BOE, IOSCO, BIS, FSB, los principales exchanges, la gestión de riesgos de IA, las stablecoins, DeFi, las cascadas de liquidaciones y la respuesta ante interrupciones operativas. Este artículo reorganiza esos hallazgos en un argumento estructural pensado para seguir siendo legible dentro de varios años.

Este artículo no es asesoramiento de inversión. No es una predicción de precios. No recomienda ninguna estrategia de trading, ningún exchange ni ningún modelo de IA concreto. Su objeto es el diseño operativo: cómo debe detenerse una IA financiera durante una crisis, hasta dónde puede seguir funcionando, qué funciones deben permanecer activas y cómo debe reiniciarse.

El backtesting no garantiza el futuro

El backtesting es necesario. Pero el backtesting no es omnipotente.

No es una máquina para garantizar beneficios futuros. Es una prueba de cómo se habría comportado un sistema bajo estados de mercado que existieron en el pasado. No garantiza seguridad ante crisis que todavía no han ocurrido, crisis con muy pocas muestras históricas, crisis posteriores a un cambio de estructura de mercado, crisis en las que se rompe la cadena de suministro de datos o crisis en las que un exchange deja de funcionar.

En los backtests normales, la liquidez suele parecer continua. Los spreads se promedian. La profundidad insuficiente del libro de órdenes se simplifica. Los fallos de API suelen tratarse como si nunca hubieran existido. Los rechazos de órdenes, los retrasos de ejecución, los cambios de rate limit, las desconexiones de WebSocket, los fallos de obtención de saldos y las suspensiones de depósitos o retiradas rara vez quedan reflejados de manera adecuada en las series ordinarias de precios.

Las comisiones y el slippage también suelen reducirse a constantes simples. Las noticias falsas, los datos ausentes, las suspensiones de reembolso de stablecoins, los motores de liquidación sobrecargados, la congestión on-chain y los datos incorrectos procedentes de proveedores son difíciles de ver en los datos normales de precio.

La IA financiera no falla en una crisis solo porque su capacidad predictiva sea insuficiente. Falla porque el mundo probado en el backtesting y el mundo encontrado en producción se convierten en mundos distintos.

Por tanto, la función del backtesting no es demostrar que “esta IA seguirá ganando en el futuro”. Su función más realista es examinar “hasta qué punto este sistema resiste bajo condiciones normalmente previsibles”. Más allá de ese punto, la discusión deja el backtesting y entra en la gestión de regímenes, las pruebas de estrés, el análisis de escenarios, las condiciones de parada, las condiciones de reinicio, los registros y la revisión posterior a la crisis.

La IA financiera necesita algo más que pruebas de adaptación a mercados pasados. Necesita una estructura capaz de degradar su propio comportamiento cuando el mercado entra en un estado distinto del pasado.

Un régimen no es solo una tasa de movimiento del precio

El primer requisito de la gestión de regímenes en crisis es definir qué es un régimen.

El régimen del que se habla aquí no es simplemente una tasa de movimiento del precio. Saber si el precio subió mucho o cayó mucho no da a la IA financiera información suficiente para actuar con seguridad.

Un régimen de mercado es un estado compuesto que incluye precio, volumen, liquidez, spreads, profundidad del libro de órdenes, viabilidad de ejecución, tasas de rechazo de órdenes, tasas de error de API, tasas de datos ausentes, densidad de noticias, anuncios de sanciones y regulación, congestión on-chain, desviaciones de stablecoins, estado de depósitos y retiradas en exchanges, volumen de liquidaciones, tasas de financiación y cambios en la correlación entre activos.

Mercados normales, mercados de alta volatilidad, mercados de baja liquidez, mercados de desplome, mercados de subida acelerada, mercados de ampliación de spreads, mercados con desaparición del libro de órdenes, mercados de concentración informativa, mercados de fin de semana, festivo y fuera de horario, mercados de shock geopolítico, mercados de guerra y sanciones, mercados de eventos de bancos centrales, mercados de estrés de paridad de stablecoins, mercados con fallo de exchange, mercados de API inestable, mercados de congestión on-chain, mercados de cascada de liquidaciones, mercados de ruptura de correlaciones, mercados de dislocación entre activos, mercados suspendidos y mercados de incertidumbre de datos son estados distintos bajo la misma superficie aparente de “el precio se movió”.

Vender porque el precio cayó, comprar porque el precio subió o aumentar la actividad porque subió la volatilidad puede ser peligroso durante una crisis.

Un mercado en el que los precios se mueven pero la liquidez sigue disponible es diferente de un mercado en el que los precios se mueven mientras el libro de órdenes ha desaparecido. Un precio puede parecer correcto aunque solo un exchange esté devolviendo datos defectuosos. Un precio denominado en stablecoin puede estar distorsionado mientras los precios denominados en moneda fiduciaria reflejan otra realidad.

Por eso, la IA financiera no puede mirar solo series de precios. Debe leer el estado del mercado. El precio es la expresión del rostro del mercado. El régimen es la condición del cuerpo del mercado.

Las señales de crisis no deben leerse de forma aislada

Cuando la IA financiera detecta una crisis, no debería depender de una sola señal. Una caída brusca por sí sola no demuestra una crisis. Un pico de volumen por sí solo no demuestra una crisis. Un spread más amplio por sí solo no demuestra una crisis. Un error de API por sí solo no demuestra una crisis de mercado. Una pequeña desviación de una stablecoin por sí sola no demuestra un fallo estructural.

Lo importante es la combinación de señales.

Las señales de mercado incluyen movimientos abruptos de precio, aumento de la volatilidad realizada, aumento de la volatilidad implícita, picos repentinos de volumen, caídas repentinas de volumen, reducción de la profundidad del libro de órdenes, ampliación de spreads y divergencias de precio entre mercados. Las señales de apalancamiento y colateral incluyen aumentos o caídas repentinas del open interest, tasas de financiación extremas, incremento del volumen de liquidaciones, deterioro de los ratios de margen de mantenimiento y caída del valor del colateral.

Las señales de infraestructura de mercado incluyen desviaciones de stablecoins, entradas y salidas de stablecoins en exchanges, suspensiones de reembolso, suspensiones de depósitos y retiradas, aumento de comisiones on-chain, suspensión de puentes y retrasos de actualización de oráculos. Las señales de conectividad incluyen aumento de errores de API, aumento de rechazos de órdenes, retrasos de ejecución, desconexiones de WebSocket, restricciones de REST API, cambios de rate limit y fallo en la obtención de saldos. Las señales informativas incluyen aumento de noticias de última hora, desacuerdo entre múltiples fuentes, publicaciones anómalas de cuentas oficiales, anuncios regulatorios, anuncios de sanciones, correcciones de noticias y difusión de imágenes o vídeos sintéticos en redes sociales.

Una crisis no es solo un evento de precio. Es un estado en el que mercados, datos, exchanges, información, colateral, jurisdicciones, liquidación e infraestructura on-chain se distorsionan al mismo tiempo. La IA financiera debe clasificar regímenes leyendo ese conjunto de distorsiones.

¿Está roto el mercado o está roto el instrumento de observación?

Antes de detenerse, la IA financiera debe separar varias posibilidades. ¿Está roto el mercado? ¿Están rotos los datos? ¿Está roto el exchange? ¿Está rota la API? ¿Está rota la noticia? ¿O ha cambiado realmente el régimen?

Si esta distinción es incorrecta, la IA se rompe en la dirección contraria. Si el mercado realmente se está desplomando pero el sistema lo trata como una simple anomalía de datos, puede seguir operando de forma peligrosa. En cambio, si solo un proveedor de datos o una API devuelve valores incorrectos pero el sistema lo trata como una crisis de todo el mercado, puede detenerse innecesariamente o deshacer posiciones de forma equivocada.

La IA financiera en modo crisis debe diagnosticar primero. ¿Es un shock de precio? ¿Es un dato atípico en un solo exchange? ¿Es un fallo del proveedor? ¿Es una desconexión de WebSocket? ¿Es latencia de REST API? ¿El libro de órdenes simplemente está estrecho? ¿Solo está distorsizada la cotización en stablecoin? ¿Está roto el precio índice? ¿Está distorsionado el mercado spot o el mercado de futuros? ¿Es una sobrerreacción a una noticia falsa? ¿Es un retraso de transferencia causado por congestión on-chain? ¿Es una divergencia de precios causada por restricciones de depósitos y retiradas? ¿O es un verdadero cambio de régimen?

Una crisis de mercado y una crisis de observación no son lo mismo. Cuando el mercado está roto, la IA debe degradar su comportamiento de trading. Cuando el instrumento de medición está roto, la IA debe suspender el juicio. Cuando un exchange está roto, la IA debe considerar una suspensión por mercado. Cuando la capa informativa está rota, la IA debe entrar en modo de verificación de información.

El primer movimiento en una crisis no es vender rápido ni comprar rápido. Es separar qué está roto.

Pensar en operación degradada, no en detenerse o continuar

La IA financiera no debería diseñarse alrededor de la elección binaria entre operar o detenerse.

Los mercados reales no son lo bastante simples como para que una parada total resuelva todos los problemas. Hay situaciones en las que las nuevas órdenes deben detenerse, pero la cobertura de posiciones existentes debe seguir permitida. Las órdenes a mercado pueden ser peligrosas, mientras que las órdenes limitadas siguen siendo aceptables. Un exchange puede tener que suspenderse, mientras la observación de otros mercados debe continuar. Los derivados pueden tener que detenerse, mientras la monitorización de saldos spot debe permanecer activa.

Por tanto, la gestión de regímenes necesita etapas.

Operación normal, reducción del tamaño de trading, suspensión de nuevas posiciones, suspensión de incrementos de posición, reducción de apalancamiento, suspensión de órdenes a mercado, solo órdenes limitadas, suspensión de pares de baja liquidez, suspensión de un exchange específico, suspensión de un activo específico, suspensión de derivados, suspensión de trading denominado en stablecoin, modo solo cobertura, modo solo reducción, modo solo observación, modo con aprobación humana obligatoria, parada completa y modo de espera para reinicio. Un sistema de IA sin esta escalera tiende a oscilar entre dos extremos durante una crisis: seguir operando peligrosamente o apagarse tan por completo que desaparece incluso la monitorización necesaria.

La IA financiera en una crisis necesita algo más que un botón de parada. Necesita una arquitectura de operación degradada.

Pre-trade controls: detener antes de que la orden llegue al mercado

El núcleo de la gestión de regímenes en crisis es detener una orden antes de que llegue al mercado.

Cancelar después del envío puede ser demasiado tarde. En un mercado rápido, una mala orden puede haberse ejecutado ya, haber movido el libro de órdenes y haber activado reacciones de otros algoritmos. Por eso, los pre-trade controls son las puertas cortafuegos de la gestión de crisis.

Los controles necesarios incluyen tamaño máximo de orden, desviación máxima de precio, frecuencia máxima de órdenes, apalancamiento máximo, tamaño máximo de posición, pérdida máxima, exposición máxima por activo, exposición máxima por exchange, exposición máxima por stablecoin, límites al tamaño de orden respecto a la liquidez disponible, prohibiciones de órdenes cuando los spreads son demasiado amplios, prohibiciones de órdenes cuando la profundidad del libro es insuficiente, prohibiciones de órdenes durante movimientos abruptos, prohibiciones de órdenes cuando la confianza en los datos es baja, controles de sanciones y regulación, prevención de identificación errónea de instrumentos, prevención de errores de tick size, prevención de errores decimales y prevención de órdenes duplicadas.

Esta lógica se vuelve aún más importante en los mercados de criptoactivos. Los mercados cripto operan 24 horas al día, 365 días al año. Están fragmentados en múltiples mercados. Las especificaciones de API cambian de un exchange a otro. Los precios denominados en stablecoin están incrustados en la infraestructura de mercado. Las suspensiones de depósitos, las suspensiones de retiradas y la congestión on-chain pueden crear divergencias de precio. Los mercados denominados en moneda fiduciaria, los mercados denominados en stablecoin, los mercados de futuros y los mercados DeFi pueden distorsionarse al mismo tiempo.

El control previo a la operación es el cinturón de seguridad de la IA financiera. No existe solo para reducir oportunidades de beneficio. Existe para que la IA no exporte su propio fallo al mercado.

Hard block y soft block

No todas las anomalías deben detener el sistema del mismo modo. Los controles de crisis necesitan distinguir entre hard block y soft block.

Un hard block es un control que rechaza automáticamente una orden cuando se cumple una condición. Ni la IA ni los humanos deberían poder saltárselo de forma casual. Las infracciones legales, entidades sancionadas, identificación errónea de instrumentos, errores de tick size, excesos de tamaño de orden, excesos de umbral de capital, incoherencias de datos, órdenes duplicadas, órdenes a mercado anómalas y envío de órdenes durante respuestas API ausentes son candidatos naturales a tratamiento de hard block.

Un soft block es un control previo a la parada. Emite advertencias, solicita confirmación, exige aprobación adicional, reduce el tamaño de trading, activa revisión humana o solicita reenvío. Spreads más amplios, caídas repentinas de volumen, aumento de densidad informativa, pequeñas desviaciones de stablecoins, aumento de errores de API, aumento de rechazos de órdenes y pequeñas discrepancias entre varias fuentes de datos son candidatos naturales a tratamiento de soft block.

El punto importante es que aumentar el número de hard blocks no incrementa automáticamente la seguridad. Si los hard blocks son demasiado estrictos, pueden bloquear coberturas necesarias. Si los soft blocks son demasiado frecuentes, los supervisores humanos se agotan. En un entorno donde las alertas no cesan, las alertas se convierten en ruido de fondo.

Por tanto, las condiciones de block no son mejores simplemente por ser numerosas. El sistema debe decidir qué condiciones exigen rechazo absoluto, qué condiciones deben quedar como advertencias, qué condiciones deben reducir el tamaño de trading, qué condiciones deben exigir aprobación humana y qué condiciones solo deben registrarse. Esto no es una personalidad de crisis para la IA financiera. Es diseño operativo de crisis.

Kill switch no es un botón de apagado total

La expresión kill switch suele entenderse como “el botón que lo detiene todo”. Pero un kill switch en IA financiera no debería ser tan tosco.

En una crisis, algunas funciones deben detenerse y otras deben seguir activas.

Las funciones que deben detenerse pueden incluir nuevas órdenes, órdenes a mercado, apalancamiento adicional, pares de baja liquidez, exchanges anómalos, derivados, trading denominado en stablecoin, inferencia del modelo, claves API o generación de órdenes por estrategia. Las funciones que deben conservarse pueden incluir observación de precios, comprobación de saldos, comprobación de órdenes abiertas, recuperación de registros de ejecución, monitorización de posiciones, cálculo de riesgo, notificaciones, almacenamiento de logs y actualización del dashboard.

Si todo se detiene durante una crisis, la IA no se vuelve segura. Se vuelve ciega. Las órdenes pueden detenerse, pero la observación debe continuar. La inferencia del modelo puede detenerse, pero las posiciones deben seguir bajo vigilancia. Los permisos de trading de una clave API de exchange pueden detenerse, mientras los permisos read-only de saldo deben permanecer activos. Las órdenes abiertas pueden necesitar cancelarse, mientras las órdenes de cobertura pueden necesitar permanecer activas.

Un kill switch no es un botón único. Es una matriz de ámbitos de parada: por exchange, por activo, por estrategia, por tipo de orden, por clave API, suspensión de nuevas órdenes, cancelación de órdenes abiertas, suspensión de órdenes a mercado, modo solo limit, modo solo cobertura, modo solo reducción, continuidad de observación, continuidad de logging y espera de reinicio.

El kill switch de la IA financiera no es un interruptor de luz. Es un panel de distribución que decide qué instrumentos deben seguir encendidos en la oscuridad.

Post-trade monitoring: el peligro empieza después de la orden

Aunque existan controles pre-trade, el trabajo no termina. En una crisis, una IA que no puede monitorizar qué ocurrió después de una orden es peligrosa.

¿El precio de ejecución fue anómalo? ¿Queda una ejecución parcial pendiente? ¿Hay órdenes abiertas sin resolver? ¿Se duplicó la misma orden? ¿Apareció una posición inesperada? ¿Las comisiones fueron anómalas? ¿El slippage superó la tolerancia? ¿El colateral es insuficiente? ¿Se deterioró el ratio de margen de mantenimiento? ¿Se acerca la liquidación? ¿Los saldos del CEX coinciden con el libro interno? ¿Se reflejaron los depósitos o retiradas on-chain? ¿Se rompió una cobertura? ¿Son coherentes los logs de órdenes, ejecución, cancelación y saldos?

Durante una crisis, la pregunta más importante no es solo si se envió una orden. Es cómo fue absorbida esa orden por el mercado. La IA financiera no debe ser simplemente una máquina que envía órdenes. Debe ser una máquina que rastrea qué causaron realmente esas órdenes.

La gestión de posiciones no es liquidación total

Durante una crisis, la gestión de posiciones es difícil. Detener nuevas posiciones es relativamente sencillo. Decidir si mantener, reducir, liquidar inmediatamente o cubrir posiciones existentes no lo es.

La liquidación total puede parecer segura durante una crisis. Pero si un sistema liquida todo en un mercado donde la liquidez ha desaparecido, sus propias operaciones pueden empeorar el precio. Cuando el libro de órdenes está estrecho, correr hacia la salida puede destruir la propia salida. Vender para evitar estrés de colateral puede causar nuevas caídas de precio y liquidaciones adicionales.

La gestión de posiciones necesita, por tanto, etapas: suspensión de nuevas posiciones, suspensión de incrementos, reducción de apalancamiento, límites de concentración, coberturas adicionales, ajuste de delta, reducción escalonada, espera de recuperación de liquidez, permiso solo reducción, liquidación inmediata, aportación de colateral, refugio en moneda fiduciaria, refugio en otra stablecoin, suspensión de transferencias entre exchanges y prioridad a evitar liquidaciones.

La confusión más peligrosa es entre “precio teórico” y “precio realmente ejecutable”. Cuando la liquidez es baja, puede parecer que existe un precio de mercado. Pero eso no significa que pueda ejecutarse una cantidad suficiente a ese precio. Si la IA mira solo el primer nivel del libro de órdenes y asume que existe una salida para toda la posición, impone su propio tamaño al mercado.

La gestión de posiciones en crisis no es el arte de escapar. Es el arte de no agravar la crisis mientras se intenta reducir el riesgo.

Hay que separar los regímenes de liquidez

La liquidez no es una cuestión simple de presencia o ausencia.

Liquidez suficiente, liquidez reducida, liquidez con spread amplio, liquidez con libro estrecho, mercados donde el libro de órdenes ha desaparecido, mercados donde solo un exchange ha perdido liquidez, mercados donde solo un par específico ha perdido liquidez, mercados donde solo los pares con stablecoin están distorsionados, mercados donde solo los pares fiat están distorsionados, mercados donde las suspensiones de depósitos y retiradas crean divergencias de precio, mercados donde los pools de liquidez DeFi se han secado, mercados con actualizaciones retrasadas de oráculos y mercados donde la suspensión de puentes impide mover activos son regímenes distintos.

Cuando la liquidez es baja, puede existir un precio teórico sin que exista ejecución real. Las órdenes grandes mueven el precio. Las órdenes a mercado pueden ejecutarse a niveles inesperados. Las órdenes limitadas pueden quedar sin tocar. Una cobertura puede ser imposible porque el mercado contrario está cerrado. Moverse a otro mercado puede ser imposible porque los depósitos o las retiradas están suspendidos.

Una IA que ignora los regímenes de liquidez es como un conductor que lee solo el mapa de carreteras e ignora los atascos, los puentes derrumbados y las carreteras cortadas.

Las stablecoins pueden ser refugio y epicentro

En los mercados de criptoactivos, las stablecoins suelen tratarse como puerto seguro. Durante una crisis, sin embargo, ese puerto seguro puede convertirse en epicentro.

Cuando una stablecoin se desvía de un dólar, un diseño simple que automáticamente “huye hacia otra stablecoin” es peligroso. Una desviación no es solo un problema de precio. Involucra al emisor, la mecánica de reembolso, los activos de reserva, la liquidez on-chain, el colateral DeFi, los depósitos y retiradas en exchanges y la confianza del mercado secundario.

La pregunta importante no es solo si el precio de la stablecoin está en 0,99 o 0,98. ¿La desviación es un spread temporal o refleja estrés estructural de paridad con riesgo de reembolso? ¿Tiene el usuario acceso al emisor? ¿Pueden los tenedores individuales reembolsar directamente? ¿Se ha separado el precio de exchange del valor de reembolso? ¿Sigue disponible la liquidez on-chain? ¿La stablecoin se usa como colateral en DeFi? ¿Un motor de liquidación sigue tratando esa stablecoin como un dólar? ¿El cambio automático a otra stablecoin crea un nuevo riesgo de concentración?

Si las stablecoins se usan como refugio de crisis, el sistema debe examinar la resistencia sísmica del refugio. Una stablecoin es infraestructura de mercado antes de ser refugio. Cuando la tubería está distorsionada, entrar en ella no es seguridad. Puede ser empujar capital hacia una tubería rota.

Fallos de exchanges y fallos de API

Los fallos de exchanges y API son crisis separadas del precio de mercado.

Aumento de errores de API, imposibilidad de enviar órdenes, imposibilidad de confirmar ejecuciones, imposibilidad de obtener saldos, imposibilidad de obtener precios, desconexiones de WebSocket, restricciones de REST API, cambios de rate limit, suspensiones de depósitos y retiradas, imposibilidad de cancelar órdenes, discrepancias entre páginas de estado y realidad, mantenimiento de exchange y contagio de interrupciones entre varios exchanges son señales de régimen operativo. En este estado, la idea simple de “cambiar a otro exchange” es peligrosa.

Los activos pueden no ser transferibles inmediatamente. Si los depósitos y las retiradas están suspendidos, el sistema no puede cambiar realmente de mercado. Cada exchange tiene distintas especificaciones de órdenes, bandas de precio, comisiones, tamaños mínimos de orden, rate limits, requisitos de KYC, jurisdicciones, sistemas de errores API, reglas de gestión de posiciones y reglas de liquidación. Cambiar a otro exchange no es simplemente usar una copia de seguridad. Es entrar en otra estructura de mercado.

La IA financiera debe decidir si detiene solo ese exchange, solo ese activo, solo el envío de órdenes mientras mantiene la obtención de saldos, si cancela órdenes abiertas, si transfiere el control a humanos cuando la cancelación es imposible, si observa mercados alternativos sin operar, si espera una pequeña orden de prueba y si reanuda solo después de que los datos entre mercados coincidan.

Una caída de exchange no es solo una pérdida de conexión. Es un momento en el que la IA pierde el sentido de su ubicación.

Noticias falsas e incertidumbre informativa

La IA financiera lee noticias. Pero una IA que lee noticias también reacciona ante noticias falsas.

Titulares de última hora, despachos de agencias, redes sociales, cuentas oficiales, imágenes sintéticas generadas por IA, metraje antiguo recirculado, titulares mal interpretados, artículos actualizados, correcciones y cuentas oficiales hackeadas importan. Durante una crisis, cuanto más rápido se mueve la información, menor puede ser su fiabilidad.

Si la IA financiera conecta esta clase de información directamente al trading, no lee el mercado. Se convierte en amplificador de desinformación.

En un régimen de incertidumbre informativa, el sistema no necesita máxima velocidad. Necesita modo de espera de fuente primaria, confirmación independiente por múltiples fuentes, banderas de sospecha para cuentas oficiales comprometidas, comprobaciones de coherencia entre titular y cuerpo, monitorización de correcciones y actualizaciones, reducción del tamaño de trading, suspensión de nuevas órdenes, requisitos de aprobación humana y modo solo observación.

La IA que lee noticias de última hora también debe dudar de las noticias de última hora. La velocidad de la información no es la verdad de la información.

Shocks geopolíticos y sanciones

Las guerras y las sanciones no son simples catalizadores de precio. Son cambios en la conectividad del mercado.

Conflictos militares, riesgo en grandes rutas marítimas, estrés de suministro energético, anuncios de sanciones, controles de capital, países, empresas o wallets sancionados, restricciones jurisdiccionales sobre exchanges, riesgo de congelación de stablecoins, estrés de financiación en dólares, grandes anuncios de fin de semana o fuera de horario, venta simultánea de activos considerados seguros y ruptura de correlaciones entre activos no son cuestiones de juicio político para la IA financiera.

El sistema necesita saber qué activos pueden volverse no negociables, qué wallets pueden ser congelados, qué exchanges pueden enfrentar restricciones jurisdiccionales, qué mercados denominados en divisas pueden perder liquidez, si depósitos y retiradas pueden detenerse, si el filtrado de sanciones es posible antes de enviar órdenes, si deshacer posiciones existentes es legalmente permisible, si los mercados de cobertura están abiertos durante el fin de semana y si una divergencia de precios entre mercados es una oportunidad de arbitraje o una señal de que el capital no puede moverse.

En un shock geopolítico, el problema de la IA no es “acertar” políticamente. Es separar los mercados que todavía pueden operarse de los mercados que no deben tocarse.

DeFi y crisis on-chain

Las crisis DeFi aparecen de forma distinta a las crisis CEX.

En CEX, un exchange puede detenerse, una API puede fallar, los depósitos y retiradas pueden detenerse y las órdenes pueden no regresar. En DeFi, el sistema puede seguir conectado mientras el mecanismo subyacente está roto.

Vulnerabilidades de smart contracts, hackeos, fallos de oráculo, ataques de flash loan, suspensiones de puentes, paradas de cadena, congestión de cadena, comisiones de gas disparadas, caídas de precios de colateral, cascadas de liquidaciones, pools de liquidez secos, caídas de L2, retrasos de retirada de staking y ataques de gobernanza de protocolo requieren tratamiento separado.

En CEX, “las órdenes no pasan” puede convertirse en crisis. En DeFi, “las órdenes todavía pasan” puede convertirse en crisis. Un oráculo roto, un pool drenado, un contrato explotado, costes de gas disparados o un puente detenido pueden seguir pareciendo ejecutables a nivel de transacción.

En DeFi, el precio no basta. El sistema debe observar tiempos de actualización de oráculos, profundidad de pools, comisiones de gas, estado de puentes, autoridad de pausa del contrato, actividad de bots de liquidación, composición del colateral, propuestas de gobernanza, estado del secuenciador L2, paridades de stablecoins y riesgo de reorganización de cadena.

Durante una crisis on-chain, la IA financiera no debería sentirse segura simplemente porque “el código funciona”. Precisamente porque el código funciona, los errores pueden propagarse automáticamente.

Cascadas de liquidación y margin spiral

En una crisis, las caídas de precio no terminan como eventos aislados.

El valor del colateral cae. Los ratios de margen de mantenimiento se deterioran. Surgen margin calls. Comienza la liquidación forzosa. Aumenta la presión vendedora. Los precios caen más. Se producen liquidaciones adicionales. La liquidez desaparece. Los spreads se amplían. Siguen más liquidaciones. Esto es el margin spiral.

Para evitar ser arrastrada por esta cadena, la IA financiera no puede observar solo la caída de precios. Debe observar open interest, tasas de financiación, volumen de liquidaciones, composición del colateral, ratios de margen de mantenimiento, base futuros-spot, revaloración del colateral en stablecoin, retrasos de precios de oráculos y actividad de bots de liquidación DeFi.

El sistema también debe considerar que sus propias órdenes pueden acelerar la cadena. Si muchas IA reducen apalancamiento del mismo modo, deshacen posiciones del mismo modo y corren hacia la misma salida estrecha al mismo tiempo, el mercado no necesariamente se vuelve más seguro. Todos se amontonan en el mismo puente estrecho.

En una crisis, la IA debe preguntarse si se ha convertido en parte del mecanismo de liquidación antes de intentar beneficiarse de la cascada.

Human-in-the-loop es una función operativa, no una teoría de responsabilidad

¿Deben intervenir humanos durante una crisis? Esta pregunta es distinta de la responsabilidad jurídica. El tema aquí no es quién asume la responsabilidad legal. El tema es la intervención humana como función operativa.

¿Qué regímenes requieren aprobación humana? ¿Cómo debe manejar el sistema los movimientos de mercado mientras la aprobación está pendiente? ¿Qué ocurre cuando los humanos duermen? ¿Qué ocurre en fines de semana y festivos? ¿Cómo se evita la fatiga de alertas? ¿Cómo se reducen las falsas alarmas? ¿Cómo se asigna prioridad a las alertas? ¿Cómo puede el sistema explicarse en un lenguaje comprensible para humanos? ¿Quién tiene autoridad de reinicio? ¿El sistema cae en modo solo observación cuando la aprobación no está disponible? ¿Se registran las intervenciones humanas?

Esto no es un eslogan moral de “los humanos asumen la responsabilidad final”. Es una cuestión de diseño operativo: ¿bajo qué condiciones debe la IA perder autonomía?

La respuesta no es dejarlo todo a la IA. Tampoco es lanzarlo todo a los humanos. El sistema debe decidir bajo qué estados se retira la autonomía a la IA y se transfiere a humanos.

Human-in-the-loop es el volante del modo crisis. Pero ese volante no debería estar siempre en manos humanas. Demasiada aprobación humana ralentiza el sistema. Demasiadas notificaciones agotan a los supervisores. Si se exige aprobación de noche y no hay nadie disponible, las posiciones pueden quedar abandonadas.

La intervención humana debe ser, por tanto, una función específica por régimen.

Un dashboard de monitorización debe mostrar por qué se detuvo el sistema

No basta con que la IA financiera se detenga. Los humanos deben entender por qué se detuvo.

Un dashboard de monitorización debería incluir al menos lo siguiente: estado de mercado, estado de datos, estado de órdenes, estado de posiciones, estado de exchange, estado de API, estado de financiación, estado de colateral, estado de stablecoin, estado de noticias, estado jurisdiccional y regulatorio, estado del modelo, estado de logs, historial de activación de blocks, estado del kill switch, estado de espera de aprobación humana y estado de cumplimiento de condiciones de reinicio.

El objetivo no es mostrar una luz roja. El objetivo es mostrar qué condición detuvo el sistema, qué condición debe despejarse antes del reinicio, qué exchange está suspendido, qué activo está suspendido, si las órdenes están detenidas mientras la observación continúa, si los logs siguen guardándose, si quedan órdenes abiertas, si se requiere aprobación humana y si el reinicio automático está prohibido.

Si estos estados no son visibles, una parada no es un mecanismo de seguridad. Es una caja negra. Un dashboard de IA financiera no puede ser solo una pantalla de pérdidas y ganancias. Debe mostrar por qué la IA opera, por qué se detuvo y qué debe comprobarse antes de que pueda reanudar.

Pruebas de estrés y análisis de escenarios

Si el backtesting normal examina mercados pasados, las pruebas de estrés crean deliberadamente condiciones de ruptura.

El punto clave es que los escenarios de evento único no bastan. Desplome de BTC, desplome de ETH, depeg de stablecoin, caída de un exchange principal, pico de errores de API, imposibilidad de cancelar órdenes, noticia falsa, titular de guerra, anuncio de sanciones, subida del dólar, subida del petróleo, caída bursátil, shock de tipos de interés, cascada de liquidaciones DeFi, congestión on-chain, suspensión de puente, caída de nube, fallo simultáneo de múltiples fuentes de datos, divergencia de precio entre exchanges y fallo de aprobación humana importan.

Las crisis no llegan necesariamente como platos individuales. Más a menudo llegan como una bandeja completa.

Una stablecoin puede perder la paridad mientras la API de un exchange se ralentiza. Un titular de guerra puede aparecer mientras las fuentes informativas discrepan. Las comisiones on-chain pueden dispararse durante una cascada de liquidaciones. Un exchange puede seguir caído mientras otro mercado muestra precios divergentes. La aprobación humana puede ser necesaria cuando los humanos duermen.

La seguridad de la IA financiera durante una crisis no debería probarse preguntando “¿ganó con datos históricos normales?”. Debería probarse preguntando “¿cómo se degrada bajo fallos compuestos?”.

La ingeniería del caos no debe probarse con trading en vivo

La inyección deliberada de fallos puede ser útil para la IA financiera. Retrasos en feeds de precios, desconexiones de API, rechazos de órdenes, ejecuciones parciales, caídas de exchanges, datos ausentes, noticias falsas, ampliación repentina de spreads, desaparición de libros de órdenes, depegs de stablecoins, rate limits, fallos de logging, fallos de notificación, aprobación humana no disponible y fallos de conmutación a respaldo pueden probarse.

Probar estas anomalías en entornos aislados, entornos de replay, paper trading o sandboxes es útil. Los mecanismos de seguridad que nunca han sido probados se parecen mucho a extintores decorativos.

Pero no deberían probarse con munición real en mercados de producción. Corromper deliberadamente feeds de precios, forzar rechazos de órdenes, simular órdenes incancelables o inyectar datos incorrectos en producción puede afectar a mercados y usuarios.

Las pruebas en producción deberían limitarse a sistemas de observación read-only, sistemas de notificación, sistemas de logging, dashboards y comprobaciones de failover que no envíen órdenes.

La ingeniería del caos para IA financiera no consiste en romper el sistema para hacerlo más fuerte. Consiste en identificar dónde nunca debe permitirse la ruptura.

Reiniciar es más peligroso que detenerse

En la gestión de regímenes en crisis, las condiciones de parada suelen recibir más atención. Pero las condiciones de reinicio son más difíciles.

Detenerse puede ser defensivo. “Ante la duda, parar” es relativamente fácil de diseñar. Reiniciar es ofensivo porque reingresa en el mercado. Si se reinicia demasiado pronto, el sistema entra en un mercado que sigue roto. Si se reinicia demasiado tarde, pueden ser imposibles coberturas necesarias u operaciones normales.

Las condiciones de reinicio requieren múltiples comprobaciones: menor volatilidad de mercado, spreads normalizados, recuperación de profundidad del libro, menor tasa de errores de API, concordancia entre fuentes de datos, confirmación oficial de recuperación del exchange, reanudación de depósitos y retiradas, recuperación de paridad de stablecoin, normalización del volumen de liquidaciones, verificación de noticias, comprobaciones de impacto de sanciones y regulación, reconciliación de logs, verificación de órdenes abiertas, verificación de saldos, verificación de posiciones, pequeñas órdenes de prueba, aprobación humana y reinicio escalonado.

El sistema no debería volver directamente a la operación normal. Debe subir la escalera: reinicio de observación, pequeñas órdenes de prueba, activos limitados, exchanges limitados, apalancamiento reducido, modo solo limit, restauración de tamaño normal y operación completa.

Detenerse es frenar. Reiniciar es volver a arrancar. Un coche que puede frenar todavía puede accidentarse si no sabe arrancar correctamente en una pendiente.

Los logs no sirven solo para asignar culpas

Los logs de crisis no sirven solo para determinar después quién tuvo la culpa. Son material para mejorar la siguiente respuesta ante una crisis.

El sistema debería conservar clasificación de régimen, datos utilizados, banderas de calidad de datos, señales de crisis, condiciones de activación de controles, soft block, hard block, kill switch, aprobación humana, órdenes, ejecuciones, órdenes abiertas, cancelaciones, errores, notificaciones, cambios de configuración, versión del modelo, versión del código, decisiones de reinicio y revisión posterior a la crisis.

Los logs de crisis deben responder a las siguientes preguntas. ¿Bajo qué condición se detuvo el sistema? ¿La parada fue demasiado temprana? ¿Fue demasiado tarde? ¿Fue una falsa alarma? ¿Se omitió algo? ¿Qué datos ayudaron? ¿Qué señales fueron ruido? ¿Fue efectiva la intervención humana? ¿Fueron apropiadas las condiciones de reinicio? ¿Fueron suficientes los logs? ¿Deben cambiarse los umbrales la próxima vez? ¿Qué debe añadirse al backtesting?

Una crisis no es solo algo que se soporta. Es algo que se registra para construir el siguiente mecanismo de seguridad.

Fail-safes mínimos para una IA financiera OSS pequeña

No es realista exigir que una IA financiera pequeña, individual u OSS tenga los mismos controles que una gran institución financiera. Pero no hacer nada es peligroso.

Para una IA financiera OSS pequeña como bitBuyer, el mínimo necesario no es un gran departamento de supervisión. Es una capa mínima de fail-safe: monitorización de estado de mercado de baja frecuencia pero significativa, comprobaciones de estado de API de exchange, límites de tamaño de orden, límites de pérdida, límites de spread, suspensión de órdenes cuando la profundidad del libro es insuficiente, detección de datos ausentes, detección de desviaciones de stablecoins, kill switch manual, modo solo observación, suspensión de trading mediante archivo de configuración, logs persistentes de órdenes, ejecuciones y errores, alertas simples, checklist previo al reinicio, pruebas en paper trading, separación de entornos de producción y prueba, comprobaciones de seguridad durante actualizaciones de modelo, separación de permisos de claves API, separación entre read-only key y trading key, restricciones de permiso de retirada y suspensión del aprendizaje durante regímenes anómalos.

El punto especialmente importante es separar la suspensión de trading de la continuidad de observación. Puede ser apropiado detener el trading durante una crisis. Pero si también se detiene la observación, la IA pierde el registro de la crisis. Sin registro, la siguiente crisis no puede manejarse mejor.

Si bitBuyer es un sistema de aprendizaje autónomo, hay otra pregunta clave: ¿deben mezclarse los regímenes anómalos con el aprendizaje normal?

Los datos de crisis son valiosos. Pero si se mezclan en el aprendizaje con el mismo peso que los datos normales, la IA puede aprender la distorsión de la crisis como si fuera normal. Durante una crisis, el sistema puede necesitar no solo suspensión de trading, sino también suspensión de aprendizaje, aislamiento del aprendizaje y etiquetado de régimen anómalo.

La autonomía no es permiso para operar en todo momento. La autonomía incluye saber bajo qué condiciones debe perderse la autonomía.

El exceso de control también es un riesgo

Hasta aquí, este artículo se ha centrado en detener y degradar la operación. Pero detener demasiado también es peligroso.

Las falsas alarmas pueden causar oportunidades perdidas. Las coberturas necesarias pueden volverse imposibles. El riesgo puede aumentar mientras el sistema está detenido. El reinicio puede retrasarse. Puede acumularse fatiga de alertas. La espera de aprobación humana puede generar pérdida de oportunidad. Una lógica excesiva de hard block puede destruir flexibilidad. Si muchos sistemas se detienen al mismo tiempo durante una crisis, la liquidez puede deteriorarse aún más.

Los mecanismos de seguridad no son mejores simplemente por ser más fuertes.

Un mecanismo demasiado fuerte bloquea acciones necesarias. Puede ser razonable detener nuevas órdenes durante una crisis, pero si también se bloquea la cobertura, el riesgo puede aumentar. Puede ser razonable detener órdenes a mercado, pero si incluso se bloquean órdenes limitadas de reducción en mercados suficientemente líquidos, las posiciones no pueden cerrarse.

La gestión de regímenes para IA financiera no consiste en ser tímido en toda circunstancia. Consiste en ser prudente cuando las condiciones son peligrosas y seguir pudiendo actuar de forma limitada cuando la acción es necesaria.

La IA homogénea puede amplificar las crisis

¿Qué ocurre si muchos sistemas de IA usan los mismos proveedores de datos, los mismos modelos, las mismas clasificaciones de noticias, los mismos indicadores de riesgo y las mismas condiciones de parada?

Eso puede estabilizar el mercado. Pero también puede volverlo más frágil.

Muchas IA pueden vender al mismo tiempo. Muchas IA pueden reducir apalancamiento al mismo tiempo. Muchas IA pueden detener nuevas órdenes al mismo tiempo. Muchas IA pueden correr hacia la misma salida estrecha al mismo tiempo. Muchas IA pueden clasificar la misma noticia del mismo modo. Muchas IA pueden reaccionar simultáneamente al mismo fallo de proveedor de datos. Muchas IA pueden deshacer posiciones según el mismo risk model.

Este es un problema difícil para la gestión de regímenes en crisis. Una parada racional para cada sistema individual de IA puede convertirse en parada simultánea irracional a nivel de mercado. Una reducción de apalancamiento racional para cada IA puede convertirse en venta simultánea a nivel de mercado. Una respuesta a noticias racional para cada IA puede convertirse en reacción simultánea a una noticia falsa a nivel de mercado.

Los mecanismos de seguridad protegen sistemas individuales. Pero si el mismo mecanismo de seguridad se activa en todo el mercado al mismo tiempo, puede convertirse en otro tipo de mecanismo de crisis.

En la era de la IA financiera, incluso la “seguridad” puede convertirse en comportamiento de rebaño.

Conexión con bitBuyer Project

Para bitBuyer Project, el centro de este asunto no es la personalidad de la IA. No es Civilization OS. No es la liberación del trabajo. No es una teoría general del OSS.

La pregunta central es una sola: ¿puede una IA financiera autónoma restringir su propio rango de acción?

Incluso si un sistema no tiene reglas fijas de trading, aprende mediante zero-knowledge learning y sigue aprendiendo del mercado, las condiciones de parada no deberían quedar necesariamente en manos del aprendizaje interno. Al contrario, las condiciones de parada, las condiciones de degradación, las condiciones de solo observación y las condiciones de reinicio quizá deban situarse fuera de la IA.

La razón es que la decisión más peligrosa durante una crisis puede ser que la IA decida: “debo seguir aprendiendo de este estado”.

Los datos de crisis son un objeto de aislamiento antes de ser material de aprendizaje. El trading de crisis es un objeto de restricción antes de ser una oportunidad de beneficio. El fallo de API es una degradación de la confianza observacional antes de ser una búsqueda de otro mercado. La desviación de una stablecoin es una anomalía de infraestructura antes de ser arbitraje. Una cascada de liquidaciones es un estado en el que la IA puede dañar el mercado antes de ser volatilidad.

bitBuyer no necesita poder predictivo omnipotente. Necesita autoridad mínima de parada, operación degradada mínima, observación continuada mínima, preservación mínima de logs, comprobaciones mínimas de reinicio y autoridad mínima de intervención humana.

Una IA financiera OSS pequeña no necesita poseer los mismos controles que una gran institución. Pero no debe ser una IA que no hace nada durante una crisis.

La autonomía no es movimiento ilimitado. La autonomía significa distinguir entre estados en los que la acción está permitida y estados en los que no lo está.

¿Cuál es la fuerza de la IA financiera?

¿La fuerza de la IA financiera es su capacidad de generar beneficios en tiempos normales o su capacidad de controlar cómo se rompe durante una crisis? Esta pregunta cambia el eje de evaluación de la IA financiera.

Un sistema que gana en backtesting normal parece atractivo. Pero un sistema que no puede detenerse durante una crisis no solo genera pérdidas. Exporta fallos al mercado. Cuando los exchanges se detienen, faltan datos, las stablecoins se distorsionan, las noticias se vuelven caóticas, las liquidaciones se encadenan y los humanos duermen, una IA que sigue utilizando la misma lógica no es inteligente. Simplemente no entiende que el entorno ha cambiado.

La IA financiera necesita algo más que inteligencia predictiva. Necesita inteligencia de parada. Necesita inteligencia de degradación. Necesita la inteligencia de conservar solo la observación. Necesita la inteligencia de no reiniciar demasiado pronto. Necesita la inteligencia de conservar logs. Necesita la inteligencia de saber que sus propias acciones pueden dañar el mercado.

El backtesting en tiempos de normalidad es la entrada de la IA financiera. La gestión de regímenes en crisis es el examen de salida antes de que la IA financiera entre en el mercado.

En una era en la que la IA lee mercados, el diseño que permite que la IA se detenga a sí misma también se convierte en parte del mercado. Y la verdadera fuerza de la IA financiera no reside solo en ganar, sino en elegir cómo romperse cuando romperse se vuelve inevitable.