Por Mariluz Rodríguez - Gerente Comercial de ACL
En los últimos años, en conversaciones con bancos en Chile y la región, he visto el mismo patrón: pilotos de IA que se anuncian con entusiasmo, muestran resultados promisorios en pequeño… y luego quedan atrapados entre Innovación, TI y Riesgo, sin llegar a convertirse en capacidades estables del banco.
Mientras tanto, el contexto se mueve a otra velocidad. El McKinsey Global Institute estima que la IA generativa podría aportar entre US$200.000 y US$340.000 millones anuales solo al sector bancario, si los casos de uso se escalan a nivel global. El Global Banking Annual Review 2025 proyecta además que, en escenarios donde la IA se despliega a escala, los bancos podrían lograr una reducción de costos de 15–20% y rediseñar su modelo operativo.
La conclusión es transparente: la IA dejó de ser un experimento y se transformó en un imperativo estratégico para la banca.
A este impulso económico se suma una presión creciente desde el lado regulatorio. El Financial Stability Board (FSB) ha advertido que el uso intensivo de IA y machine learning en servicios financieros trae beneficios, pero también nuevos riesgos de estabilidad, especialmente cuando los modelos carecen de transparencia, trazabilidad y controles de ciclo de vida.
En Europa, el AI Act clasifica varios usos de IA en banca —como decisiones de crédito y ciertos sistemas de detección de fraude— como aplicaciones de alto riesgo, con exigencias reforzadas en materia de gobernanza, documentabilidad y explicabilidad. Aunque Chile aún discute sus propios marcos regulatorios, la influencia de estos estándares ya se siente en las conversaciones con supervisores y casas matrices.
Es decir, los bancos están obligados a avanzar en IA, pero también a demostrar que lo hacen con control.
Cuando entra la conversación sobre IA, casi siempre aparece la misma lista de temas: scoring más preciso, detección temprana de fraude, personalización de ofertas, automatización de back-office, asistentes virtuales. Es una lista válida, pero incompleta.
Después de quince años liderando proyectos tecnológicos y transformaciones en entornos regulados, mi conclusión es que los casos de uso son solo la superficie. Lo que determina si la IA se vuelve un pilar del banco —o se queda como un conjunto de iniciativas sueltas— es la estructura:
No voy a profundizar en “las aplicaciones más típicas de IA en banca”, sino en algo que muchas veces se deja para más adelante: cómo organizar el área de IA para escalar sin perder el control, especialmente en el contexto de bancos chilenos y latinoamericanos.
En la banca, la IA no es un proyecto aislado en TI. Es una capacidad transversal que cruza estrategia, negocio, tecnología, riesgo y cultura.
En los bancos que avanzan con más solidez suele existir, de manera explícita o implícita, una figura de liderazgo estratégico en IA. En algunos casos es un Chief AI Officer (CAIO); en otros, un Chief Data Officer (CDO) con un mandato que ya no se limita a datos, sino que incluye IA como palanca central de negocio.
El rol de esta figura no es “patrocinar pilotos simpáticos”, sino algo bastante más incómodo y relevante: definir la visión de IA para el banco, establecer criterios de inversión, vincular cada iniciativa con métricas de negocio (margen, riesgo, productividad, experiencia de cliente) y alinear a TI, datos, riesgo, operaciones y negocio detrás de un roadmap común.
A su lado, el AI Product Manager cumple una función que se nota cuando falta. Es quien traduce los objetivos de negocio en casos de uso concretos, prioriza el backlog de modelos, dialoga con áreas comerciales y técnicas, y mantiene el foco en el valor generado: ingresos, reducción de costos, mitigación de riesgo o mejora en NPS, según el caso. Sin esta dupla, la IA corre el riesgo de vivir en presentaciones de PowerPoint, pero no en los procesos que mueven el banco día a día.
Si el liderazgo define el “por qué” y el “para qué”, el corazón técnico se encarga del “cómo”. Allí conviven tres perfiles que se necesitan mutuamente.
El Data Scientist diseña y entrena modelos, explora variables, evalúa métricas y hace propuestas de mejora. El Data Engineer asegura que los datos lleguen a tiempo, con calidad y bajo las políticas de seguridad y privacidad adecuadas, construyendo y manteniendo los pipelines que alimentan los modelos. Y el rol de Machine Learning Engineer o MLOps se encarga de que esos modelos no se queden en un notebook, sino que lleguen a producción, se integren con sistemas core, se monitoreen y se mantengan a lo largo del tiempo.
Diversos estudios coinciden en que una parte muy importante de la pérdida de valor en proyectos de IA ocurre cuando los modelos no se logran llevar a producción de manera estable, o bien se despliegan y nadie se hace cargo de monitorearlos y ajustarlos.
En un banco, la IA no puede existir de espaldas al área de riesgos. El enfoque de Model Risk Management (MRM), que nació pensando en modelos de riesgo de crédito y mercado, hoy se extiende a cualquier modelo de IA que influya en decisiones relevantes: qué crédito se aprueba, qué operación se califica como sospechosa, qué segmentos reciben determinada oferta.
Los equipos de Model Risk y Compliance participan en la validación independiente de modelos, revisan su robustez, ayudan a definir los umbrales de desempeño aceptables y se preocupan por el componente de sesgo y fairness. En algunos grupos financieros globales ya vemos aparecer comités de ética de datos o figuras específicas encargadas de velar por el uso responsable de IA.
La pregunta que hay detrás es simple y poderosa: si un regulador, un comité de auditoría o un cliente nos preguntan por qué un modelo tomó una decisión, ¿Tenemos una respuesta clara, documentada y defendible?
Finalmente, la IA solo genera impacto cuando se integra en procesos y decisiones reales. Aquí el papel de negocio y operaciones es decisivo. Product Owners y equipos de dominio no pueden ser espectadores a quienes se les “entrega” una solución; tienen que estar sentados en la mesa desde el diseño del caso de uso, aportando conocimiento del cliente, restricciones regulatorias y fricciones reales en los procesos.
Un rol que valoro especialmente es el del “traductor” entre negocio y datos: personas capaces de entender el lenguaje de los modelos, pero también de explicar su lógica en términos de riesgo, cliente y rentabilidad. En muchos proyectos son ellos quienes logran que el comité de riesgos confíe en un nuevo enfoque, o que un equipo comercial vea la IA como una herramienta para tomar mejores decisiones, y no como un competidor.
La pregunta que viene después de definir roles es inevitable: ¿Dónde se sientan? ¿Centralizados? ¿Distribuidos en negocio? ¿En un híbrido? No hay una receta única, pero sí aprendizajes de lo que ha funcionado y lo que no.
El modelo de Centro de Excelencia concentra la mayor parte de las capacidades de IA en un equipo central. Allí viven las personas, las herramientas clave y los estándares. La ventaja es evidente: se reduce la dispersión, se evitan reinvenciones permanentes y se consolida un lenguaje común para hablar de modelos, datos y riesgos.
El riesgo, cuando este modelo se implementa mal, es crear una “torre de marfil” donde el CoE se percibe como un ente lejano que define reglas sin entender la presión del día a día en los negocios. En ese escenario, los equipos comerciales y de operaciones empiezan a buscar soluciones por su cuenta y el banco termina con dos mundos paralelos: la IA formal del CoE y la IA “a la chilena” en los bordes.
En el extremo opuesto están los modelos donde cada unidad de negocio cuenta con equipos propios de datos e IA. La ventaja es la proximidad: quienes construyen los modelos conviven con quienes viven el negocio y reciben feedback constante.
Pero esta proximidad tiene un costo: sin una gobernanza central sólida, es fácil que se dupliquen esfuerzos, que aparezcan múltiples herramientas inconexas, que se repliquen modelos similares en distintas áreas y que el banco pierda la visión global del riesgo asociado a la IA.
Entre ambos extremos, el modelo que vemos consolidarse con más fuerza es el híbrido Hub & Spoke. En este esquema, existe un Hub central que actúa como columna vertebral: define estándares, gestiona la plataforma de IA y MLOps, coordina el MRM y lidera la relación con reguladores y auditoría.
A su alrededor, los Spokes en las unidades de negocio concentran el conocimiento de dominio y ejecutan los casos de uso, en equipos mixtos donde conviven perfiles de datos, negocio y riesgo.
Análisis de bancos líderes en adopción de IA muestran variantes de este modelo, justamente porque equilibra coherencia con velocidad.
La elección no debería ser doctrinaria, sino honesta. Bancos con baja madurez en datos, arquitecturas legadas complejas y culturas muy centralizadas suelen beneficiarse al partir con un Hub fuerte y Spokes más pequeños. A medida que se consolidan capacidades, confianza y mecanismos de gobernanza, se puede abrir más espacio a modelos integrados por negocio.
La clave es no copiar organigramas de otros bancos, sino diseñar una estructura que haga sentido a la historia, cultura y contexto regulatorio de cada institución.
Si hay un tema donde la banca no puede improvisar es en la gobernanza de modelos. La IA multiplica el impacto de las decisiones; por lo mismo, multiplica las consecuencias cuando las cosas se hacen sin control.
Un buen marco de Model Risk Management no se limita a validar modelos justo antes de producción. Define todo el ciclo de vida: desde la idea inicial hasta el retiro. Eso incluye entender qué problema de negocio se busca resolver, con qué datos se alimentará el modelo, cómo se mide su desempeño, quién lo revisa de forma independiente, quién lo aprueba para producción y bajo qué condiciones se retira o reemplaza.
El FSB ha insistido en que la generalización de la IA en servicios financieros exige precisamente este tipo de marcos, donde la trazabilidad de los modelos sea tan clara como la trazabilidad de los estados financieros.
La conversación sobre sesgos y fairness no es teoría en la banca. Cuando un modelo aprende a partir de datos históricos, también puede aprender las inequidades que esos datos contienen. Si no se gestiona, la IA puede terminar reforzando brechas en acceso a crédito o tratamiento de distintos segmentos de clientes.
La pregunta práctica es: ¿Podemos explicar de forma clara, a un cliente y a un regulador, por qué este modelo tomó esta decisión? Si la respuesta es no, es cuestión de tiempo para que ese modelo se convierta en un problema.
Aunque la regulación chilena de IA todavía se está discutiendo, los bancos locales ya se mueven bajo la influencia de marcos internacionales como el AI Act europeo, las orientaciones del BIS y las recomendaciones del FSB.
Anticiparse a esos estándares —en lugar de esperar a que lleguen en forma de obligación urgente— permite que la conversación con supervisores sea de colaboración, no solo de cumplimiento. Y, sobre todo, abre espacio para innovar sin que la IA se perciba como una amenaza a la estabilidad.
La gobernanza no son solo documentos y comités. También es plataforma. Una base tecnológica común para IA y MLOps permite saber qué modelos existen, quién responde por ellos, qué versiones están en producción, con qué datos se alimentan y cómo están funcionando.
En un banco con decenas de modelos, la diferencia entre tener o no este tipo de plataforma es la diferencia entre conducir de noche con luces altas o con las luces apagadas.
Cada banco tiene su historia, su cultura y su punto de partida. Pero hay una secuencia que suele ser un buen marco para ordenar este camino.
El primer paso es mirarse con honestidad: entender qué capacidades existen hoy en datos e IA, cómo está la arquitectura, qué modelos ya operan (aunque no se llamen “IA”), quién los mantiene y bajo qué reglas. Ese diagnóstico debería incluir tanto la dimensión técnica como la cultural y la relación con el regulador.
No todos los bancos pueden partir con un área grande, pero sí con un equipo núcleo con roles claros de liderazgo, técnica y conexión con negocio y riesgo. Lo importante es que ese equipo tenga mandato, apoyo de la alta dirección y una misión concreta que pueda mostrar resultados en un plazo razonable.
Antes de multiplicar modelos, conviene acordar algunas reglas del juego: qué tipo de modelos requieren validación independiente, qué información mínima se registra en el inventario de modelos, qué criterios se usan para decidir el retiro o actualización de un modelo. Es mejor partir con reglas simples pero claras que esperar a diseñar el marco perfecto y no avanzar.
Los primeros casos de uso construirán la narrativa interna: o bien “la IA es humo”, o bien “la IA nos ayudó a resolver un problema real”. Por eso es clave elegir iniciativas con impacto visible, viables con los datos actuales y con un riesgo regulatorio manejable. Muchas veces tiene sentido comenzar con modelos que apoyan la toma de decisiones humana, en lugar de automatizar totalmente procesos sensibles desde el día uno.
Finalmente, pocos bancos pueden hacer este recorrido solos. A nivel global, DataArt agrupa a más de 5.000 profesionales en más de 20 países y trabaja con más de 400 clientes, muchos de ellos en servicios financieros e industrias reguladas.
En 2025, la compañía anunció además un compromiso de US$100 millones para fortalecer sus capacidades de datos e IA a nivel global (press release DataArt).
Desde Chile, ACL powered by DataArt combina esa experiencia global con el conocimiento del contexto local para acompañar a bancos en la definición de su estrategia de IA, el diseño de arquitecturas de datos y MLOps, la implementación de marcos de gobernanza y la ejecución de casos de uso alineados al negocio.
Los datos son claros: la IA está reconfigurando la industria financiera. El Global Banking Annual Review 2025 recuerda, que los bancos que no logren adaptarse a tiempo pueden ver erosionados sus márgenes en un mercado cada vez más competitivo.
Desde mi experiencia liderando proyectos tecnológicos y comerciales, creo que la diferencia no estará en quién tenga más pilotos, sino en quién sea capaz de convertir la IA en una capacidad estructurada, confiable y alineada al negocio. Eso implica tomar decisiones sobre roles, estructuras, plataformas, datos, riesgo y cultura. Implica también asumir que este tránsito no es solo tecnológico, sino organizacional.
Si en tu banco ya están apareciendo estas preguntas —cómo ordenar los modelos, cómo hablar con el regulador, cómo conectar IA con negocio— es una buena señal: quiere decir que la conversación ya dejó de ser solo tecnológica.
Desde ACL powered by DataArt estamos acompañando a bancos y actores financieros en Chile y la región a transformar esa conversación en arquitecturas, marcos de gobernanza y casos de uso concretos.
Si quieres explorar cómo se vería una hoja de ruta de IA estructurada para tu organización, conversemos. A veces, el primer paso no es un gran proyecto, sino una buena conversación con los actores correctos en la mesa.
Gerente Comercial, ACL Tecnología