IA en producción: qué separa una demo de un sistema confiable

Cualquier desarrollador puede hacer que un modelo de lenguaje extraiga el valor de un comprobante de pago en cinco minutos. Pegar el PDF en el prompt, ver el output, mostrarle al cliente. Demo lista.

El problema es que una demo no es un sistema. Un sistema es lo que funciona cuando el documento está torcido, fotografiado con el celular en la penumbra, con un sello tapando el código de barras. Un sistema es lo que confías a las tres de la mañana sin nadie monitoreando.

Lo que describo aquí viene de automatizaciones de documentos financieros en producción, extrayendo datos de facturas y comprobantes en volumen. No es teoría.

El problema específico con documentos financieros

Las facturas y comprobantes tienen una característica que hace el problema más exigente de lo que parece: el error tiene consecuencia financiera directa. Un valor extraído incorrectamente en un pago automático no es un bug de UX que alguien va a reportar al día siguiente. Es un problema de compliance que puede costar más que el proyecto entero.

El flujo involucraba clasificación y extracción. Primero el modelo necesitaba decidir si el documento enviado era realmente una factura o comprobante válido. Luego, si lo era, extraer los campos relevantes. Dos problemas diferentes, tratados por separado.

El test que la mayoría omite

La diferencia entre un sistema que funciona en demo y uno que funciona en producción empieza en las pruebas. No en las pruebas del happy path, que cualquiera hace. En las pruebas adversariales.

El conjunto de tests que usamos incluía:

• Documentos reales — facturas y comprobantes de los tipos que el sistema iba a procesar, con toda la variación natural de diagramación, fuente y calidad
• Documentos ficticios — creados para cubrir casos extremos sin exponer datos reales en el ambiente de desarrollo
• Dibujos a mano — para testear los límites del clasificador: ¿el modelo sabe decir "esto no es una factura" cuando el input es claramente inválido?
• Fotos completamente fuera de contexto — paisajes, selfies, capturas de pantalla de juegos. El clasificador necesita rechazar esto con confianza

El test con imágenes fuera de contexto es lo que separa un clasificador de juguete de uno de producción. En demo, solo mostrás los casos donde funciona. En producción, el usuario va a enviar exactamente lo que no probaste.

Además de la clasificación, cada campo extraído se validaba contra reglas de negocio: ¿el valor numérico es plausible para el contexto? ¿El CUIT tiene formato correcto? ¿La fecha no está en el pasado distante? El modelo puede extraer con aparente confianza mientras el campo puede seguir siendo validado por lógica determinística. Son capas independientes.

Observabilidad: saber que el sistema está sano sin revisar cada respuesta

En producción, no vas a revisar manualmente el output del modelo para cada ejecución. Eso no escala. La pregunta es: ¿cómo sabés que todo está bien?

Lo que teníamos:

• Sentry para fallas — los errores 5xx llegaban como alerta inmediata. Cuando el sistema se rompía, el equipo lo sabía antes de que el usuario lo reportara
• Grafana para ejecuciones — log de cada ejecución del flujo: input recibido, respuesta del modelo, campos extraídos, resultado final. Trazabilidad completa para diagnóstico
• Equipo de operaciones monitoreando calidad — la parte que las herramientas no reemplazan. Alguien necesita mirar periódicamente las respuestas del modelo e identificar patrones de degradación antes de que se vuelvan un problema

La degradación de modelos es real. Un proveedor puede actualizar el modelo subyacente sin aviso. El comportamiento cambia sutilmente. Sin alguien mirando los outputs, te enterás cuando el cliente se queja.

Gestión de prompts: quién puede cambiar y con qué proceso

Un prompt es código. Cambiar un prompt cambia el comportamiento del sistema. Pero un prompt también es lenguaje natural, y a veces quien mejor entiende el dominio no es el ingeniero.

En los proyectos que construimos, usamos dos enfoques según el contexto:

Prompt en el código, en archivo .txt — versionado con git, auditable, cualquier cambio pasa por revisión de código y deploy. Más lento para ajustar, pero trazable. Bueno para prompts que se mantienen estables.

Prompt en Drive — el equipo de operaciones puede ajustar sin ingeniero. Útil cuando el dominio cambia con frecuencia y el equipo de ops tiene el conocimiento. El trade-off es trazabilidad: sin git, no sabés quién cambió qué y cuándo, y no podés revertir fácilmente.

La elección no es técnica. Es sobre quién necesita control y con qué frecuencia va a cambiar el prompt. Lo importante es que sea una elección consciente, no el camino más fácil de implementar.

Costo real de API en escala

En volumen, el costo de API deja de ser despreciable. Lo que importa no es solo el precio por token: es el costo de prompts largos con contexto redundante, el costo de retries cuando el proveedor falla, el costo de un modelo más caro usado donde uno más barato resolvería.

Usamos LiteLLM como intermediario entre la aplicación y los proveedores. Esto da flexibilidad para cambiar de proveedor sin modificar el código de la aplicación. Si GPT-4o se vuelve caro, apuntás a Claude o Gemini con una línea de configuración. Si un proveedor se vuelve inestable, tenés fallback.

Qué monitorear en producción:

• Tamaño promedio de prompts por ejecución — un prompt que crece con el tiempo (contexto acumulado sin limpieza) es costo creciente invisible
• Tasa de retry — alta tasa indica inestabilidad del proveedor o límite de rate alcanzado
• Distribución de uso por modelo — si estás usando un modelo caro donde uno barato resolvería, es optimización directa

Seguridad con datos sensibles

El dato financiero tiene implicaciones de compliance que el dato genérico no tiene. Algunas prácticas que aplicamos:

• Ambiente de desarrollo solo con datos ficticios o anonimizados. Dato real nunca sale de la infraestructura de producción para pruebas locales
• El modelo procesa el documento, no lo almacena. Lo que va a la base de datos es el campo extraído, no el documento original con todos los datos del pagador
• Los logs tienen nivel de detalle calibrado: suficiente para diagnóstico, sin exponer PII completo en texto libre en los registros

En Chiarelli Labs

Cuando construimos automatizaciones con IA, esta disciplina entra en el proyecto desde el inicio, no como retrofit después del primer bug en producción.

Antes de cualquier deploy, el conjunto de tests incluye los casos adversariales, no solo el happy path. La observabilidad es parte de la entrega, no un extra. La gestión de prompts se decide junto con el cliente basándose en quién necesita control.

Si estás evaluando proveedores para un proyecto con IA, la pregunta correcta no es "¿ya hicieron esto antes?" Es "¿qué pasa cuando el modelo se equivoca?" y "¿cómo voy a saber que sigue funcionando dentro de seis meses?"

Si querés esa conversación, contactanos.