La máquina financiera sostenida por electricidad, semiconductores, redes, API de mercados, claves y sistemas de monitoreo
La nube no es un lugar donde desaparece la realidad física.
Existen centrales eléctricas que suministran energía, líneas de transmisión que la transportan, subestaciones que transforman su voltaje, sistemas de refrigeración que extraen el calor y servidores llenos de semiconductores. Desde los edificios que los albergan se extienden cables de fibra óptica. La maquinaria física sigue existiendo. Lo único que ha cambiado es que sus propietarios, ubicaciones y puntos de falla se han alejado del campo de visión del usuario.
Las conversaciones sobre IA financiera suelen concentrarse en la precisión de los modelos, los datos de entrenamiento, la capacidad de inferencia y los algoritmos de ejecución de órdenes. Sin embargo, una IA financiera conectada a un mercado real no puede operar únicamente con modelos y código.
Debe recibir precios, registrar marcas de tiempo, tomar decisiones, enviar órdenes, confirmar ejecuciones, conciliar saldos, conservar registros, detectar anomalías, detenerse cuando sea necesario y recuperarse después de una falla. Cada etapa depende de una cadena formada por electricidad, refrigeración, semiconductores, recursos de cómputo, infraestructura de comunicaciones, sistemas de autenticación, mercados, servicios de custodia, verificación de identidad, monitoreo, copias de seguridad, jurisdicciones legales y contratos con terceros.
La IA financiera no es una inteligencia que flota sobre la nube.
Es una máquina financiera que solo puede alcanzar el mercado porque un amplio conjunto de infraestructuras externas le permite hacerlo.
El suelo físico bajo la inteligencia
La Agencia Internacional de Energía proyecta que el consumo mundial de electricidad de los centros de datos podría aumentar desde aproximadamente 415 teravatios-hora en 2024 hasta cerca de 945 teravatios-hora en 2030, y que la IA representará una parte importante de ese crecimiento. Al mismo tiempo, las listas de espera para conectarse a las redes eléctricas, la escasez de transformadores y cables, y los largos periodos necesarios para construir nueva capacidad de generación y transmisión están convirtiéndose en restricciones físicas para la expansión de los centros de datos. (IEA)
Los recursos de cómputo no surgen de la GPU de un único fabricante. La producción de semiconductores depende del diseño, los equipos de fabricación, los materiales especializados, las obleas, la fabricación de front-end, la memoria, el empaquetado avanzado, el ensamblaje y las pruebas. Estas etapas atraviesan repetidamente fronteras corporativas y nacionales. La OCDE describe la cadena de valor de los semiconductores como una estructura distribuida globalmente, pero también altamente concentrada en determinadas etapas y alrededor de ciertos insumos críticos. (OCDE)
La supervisión financiera también ha empezado a transformarse. En la Unión Europea, determinados terceros que prestan servicios esenciales de tecnologías de la información y las comunicaciones a entidades financieras han quedado sujetos a supervisión directa debido a su posible impacto sobre la continuidad operativa del sistema financiero. Su importancia no se evalúa únicamente por el tamaño de la empresa, sino por la cantidad de funciones financieras críticas que respaldan, la dificultad de sustituirlos y la amplitud con la que una interrupción podría propagarse. (ESMA)
El objetivo no es evaluar a una empresa eléctrica, fabricante de semiconductores, proveedor de nube o mercado en particular.
El cambio importante es que las instalaciones, cadenas de suministro, relaciones contractuales y jurisdicciones que sostienen a la IA financiera ya no se consideran simples condiciones de fondo. Cada vez se reconocen más como componentes de la disponibilidad del propio sistema financiero.
Observar la IA financiera desde abajo
La estructura de una IA financiera se entiende mejor cuando se construye desde la infraestructura física hacia arriba, en lugar de descender desde el modelo.
Electricidad, refrigeración, agua y edificios ↓Semiconductores, servidores, memoria, almacenamiento y hardware de red ↓Sistemas locales, infraestructura propia, servicios en la nube,virtualización y contenedores ↓Redes fijas y móviles, puntos de intercambio de internet, BGP, DNS,TLS, NTP y PTP ↓Fuentes de precios, noticias, información on-chain y flujos de mercados ↓API de mercados, API de brókeres, billeteras, custodios y sistemas KYC ↓IAM, claves de API, claves privadas, KMS, HSM, MPC y permisos de órdenes ↓Métricas, registros, trazas, alertas y conciliación de saldos ↓Copias de seguridad, conmutación por error, recuperación manual,contratos y jurisdicciones
Cuando falla la capa inferior, todas las capas situadas por encima pueden quedar inutilizadas.
Sin electricidad, el sistema no puede calcular. Sin refrigeración, las máquinas se apagan para evitar daños físicos. Sin infraestructura de comunicaciones, el sistema no puede observar el mercado. Sin DNS, puede ser incapaz de localizar el servicio con el que necesita comunicarse. Sin sincronización temporal, no puede establecer de forma confiable la secuencia de órdenes, ejecuciones y registros.
Si falla la API del mercado, el sistema no puede enviar órdenes. Si falla la autenticación, no puede acceder a la API. Si una revisión KYC deja una cuenta en espera, la cuenta puede quedar inutilizable. Si se pierde una clave privada, los activos pueden quedar inmovilizados. Si falla el monitoreo, el operador puede no saber que el sistema se ha detenido. Si las copias de seguridad son defectuosas, eliminar la causa original de la falla no será suficiente para recuperar la operación.
Que el modelo funcione solo demuestra que funciona uno de los componentes de esta cadena.
La electricidad y el calor son las primeras condiciones de parada
La primera dependencia de una IA financiera no es la nube. Es la electricidad.
Un centro de datos no funciona únicamente con la energía de la red pública. El suministro confiable a los servidores depende de la infraestructura de recepción, los cuadros eléctricos, los sistemas de alimentación ininterrumpida, las baterías, los generadores de respaldo, el abastecimiento de combustible, las bombas de refrigeración y los equipos de monitoreo.
Un UPS no es una fuente permanente de electricidad. Es un puente entre la pérdida del suministro eléctrico y el arranque de la generación de respaldo. Los generadores pueden no arrancar. El combustible puede agotarse. El mantenimiento puede ser insuficiente. Los equipos de transferencia pueden fallar. Incluso una instalación con múltiples alimentaciones eléctricas puede tener una redundancia meramente superficial si todas comparten la misma subestación, el mismo cuadro eléctrico o la misma ruta de distribución.
Prácticamente toda la energía eléctrica utilizada para computar termina convirtiéndose en calor.
Cuanto mayor es la densidad de un clúster de GPU o aceleradores de IA, más difícil resulta extraer ese calor únicamente mediante refrigeración por aire. El sistema pasa a depender cada vez más de la refrigeración líquida, el agua enfriada, las bombas, los intercambiadores de calor y las enfriadoras. La temperatura exterior, la humedad, la disponibilidad de agua y la regulación ambiental se convierten tanto en criterios de localización como en condiciones que determinan la disponibilidad de los recursos de cómputo.
Un análisis de incidente publicado en 2026 por una importante plataforma de activos digitales describió una falla en la que varias unidades de refrigeración de una misma sala de un centro de datos en la nube dejaron de funcionar simultáneamente. Los mecanismos de protección térmica apagaron después la infraestructura de cómputo y almacenamiento. La falla se propagó al motor de casación, la distribución de eventos, las cotizaciones de mercado, el procesamiento de saldos, los depósitos y los retiros, dejando fuera de servicio durante horas importantes funciones de negociación. (Coinbase)
Esto no constituye un argumento contra el proveedor de nube implicado.
Confirma que una falla de un sistema financiero puede comenzar en una máquina de refrigeración y no en un algoritmo.
Una GPU no es un recurso autónomo
Una IA financiera sigue dependiendo de la cadena de suministro de semiconductores incluso cuando nunca compra una GPU física.
Los recursos de cómputo en la nube siguen estando formados por GPU, CPU, módulos de memoria, dispositivos de almacenamiento, interfaces de red y sistemas de alimentación físicos. Una GPU no puede ofrecer el rendimiento previsto sin suficiente memoria de alto ancho de banda. Los chips fabricados no pueden convertirse en productos utilizables si no existe capacidad de empaquetado avanzado. Varios aceleradores no pueden funcionar como un clúster si no se dispone del equipo de red necesario.
La cadena de suministro de semiconductores no es una sola fábrica. Es una secuencia de procesos distribuida entre varias regiones.
Las capacidades de diseño, los equipos de fabricación, los materiales químicos, las obleas de silicio, la producción de lógica avanzada, la fabricación de memoria, el ensamblaje, las pruebas y el empaquetado avanzado se concentran en lugares distintos. Un retraso en una sola etapa puede reducir la oferta final de recursos de cómputo utilizables. (OCDE)
Los controles de exportación también forman parte de estas condiciones de suministro. El acceso a los recursos de cómputo puede depender no solo de dónde se encuentra el hardware, sino también de la identidad del usuario, la empresa matriz, el uso final previsto y la contraparte contractual. Las orientaciones publicadas por las autoridades estadounidenses a finales de mayo de 2026 aclararon además determinadas circunstancias en las que los requisitos de licencia aplicables a equipos avanzados de cómputo pueden extenderse a empresas ubicadas en terceros países. Las normas específicas pueden cambiar, pero la estructura subyacente es más duradera: el acceso a los recursos de cómputo puede variar según la jurisdicción y la identidad del usuario. (BIS)
Para la IA financiera, la escasez de semiconductores no es únicamente un problema de entrenamiento.
Puede alargar las colas de pruebas retrospectivas, reducir la frecuencia de actualización de los modelos, impedir la sustitución de hardware averiado por sistemas equivalentes y restringir el acceso a reservas de capacidad o cuotas regionales en la nube. Cuantas más funciones esenciales dependan de GPU, más directamente pueden convertirse las restricciones de oferta en restricciones operativas.
Para un proyecto pequeño de IA financiera, las funciones de observación compatibles con CPU, los modelos ligeros, la inferencia de menor frecuencia y la separación entre los sistemas de entrenamiento y los sistemas de producción no son simples concesiones de rendimiento.
Impiden que la indisponibilidad de una categoría de recursos de cómputo se convierta en una interrupción total del sistema.
La nube produce resiliencia y concentración al mismo tiempo
La nube no debilita necesariamente a la IA financiera.
Puede poner al alcance incluso de pequeños desarrolladores la implementación en múltiples ubicaciones, el almacenamiento redundante, las bases de datos administradas, el escalado automático, las copias de seguridad, el monitoreo y el control de acceso. En muchos casos, puede ofrecer una disponibilidad superior a la de una sola computadora instalada en una vivienda o una pequeña oficina.
Al mismo tiempo, los servicios en la nube pueden concentrar numerosas dependencias en una sola relación comercial.
El cómputo, el almacenamiento, las bases de datos, las colas de mensajes, los contenedores, los servicios de identidad, la gestión de claves, la conservación de registros, el monitoreo y el despliegue continuo pueden quedar bajo un mismo proveedor. Una interrupción, una suspensión de cuenta, un error de configuración o un cambio jurisdiccional pueden propagarse entonces por un amplio conjunto de funciones.
El concepto de tercero crítico ha adquirido importancia en el sector financiero porque esta concentración puede afectar simultáneamente a muchas entidades y no solo a un cliente. El Comité de Basilea sobre Supervisión Bancaria ha señalado que la dependencia de los proveedores externos ya supera el ámbito de la externalización convencional. Incluye subcontratistas, dependencias de terceros situados más abajo en la cadena, concentración geográfica y dependencia compartida de servicios comunes. El Consejo de Estabilidad Financiera también ha propuesto gestionar los servicios externos importantes durante todo su ciclo de vida, desde la selección y la contratación hasta la supervisión continua, la sustitución y la salida. (BIS)
Por lo tanto, la pregunta de si la nube fortalece a la IA financiera o crea un punto único de falla solo admite una respuesta honesta.
Puede hacer ambas cosas, según la arquitectura.
La redundancia no es el número de copias
Ejecutar dos servidores en la misma nube no proporciona una independencia significativa si ambos dependen del mismo edificio, sistema eléctrico, servicio de identidad y capa de almacenamiento.
La replicación en otra región puede seguir dejando un punto único de falla si se mantienen compartidos la cuenta de despliegue, el proveedor de DNS, las claves de cifrado, el repositorio de código fuente y el personal operativo.
El uso de dos proveedores de nube tampoco crea necesariamente una verdadera redundancia de acceso al mercado si ambos entornos se actualizan desde el mismo sistema de CI/CD, reciben los mismos archivos de configuración, se autentican mediante el mismo proveedor externo de identidad y se conectan a la misma API de mercado.
La redundancia no consiste en multiplicar componentes.
Consiste en separar los componentes que, de otro modo, fallarían por la misma causa.
Los propios proveedores de nube describen la implementación en una sola ubicación como una arquitectura de alto riesgo, pero también advierten que los diseños multirregión innecesarios pueden introducir divergencias de configuración, retrasos de replicación, dependencias entre regiones y mayores costos. Cuanta más redundancia adquiere un sistema, más complejas se vuelven la gestión de su configuración y sus operaciones de recuperación. (AWS)
Para determinar si un sistema está realmente distribuido, es necesario preguntar si las redes eléctricas son distintas, los edificios son distintos, las rutas de comunicación son distintas, los sistemas DNS son distintos, los sistemas de identidad son distintos, las cuentas administrativas son distintas, las rutas de recuperación de claves son distintas, las jurisdicciones son distintas y los operadores humanos son independientes.
Tener varias configuraciones no equivale a disponer de varias rutas independientes.
Las comunicaciones y el tiempo definen las coordenadas del acceso al mercado
Una IA financiera parece conectarse directamente a la API de una plataforma de negociación.
En realidad, el trayecto puede incluir una red local, un enrutador, un proveedor de servicios de internet, un punto de intercambio, rutas BGP, cables submarinos, infraestructura DNS, redes de distribución de contenidos, certificados TLS y sistemas de protección contra ataques DDoS.
La conexión no necesita desaparecer por completo para que la operativa se vuelva insegura. La pérdida de paquetes, el jitter, los cambios de ruta y las fallas de DNS pueden alterar la relación temporal entre la recepción de precios y las respuestas a las órdenes. Si una conexión WebSocket se interrumpe y se pierden ciertos eventos después de la reconexión, el sistema debe comprobar si su estado interno sigue coincidiendo con el estado del mercado.
La sincronización temporal resulta todavía más fácil de pasar por alto.
NTP y PTP no son simples mecanismos destinados a mostrar la hora correcta en una esquina de la pantalla. Proporcionan una línea temporal común para la recepción del precio, la generación de decisiones, la transmisión de órdenes, su aceptación por el mercado, la ejecución y el registro.
El Instituto Nacional de Estándares y Tecnología explica cómo los sistemas operativos ordinarios consultan periódicamente servidores NTP para sincronizar sus relojes y cómo la precisión puede verse afectada por la estabilidad de la ruta de red. Los distintos métodos de tratamiento de los segundos intercalares también pueden introducir ambigüedad en el orden de los eventos. (NIST)
Si el reloj de una IA financiera se desvía, las consecuencias no se limitan al rechazo de órdenes.
El sistema puede ser incapaz de determinar cuál de dos órdenes se emitió primero. Puede no poder demostrar si una decisión se tomó antes o después de un movimiento de precios. Las marcas temporales de las fallas y las secuencias de registros pueden dejar de coincidir, produciendo un análisis incorrecto de la causa raíz.
La sincronización temporal no es un complemento de la calidad de los datos.
Es el sistema de coordenadas que hace posibles la causalidad y la auditabilidad.
Una API de mercado es un contrato operativo de acceso
Una IA financiera no envía órdenes a una entidad abstracta llamada mercado.
Participa a través de interfaces técnicas definidas por una plataforma de negociación o un bróker.
Las interfaces REST, WebSocket y FIX tienen finalidades, métodos de autenticación, límites de conexión, límites de solicitudes y requisitos de gestión de errores diferentes. Las plataformas también definen sus propios tamaños mínimos de orden, variaciones mínimas de precio, tipos de órdenes admitidos, comportamiento de las ejecuciones parciales, procedimientos de cancelación, requisitos de marcas de tiempo, restricciones de IP y procesos de mantenimiento.
La documentación de las API de mercados contiene límites explícitos de solicitudes, conexiones y mensajes para las interfaces REST, FIX y WebSocket. Las cifras concretas pueden cambiar, pero el principio permanece: una API no es un conducto ilimitado. Es una infraestructura privada regida por las normas técnicas de la plataforma. (Documentación de Coinbase)
Cuando falla una API, el resultado no consiste únicamente en la pérdida de datos.
El sistema puede no poder enviar nuevas órdenes. Puede ser incapaz de confirmar cancelaciones. Puede no saber si una orden fue ejecutada o sigue abierta. Los saldos pueden dejar de actualizarse. El estado de depósitos y retiros puede quedar inaccesible. El sistema puede ser incapaz de distinguir una interrupción de la plataforma de una falla local de autenticación.
Por lo tanto, una IA financiera nunca debe seguir tratando el último estado recuperado como un hecho actual después de perder la conectividad con el mercado.
La pérdida de acceso a la API debe considerarse una pérdida de acceso al mercado.
KYC, autenticación, claves y custodia son la infraestructura del derecho a operar
Aunque el modelo, la red y la API del mercado estén funcionando correctamente, todavía puede ser imposible operar.
La cuenta debe haber completado la verificación de identidad. El país de residencia del usuario o la jurisdicción de la empresa deben estar admitidos. Las reautenticaciones exigidas deben haberse completado. La cuenta no debe encontrarse retenida por una revisión de sanciones o prevención del lavado de dinero.
El Grupo de Acción Financiera reconoce que los sistemas de identidad digital pueden utilizarse para identificar clientes, realizar diligencia debida continua y monitorear transacciones. También establece que deben evaluarse su confiabilidad, nivel de garantía, características de ciberseguridad y dependencias de terceros. Si falla el sistema de identidad, una aplicación de IA financiera puede seguir funcionando desde el punto de vista computacional y, aun así, ser incapaz de abrir una cuenta, completar una reautenticación o ejecutar operaciones sensibles. (GAFI)
Después de la autenticación viene la autorización.
El permiso para leer precios, consultar saldos, enviar órdenes, cancelar órdenes y retirar activos no es un único permiso.
Si el entorno de ejecución de la IA financiera recibe autoridad para efectuar retiros, una vulneración del código o una filtración de la clave de API puede transformarse directamente en una transferencia de activos. Separar el acceso de lectura, la autoridad de negociación y la autoridad de retiro reduce el alcance de los daños. El sistema solo debe conservar los permisos necesarios para su función actual.
El mismo principio se aplica a las billeteras y a la custodia.
Las billeteras calientes, las billeteras frías, los esquemas multifirma, la computación multipartita y los módulos de seguridad de hardware no pueden ordenarse en una sola escala. Distribuyen de manera diferente la inmediatez, la disponibilidad, los requisitos de recuperación, la carga operativa y la resistencia frente al abuso interno.
No basta con ocultar una clave privada.
¿Puede revocarse? ¿Puede rotarse? ¿Puede restaurarse desde una copia de seguridad? ¿Puede continuar la recuperación cuando el operador principal no está disponible? ¿Están protegidos los datos de recuperación y los activos cifrados frente a la posibilidad de perderse en un mismo incidente?
Una IA financiera no necesita capacidad para poseer todas las claves.
Necesita conservar de forma segura únicamente los permisos requeridos y controlar su revocación y recuperación.
Cuando falla el monitoreo, el sistema pierde su propio estado
No basta con que una IA financiera funcione correctamente.
También debe ser posible verificar que está funcionando correctamente.
El monitoreo debe ir más allá del uso de CPU y GPU. Debe incluir el consumo de memoria, el espacio de almacenamiento disponible, la latencia de red, la resolución DNS, la desviación del reloj, las tasas de éxito de las API, las desconexiones WebSocket, las tasas de éxito y rechazo de órdenes, las discrepancias de saldos, el estado de entrega de registros, el vencimiento de certificados, la finalización de copias de seguridad y la profundidad de las colas.
Los sistemas de monitoreo también pueden fallar.
Si la aplicación y la plataforma de monitoreo residen en la misma nube, región y cuenta, una sola interrupción puede eliminar tanto el sistema como el mecanismo destinado a observarlo. Una página pública de estado es, a su vez, una dependencia externa y puede actualizarse después de que la interrupción subyacente ya haya comenzado.
Por ello, la IA financiera necesita monitoreo interno y externo.
El monitoreo interno proporciona información detallada sobre procesos, colas y ejecución de órdenes. El monitoreo externo comprueba si se puede acceder al servicio a través de la misma ruta disponible para los usuarios. El monitoreo local conserva un registro operativo mínimo cuando los registros ya no pueden enviarse a la nube.
Un sistema sin monitoreo puede detenerse sin que nadie lo advierta.
Un sistema sin registros puede seguir funcionando sin poder explicar lo que hizo.
La disponibilidad de una IA financiera no significa únicamente que el procesamiento continúe. Significa que ese procesamiento puede observarse, verificarse y detenerse cuando sea necesario.
Recuperarse no significa reiniciar un servidor
Una copia de seguridad de una IA financiera no puede limitarse a una copia de la base de datos.
La recuperación puede requerir archivos de configuración, artefactos de modelos, dependencias de software, imágenes de contenedores, parámetros de conexión a mercados, información para recuperar claves, registros, posiciones de lectura en colas de mensajes, procedimientos operativos y configuraciones de monitoreo.
Los requisitos de tiempo de recuperación y pérdida tolerable de datos serán diferentes para cada uno de estos elementos.
Los registros de auditoría pueden necesitar conservarse sin interrupciones. Algunos datos de mercado pueden recuperarse de nuevo. Los archivos de modelos pueden volver a distribuirse, pero no será posible reproducir un comportamiento idéntico si se han perdido el entorno y la configuración de entrenamiento. Las claves privadas se vuelven peligrosas si se copian en demasiados lugares, pero los activos pueden quedar permanentemente inaccesibles si no existe una copia recuperable.
Las orientaciones del NIST sobre planes de contingencia tratan la recuperación no como una tarea que se realiza únicamente después de una falla, sino como una actividad arquitectónica cuyas prioridades y requisitos se definen durante el diseño del sistema. (NIST)
Una IA financiera no debe reanudar las operaciones automáticas en cuanto la infraestructura vuelve a estar en línea.
¿Queda alguna orden abierta? ¿Se ejecutó alguna orden durante la interrupción? ¿Coinciden los saldos y las posiciones? ¿Existen vacíos en los registros? ¿Qué antigüedad tiene el último dato de mercado confirmado? ¿Está sincronizado el reloj? ¿Ha caducado o se ha revocado alguna clave de API? ¿Se ha eliminado realmente la causa subyacente de la falla?
Que un servidor esté en línea y que un sistema de negociación pueda reiniciarse con seguridad son condiciones distintas.
La operación local, en la nube o híbrida no tiene un ganador universal
La operación local puede reducir la exposición a contratos de nube y suspensiones de cuentas. Puede mantener los datos y las claves físicamente cerca del operador y disminuir el número de servicios externos.
También crea una dependencia directa de la electricidad doméstica, los enrutadores, los proveedores locales de internet, el control de temperatura, los dispositivos de almacenamiento, la seguridad física y la disponibilidad de la persona responsable del mantenimiento. La operación local no escapa de la infraestructura física. Transfiere su responsabilidad al usuario.
La operación en la nube facilita la implementación en múltiples ubicaciones, el almacenamiento redundante, el monitoreo externo y la reconstrucción rápida. También crea dependencia de precios, cuotas, condiciones de servicio, jurisdicciones, administración de cuentas y comportamiento de servicios administrados. La nube no elimina el mundo físico. Convierte la infraestructura física y las operaciones en una dependencia contractual.
La operación híbrida puede permitir que la infraestructura local y la nube compensen mutuamente sus debilidades.
También dificulta la sincronización, la ubicación de las claves, la coherencia de la configuración y la determinación de qué sistema debe asumir el control durante una falla. Si está mal diseñada, una arquitectura híbrida no obtiene dos formas de resiliencia. Obtiene dos categorías de fallas.
La decisión relevante no es ideológica. Es arquitectónica.
¿Qué funciones deben permanecer en local? ¿Qué información debe replicarse en la nube? ¿Qué funciones pueden detenerse de forma segura? ¿Cuáles deben continuar durante una interrupción?
bitBuyer no necesita convertirse en una institución financiera en miniatura
Un proyecto pequeño y de código abierto de IA financiera como bitBuyer no puede mantener de forma realista la infraestructura, los múltiples entornos de nube, la conectividad dedicada y los equipos especializados de operaciones disponibles para una gran institución financiera.
No necesita una redundancia perfecta. Necesita dependencias que sigan siendo visibles y comprensibles.
Como mínimo, pueden aplicarse los siguientes principios de diseño.
Primero, documentar las dependencias externas.
Se deben registrar todos los mercados, API, servicios DNS, fuentes de tiempo, servicios en la nube, sistemas de autenticación, destinos de registros, servicios de actualización y modelos externos utilizados por el sistema. No basta con anotar el nombre del servicio. Debe indicarse si su falla impediría observar, decidir, operar, explicar o recuperar.
Segundo, distinguir la pérdida de datos de la pérdida de capacidad para enviar órdenes.
La falla de una fuente de datos no siempre exige detener todas las funciones. Sin embargo, no debe enviarse ninguna nueva orden cuando ya no pueda garantizarse la calidad de la observación. El sistema debe poder detener las operaciones mientras mantiene las comprobaciones de conectividad, el registro y la presentación de su estado.
Tercero, separar la autoridad de retiro del entorno de ejecución de la IA.
Las claves de solo lectura, las claves de negociación y la autoridad de retiro deben estar separadas. Las claves privadas y frases semilla que la IA no necesite no deben colocarse en su entorno de ejecución.
Cuarto, conservar registros cuando la nube no esté disponible.
Si los registros no pueden enviarse a un servicio en la nube, deben almacenarse localmente y transmitirse después de la recuperación. La imposibilidad de conservar un registro debe registrarse también.
Quinto, conservar una funcionalidad mínima sin GPU.
Aunque un modelo grande no esté disponible, un sistema basado en CPU debe seguir siendo capaz de comprobar la conectividad, mostrar el estado, emitir alertas y detener el envío de órdenes. Los recursos de cómputo utilizados para investigación y entrenamiento deben separarse de los recursos mínimos necesarios para la seguridad en producción.
Sexto, hacer copias de seguridad de algo más que el código fuente.
Las copias deben incluir la configuración, los modelos, las versiones de las dependencias, la información sobre compatibilidad con los mercados, las reglas de monitoreo, los procedimientos de recuperación y los metadatos de gestión de claves. Las copias de seguridad deben evaluarse por el éxito de las pruebas de restauración y no por la cantidad de copias creadas.
Séptimo, mostrar a los usuarios el estado actual de las dependencias.
La conectividad con los mercados, la sincronización del reloj, la actualidad de los datos, la conservación de registros, la autoridad para operar y el estado del monitoreo deben mostrarse junto con la última hora en la que se verificó cada condición.
Octavo, establecer un límite a la complejidad arquitectónica.
Cada mercado, proveedor de nube, fuente de datos y servicio de monitoreo adicional incorpora nuevas claves, contratos, pruebas, modos de falla y procedimientos de recuperación. Una redundancia que el desarrollador no puede comprender, probar y mantener se convierte en un punto de falla no documentado.
bitBuyer no necesita evitar todas las interrupciones posibles.
Necesita explicar qué ha fallado, qué se ha perdido, qué funciones continúan siendo seguras y qué debe verificarse antes de volver a conectarse al mercado.
Diseñar la forma en que falla la inteligencia
La capacidad de una IA financiera no puede medirse únicamente por la precisión de su modelo.
¿Puede detenerse de forma segura cuando se pierde la electricidad? ¿Se negará a tratar un precio antiguo como actual cuando las comunicaciones se vuelvan inestables? ¿Evitará reenviar indefinidamente una orden cuando la API del mercado deje de responder? ¿Reconocerá que la ausencia de monitoreo no demuestra que todo funciona con normalidad? ¿Podrá recuperarse si se pierde una clave? ¿Podrá conciliar los saldos y el estado de las órdenes después de que regrese la infraestructura?
Añadir capacidades a una IA financiera es sencillo.
Un desarrollador puede llamar a otro modelo externo, añadir otra fuente de datos, conectar otra plataforma de negociación e incorporar otro servicio en la nube. Sin embargo, cada nueva función crea dependencias adicionales de electricidad, comunicaciones, contratos, autenticación, claves, monitoreo y recuperación.
Lo que es técnicamente posible y lo que puede operarse a largo plazo no son la misma cosa.
Existen situaciones en las que un modelo pequeño ejecutado localmente resulta más valioso que un modelo mayor dependiente de capacidad remota. Hay situaciones en las que un único entorno completamente comprendido es más seguro que varios entornos en la nube mal gobernados. También hay situaciones en las que la recuperación debe seguir siendo manual hasta que una persona haya verificado el estado del sistema.
La fortaleza de una IA financiera no consiste en que nunca se rompa.
Consiste en saber dónde se ha roto, limitar las consecuencias, conservar únicamente las funciones que siguen siendo seguras, explicar su estado y volver a conectarse al mercado solo después de haber comprobado la recuperación.
La IA financiera no funciona sobre una idea llamada «nube».
Funciona sobre una cadena de física, infraestructura de comunicaciones, instituciones, contratos y operaciones humanas que se extiende desde la central eléctrica hasta el mercado.
Solo cuando esa cadena queda incorporada a la arquitectura, la IA financiera deja de ser una inteligencia abstracta y se convierte en una máquina financiera operable.
