Soy contador. Cuando firmo un reporte, cada cifra tiene que resistir una pregunta: ¿de dónde salió este número? Si la respuesta es "lo estimó un modelo de lenguaje", no tengo un reporte — tengo un problema.
Por eso, cuando decidí incorporar IA a la plataforma de análisis financiero que construí, la primera decisión no fue qué modelo usar ni qué proveedor contratar. Fue escribir una regla no negociable:
La IA nunca calcula el número. Python precalcula; la IA cita, no deriva.
El problema de fondo: la aritmética probabilística
Un modelo de lenguaje no "suma" como suma una hoja de cálculo. Predice, token por token, qué texto es más probable que siga. Cuando le pides un total, la mayoría de las veces acierta — y ese "la mayoría de las veces" es exactamente el problema. En marketing, un 97% de precisión es excelente. En un estado financiero, un total correcto el 97% de las veces es una alucinación esperando auditoría: no sabes cuál de tus cien reportes tiene el error, así que tienes que revisar los cien. Acabas de perder todo lo que la automatización te había ganado.
La conclusión no es "la IA no sirve para finanzas". Es más precisa y más útil: la IA no sirve para calcular en finanzas — y resulta que calcular es la parte que ya teníamos resuelta hace décadas, con software determinista que suma igual las cien veces.
Python por defecto, IA por excepción
De ahí la doctrina que gobierna toda mi capa de IA: Python es el default; la IA es la excepción, y solo se justifica donde el problema no se reduce a una regla confiable. Meter IA donde un if gana solo agrega costo y riesgo de alucinación.
Esto no es timidez tecnológica. Es entender qué es irreductible a reglas — y ahí sí, usar IA sin complejos:
- Criterio de saliencia: decidir qué es lo importante de un periodo y cómo enmarcarlo en una carta a gerencia. Ninguna plantilla lo resuelve.
- La cola larga del lenguaje: clasificar la glosa ambigua que las reglas por keywords no alcanzan.
- Orquestación: traducir una pregunta libre ("¿por qué cayó el margen en marzo?") en la secuencia correcta de consultas.
Fíjate en el patrón: en los tres casos la IA aporta juicio sobre lenguaje y contexto — nunca aritmética.
Las dos formas de enchufar la IA (y una sola regla)
En mi arquitectura, toda función de IA cae en una de dos formas:
1. Narrativa con grounding. Python calcula todo primero — cifras, variaciones, inconsistencias — y arma un expediente de evidencia. La IA lo lee y lo redacta: una carta de gerencia, un resumen de riesgos. Es lectura y redacción, cero aritmética. Cada afirmación tiene su fuente en el expediente.
2. Agente acotado. El usuario pregunta en lenguaje natural; la IA decide qué capacidad determinista invocar y con qué parámetros; Python calcula; la IA presenta el resultado citando su origen. El agente tiene tope de iteraciones, solo capacidades de consulta (read-only), y un contrato explícito en su prompt: "no puedes sumar ni estimar; para cualquier cifra, invoca una capacidad y cita el documento que devuelva".
El contrato técnico que hace esto posible es deliberadamente aburrido:
class ICapacidad:
nombre: str # única en el registro
descripcion: str # para el modelo: CUÁNDO usarla
esquema: dict # JSON Schema de parámetros
def ejecutar(self, **params) -> Resultado:
# datos: lo que el modelo ve (ya agregado)
# traza: cuentas, documentos, periodo de origen —
# todo lo que el modelo afirme es rastreable aquí
...Ese campo traza es el corazón del asunto: el registro de cada invocación — capacidad, parámetros, origen de cada dato — es la explicabilidad. No la agrego después para cumplir; el sistema la produce por construcción. Es la misma tesis que desarrollo en el artículo sobre el Explainability Gap: a la confianza no se llega con más agentes, se llega con trazabilidad desde el diseño.
Las guardas (porque la doctrina sin guardas es un deseo)
- El humano firma. Toda salida de IA es borrador. El profesional edita y decide. Siempre.
- Solo lectura. Ninguna capacidad expuesta a la IA muta datos. La escritura se gana con confianza demostrada, no se regala en el diseño.
- Incertidumbre declarada. Si la evidencia no alcanza, el modelo lo dice. Un "no lo sé" honesto vale más que un párrafo seguro y falso.
- Recortes visibles. Cuando una capacidad acota la evidencia que entrega (top-N documentos), declara cuántos omitió y por cuánto. El recorte nunca es silencioso.
El trinquete: cómo mejora sin ceder el control
Queda un problema práctico: la cola larga. Los clasificadores por reglas resuelven el grueso, pero siempre hay glosas nuevas que caen a "OTROS". La tentación es dejar que la IA las clasifique en runtime — y con eso el reporte pierde determinismo, auditabilidad, y plata en tokens en cada corrida.
Mi solución es un ciclo que llamo mejora con trinquete, con una regla mnemónica: números → artefacto; prosa → contexto.
- Python mide su propia ignorancia: expone el residual que sus reglas no alcanzan.
- La IA propone una regla nueva: keyword → concepto, con confianza y evidencia.
- El humano firma la regla (queda sellado quién y cuándo).
- La regla se vuelve configuración determinista — un JSON versionable.
- El motor la corre en cada cierre. Sin IA, sin tokens, igual las cien veces.
Cada aprobación deja la plataforma permanentemente más inteligente sin ceder el control: el trinquete nunca retrocede, y nunca avanza sin firma. La IA escribe la regla; Python la corre; el humano decide. Cada quien en lo que es mejor.
La pregunta que deberías hacerle a tu proveedor
Si estás evaluando "IA para finanzas" — propia o comprada — hay una pregunta que corta el humo en diez segundos: ¿quién calcula los números que aparecen en la respuesta? Si la respuesta es "el modelo", pide la tasa de error y multiplícala por tu volumen de reportes. Si la respuesta es "un motor determinista, y el modelo los cita con su traza", estás ante alguien que entendió el problema.
Una firma financiera no lidera demostrando que usa IA. Lidera demostrando que su IA es precisa, auditable, y sabe cuándo no opinar.