La inteligencia artificial está cambiando una de las decisiones tecnológicas más tradicionales de la industria financiera: ¿desarrollar software internamente o comprar una plataforma?
Para bancos, aseguradoras y otras empresas de Financial Services Industry (FSI), desarrollar soluciones propias es hoy considerablemente más accesible. AI coding assistants y agentes de desarrollo permiten generar código, pruebas, documentación e integraciones en una fracción del tiempo que requerían anteriormente. Y esta capacidad seguirá aumentando.
Esto hace que una pregunta clásica aparezca con mayor frecuencia: si ahora podemos construirlo nosotros mismos mucho más rápido, ¿por qué comprarlo?
Es una pregunta válida, pero puede estar comparando las cosas equivocadas. Porque el costo de construir software y el costo de poseer una capacidad de software no son lo mismo.
El desarrollo puede terminar. La responsabilidad sobre el producto que se acaba de crear apenas comienza.
AI está cambiando Build vs. Buy
La reducción del costo de desarrollo no es una hipótesis futura. AI ya está entrando progresivamente en todo el ciclo de desarrollo: análisis de requerimientos, diseño, generación de código, testing, documentación, deployment, mantenimiento y modernización de sistemas.
Esto modifica profundamente la ecuación tradicional de Build vs. Buy. Una institución financiera con un equipo tecnológico sólido puede crear hoy aplicaciones, integraciones y automatizaciones que hace pocos años habrían requerido proyectos mucho más grandes.
Por eso, argumentar que una institución debería comprar software simplemente porque “desarrollarlo es demasiado costoso” resulta cada vez menos convincente. La pregunta estratégica está cambiando: cuando construir se vuelve mucho más fácil, ¿qué vale realmente la pena construir y poseer?
El go-live no es el final
Imagine que una institución financiera necesita automatizar una operación. Con AI, su equipo puede desarrollar rápidamente un workflow que recibe información desde un sistema core, aplica determinadas reglas, genera un documento, lo envía al cliente y actualiza otro sistema cuando el proceso termina.
El desarrollo funciona, se realizan las pruebas y la solución entra en producción. Desde la perspectiva del proyecto, se llegó al objetivo. Desde la perspectiva de la operación, sin embargo, es apenas el comienzo.
Ahora alguien tiene que garantizar que esa solución continúe funcionando mañana, dentro de seis meses y dentro de cinco años. Tiene que mantenerse disponible frente a cambios de volumen, modificaciones de proveedores, nuevas integraciones, incidentes, vulnerabilidades, cambios en el negocio y nuevas necesidades de los usuarios.
Ese problema tiene un nombre diferente: operatividad sostenida.
Construir una operación no es lo mismo que desarrollar la capacidad para operarla
Cuando una automatización comienza a procesar cientos, miles o millones de operaciones, aparecen preguntas que no necesariamente estaban presentes durante el desarrollo inicial. ¿Cuántas operaciones están ejecutándose? ¿Cuántas terminaron correctamente? ¿Cuáles están demoradas o fallaron? ¿Dónde ocurrió la falla? ¿Fue un problema del workflow, de los datos, de una API o de un proveedor? ¿Se están cumpliendo los SLA? ¿Qué operaciones requieren intervención humana?
Aquí existe una diferencia importante entre monitorear software y monitorear operaciones.
Un equipo tecnológico puede observar infraestructura, logs, excepciones, latencia o disponibilidad de APIs. Un responsable de Operaciones necesita saber, por ejemplo, que de 12.438 operaciones iniciadas, 12.107 terminaron, 186 continúan en proceso, 94 requieren intervención y 51 fallaron.
Y necesita poder pasar de esa visión agregada a una operación específica para reconstruir su recorrido completo: la solicitud fue recibida, se ejecutó una validación, se generó un documento, se solicitó una firma, se envió un WhatsApp, el cliente no respondió, se ejecutó un fallback por email y finalmente se completó la operación.
Eso es monitoreo operacional end-to-end. Y no aparece automáticamente porque el workflow del software haya sido desarrollado correctamente.
El verdadero desafío aparece cuando algo falla
Construir el happy path es solamente una parte del problema. Una operación real tiene excepciones: una API que no responde, un proveedor temporalmente fuera de servicio, un dato faltante, un documento que no puede generarse, una firma que expira, una comunicación rechazada o dos sistemas que quedan temporalmente en estados diferentes.
Entonces hay que decidir qué ocurre. ¿Se reintenta automáticamente? ¿Cuántas veces? ¿Se utiliza otro proveedor o canal? ¿Se pausa la operación? ¿Se genera una alerta? ¿Se asigna el caso a una persona? ¿Puede esa persona corregir el problema y continuar el workflow desde donde quedó?
La automatización madura no se define solamente por lo que hace cuando todo funciona. También se define por cómo detecta, administra y recupera aquello que no funcionó.
AI puede multiplicar precisamente este problema
Existe una paradoja. Cuanto más fácil sea crear software, más software podrá crear una organización. AI puede permitir que equipos mucho más pequeños produzcan aplicaciones, APIs, agentes, workflows y automatizaciones a una velocidad difícil de imaginar hace pocos años.
Esto representa una enorme oportunidad para FSI, pero también puede producir proliferación tecnológica: más aplicaciones, automatizaciones, agentes, integraciones y componentes accediendo a sistemas y datos; y, por tanto, más operaciones que necesitan ser monitoreadas y gobernadas.
El desafío puede desplazarse rápidamente de “¿cómo construimos esto?” a “¿cómo gobernamos todo lo que ahora somos capaces de construir?”
En Financial Services, la segunda pregunta puede terminar siendo mucho más importante que la primera.
Cuando AI deja de asistir y empieza a ejecutar
La evolución hacia Agentic AI vuelve esta discusión todavía más relevante. Los primeros casos de AI empresarial estuvieron principalmente orientados a asistir a las personas: encontrar información, resumir documentos, generar contenido, analizar datos o recomendar una acción.
Los agentes de IA introducen otra posibilidad: actuar.
En una operación financiera, un agente podría analizar una situación, consultar diferentes sistemas, aplicar una decisión, generar un documento, solicitar una firma, enviar una comunicación, esperar una respuesta, utilizar otro canal si no existe respuesta, actualizar un sistema y escalar una excepción a una persona.
El desafío ya no consiste solamente en gobernar qué puede decidir AI. También hay que gobernar qué puede ejecutar, bajo qué condiciones y con qué límites. Y posteriormente poder reconstruir qué hizo, sobre qué operación, utilizando qué información y cuál fue el resultado.
La capacidad de ejecutar más automáticamente aumenta, no disminuye, la necesidad de monitoreo, control y trazabilidad.
En FSI, saber qué ocurrió no siempre es suficiente
También existe una diferencia entre trazabilidad y evidencia. La trazabilidad permite reconstruir una operación; la evidencia permite demostrarla.
Una institución puede necesitar determinar qué información recibió un cliente, qué versión de un documento se utilizó, qué comunicación fue enviada, por qué canal y cuándo. También puede necesitar conocer qué regla estaba vigente, qué decisión tomó el proceso, quién modificó esa regla, si existió una intervención manual y qué ocurrió posteriormente.
En operaciones financieras, una solución puede funcionar perfectamente desde el punto de vista funcional y seguir siendo insuficiente desde el punto de vista operacional o de auditoría. Por eso la auditabilidad no debería agregarse al final del proyecto como una característica adicional: debe formar parte de la arquitectura de la operación.
Low Code adquiere un significado diferente en la era de AI
AI también obliga a reconsiderar el valor de Low Code. Durante años, una de sus principales promesas fue desarrollar más rápido. Pero si AI puede generar software en minutos u horas, competir solamente por velocidad de desarrollo deja de ser suficiente.
El valor más interesante de Low Code pasa a ser hacer que las operaciones continúen siendo comprensibles y gestionables por personas.
Imagine dos soluciones que AI permite construir con la misma rapidez. En una, la lógica queda distribuida entre código, servicios, scripts, prompts, APIs, configuraciones y bases de datos. En otra, la operación permanece representada visualmente como un workflow: evento, validación, condición, documento, firma, espera, comunicación, fallback, intervención y cierre.
El día del go-live ambas pueden hacer exactamente lo mismo. La diferencia aparece seis meses después, cuando Operaciones necesita cambiar una regla, llega una nueva persona al equipo, Auditoría necesita comprender el proceso o el negocio necesita identificar dónde está ocurriendo una excepción.
La pregunta pasa a ser: ¿para modificar una operación tenemos que volver a desarrollar software o podemos modificar la operación?
Una plataforma Low Code bien diseñada permite que la lógica operacional sea visible y que determinados cambios puedan ser realizados por usuarios autorizados, manteniendo a IT a cargo de arquitectura, seguridad, integraciones, permisos y gobierno tecnológico. No se trata de eliminar a IT, sino de evitar que cada cambio operacional tenga que convertirse en un nuevo requerimiento de desarrollo.
El software evoluciona. Sus usuarios también tienen que hacerlo
Hay otro costo que pocas comparaciones Build vs. Buy incluyen: formar continuamente a quienes utilizan la solución.
Una plataforma útil no permanece estática. Incorpora funcionalidades, canales, integraciones, capacidades de AI, controles y nuevas posibilidades de automatización. Cada mejora incrementa lo que el producto puede hacer, pero también lo que sus usuarios necesitan conocer.
Alguien tiene que enseñar cómo utilizar esas nuevas funcionalidades, formar nuevos usuarios, documentar procesos, compartir mejores prácticas y ayudar a que las capacidades disponibles se traduzcan en mejores operaciones.
Por eso la evolución del software genera también una necesidad permanente de evolución de sus usuarios. Esta es una de las razones por las que DANAconnect complementa su plataforma con DANAconnect Academy: la formación no consiste solamente en aprender cómo utilizar una funcionalidad, sino también en desarrollar progresivamente las capacidades necesarias para aprovechar el producto y aplicar mejores prácticas.
En una solución interna esa función también tiene que existir. Puede tener otro nombre y otra estructura, pero alguien de la organización tendrá que asumirla.
Una plataforma también acumula conocimiento especializado
Formar al usuario es una parte del problema. La otra es desarrollar y mantener expertise sobre aquello que la plataforma permite hacer.
Las comunicaciones son un buen ejemplo. Una institución puede desarrollar perfectamente la capacidad técnica para enviar email, SMS, WhatsApp u otros canales. Eso no responde automáticamente cuál es la mejor manera de estructurar una comunicación transaccional, cómo debería adaptarse entre canales, cuándo utilizar un fallback, cómo diseñar un journey de cobranza o qué prácticas pueden afectar la entregabilidad.
Lo mismo ocurre con automatización, documentos, integraciones y otros componentes operacionales. Una cosa es proporcionar una funcionalidad; otra es acumular conocimiento sobre cómo utilizarla correctamente.
Una plataforma especializada no acumula solamente código. También acumula experiencia proveniente de implementaciones, nuevos requerimientos, cambios en proveedores, casos de uso y problemas resueltos. Ese conocimiento puede regresar al producto en forma de mejores prácticas, soporte, formación y nuevas funcionalidades.
Mantener no es lo mismo que evolucionar
Existe además un costo que suele confundirse con mantenimiento: R&D.
Mantenimiento significa conseguir que lo que ya existe continúe funcionando. R&D significa conseguir que lo que existe no deje de ser relevante.
Una solución desarrollada hoy tendrá que convivir con nuevas tecnologías, modelos, interfaces y formas de automatización durante los próximos años. También cambiarán proveedores, APIs, canales, requerimientos de seguridad, expectativas de los usuarios y capacidades de los agentes.
Una institución que decide construir una plataforma interna tiene que decidir también quién seguirá investigando esas transformaciones, cuáles deben incorporarse al roadmap y quién desarrollará las nuevas funcionalidades necesarias.
Porque una plataforma operacional no termina realmente con su primera versión. Se convierte en un producto que necesita evolucionar continuamente.
Build puede significar convertirse en su propio software vendor
Aquí aparece quizá el costo menos visible de todos.
Cuando una organización decide desarrollar internamente una capacidad operacional compleja, no necesita solamente developers. Con el tiempo puede necesitar Product Management para definir roadmap y prioridades; R&D para investigar nuevas capacidades; Engineering y QA para desarrollarlas y validarlas; Operations y Monitoring para garantizar operatividad sostenida; Security y Governance para proteger y controlar la plataforma; Support para asistir a los usuarios; Academy o enablement para formar y actualizar esos usuarios; y expertise especializado para aplicar correctamente la tecnología.
También necesita mantener las capacidades de trazabilidad y evidencia que permitan reconstruir y demostrar qué ocurrió en una operación.
Visto de esta manera, la pregunta cambia:
¿Estamos desarrollando una solución interna o estamos construyendo nuestro propio proveedor de software?
Si la capacidad es suficientemente estratégica, hacerlo puede estar completamente justificado. Pero el business case debería reconocer explícitamente esa decisión.
El costo que AI está reduciendo es precisamente el más visible
Aquí está la paradoja de Build vs. Buy en la era de AI: AI está haciendo que Build parezca extraordinariamente atractivo porque está reduciendo precisamente la parte más visible de su costo: construir.
Después del desarrollo siguen existiendo responsabilidades permanentes: operar la solución, monitorear las operaciones, resolver excepciones, cambiar procesos y reglas, gobernar usuarios y agentes, mantener trazabilidad y evidencia, formar a los usuarios y continuar invirtiendo en evolución y R&D.
AI también ayudará a reducir el esfuerzo necesario en muchas de estas actividades. Pero no elimina la necesidad de que alguien sea responsable de ellas.
Por eso el Total Cost of Ownership de una capacidad propia no debería calcularse únicamente como desarrollo + infraestructura + mantenimiento. También debería considerar la organización que será necesaria para operarla y evolucionarla de manera sostenida.
Entonces, ¿Build o Buy?
La respuesta no debería ser ideológica.
Hay capacidades que una institución financiera probablemente debería desarrollar: modelos propietarios de riesgo, lógicas diferenciales de pricing, capacidades antifraude, decisioning, experiencias que constituyen una ventaja competitiva o propiedad intelectual específica del negocio. AI permite invertir todavía más agresivamente en esas áreas.
Pero existen otras capacidades que muchas organizaciones necesitan de manera recurrente: orquestación de procesos, integraciones, documentos, firma, comunicaciones cross-channel, monitoreo operacional, gestión de excepciones, trazabilidad, evidencia, auditoría, gestión de usuarios, formación y evolución continua de la plataforma.
En estos casos, la comparación no debería limitarse a cuánto cuesta una licencia frente a cuánto cuesta desarrollar la funcionalidad.
La pregunta más completa es:
¿Queremos convertir esta capacidad en una competencia interna permanente?
Build the differentiation. Buy the operational capability.
Esta es una manera diferente de entender el rol de plataformas como DANAconnect en la era de AI.
DANAconnect no existe porque las instituciones financieras sean incapaces de desarrollar software. Cada vez serán más capaces de hacerlo. El objetivo es proporcionar una plataforma Low Code sobre la cual puedan convertir sistemas, datos, decisiones y AI en operaciones ejecutables, monitoreables, gobernables y auditables, sin tener que construir y sostener internamente toda la infraestructura que existe alrededor de esas operaciones.
Los sistemas propios, modelos y agentes pueden determinar qué debe ocurrir. DANAconnect ayuda a administrar cómo ocurre de manera sostenida: desde la orquestación de workflows hasta documentos y firma; desde comunicaciones cross-channel hasta integraciones; desde monitoreo operacional hasta trazabilidad y evidencia.
Alrededor de la tecnología existen además capacidades que requieren inversión permanente: soporte, formación continua, mejores prácticas, conocimiento especializado, Product Management y R&D continuo.
Eso también forma parte del producto.
El nuevo business case
La inteligencia artificial no hace irrelevante la decisión Build vs. Buy. Hace necesario formularla mejor.
Ya no basta con preguntar “¿podemos construirlo?”. Probablemente la respuesta sea sí. Tampoco basta con preguntar cuánto tardaremos, porque ese tiempo seguirá disminuyendo.
La pregunta más útil es:
¿Queremos ser responsables de operar, monitorear, resolver, cambiar, gobernar, auditar, enseñar y evolucionar esta capacidad de manera sostenida?
AI está democratizando la construcción de software y eso representa una extraordinaria oportunidad para Financial Services. Pero precisamente por eso, la ventaja competitiva no estará necesariamente en quién consiga construir más software, sino en quién sepa qué vale la pena construir, qué conviene consumir como plataforma y cómo convertir ambas cosas en operaciones sostenibles.
El código puede generarse cada vez más rápido. La responsabilidad sobre lo que ese código pone en producción permanece.
