Análisis · Mayo 2026

Pilot purgatory: por qué tu piloto de Claude no llega a producción

El 95% de los pilotos empresariales de GenAI no genera impacto medible en P&L. No es por el modelo. Es por los seis elementos que faltan entre una demo que impresiona en el comité y un sistema que sobrevive un trimestre en producción.

La estadística que la junta directiva ya leyó

En agosto de 2025, el reporte The GenAI Divide: State of AI in Business 2025 publicado por MIT NANDA (Project NANDA, MIT Media Lab) puso un número a algo que muchos CTOs ya intuían: solo el 5% de los pilotos empresariales de GenAI genera impacto medible en P&L. El 95% restante se queda atrapado en pilots que nunca producen retorno.

La metodología es honesta: 300+ deployments empresariales revisados, 52 entrevistas estructuradas con ejecutivos, 153 respuestas de encuesta. El sesgo del estudio favorece a Fortune 500 y enterprise grande, así que la cifra LATAM podría ser distinta — probablemente peor en organizaciones más chicas con menos budget para governance, ligeramente mejor en bancos que ya tienen DevSecOps maduro. Pero la dirección de la flecha es la misma.

No es la única señal en esa dirección. RAND publicó en agosto de 2024 que más del 80% de los proyectos de IA falla — el doble del rate de proyectos IT que no usan IA. Gartner predice que más del 40% de los proyectos de IA agentic serán cancelados antes de 2027 por costos escalando sin control, valor de negocio sin claridad, o controles de riesgo insuficientes. McKinsey, en su State of AI 2025, reporta que solo cerca del 6% de las organizaciones se califica como “AI high performers” (más del 5% de EBIT atribuible a IA), y apenas un 39% reporta cualquier impacto medible en EBIT.

Esto no es FUD de consultora. Es la condición de mercado real. Si tu organización está en pilot con Claude y no ha cerrado el gap entre demo y producción, estás en mejor compañía de lo que crees — y en peor situación de lo que tu deck dice.

Y en LATAM, en particular

Las cifras anteriores están sesgadas hacia Fortune 500 y enterprise de Norteamérica y Europa Occidental. McKinsey publicó en 2025 un reporte regional — AI in Latin America: From potential to productivity — que pinta una versión más aguda del mismo patrón:

Solo el 10% de las organizaciones LATAM vincula su implementación de IA a una estrategia de negocio amplia (vs. la cifra global más alta).
Solo el 23% reporta cualquier valor económico de IA, y apenas el 6% reporta impacto significativo en P&L — paralelo casi exacto al 5% de MIT NANDA.
El 60% de las PyMEs LATAM dice no generar ningún valor medible de IA.
67% de líderes de negocio en LATAM espera que la IA genere valor para su organización, vs. el promedio global del 84%. La brecha de expectativas refleja la realidad operativa de la región.

El contexto de inversión que da CEPAL en su Índice Latinoamericano de Inteligencia Artificial (ILIA) 2025 — preparado con CENIA Chile — explica parte del fenómeno: aunque la región representa el 6.6% del PIB global, atrae apenas el 1.12% de la inversión global en IA. La adopción del consumidor sin embargo es alta: LATAM concentra el 14% de las visitas globales a soluciones de IA y es el tercer mercado mundialen descargas de aplicaciones de IA generativa. Chile, Brasil y Uruguay encabezan el índice ILIA con más de 60 puntos; ocho países más — incluyendo Colombia, Ecuador, Costa Rica y República Dominicana — están en la categoría “adopter”.

La asimetría entre adopción de consumo y madurez empresarial tiene una implicación operativa: en LATAM el cliente final ya espera respuestas de IA, pero las empresas que las pueden entregar con governance enterprise son pocas. Quien cierra el gap pilot → producción primero captura desproporcionadamente. Quien se queda en demo mode el año que viene compite contra empresas que ya escalaron.

Una última nota honesta: ni McKinsey ni CEPAL miden específicamente el rate de pilots GenAI que fallan en producciónen LATAM. Lo que sí miden — adopción, valor económico, expectativas — converge en la misma dirección que MIT NANDA y RAND. No tenemos una cifra LATAM-específica análoga al “95%” del MIT, pero la dirección del problema es la misma o mayor.

Qué significa “fallar” — y por qué no es lo que crees

El estudio MIT NANDA tiene una nota metodológica que vale subrayar: “fail to deliver measurable P&L impact” no significa falla técnica. La mayoría de los pilotos atrapados en purgatory funcionan — clasifican tickets, redactan resúmenes, contestan preguntas. Lo que les falta es el aparato de medición y governance que convierte una demo funcional en un sistema que el CFO puede defender, el área legal puede aprobar, y un equipo de operaciones puede mantener cuando el modelo subyacente cambie en seis meses.

En otras palabras: el problema no es que Claude no funcione. El problema es que tu pilot fue construido como una demo y la organización está pidiendo que se comporte como un sistema de producción. Son dos animales distintos. La buena noticia: el delta es enumerable. Son seis elementos concretos.

Los seis elementos que faltan entre piloto y producción

1. Governance de RAG (no “mejor retrieval”)

La demo masiva de RAG — “cargá 100 PDFs en un vector DB, hacé preguntas” — colapsa en producción no por culpa del algoritmo de retrieval sino por governance. Los gaps típicos:

Chunking ingenuo. La demo usa chunks de tamaño fijo. Producción requiere chunking estructural: respetar headings, bloques de código, tablas, cláusulas de policy. Los chunk IDs deben ser estables para no romper citas cuando re-indexes.
Embedding sin versionado. ¿Qué pasa cuando Anthropic libera un mejor embedding model? Si tu pipeline no soporta re-index incremental versionado, una mejora de modelo se convierte en un proyecto de tres meses.
Source attribution superficial. “Fuente: doc_42.pdf” no es trazabilidad. Producción enterprise (especialmente bancaria) exige citación a nivel de span: URI + página + sección, expuesta al usuario, auditable por compliance. Anthropic publicó la Citations API precisamente para esto.
Access control en el lugar equivocado. El error más caro: filtrar los resultados después de que el modelo los procesó (en el output). El access control debe enforce-arse en el retrieval, no en la salida del LLM. Los atributos de permiso viven a nivel de chunk; la query nunca recupera chunks que el usuario no debería ver.
Sin freshness signals. Regulación CNBV cambia. Políticas internas se actualizan. Sin TTL por fuente y owners de SLA por corpus de alta decay, tu sistema cita información obsoleta sin saber que lo hace.
Sin manejo de PII. Detección y redacción pre-index. Aislamiento per-tenant. Pruebas adversariales para confirmar que un usuario del banco A no puede recuperar chunks del banco B.

2. Observabilidad granular (no solo costo total)

Un dashboard que muestra “tokens por día” te dice que algo creció. No te dice qué workflow lo causó, qué endpoint regresa respuestas lentas, ni qué porcentaje de las respuestas están groundedeadas en los documentos correctos. Las métricas mínimas que un sistema productivo necesita instrumentar desde el día uno:

Costo por request, separando input / output / cache-read (los tokens cacheados cuestan ~10% del estándar — necesitas saber cuántos son cacheados para entender tu factura real).
Latencia P50 y P99, distinguiendo TTFT (time to first token) de latencia total de streaming.
Tasa de groundedness / faithfulness. Para RAG, el estándar es descomponer cada respuesta en claims atómicos y verificar cada uno contra el contexto recuperado, usando LLM-as-judge. Frameworks probados: RAGAS faithfulness, TruLens RAG Triad, Vectara HHEM.
User feedback signals: thumbs up/down, edit-distance entre la respuesta aceptada y el draft del agente, escalation rate a humanos.
Composite confidence: nunca confíes en un solo score. Combina self-assessment del modelo, similitud semántica, validadores de regla y precisión histórica del workflow.

Herramientas que cubren esto bien: Langfuse (open source, MIT, self-hosteable), LangSmith (integración nativa con LangChain), Datadog LLM Observability (si ya tienes Datadog enterprise), Arize AI para evals y drift monitoring.

3. Manejo de errores y fallbacks

Tres patrones que necesitan trabajar juntos. Esto no es opcional en producción, es la diferencia entre un sistema que degrada con gracia y uno que entrega errores 500 al cliente final.

Retries con exponential backoff y jitter para fallos transitorios (rate limits, timeouts de red).
Cadenas de fallback de modelo: por ejemplo, Claude Opus 4.7 → Sonnet 4.6 → Haiku 4.5 → respuesta canned cacheada. El usuario nunca debería ver un 500 cuando hay un modelo más barato disponible.
Circuit breakers con tres estados (Closed / Open / Half-Open). La modificación LLM-específica importante: el breaker debe trip-ear no solo por errores HTTP, sino también por degradación de calidad medida — si el groundedness rate cae bajo un umbral, el sistema corta el flujo y escala.

La AWS Well-Architected Generative AI Lens (publicada en noviembre de 2025) trata esto bajo el pilar de Reliability con 6 fases del lifecycle. Es buen material de baseline para auditar tu propia arquitectura.

4. Human-in-the-loop calibrado

No todos los flujos requieren HITL, y los que lo requieren no necesitan el mismo nivel. La taxonomía mínima:

Acciones irreversibles (reembolsos, cambios de cuenta, decisiones de crédito, advice médico/legal) → HITL obligatorio, umbral de confianza típico 0.85.
Acciones reversibles de bajo riesgo (recomendaciones, sugerencias) → confianza típica 0.70, sample del 5-10% para drift detection.
Flujos compliance-sensitive en banca LATAM (KYC, AML) → HITL obligatorio independientemente de confianza, por requisito regulatorio.

El error más caro y más común: treshold-ear en raw confidence solo. Estudios han observado confianza promedio de 0.87 en acciones que resultaron equivocadas. El modelo está muy seguro y muy equivocado al mismo tiempo. La calibración correcta combina confianza × impacto × historia de precisión del workflow.

Los signos de alerta operativos: si tus reviewers humanos están aprobando más del 95% de los items en la cola, tu umbral está muy bajo y van a rubber-stamp errores. Si están aprobando menos del 60%, está muy alto y el HITL se vuelve cuello de botella inútil.

5. Costo a escala (de 100 a 100,000 consultas/día)

El modelo de costos del pilot se rompe en tres puntos al escalar: gasto bruto de tokens, refresh de embeddings, overhead de evaluación / observabilidad. Anthropic publica tres palancas concretas que mueven la aguja:

Prompt caching nativo. Cachea el system prompt y herramientas en prompts grandes. Reducción de hasta 90% en costo de input y 85% en latencia para prompts largos. Detalle de implementación en anthropic.com/news/prompt-caching.
Batch API. 50% de descuento sobre input y output para cargas asíncronas. Retención de 29 días (no es ZDR-elegible). Ideal para scoring nocturno, generación masiva de embeddings, procesamiento documental batch.
Model routing: Haiku 4.5 para clasificación y extracción simple, Sonnet 4.6 para la mayoría del razonamiento, Opus 4.7 para lo más complejo. La guía oficial de Anthropic: “evaluate cost at the task level rather than just comparing per-token pricing”.

Casos productivos documentados que vale citar como prueba de que esto se puede: Bridgewater Associates reporta reducciones de 50-70% en time-to-insight para reportes complejos de equity/FX/fixed-income usando Claude Opus en Bedrock. IG Group reporta payback en menos de 3 meses con 70 horas semanales liberadas por analista. N26 automatizó hasta el 70% de tareas dirigidas. (Casos vía Anthropic Customer Stories — los números exactos son los publicados por Anthropic, conviene confirmar con la fuente al momento de pitchear.)

6. Compliance, residencia de datos y permanencia del modelo

Esta es la sección que el área Legal y el CISO van a leer con lupa. Anthropic tiene primitivos enterprise sólidos — y publicados — que materialmente reducen el riesgo de adoptar Claude. Los tres que más importan en LATAM:

Zero Data Retention (ZDR). Los datos enviados a la API no se almacenan después de devolver la respuesta, ni se usan para entrenamiento. Aplica a Messages API, Token Counting API y Claude Code (con API keys de organización comercial o Claude Enterprise con ZDR habilitado). Las excepciones son retención por violación de policy o requerimiento legal, hasta 2 años. Documentación oficial.

Compromiso de preservación de pesos. En noviembre de 2025, Anthropic publicó un compromiso público de preservar los pesos de todos los modelos públicamente liberados durante la vida de Anthropic como compañía. Esto baja sustancialmente el riesgo de pinear una versión y quedarte sin acceso a ella si decides no migrar. Plus: 60 días mínimo de aviso antes de retirar un modelo productivamente.

Residencia de datos. La API directa de Anthropic ofrece inference_geo de us o global — no hay región EU ni LATAM dedicada. Para empresas con requerimientos estrictos de residencia (LGPD en Brasil, casos específicos bajo LFPDPPP en México), el camino estándar es deployment vía AWS Bedrock en São Paulo (la disponibilidad de Claude por región varía; verificar al cierre del contrato) o Vertex AI. El resto del marco regulatorio LATAM — DPA, SCCs, SOC 2 Type II, ISO 27001:2022, ISO/IEC 42001:2023 — está disponible off-the-shelf en el Anthropic Trust Center. Muchas empresas LATAM no saben que estos documentos existen ya en formato firmable y arrancan una negociación custom de 4-6 meses.

Vendor lock-in: el miedo que tu compliance team va a mencionar

Es el primer reflejo de cualquier CIO en LATAM: “¿qué pasa si Anthropic cambia el modelo bajo nuestros pies o sube precios?”. Tres datos para enmarcar la conversación:

Anthropic se comprometió por escrito en noviembre de 2025 a preservar los pesos de modelos públicos por la vida de la compañía. Eso no existe en otros proveedores.
Mínimo 60 días de notice antes de retirar un modelo. El compromiso es público y trackeable.
Claude está disponible en al menos cuatro superficies: API directa de Anthropic, AWS Bedrock, Google Vertex AI, Microsoft Foundry. Mismos pesos, distintos data processors. La portabilidad real existe.

Y aun así: arquitecturalmente, lo correcto es construir con una capa de abstracción (gateway / proxy LLM-aware) que te permita rotear entre proveedores sin reescribir prompts. Portkey, LiteLLM y construcciones custom funcionan bien. El miedo a lock-in no debería bloquear adopción, pero la abstracción es buena higiene.

El camino concreto: 6-8 semanas para cerrar los seis gaps

Los seis elementos anteriores se pueden enumerar pero no se implementan en una semana. La pregunta operativa es: ¿en cuánto tiempo realista se cierra el delta entre tu pilot y un sistema productivo? Para un pilot que ya tiene la lógica de negocio funcionando, la respuesta práctica es 6 a 8 semanas con un equipo enfocado. La estructura que usamos en Vorantis:

Semana 1 — Diagnóstico técnico. Sesión de 4 horas con tu arquitecto y sponsor. Mapeo del pilot actual contra los seis elementos. Salida: arquitectura objetivo y criterios de aceptación firmados.
Semanas 2-5 — Construcción e iteración. Implementación de RAG governance (chunking estructural, citations, access control en retrieval), observabilidad (Langfuse o tu stack), error handling (retries / fallbacks / circuit breakers), HITL calibrado. Demo cada viernes con tu equipo, no handoff al final.
Semanas 6-7 — Endurecimiento para producción. Prompt caching y Batch API si aplica. Guardrails. Audit logs. Penetration testing del prompt layer. Runbook operativo.
Semana 8 — Entrega y capacitación. Documentación técnica, capacitación al equipo interno, 2 semanas de soporte post-entrega incluido.

Anthropic mismo, en su guía Building Effective Agents, repite el mantra: “los implementadores más exitosos no usaban frameworks complejos ni librerías especializadas. Estaban construyendo con patrones simples y componibles.” Empieza simple, mide todo, agrega complejidad solo cuando entrega valor medible. Un agente simple se despliega en semanas; sistemas multi-agente toman meses bien hechos.

El 5% que sí llega a producción

El estudio MIT NANDA mide al 95% que no llega. Pero al inverso, el 5% que sí llega tiene patrones en común: sponsor ejecutivo con presupuesto asignado (BCG documentó que orgs con sponsor activo tienen 1.8x más probabilidad de escalar IA), métricas baseline antes de empezar, atribución de ROI medible a 6 meses, y los seis elementos anteriores instrumentados antes de que el tráfico escale.

Si tu piloto de Claude lleva tiempo en sandbox sin saltar a producción, lo más probable es que esté en pilot purgatory porque uno o varios de los seis gaps no están cerrados. Un sprint de 6-8 semanas enfocado en cerrarlos cuesta menos que tener al equipo entero seis meses más en demo mode. En Vorantis ofrecemos exactamente eso bajo el nombre Last-Mile Acceleration — alcance fijo, precio fijo, sin sorpresas. Si tu situación es la inversa — el pilot ya está productivo pero tu factura se está saliendo de control — la pieza que necesitas es AI FinOps & Governance.

La diferencia entre el 5% y el 95% no es el modelo. Es la disciplina de los seis gaps.

Fuentes principales: MIT NANDA — The GenAI Divide: State of AI in Business 2025, lead author Aditya Challapally (media.mit.edu/groups/nanda), cobertura abierta vía Fortune; RAND, Root Causes of Failure for AI Projects (agosto 2024); Gartner press release, junio 2025; McKinsey State of AI 2025; McKinsey — AI in Latin America: From potential to productivity (2025); CEPAL — ILIA 2025 (Latin American Artificial Intelligence Index, con CENIA Chile); AWS Well-Architected GenAI Lens; Anthropic API and Data Retention; Anthropic deprecation commitments. Todas verificadas al 17 de mayo de 2026.