IA para finanzas
En un reporte financiero una cifra sin origen no es un dato: es un riesgo. Construimos sistemas donde cada número que aparece se puede rastrear hasta la fila que lo produjo, y donde el modelo no hace aritmética por su cuenta.
En resumen
La regla de este dominio es una sola: el modelo no calcula. Los números los produce el sistema —consulta, hoja o motor de cálculo— y el modelo los explica y los redacta.
Un modelo de lenguaje suma mal de forma silenciosa y presenta el resultado con la misma confianza que uno correcto. Toda aritmética va fuera del modelo, y esa es una decisión de arquitectura.
Cada cifra del reporte lleva su origen: de qué consulta, sobre qué periodo, con qué filtro. Sin eso, nadie del área puede defender el número en un comité.
Donde más rinde no es el pronóstico sino la consolidación: juntar lo que hoy vive en cinco sistemas y tres hojas, que es de donde salen las horas del cierre de mes.
Los cinco atascos de un área financiera
Ninguno es de análisis: los cinco son de recolectar, cuadrar y presentar, que es donde se va el mes.
- La desviación se descubre cuando ya ocurrió, y para entonces la decisión que la habría evitado ya no está disponible.
- Copiar, pegar, cuadrar y formatear. Es la parte más mecánica del mes y la que más gente ocupa.
- ERP, banco, facturación, nómina y hojas de cálculo, y ninguna cuadra exactamente con la otra.
- El modelo del pronóstico vive en una hoja que entiende una persona, y esa persona se va de vacaciones.
- Cuando la cifra está lista y validada, la ventana para actuar sobre ella ya pasó.
El modelo no calcula: consulta, explica y redacta
Es la decisión que separa un sistema financiero utilizable de uno peligroso. Un modelo de lenguaje puede equivocarse en una suma y presentar el resultado con exactamente la misma seguridad que uno correcto, sin ninguna señal de que algo falló. Así que la aritmética sale del modelo: los números los produce una consulta a la base, el ERP o un motor de cálculo, y lo que hace el modelo es interpretar qué significan, redactar el análisis y responder preguntas sobre ellos.
La segunda regla es la trazabilidad. Cada cifra que aparece en un reporte lleva de dónde salió —qué consulta, sobre qué periodo, con qué filtro—, visible para quien lea. Eso es lo que permite que alguien del área defienda el número en un comité, y lo que convierte el sistema en algo auditable en vez de una caja que produce PDF.
Y una advertencia sobre el pronóstico: predecir flujo de caja es un problema estadístico, no de lenguaje. Cuando el caso lo pide, el pronóstico lo hace un modelo estadístico con su intervalo de confianza declarado, y el modelo de lenguaje solo explica el resultado. Un pronóstico presentado como una cifra única y segura, sin rango, es una señal de que nadie modeló nada.
Lo que se verifica antes de que un reporte salga solo
| Qué se mide | Qué significa | Cómo se corrige |
|---|---|---|
| Trazabilidad de la cifra | Que cada número del reporte tenga su consulta, periodo y filtro de origen, verificables. | Salida estructurada con el origen obligatorio en cada fila; lo que no lo trae, no se publica. |
| Cero aritmética del modelo | Sobre una muestra: que ningún número del reporte haya sido calculado por el modelo en vez de consultado. | Se mueve el cálculo a la consulta o al motor y el modelo se queda solo con la redacción. |
| Consistencia entre fuentes | Cuando dos sistemas dicen cosas distintas del mismo periodo, que el reporte lo declare en vez de escoger. | Regla de conciliación explícita y una alerta cuando la diferencia supera el umbral acordado. |
| Negativa correcta | Cuando el dato no está disponible o el periodo está incompleto, que lo diga. | Un reporte financiero con un hueco declarado es útil; uno que rellena el hueco es un problema. |
No construimos sistemas que tomen decisiones de inversión, aprueben créditos o autoricen pagos por su cuenta. La responsabilidad de una decisión financiera tiene un nombre en el organigrama, y automatizarla no la traslada: la difumina.
Y si la información financiera vive dispersa en hojas sin una fuente única, el proyecto correcto es esa consolidación, no el asistente. Un sistema de análisis sobre datos que no cuadran produce análisis que no cuadran, con mejor redacción.
Servicios relacionados
Integraciones y APIs
Servidores MCP contra los sistemas en operación.
Ver servicioAutomatización con IA
Aplicada donde hay volumen y reglas estables, no donde hay expectativa.
Ver servicioSistemas RAG
Segmentación, reordenamiento y búsqueda híbrida, evaluados con recall@k y NDCG.
Ver servicioConsultoría de IA
Arquitectura, criterios de evaluación y costo por consulta antes de escribir código.
Ver servicioMás del blog
Las 15 mejores empresas de desarrollo de software en Colombia
Colombia exporta ingeniería a Estados Unidos desde hace veinte años y el mercado local ya está segmentado.
Seguir leyendo¿Cuánto cuesta un chatbot con IA en Colombia?
Hace un año, dos proveedores colombianos publicaban precio.
Seguir leyendoRAG vs fine-tuning: cuál necesitás
La pregunta llega casi siempre mal planteada, como si fueran dos caminos hacia el mismo lugar.
Seguir leyendoPreguntas frecuentes
¿Cómo evitan que el sistema se equivoque en un número?
Sacando la aritmética del modelo, que es la única forma que funciona. Los números los produce una consulta a la base, el ERP o un motor de cálculo; el modelo interpreta, redacta y responde preguntas sobre ellos, pero no suma. Además cada cifra lleva su origen visible —consulta, periodo, filtro— y sobre una muestra se verifica que ningún número del reporte haya sido calculado por el modelo. Un modelo de lenguaje que suma mal lo presenta con la misma seguridad que si sumara bien, y esa es la razón de la regla.
¿Se conecta con nuestro ERP?
Sí, por API o servidor MCP contra SAP, Dynamics, Siigo, World Office o lo que usen, y también contra la base de datos directamente cuando tiene más sentido. La parte que suele tomar más trabajo no es la conexión sino acordar cuál es la fuente de verdad cuando dos sistemas dicen cosas distintas del mismo periodo. Esa decisión es del área financiera, no nuestra, y hay que tomarla antes de construir.
¿Puede hacer pronósticos de flujo de caja?
Puede, con una condición: el pronóstico lo hace un modelo estadístico con su intervalo de confianza declarado, y el modelo de lenguaje solo explica el resultado. Predecir es un problema estadístico, no de lenguaje. Desconfíe de cualquier pronóstico presentado como una cifra única y segura sin rango: es señal de que nadie modeló nada y de que el número salió de un texto generado.
¿La información financiera sale de nuestra infraestructura?
Solo si ustedes lo aceptan, y en esta área la respuesta suele ser no. Desplegamos sobre Azure OpenAI o Amazon Bedrock dentro de la suscripción de la empresa, así que los datos no salen de su nube. En cualquier configuración usamos planes empresariales donde lo enviado por API no se usa para entrenamiento, y podemos trabajar sobre agregados en lugar de registros individuales cuando el caso lo permite.
¿Qué es lo primero que conviene hacer?
Casi siempre la consolidación y el reporte recurrente, no el análisis predictivo. El cierre de mes es donde están las horas, la respuesta es mecánica y el resultado se verifica contra lo que el área ya produce a mano, lo cual hace fácil demostrar que sirve. El análisis y el pronóstico vienen después, sobre datos que ya cuadran.
¿Cuánto tarda y cómo se cotiza?
De cuatro a ocho semanas hasta producción para un alcance de consolidación y reportería, con algo funcionando desde la primera semana. Se cotiza con alcance, precio y fecha cerrados en una propuesta a 48 horas de la primera llamada, y el precio lo determinan cuántas fuentes hay que conectar y qué tan limpias están.
Agendar 15 minutos
Una llamada para poner sobre la mesa qué se está construyendo o qué dejó de funcionar. Termina con una respuesta concreta: se arregla, se construye, o no vale la pena.