Cómo construí un analista de tesorería en Claude (y lo que me enseñó sobre diseño de productos de IA)

Hace seis meses, me propuse construir algo concreto: un sistema de IA capaz de hacer lo que yo había estado haciendo manualmente durante siete años como responsable de operaciones de tesorería. No un chatbot. No un resumidor. Un analista de tesorería capaz de ingerir datos financieros reales, razonar sobre ellos como lo haría un operador experimentado, y producir outputs que un CFO pudiera realmente utilizar.

Elegí Claude para la construcción. Lo que siguió fue un curso acelerado sobre la diferencia entre prompt engineering (conseguir que un LLM produzca buen texto) y diseño de productos de IA (construir un sistema que produzca de forma fiable decisiones correctas en condiciones reales). No son lo mismo, y confundirlos es el error más común que veo en el espacio de productos de IA.

Este es un recorrido por lo que construí, las decisiones de arquitectura detrás de cada componente, qué funcionó, qué falló y los principios de diseño que extraje del proceso.

El problema: la previsión de tesorería está rota

Todos los equipos de tesorería con los que he trabajado prevén el flujo de caja de la misma forma. Toman comportamientos históricos de cobro (qué porcentaje de facturas se paga a 30, 60, 90 días), calculan la media y la aplican al portfolio actual de cuentas por cobrar. Es un ejercicio de hoja de cálculo, normalmente mantenido por una persona que entiende las fórmulas, y se rompe en el momento en que esa persona se va de vacaciones.

El problema fundamental no es la complejidad. Es que el enfoque estándar ignora al menos tres cosas que importan enormemente: estacionalidad (los clientes pagan distinto en diciembre que en marzo), sesgo de recencia (el comportamiento de cobro del último mes es más predictivo que el de hace 12 meses), y pagos parciales (un porcentaje creciente de cobros que los modelos tradicionales ignoran o clasifican mal).

Yo ya lo había resuelto manualmente. Construí un modelo de comportamiento de cobro usando medias móviles ponderadas con factor de decaimiento (λ=0,9, lo que significa que los datos de cada mes pesan un 10% menos que el siguiente), índices estacionales calculados por bucket de cobro, y tratamiento explícito de patrones de pagos parciales. Mejoró la precisión de las previsiones aproximadamente un 30% respecto a las medias simples. Pero era una hoja de cálculo, y me llevaba un día entero cada mes actualizarla en 10 países.

La pregunta era: ¿podía Claude hacer esto de forma fiable?

Arquitectura: skills, no prompts

Lo primero que aprendí es que un prompt único, por bien diseñado que esté, es la abstracción equivocada para una tarea analítica compleja. Lo que necesitas es un skill: un conjunto estructurado de instrucciones, contexto y definiciones de herramientas que el modelo puede usar para ejecutar un workflow multi-step.

Mi skill de analista de tesorería tiene cuatro componentes:

System Architecture

La capa de contexto es donde vive el conocimiento operativo. No es un system prompt genérico. Codifica reglas de dominio específicas: cómo las facilidades de titulización afectan al timing del cash-in, por qué los patrones de cobro en UK y España difieren estructuralmente, qué significa un "pago parcial" en la práctica versus la teoría. Dediqué más tiempo a escribir este contexto que a cualquier otra parte del sistema. Es el equivalente a contratar a un analista y darle un mes de onboarding.

Decisión de diseño 1: outputs estructurados sobre texto libre

Mi primera iteración dejaba a Claude generar análisis en texto libre. "Basándonos en los datos, los cobros en España parecen estar disminuyendo..." El output era elocuente e inútil. Un CFO no quiere prosa. Quiere un número, un intervalo de confianza y una explicación de una línea sobre qué ha cambiado.

Rediseñé la capa de output para forzar respuestas estructuradas. Cada análisis produce un objeto JSON con campos específicos: valor de previsión, nivel de confianza (0-100), varianza respecto a la previsión anterior, tres principales drivers de cambio, y una acción recomendada. La explicación en texto libre pasó a ser contexto opcional, no el output principal.

Decisión de diseño 2: verificación de cálculos

Los LLMs no son fiables en aritmética. Esto es bien sabido, pero las implicaciones para el diseño de productos financieros están infravaloradas. Mi analista de tesorería realiza cálculos: medias ponderadas, ajustes estacionales, análisis de varianza. Si alguno de estos es incorrecto, el output es peor que inútil porque parece riguroso.

La solución fue separar razonamiento de cálculo. Claude determina qué hay que calcular y por qué, y luego llama a herramientas externas para realizar las operaciones matemáticas reales. La fórmula de media móvil ponderada, el cómputo de índices estacionales, la agregación de previsiones: todo se ejecuta como código determinista, no como inferencia del LLM.

El rol de Claude pasa a ser orquestación e interpretación: decidir qué cálculo ejecutar, sobre qué subconjunto de datos, y qué significa el resultado en contexto de negocio. Esto es en lo que los LLMs son realmente buenos. Los números en sí nunca tocan el razonamiento del modelo.

Decisión de diseño 3: razonamiento específico por país

Uno de los mayores fallos en mis primeras iteraciones fue tratar a todos los países de forma idéntica. El modelo analizaba las cuentas por cobrar de España usando supuestos que solo eran válidos para UK. Esto producía outputs técnicamente correctos pero operativamente sin sentido.

Lo resolví con ficheros de configuración por país: documentos estructurados que codifican las características específicas de cada mercado. La configuración de España incluye: plazos de pago típicos (60-90 días), reglas de facilidades de titulización y su impacto en el timing de cash-in, patrones estacionales (agosto muerto, enero lento, recuperación en septiembre). La configuración de UK es completamente diferente: plazos de pago más cortos (30 días), mecánicas de invoice finance, y un parón en diciembre que no afecta a España de la misma forma.

Cuando el skill procesa datos de un país específico, carga la configuración correspondiente y ajusta su razonamiento en consecuencia. Esta fue una decisión de diseño de producto, no de prompt engineering. El modelo no necesita "aprender" diferencias entre países a partir de ejemplos. Necesita acceso a conocimiento de dominio estructurado que restrinja su razonamiento de forma apropiada.

Qué falló

Fallo 1: detección de anomalías excesivamente confiada

Construí un módulo de detección de anomalías que debía señalar patrones de cobro inusuales. Lo señalaba todo. ¿Un cliente pagando 3 días antes de lo habitual? Anomalía. ¿Una caída estacional que ocurre cada agosto? Anomalía. El modelo no tenía concepto de volatilidad de referencia.

La solución fue añadir una capa de contexto estadístico: para cada métrica, el sistema calcula el coeficiente de variación histórico. Las anomalías solo se señalan cuando superan 2 desviaciones estándar respecto a la línea base ajustada estacionalmente y por país. Esto redujo los falsos positivos aproximadamente un 80%.

Fallo 2: el problema del "analista servicial"

Claude está entrenado para ser útil. En un contexto de tesorería, esto significa que encontrará una narrativa para explicar cualquier patrón de datos, incluso cuando la respuesta correcta es "los datos son incompletos" o "no hay una tendencia estadísticamente significativa aquí". Mi sistema inicial explicaba con confianza una varianza del 2% que estaba perfectamente dentro del ruido normal.

Lo abordé añadiendo umbrales de materialidad explícitos a la definición del skill. Las varianzas por debajo de €100K o del 5% se registran pero no se analizan. El sistema tiene instrucciones de distinguir entre "esto es una señal real" y "esto es ruido" antes de generar cualquier explicación. Suena simple. Conseguir que funcionara de forma fiable llevó decenas de iteraciones.

Fallo 3: razonamiento temporal

El skill necesitaba razonar sobre el tiempo: "cobros de facturas emitidas en marzo que actualmente están a más de 90 días". Los LLMs son sorprendentemente malos en razonamiento temporal cuando las relaciones son implícitas. Tuve que reestructurar los inputs de datos para que las relaciones temporales fueran explícitas: cada dato etiquetado con fecha de emisión, fecha de vencimiento, bucket de antigüedad actual y fecha de cobro. Un pre-procesamiento que sería trivial para un analista humano resultó ser crítico para un rendimiento fiable de la IA.

Lo que aprendí sobre diseño de productos de IA

Construir este sistema me enseñó cinco cosas que no he visto en ningún currículo de AI PM:

1. La regla 80/20 está invertida. El 80% de tu tiempo de desarrollo debería ir al 20% de los casos que son excepciones. Los casos estándar son fáciles. Los edge cases son donde tu producto gana confianza o la pierde permanentemente.
2. El contexto de dominio es más importante que la selección de modelo. La diferencia entre Claude Sonnet y Claude Opus importó mucho menos que la diferencia entre un prompt genérico y un skill bien estructurado con contexto de dominio adecuado. La mayoría de discusiones sobre productos de IA se centran en la variable equivocada.
3. Los raíles deterministas importan. Cualquier paso que requiera precisión (aritmética, cálculos de fechas, conversión de divisas) debe ejecutarse de forma determinista, no inferirse por el modelo. El LLM orquesta; el código calcula.
4. La calibración de confianza es un feature de producto. La capacidad del sistema de decir "tengo un 60% de confianza y esta es la razón" es más valiosa que acertar el 90% de las veces sin expresar incertidumbre. Los profesionales de finanzas confían en sistemas que conocen sus propios límites.
5. La velocidad de iteración lo es todo. Pasé por más de 40 versiones de la definición del skill. Cada iteración estaba informada por datos reales produciendo resultados incorrectos. No puedes diseñar un producto de IA en un documento de especificación. Lo diseñas lanzando, fallando y corrigiendo.

Hacia dónde va esto

El skill de analista de tesorería es un proof of concept de algo mayor: agentes financieros autónomos que pueden operar a través de funciones de tesorería completas. Aplicación de pagos, optimización de cobros, previsión de liquidez, monitorización de riesgo de contrapartida: cada uno de estos es un skill que se puede diseñar con el mismo framework. Conectados a través de una capa de orquestación, forman la pila autónoma de tesorería.

No estoy construyendo un producto para vender. Estoy construyendo la intuición técnica para diseñar estos sistemas a escala. Cada skill que construyo, cada fallo que depuro, cada principio de diseño que extraigo: es preparación para el momento en que una empresa con más de €1.000M en cuentas por cobrar decida que quiere que su función de tesorería se gestione sola.

Ese momento llega más rápido de lo que la mayoría piensa.