Qué acelera la IA cuando tu banco lanza un producto nuevo (y qué no)

Cuando una dirección de tecnología evalúa meter inteligencia artificial en su cadena de entrega, la pregunta rara vez es si la tecnología funciona. Son otras tres: cuánto antes sale el producto, cuánto cuesta sostenerlo y qué riesgo se compra por el camino.

La respuesta honesta no es un porcentaje global. Sacar un feature bancario no es una unidad homogénea de trabajo: es una cadena que va del requerimiento al contrato de servicio, del contrato al código, del código a las pruebas y de ahí a producción, con decisiones de arquitectura intercaladas que nadie puede saltarse. La IA absorbe una parte de esa cadena casi por completo y otra parte prácticamente nada.

Distinguir cuál es cuál es la diferencia entre un caso de negocio que se cumple y uno que se cae en el primer trimestre.

Lo que medimos

Construimos un modelo de esfuerzo asistido por IA sobre un portafolio bancario real —un conjunto acotado de funcionalidades de una plataforma digital— y lo comparamos, actividad por actividad, contra el esfuerzo de hacer el mismo trabajo a mano.

Para la etapa de arquitectura la unidad de análisis no fue el requerimiento ni la historia de usuario, sino la funcionalidad completa: todo lo que un equipo necesita para construirla sin volver a preguntar. Eso incluye contratos de servicio, definición arquitectónica y documentación para desarrollo. Para cada artefacto se estimó por separado qué parte del trabajo queda absorbida por la generación asistida y qué parte sigue exigiendo a un arquitecto corrigiendo, decidiendo lo que el generador no puede decidir y respondiendo por el resultado.

La columna de absorción usa una sola escala para las diecisiete actividades, porque mezclar bandas con porcentajes en la misma columna sugiere una precisión que no existe: Alta es que el grueso del trabajo queda absorbido, Media que se absorbe una parte apreciable pero el peso sigue siendo humano, y Baja que la asistencia ayuda en los márgenes. La columna de base dice de dónde sale cada juicio.

Modelo son las tres actividades de arquitectura que se estimaron artefacto por artefacto. Observado son actividades donde la absorción se vio en operación pero no se cuantificó con el mismo método, y por eso se publican como banda y nunca como cifra.

La etapa que nadie presupuesta: leer el sistema que ya existe

Antes de diseñar nada hay que averiguar qué hace hoy el banco. Y en una plataforma con veinte años encima, eso no está escrito en ningún documento: está dentro de procedimientos almacenados, de programas que nadie firmó y de columnas cuyo nombre ya no significa lo que parece. Esa arqueología suele ser la etapa más larga de una modernización de core, y casi nunca aparece con su peso real en una propuesta.

Es también donde más agresivamente se vende la IA hoy, así que conviene separar qué se sostiene y qué no.

Lo que la máquina hace bien aquí

Trazar dependencias. Qué programa llama a cuál, qué trabajo toca qué tabla, qué queda huérfano. Es recorrido de grafo sobre un artefacto que existe: derivable y verificable contra el propio código.

Redactar el borrador de las reglas. Leer un procedimiento almacenado de tres mil líneas y devolver una lista de reglas candidatas en lenguaje de negocio. En una implantación documentada se extrajeron 1.984 especificaciones con un 85,5% validado por los expertos del negocio. Es un punto de partida que a mano cuesta meses.

Proponer el mapeo de datos. Alinear el modelo legado con el destino usando el contexto de la cuenta y no solo el nombre del campo. Con revisión humana sobre las excepciones, el análisis de veinticuatro migraciones de core reporta reducciones del orden de 4,7 meses en la duración de la corrida en paralelo.

Lo que no puede hacer, y es lo que decide el proyecto

Ese mismo análisis sitúa el techo de exactitud de la transformación de datos financieros entre 90% y 95% sin compuertas de excepción atendidas por personas. En un core bancario, el 5% restante no es ruido estadístico: son cuentas reales. Y los sistemas con más de quince años arrojan cerca de 2,3 veces más excepciones en la corrida en paralelo que los construidos después de 2010 — que es exactamente el perfil del sistema que vas a migrar.

Pero el límite de fondo no es de exactitud, es de naturaleza del problema:

La máquina te dice qué hace el código. No te dice por qué lo hace.

Cuando encuentra una validación añadida en 2012, no puede saber si está ahí por una exigencia del regulador, por un acuerdo con un cliente grande o por un incidente que alguien parchó un viernes. Ninguna de esas tres respuestas está en el código, y las tres llevan a decisiones opuestas: la primera se conserva, la segunda se negocia, la tercera se borra.

De ahí que la fila más incómoda de la tabla sea decidir si una regla encontrada sigue siendo política vigente o es residuo. No es que la máquina se equivoque: es que no hay contra qué comparar. La respuesta no vive en el sistema, vive en gente que sigue en el banco.

El caso que mejor lo ilustra viene de una migración de telecomunicaciones: una traducción sintácticamente correcta, que compiló sin un solo error, eliminó en silencio una exención para cuentas suspendidas que llevaba quince años en producción. No hubo falla técnica. Hubo una regla que nadie reconoció como regla.

Y la decisión que ninguna herramienta toma por ti

Al final de esta etapa hay que responder qué capacidades se exponen desde el sistema legado y dónde queda la frontera: qué se envuelve y se deja quieto, qué se reimplementa, qué se jubila. Esa elección fija el alcance, el costo y el riesgo de todo lo que viene después, y depende de cosas que no están en ningún repositorio —qué puede operar tu equipo, qué va a preguntar el regulador, qué contrato con un proveedor vence en dieciocho meses—.

Por eso el patrón que funciona es el mismo en todos los casos documentados: la máquina redacta el borrador, el experto del dominio firma. Invertir ese orden —dar por buena la extracción y construir encima— es la forma más cara de descubrir, en la corrida en paralelo, que faltaba una regla.

Qué significa eso en tu calendario

La mitad del esfuerzo no es la mitad del tiempo de salida, y esa confusión es la que rompe los compromisos con el negocio. El ahorro no está repartido a lo largo de la cadena: está concentrado en los tramos donde existe una referencia contra la cual comparar. Los tramos de decisión conservan exactamente la misma duración.

Conviene fijar el término antes de seguir, porque ordena todo lo demás. Un trabajo es derivable cuando hay algo contra lo cual comparar el resultado: existe un insumo, existe una regla y de ahí sale la respuesta. No hay que elegir, hay que aplicar — y como se puede verificar, la máquina puede producirlo y tú puedes comprobar si lo hizo bien. Un contrato de servicio a partir de un vocabulario estándar es derivable; el estándar dice cómo se llama cada cosa.

Lo contrario es una decisión: no hay contra qué comparar, porque la respuesta no está en ningún insumo. Dónde poner la frontera con el core, o si una regla que encontraste en el legado sigue siendo política del banco, se eligen bajo restricciones que casi nunca están escritas.

La prueba de bolsillo: ¿puedo comprobar si está bien sin preguntarle a nadie? Si sí, es derivable. Si tengo que preguntarle a alguien del banco, es decisión.

El efecto práctico para una dirección de tecnología es doble. El tiempo de salida baja de forma real, pero menos de lo que sugiere el titular. Y la proporción del calendario que ocupan las decisiones sube: cuando lo mecánico se comprime, lo que queda expuesto es el tiempo que tu organización tarda en decidir.

La regla que sirve para leer cualquier propuesta

Leída por etapas, la tabla parece dispersa. Leída por otra variable, es una sola línea recta: la absorción no depende de la etapa del ciclo, depende de si el artefacto tiene un criterio de corrección verificable sin juicio.

Donde existe una referencia contra la cual comparar —un estándar, un arquetipo, un contrato ya escrito, una regla de transformación—, la máquina rinde. Donde el criterio de corrección es «esto es lo correcto para este banco, en este momento, con estas restricciones», no hay contra qué comparar y el trabajo sigue siendo humano completo.

Esta regla es la herramienta más útil que puede llevarse un comité a una evaluación de proveedores: si la propuesta que te presentan reduce el esfuerzo de forma uniforme a lo largo de todo el ciclo, la propuesta está mal construida, independientemente de lo convincente que sea la demostración.

Lo que no se acelera, y conviene saberlo antes de firmar

Un contrato de servicio alineado a un vocabulario de industria es, en el fondo, una traducción: hay un dominio funcional descrito por un estándar, una capacidad que el banco ya reconoce y un formato de salida conocido. Las reglas de correspondencia son explícitas y verificables. Ese es justo el tipo de trabajo donde un generador bien instruido rinde.

Una definición arquitectónica no es una traducción. Es dónde poner la frontera con el core, qué se reemplaza y qué se envuelve, cómo se comporta el sistema cuando el proveedor no responde, qué decisión queda fija al crear el recurso y ya no se puede deshacer. No hay respuesta derivable de los insumos: hay una elección, tomada bajo restricciones que casi nunca están escritas —la política interna, lo que el regulador va a preguntar, lo que el equipo del banco puede realmente operar—.

Un generador puede producir una arquitectura plausible. No puede producir una arquitectura defendible, porque defenderla exige haber elegido, y elegir implica responder.

El caso de la documentación para desarrollo sorprende a mucha gente, porque parece trabajo mecánico. No lo es: su valor está en anticipar lo que el equipo va a malinterpretar, y eso depende de conocer a ese equipo, su plataforma y sus costumbres. Un texto correcto que nadie entiende no ahorra un solo día.

Lo que encontró el resto del mercado

Lo anterior sale de un solo portafolio. Conviene contrastarlo con lo que midieron otros, con muestras mayores y sin nuestro interés de por medio. Los estudios publicados en 2025 coinciden en algo que rara vez aparece en una propuesta comercial: la ganancia y el costo no caen en la misma fase del ciclo.

El resultado de METR es el más incómodo para quien vende aceleración, y el que más se parece a lo que vimos: midieron trabajo sobre bases de código grandes, complejas y ya conocidas por quien las tocaba. Es exactamente la fila donde nuestro modelo pone absorción baja —diseño de la solución sobre el paisaje existente— y exactamente la condición de cualquier modernización bancaria, que por definición ocurre sobre un paisaje que ya existe.

El de DORA explica por qué la aceleración no siempre llega al negocio. Si se generan más cambios de los que la revisión, la prueba y el despliegue pueden absorber, el cuello de botella no desaparece: se muda aguas abajo, y reaparece como fallos en producción.

Dicho de otra forma: cuatro estudios independientes, con métodos distintos, terminan dibujando la misma frontera que encontramos actividad por actividad. Lo derivable se absorbe. Lo que exige decidir, no. Y lo que se acelera sin criterio para validarlo se paga después.

El riesgo que se compra al hacerlo mal

Antes de meter IA en cualquier proceso de ingeniería usamos una condición de entrada:

Si el equipo no tiene el criterio para detectar que lo generado está mal, la IA no está ahorrando trabajo: está trasladando riesgo hacia adelante, donde sale más caro. Un arquitecto con experiencia usa un generador y detecta en dos minutos que el diseño propuesto acopla dos dominios que no deben acoplarse. Un perfil sin ese criterio produce el mismo documento, más rápido, y nadie nota el problema hasta la integración.

De ahí se desprende algo que rara vez aparece en una presentación de transformación: la IA aumenta el valor de la gente con criterio y aumenta el costo de la gente sin él. Por eso una adopción seria empieza por nivelar competencias y no por comprar licencias, y por eso las organizaciones que reportan mejores resultados son las que acompañaron el despliegue con formación en vez de anunciarlo.

Conviene tener presente el contrapeso: Gartner proyecta que más del 40% de los proyectos de IA agéntica serán cancelados para el cierre de 2027, principalmente por costos crecientes, valor de negocio poco claro o controles de riesgo insuficientes. Nuestra lectura, después de construir varios de estos flujos, es que la mayoría de los que fracasan no fracasan por la tecnología: fracasan porque nadie definió qué artefacto debía producir el agente, con qué criterio se aceptaba y quién respondía por él. Un agente sin definición de terminado es un generador de trabajo, no un ahorro.

Lo que el regulador va a preguntar

En banca mexicana este tema deja de ser técnico muy rápido. Cuando la IA participa en la producción de artefactos que sustentan decisiones sobre los sistemas de una institución financiera, aparecen preguntas de gobierno que conviene tener respondidas antes de que alguien las haga: qué información se expuso al modelo, dónde se procesó, quién aprobó el resultado y cómo se demuestra que hubo control humano.

No existe todavía una norma local específica de IA. Marcos como la ISO/IEC 42001 para gestión de sistemas de IA y el marco de gestión de riesgos de IA del NIST no son requisitos en México, pero dan la estructura para responder esas preguntas con algo más que buena voluntad, y la disciplina que imponen —inventario de usos, evaluación de riesgo por caso, control humano documentado— es exactamente la que un supervisor entiende.

Una regla práctica que ahorra problemas: antes de usar cualquier asistente sobre material de un cliente bancario, verificar qué permite el contrato con esa institución. Varias entidades prohíben explícitamente procesar su información en modelos de terceros sin autorización escrita. Es un detalle contractual, no técnico, y es de los que detienen un proyecto entero.

Por dónde empezar

Tres decisiones que se desprenden directamente de lo medido:

• Empieza donde hay referencia verificable. Contratos sobre vocabulario estándar, código sobre arquetipo, casos derivados de un contrato, migraciones con reglas de transformación. Ahí el retorno es inmediato y el riesgo bajo, porque se puede comprobar si la salida está mal.
• No presupuestes ahorro en las decisiones, en ninguna etapa. Ni en el diseño de la solución, ni en la estrategia de prueba, ni en la causa raíz de un incidente. Esa parte se vuelve más rápida, no más barata, y sigue necesitando a alguien que responda por ella.
• Invierte primero en criterio. El multiplicador de la herramienta depende del nivel de quien la opera. Sin eso, lo que se acelera es la producción de errores.

La promesa de que la IA va a modernizar tu banco es falsa en la misma medida en que lo era la promesa de que lo haría el estándar, la nube o la metodología ágil. Lo que hace es cambiar la proporción del trabajo: menos horas escribiendo lo que ya estaba definido, las mismas horas decidiendo lo que nadie había decidido.

La buena noticia para una dirección de tecnología es que esa proporción sí se puede medir antes de comprometerse, y es lo primero que conviene hacer.

Esto es parte de lo que hacemos: Profesionalización de equipos.