La mayoría de los líderes de finanzas de las grandes organizaciones han hecho las inversiones correctas. Un ERP moderno, plataformas de datos en la nube, herramientas de planificación y mucho más. Y ahora, cada vez más, la IA: para soporte de previsiones, detección de anomalías, aceleración del cierre y generación de informes a medida.
El stack tecnológico parece correcto. Pero cuando la junta comienza a preguntar sobre los resultados, es más difícil señalar los rendimientos que las inversiones.
Para qué fue diseñado tu ERP y para qué no
Tu ERP es excelente para aquello para lo que fue diseñado: registrar transacciones, garantizar el cumplimiento de las normas contables y administrar el catálogo de cuentas. Es el sistema de registro, y cumple bien esa tarea.
Pero no codifica cómo tu organización ha decidido gestionar las eliminaciones entre empresas en una estructura de entidades compleja. No incorpora la metodología de asignación de costos de tu equipo de planificación y análisis financieros, perfeccionada a lo largo de tres ciclos presupuestarios. No sabe qué umbral de variación activa una revisión del controlador en lugar de un escalamiento al vicepresidente, ni cómo tu equipo de impuestos ha mapeado las jurisdicciones para el Pilar Dos. Esa lógica, específica, documentada, definida por la organización, no está en tu ERP. Tampoco está en tu almacén de datos.
Para la mayoría de las organizaciones financieras, toda esa información está en hojas de cálculo. A veces, en la mente de quienes las diseñaron.
Dónde la IA se mete en problemas en el mundo de las finanzas
Hay un hallazgo que se cita mucho en las conversaciones sobre IA financiera: una investigación del MIT reveló que el 95 % de las organizaciones no ven un retorno medible de sus inversiones en IA generativa. Bain & Company analizó el mismo panorama y llegó a una conclusión diferente para finanzas. La forma más rápida de recuperar la inversión en IA en el sector financiero es integrarla en los flujos de trabajo, no mediante pilotos. La distinción es importante porque explica por qué tantos esfuerzos de IA en finanzas se estancan después de la prueba de concepto.
La IA puede procesar datos rápidamente y detectar patrones en grandes conjuntos de datos. Lo que no puede hacer es inferir tu lógica de negocio a partir de las entradas sin procesar. Sin ese contexto, las salidas de IA en finanzas parecen confiables, pero no son defendibles, y en una función donde la auditabilidad es un requisito de línea base, esa brecha no es una limitación menor. Esto confirma que una IA confiable es clave para ampliar los flujos de trabajo y los proyectos piloto de IA.
Nuestra propia encuesta, realizada a 1400 líderes de TI y de negocios preguntó cuáles eran sus mayores obstáculos para el éxito con los flujos de trabajo de IA. Uno de cada dos (49 %) afirmó que los resultados eran inexactos o estaban sesgados. El 38 % afirmó que se debía a la reticencia a permitir que la IA tome decisiones sin supervisión humana. Si bien no se necesitan datos perfectos para empezar a usar modelos LLM, sí se necesitan datos confiables.
La capa que en realidad falta
La brecha entre tu ERP y tus ambiciones de IA no es una brecha de datos. Es una brecha de lógica de negocios, la capa donde residen las reglas específicas, las metodologías y los criterios de decisión de tu organización, y donde la IA necesita operar para producir resultados en los que puedas confiar.
Cuando esa capa se construye correctamente, lógica documentada, flujos de trabajo repetibles, resultados rastreables, la IA dispone de entradas validadas y estructuradas en lugar de datos sin procesar que tiene que interpretar. Los resultados pueden explicarse a los auditores y a la junta directiva. Y la cuestión de la secuencia se resuelve por sí sola: la clave para adoptar la IA reside en hacer bien el proceso.
Lo que se necesita para construir esa capa
Para cerrar esa brecha se necesita algo más que un mandato de “usar la IA de manera responsable”. Se necesitan tres cosas específicas, desarrolladas y administradas dentro de finanzas en lugar de delegadas a TI.
- Un activo de datos diseñado específicamente para cada proceso. No otro almacén, sino un conjunto de datos acotado y bien definido, limitado a un proceso, que refleje cómo tu equipo lo mide, no solo lo que tu ERP almacena por defecto.
- Lógica codificada, no conocimiento tribal. La metodología de asignación o el umbral de variación que activa un escalamiento, integrados en un flujo de trabajo repetible en lugar de en la hoja de cálculo de un analista sénior. El cambio consiste en construirlo una sola vez, en un formato que la IA pueda usar.
- Una forma de actualizarlo cuando el negocio cambia. Los planes de compensación se revisan, las jurisdicciones fiscales cambian y el plan de cuentas se reestructura tras una adquisición. La lógica que solo puede modificarse enviando un ticket a TI estará desactualizada antes de implementarse: las personas que son responsables del proceso deben ser quienes puedan ajustar la regla.
Nada de esto requiere esperar a una arquitectura perfecta. El punto de partida más valioso es cualquier proceso en el que tus analistas tengan que responder la misma pregunta, de la misma manera, en cada ciclo. Codifica ese flujo de trabajo primero, conéctalo con las herramientas de IA que tu equipo ya está usando, y la lógica se compone a partir de ahí: el mismo cálculo gobernado que responde a la pregunta de un controlador puede alimentar el modelo de escenarios que ejecuta tu próximo ciclo de planificación.