IA Generativa en Producción 2025: De Piloto a ROI Real

Hace dieciocho meses, el 73% de las empresas españolas tenía al menos un piloto de IA generativa en marcha. Hoy, según el último barómetro de ONTSI, solo el 31% ha escalado alguno a producción con métricas de negocio claras. La brecha no es tecnológica: es arquitectónica, organizativa y, sobre todo, de expectativas mal calibradas.

En BAOSS hemos acompañado a una veintena de organizaciones —banca, logística, sector público, industria— en ese salto del proof-of-concept al servicio productivo que factura o ahorra. Este artículo no es una lista de tendencias de consultora: es el resumen de lo que hemos visto fallar, lo que hemos visto funcionar y las cifras que ahora mismo ponemos sobre la mesa en cada propuesta.

El problema real 2025: pilotos que no escalan, costes que se descontrolan

El patrón se repite en casi todos los sectores: un equipo de innovación monta un chatbot con GPT-4o o Claude 4 sobre un vector store genérico, consigue respuestas plausibles en entorno controlado y la dirección aprueba presupuesto para «ponerlo en producción». Tres meses después:

• El coste por consulta se ha multiplicado por 6 al crecer el volumen y el context window.
• La latencia P95 supera los 12 segundos porque el retrieval no está optimizado.
• El equipo de seguridad bloquea el despliegue por fugas de PII en logs de prompt.
• Negocio no sabe medir el impacto: «los usuarios preguntan cosas» no es un KPI.

Un cliente bancario (anonimizado) llegó a nosotros con exactamente este cuadro: 180.000 € gastados en tokens en cuatro meses, cero transacciones automatizadas y un churn interno del 40% en el equipo de datos por burnout de prompt engineering artesanal.

Arquitectura que sí escala: RAG modular, agentes con memoria y eval-driven development

La diferencia entre un piloto y un servicio productivo en 2025 no es el modelo base —GPT-4o, Claude 4 Sonnet, Llama 3.1 405B o Nemotron 3 Ultra son intercambiables si la capa de orquestación está bien hecha—, sino tres decisiones de arquitectura que tomamos en cada proyecto BAOSS:

1. RAG no es un vector store: es pipeline de datos gobernado

Implementamos RAG híbrido con tres capas de retrieval (denso + disperso + grafo de conocimiento) y reranking con Cohere Rerank 3.5 o bge-reranker-v2-m3 en local vía Ollama/vLLM. Cada capa tiene SLAs de latencia y contracts de calidad medidos con RAGAS y DeepEval en CI/CD.

Resultado medido en cliente logística (flota 12.000 vehículos): precisión de respuesta técnica subió del 67% al 94%, latencia P95 bajó de 11,2 s a 1,8 s, coste por consulta cayó un 78% al mover embedding y rerank a GPU propias (2× H100 en colocation madrileña).

2. Agentes autónomos con state y tool calling tipado, no prompt chains frágiles

Usamos LangGraph (no LangChain legacy) para definir grafos de estados deterministas con checkpointing en PostgreSQL. Cada nodo es un tool tipado con Pydantic y validado en runtime. Orquestamos flujos multi-agente con CrewAI o AutoGen 0.4 solo donde la no-determinismo aporta valor (negociación, planificación estratégica); el 80% del flujo es determinista y auditable.

Caso real: automatización de conciliación contable para grupo industrial (2,4 M asientos/año). Agente retriever busca facturas en S3 + metadata en SAP, agente matcher propone emparejamientos con confidence score, agente validator aplica reglas fiscales duras. Humanos solo revisan edge cases (< 3%). Despliegue en 6 semanas, ROI 3,2× a los 6 meses, 40% reducción en tiempo de cierre mensual.

3. Eval-driven development: si no se mide, no se despliega

Cada pull request que toca prompts, tools o retrieval dispara una suite de 200+ casos de test (golden set curado con expertos de negocio) que mide: faithfulness, answer relevance, context precision, hallucination rate, latencia, coste estimado. Umbral de merge: faithfulness ≥ 0,92, hallucination ≤ 0,03. Esto elimina el «vibe coding» y convierte la IA en ingeniería de software trazable.

Modelos abiertos en producción: cuándo y cómo

En 2025, Llama 3.1 405B, Nemotron 3 Ultra, Qwen 2.5 72B y Gemma 2 27B son alternativas viables a GPT-4o/Claude 4 para cargas de throughput alto y datos sensibles que no pueden salir del perímetro. Nuestra regla práctica:

• GPT-4o / Claude 4: razonamiento complejo, tool use nativo, multimodal nativo, volumen < 50k req/día.
• Modelos abiertos en vLLM/Ollama: embedding, rerank, clasificación, extracción estructurada, volumen alto, datos regulados, coste/token crítico.

Cliente sector público (expedientes administrativos): migramos clasificación documental de GPT-4o a Qwen 2.5 72B quantizado AWQ 4-bit en 4× A100. Coste mensual pasó de 9.200 € a 1.100 € (infraestructura propia), latencia media 340 ms, F1 0,91 vs 0,93 del modelo cerrado. Aceptable y soberano.

MCP y el fin de los connectors a medida

El Model Context Protocol (MCP) —estándar abierto impulsado por Anthropic y adoptado ya por Microsoft, GitHub, Cloudflare, y decenas de vendors— está cambiando cómo los agentes acceden a datos y herramientas. En BAOSS ya no escribimos wrappers para SAP, Salesforce, SharePoint, bases de datos legacy o APIs internas: exponemos MCP servers ligeros (Go/Rust, < 500 LOC cada uno) y los agentes descubren tools y resources en tiempo de ejecución.

Impacto real: onboarding de nueva fuente de datos en < 2 días vs 3 semanas previas. Un cliente retail integró 7 sistemas (ERP, WMS, CRM, PIM, BI, ticketing, legacy AS/400) en 10 días hombre. Antes: 6 meses de proyecto de integración.

Gobernanza, seguridad y observability: lo que la dirección exige en 2025

Ningún proyecto BAOSS sale a producción sin:

• PII/PHI redaction en stream (Presidio + regex custom) antes de llamar al LLM.
• Prompt injection defense: system prompt inmutable, user input sanitizado, tool output validado contra esquema.
• Audit log inmutable (append-only en Cloud Object Storage + hash encadenado) con trazabilidad completa: prompt → retrieval → tool calls → response → feedback usuario.
• Cost guardrails: presupuestos por tenant/user/feature con hard limits y alertas en Grafana/Loki.
• Model monitoring: drift detection sobre distribución de embeddings de consultas y respuestas; reentrenamiento/finetuning programado trimestral.

Todo esto se despliega como Infrastructure as Code (Terraform + Helm + ArgoCD) sobre Kubernetes (EKS/AKS/GKE u on-prem con Rancher). Time-to-production de la plataforma base: 3 semanas. A partir de ahí, cada caso de uso es un Argo Workflow que hereda seguridad, observabilidad y gobernanza.

Métricas de negocio, no métricas de modelo

La conversación con el CFO no va de perplexity ni BLEU. Va de:

• Coste por transacción automatizada vs coste manual actual.
• Tiempo de ciclo reducido (días → horas → minutos).
• Tasa de escalado a humano (< 5% objetivo).
• CSAT/NPS del usuario final interactuando con el agente.
• Revenue uplift o cost avoidance trazable a la automatización.

En el caso de conciliación contable mencionado: 2,4 M asientos/año × 4 min/asiento manual = 160.000 h/año. Automatización 97% → 4.800 h/año revisión. Ahorro bruto 1,2 M€/año. Coste plataforma + inferencia + mantenimiento: 380 k€/año. ROI neto 3,2× año 1. Payback mes 4.

El talento que hace falta (y cómo lo organizamos)

No buscamos prompt engineers. Buscamos ingenieros de software que entiendan:

• Diseño de pipelines de datos streaming (Kafka/Flink/Redpanda).
• Evaluación sistemática de sistemas no deterministas.
• Optimización de inferencia (batching, speculative decoding, KV cache management).
• Seguridad ofensiva/defensiva aplicada a LLM.
• Arquitectura de sistemas distribuidos con human-in-the-loop.

En BAOSS operamos en squads mixtos: 1 ML Platform Engineer, 1 Backend Engineer (Python/Go/Rust), 1 Data Engineer, 1 Domain Expert del cliente, 1 Product Owner técnico. Sin handoffs