Written By
Rdrigo Azziani
Published
June 10, 2026
La conversación siempre empieza en el mismo lugar.
El CTO de una institución del mercado de capitales describe lo que quiere: detección de anomalías durante la rueda, scoring de contraparte antes de confirmar una operación, alertas automáticas que disparen antes de que un error en la liquidación se propague al resto del sistema. Todo eso es tecnológicamente posible hoy. La pregunta no es si existe la IA para hacerlo. La pregunta es si la infraestructura que tienen debajo puede sostenerla.
En la mayoría de los casos, no puede.
Cuando una institución financiera decide invertir en inteligencia artificial, el foco natural es el modelo: qué algoritmo, qué proveedor, qué caso de uso. Esa es la parte visible, la que genera conversación en reuniones de directorio y aparece en los roadmaps de innovación.
Lo que no aparece en esos roadmaps es lo que viene antes. Para que un modelo de detección de fraude funcione en tiempo real, necesita datos limpios, accesibles y con latencia baja. Para que un sistema de scoring calcule exposición antes del cierre de la operación, necesita una infraestructura que procese y sirva esa información en milisegundos. Para que cualquier modelo de ML se mantenga útil más de seis meses, necesita un pipeline de reentrenamiento continuo con datos actualizados.
Ninguna de esas condiciones se cumple por defecto. Todas dependen de decisiones de infraestructura que preceden al modelo por meses, a veces por años.
En casi cualquier otro sector, si un modelo tiene latencia subóptima o los datos llegan con algunos minutos de retraso, el impacto es tolerable. En el mercado de capitales argentino, no lo es.
Una cámara compensadora que liquida operaciones de renta variable tiene una ventana de procesamiento que no admite degradación. Un error que no se detecta antes del cierre de la rueda no es un inconveniente operativo: es un problema de riesgo sistémico. Un modelo de scoring que tarda diez segundos en responder no es scoring en tiempo real: es una consulta batch con aspiraciones de IA.
Las instituciones del mercado de capitales —cámaras compensadoras, depositarias centrales, agentes de liquidación— operan con restricciones de latencia y disponibilidad más exigentes que las de la mayoría de los sistemas financieros. Por eso el prerequisito de infraestructura no es una recomendación técnica opcional: es una condición de funcionamiento.
La conversación sobre datos en contextos de IA suele concentrarse en la calidad: datos incorrectos, duplicados, inconsistentes. Ese es un problema real, pero no es el primero que aparece.
El primero es el acceso. En la mayoría de las instituciones con las que trabajamos, los datos operativos existen y en volúmenes considerables. El problema es que están distribuidos en sistemas que no se diseñaron para ser consultados en tiempo real, en formatos que requieren transformación antes de poder usarse, y en silos sin mecanismos de integración modernos.
Un modelo de detección de anomalías en liquidación necesita visibilidad simultánea sobre órdenes, confirmaciones, posiciones y garantías. Si esos datos viven en sistemas separados sin una capa de integración unificada, construir el modelo es el problema más fácil. El problema difícil es llegar a los datos antes de que la ventana de procesamiento se cierre.
"AI-ready" no es una certificación ni un estado binario. Es una combinación de capacidades que se construyen en secuencia y que habilitan distintos niveles de sofisticación.
El punto de entrada es la capacidad de ingestión y procesamiento de datos en tiempo real. Sin eso, los casos de uso más valiosos para el mercado de capitales —detección de anomalías, scoring en tiempo real, alertas preventivas— son directamente inaccesibles.
El segundo nivel es la disponibilidad de datos históricos para entrenamiento: limpios, accesibles, versionados. Un modelo que no puede reentrenarse con datos actualizados empieza a degradarse desde el día en que se despliega.
El tercer nivel es la infraestructura de serving: la capacidad de servir inferencias con latencia consistente bajo carga real de producción. Un modelo que funciona en un notebook de desarrollo y no escala bajo demanda no es un modelo de producción.
Ninguno de estos niveles requiere empezar desde cero si la organización ya tiene parte de la infraestructura cloud construida. Pero sí requieren una revisión explícita contra estos criterios antes de comprometer presupuesto en el modelo.
La tendencia natural es invertir en el caso de uso primero —el modelo, el proveedor, el contrato de datos— y resolver la infraestructura después, cuando aparecen los problemas. Esa secuencia es cara y lenta.
Lo que funciona es la inversa: evaluar qué capacidades de infraestructura ya existen, identificar los gaps contra los criterios de AI-readiness, resolverlos, y construir el modelo sobre esa base. El modelo llega al final, cuando la infraestructura puede sostenerlo.
No es la secuencia más glamorosa. Pero es la que evita llegar a mitad de un proyecto de IA y descubrir que los datos no están donde deberían, o que la latencia en producción es diez veces la del ambiente de desarrollo.
Si tu institución está evaluando casos de uso de IA y no tenés claridad sobre el estado de tu infraestructura de datos, ese es el primer diagnóstico que vale hacer — antes de cualquier otro paso.
No es un proceso largo. En dos o tres semanas se puede mapear el estado actual contra los criterios de AI-readiness y tener una imagen clara de qué está listo, qué falta construir y en qué orden. Eso define si el proyecto de IA que tenés en mente puede arrancar en seis meses o en dieciocho.
En Renaiss trabajamos con instituciones del mercado de capitales y el sector financiero argentino en ese diagnóstico y en la implementación que sigue. Si querés conversar sobre tu caso, coordinemos una reunión.
© 2026 - Renaiss with love