Por qué el 80% de los proyectos de IA no llegan a producción
Hay una cifra que circula en los reportes del sector y que se ajusta bastante a lo que vemos en clientes: la mayoría de iniciativas de IA en empresas no superan el piloto. El número exacto depende del estudio (60%, 75%, 80%), pero el orden de magnitud es consistente. Lo interesante no es la cifra — es la causa.
Casi nadie falla por la tecnología. Los modelos están maduros. Las integraciones existen. El cloud aguanta. Los equipos técnicos saben construir. Lo que falla es el caso de uso elegido. Casos que sonaban bien en una reunión de dirección, que se compraron por presión de tendencia, que en cuanto se intentan llevar a producción descubren que los datos no están, que el proceso real es distinto al descrito, que el ahorro estimado no compensa el esfuerzo de implementación, o que el equipo afectado no está alineado.
Por eso el primer proyecto importa más que el modelo, más que el framework, más que el partner. Un primer caso de uso bien elegido empieza a aportar valor en semanas y construye la credibilidad para el siguiente. Uno mal elegido consume seis meses, deja al equipo escarmentado y mete la palabra "IA" en la lista negra del comité de dirección durante años.
Este artículo explica el método con el que decidimos, en cada empresa, qué caso de uso entra primero. No es magia — es scoring sobre tres ejes, discovery operativo y honestidad para descartar lo que no toca.
La matriz de scoring: impacto, esfuerzo y riesgo
Cualquier candidato a primer caso de uso de IA se evalúa contra tres ejes. Cada uno se puntúa de 1 a 5; el caso de uso ganador es el que combina mejor los tres, no el que destaca solo en uno.
Impacto. Cuánto valor real aporta al negocio si funciona. Tres preguntas:
- ¿Cuántas horas / euros / errores ahorra? No "muchos" — un número estimado. Si nadie en la empresa puede estimar el ahorro, el caso no está suficientemente entendido.
- ¿Cuántas personas o procesos toca? Un caso que afecta a 200 personas/mes tiene más impacto que uno que afecta a 5, manteniendo todo lo demás igual.
- ¿Es ahorro de coste o crecimiento de ingresos? Ambos cuentan, pero generan dinámicas de negocio distintas. Conviene saber cuál se está atacando.
Esfuerzo. Qué cuesta llevarlo a producción de verdad. Tres preguntas:
- ¿Los datos necesarios están disponibles y limpios? Si requieren extracción de un sistema legacy, normalización manual y validación durante meses, el esfuerzo se dispara. Los datos sucios son la causa más subestimada de proyectos fallidos.
- ¿Con qué sistemas hay que integrarse? Una integración con HubSpot estándar pesa poco. Una integración con un ERP propietario sin API documentada pesa mucho.
- ¿Quién más tiene que aprobar / participar? Casos que tocan legal, RRHH, finanzas y operaciones a la vez tienen más esfuerzo organizativo que técnico.
Riesgo técnico. Qué probabilidad hay de que la solución no funcione en producción aunque se construya bien. Tres preguntas:
- ¿La tecnología es madura para este caso? RAG sobre documentos en español maduro, sí; agentes que negocian precios autónomamente, no todavía. Conocer la frontera evita comprar humo.
- ¿La calidad mínima aceptable está al alcance? Algunos casos toleran un 85% de acierto; otros necesitan 99,5%. Saber el umbral mínimo decide si el caso entra o sale.
- ¿Hay dependencia de un proveedor único? Casos que solo funcionan con un proveedor concreto (modelo cerrado, plataforma cerrada) tienen riesgo estratégico mayor.
El scoring se hace en sesión con el cliente, con cada candidato sobre la mesa. La conversación que provoca puntuar es a menudo más valiosa que el resultado final — saca a la luz suposiciones que nadie había verbalizado.
Los cinco candidatos típicos que aparecen en discovery
En empresas españolas medianas y grandes, los candidatos a primer caso de uso convergen casi siempre en cinco familias. Los listamos por orden de frecuencia con la que ganan el scoring inicial:
1. Soporte / atención al cliente nivel 1. Atender preguntas frecuentes sobre estado de pedido, dudas de producto, gestión de cuentas. Impacto alto (volumen grande), esfuerzo medio (las APIs suelen existir), riesgo bajo (tecnología madura). Es el caso que más veces gana. Tres meses para llegar a un % razonable de autoresolución, métricas claras.
2. Cualificación comercial / SDR digital. Cualificar leads entrantes, enriquecer datos, agendar reuniones con un comercial humano. Impacto alto (afecta directamente al pipeline), esfuerzo medio (integración con CRM, normalmente HubSpot o Salesforce), riesgo bajo. Excelente cuando el equipo comercial está sobrecargado y los leads se enfrían.
3. Procesamiento documental. Lectura, clasificación y extracción de datos de facturas, contratos, formularios. Impacto medio-alto (depende del volumen), esfuerzo medio (depende de la variabilidad de formatos), riesgo bajo. Particularmente bueno en empresas con departamentos administrativos saturados.
4. Asistente interno de conocimiento. Responder preguntas internas sobre procesos, políticas, datos de proyectos. Impacto medio (mejora marginal pero generalizada), esfuerzo medio-alto (los datos suelen estar dispersos), riesgo bajo. Buen segundo o tercer proyecto, raramente el primero — porque el ROI es menos medible.
5. Reporting automatizado. Generación de informes recurrentes a partir de datos del CRM, ERP o hojas de cálculo. Impacto medio (ahorra horas pero rara vez transforma), esfuerzo bajo (los datos están), riesgo bajo. Buen quick win pero rara vez justifica un proyecto en sí mismo — suele incluirse como parte de otro caso de uso mayor.
Hay otros candidatos que aparecen menos pero merecen mención: agentes que operan sobre WhatsApp para reservas o cualificación (típicos en hostelería y servicios), copiloto de comercial integrado en HubSpot, automatización de onboarding de empleados nuevos. Cada uno tiene su perfil de scoring.
Anti-patterns: casos de uso que parecen buenos y no lo son
Lo más útil de una auditoría seria es descartar candidatos atractivos pero malos. Cinco anti-patterns que aparecen una y otra vez en discovery y que casi siempre desaconsejamos:
"Reemplazar a todo el equipo de soporte con IA." El equipo de soporte resuelve casos complejos, con criterio, con contexto. Reemplazarlo entero es el objetivo equivocado y, además, es políticamente tóxico. El objetivo correcto es absorber el 60-70% de casos rutinarios para que el equipo humano se centre en los complejos. La diferencia entre "automatizar tareas" y "sustituir personas" decide si el proyecto convive con el equipo o lo enfrenta.
"Crear un copiloto general para el director." Suena bien y no funciona. Un copiloto general — "asistente para todo lo que el director necesite" — no tiene rol acotado, no tiene métricas, no tiene tools claras. Acaba siendo una pantalla de chat con poca utilidad real. El director necesita herramientas concretas (resumen de pipeline, alertas de cuentas críticas, redacción de comunicaciones específicas), no un asistente vago.
"Convertir toda la web en un chatbot." Las webs cumplen funciones — navegación, exploración, lectura comparativa — que un chat lineal no replica bien. Un chatbot en la web es complemento, no sustituto. Empresas que se proponen "matar la navegación" suelen acabar con peor experiencia y peor conversión.
"Generar todas las propuestas comerciales con IA." Las propuestas tienen partes plantilla (donde la IA aporta) y partes de criterio comercial real (donde un humano decide). El éxito está en mezclar las dos, no en automatizar la totalidad. Las propuestas 100% IA suelen perder los matices que cierran deals.
"Empezar por el caso más impactante." Contraintuitivo pero real. El caso más impactante es a menudo el más complejo, el más político y el más arriesgado. Si falla, el comité saca conclusiones sobre la IA entera, no sobre ese proyecto. Empezar por un caso medio-impactante que funcione genera la credibilidad para atacar el grande después.
Discovery: a quién entrevistar y qué preguntar
Una auditoría que solo entrevista a directivos produce candidatos teóricos. Una que solo entrevista a operativos produce candidatos pequeños. La mezcla correcta tiene dos capas:
Capa de operativa. Personas que hacen el trabajo a diario: comerciales, agentes de soporte, administrativos, técnicos. Las preguntas que sacan información útil:
- "¿Qué parte de tu día te aporta menos valor?" — los huecos repetitivos son candidatos naturales.
- "¿Qué tarea has hecho hoy que sabes que un ordenador podría hacer si supiera lo que tú sabes?" — pone el dedo en la transferencia de conocimiento implícito.
- "¿Qué se te pide informe o report una y otra vez?" — el reporting recurrente es casi siempre automatizable.
- "¿Qué pregunta tuya queda sin respuesta porque buscar la información cuesta demasiado?" — son los huecos donde un asistente de búsqueda interno aportaría valor.
Capa de dirección y procesos. Responsables que conocen los procesos críticos del negocio y las restricciones legales/financieras. Las preguntas:
- "¿Cuál es el cuello de botella operativo más caro del último trimestre?" — empieza por el dolor real, no por la lista de deseos.
- "¿Qué proceso, si se acelerara X%, movería una métrica de negocio relevante?" — conecta la operativa con KPIs reales.
- "¿Qué restricciones legales o regulatorias afectan a los datos del cliente?" — el GDPR y, ya en 2026, el EU AI Act condicionan muchos casos de uso.
Un discovery serio dedica entre 5 y 12 entrevistas, dependiendo del tamaño del cliente. Cada entrevista de 45-60 minutos. Resultado: una lista de 10-15 candidatos brutos que se filtran a 5-8 con scoring formal.
Del scoring al roadmap
El scoring entrega un orden, pero entregar solo un orden no es suficiente. La auditoría termina con un roadmap por fases:
Fase 1 — Quick wins (4-8 semanas). Casos de scoring alto con esfuerzo bajo. El objetivo es generar evidencia rápida: un caso en producción que el equipo pueda mostrar, con métricas reales. Suele ser el SDR digital, el soporte L1 o un asistente de reporting.
Fase 2 — Proyecto estructural (3-6 meses). El caso de mayor impacto que requiere más trabajo. Una vez validado el quick win, se ataca el proyecto que justifica la inversión en infraestructura: procesamiento documental a gran escala, asistente interno de conocimiento sobre toda la documentación corporativa, sistema multi-agente que combina varios casos.
Fase 3 — Plataformización (6-12 meses). Si los dos primeros casos funcionan, se construye la plataforma común: el servidor de orquestación de agentes, los servidores MCP a cada sistema interno, el pipeline de evals, el dashboard de monitorización. A partir de aquí, cada nuevo caso de uso entra en cuestión de semanas, no de meses.
Esta progresión no es exclusiva de IA — es ingeniería normal aplicada a una capa nueva. Lo que distingue una empresa que escala IA de una que tropieza es respetar el orden: validar primero, plataformizar después.
Cómo es una auditoría IA seria (y cómo no es)
Una auditoría seria tiene tres entregables y tres cosas que no entrega:
Sí entrega:
- Mapa de procesos candidatos con su contexto operativo: quién hace qué, con qué frecuencia, con qué dolor, con qué datos.
- Matriz de scoring con cada candidato puntuado en los tres ejes, las suposiciones detrás de cada puntuación y la conversación que llevó a los números.
- Roadmap priorizado por fases, con tiempos estimados, dependencias técnicas, equipo requerido y métricas de éxito para cada fase.
No entrega:
- PDF de 40 páginas con conceptos genéricos sobre IA. Tu equipo ya sabe qué es un LLM. La auditoría es sobre tu negocio, no sobre el estado del arte.
- Recomendación cerrada de proveedor o plataforma. La elección de stack es una decisión técnica que viene después, no parte de la auditoría. Mezclarlas es conflicto de interés.
- Promesas de ahorro infladas. Los rangos son rangos. Si nadie puede defender una cifra concreta con un cálculo concreto, no se mete en el informe.
Duración típica: dos a tres semanas. Una semana de entrevistas, unos días de análisis y scoring, una semana de roadmap y presentación. Más allá de tres semanas suele indicar que se está alargando algo que no tenía datos suficientes desde el principio — o que se está vendiendo un proyecto disfrazado de auditoría.
Cómo lo construimos en producción
Cuando un cliente nos pide una auditoría de IA, el primer compromiso no es entregar una recomendación — es ser honestos sobre lo que merece pena y lo que no. A veces la conclusión es "no hagáis IA todavía" porque los datos no están limpios y arreglarlos pesa más que el caso de uso. Otras, la recomendación es un quick win pequeño antes que el proyecto grande que el cliente quería atacar. La auditoría existe para tomar esa decisión con criterio, no para confirmar lo que ya estaba decidido.
El entregable final es del cliente. Mapa de procesos, scoring y roadmap viven en un documento que el comité puede leer, editar y usar para tomar decisiones futuras — independientemente de quién acabe ejecutando el proyecto.
Detrás de cada auditoría hay un equipo de desarrolladores que cree que la ingeniería seria de IA empieza por entender el negocio del cliente — qué procesos consumen tiempo, qué decisiones se toman a ciegas, qué dolor real existe — y no por celebrar lo que un modelo puede hacer en un laboratorio. La excelencia técnica no se mide por la sofisticación del primer agente; se mide porque el primer caso de uso aporta valor en semanas y construye la credibilidad para el siguiente.
Honestidad radical significa decirte que un proyecto no tiene sentido cuando no lo tiene, aunque sea negocio para nosotros. Esa es la diferencia entre una auditoría de IA y un brochure de servicios.
Si estás evaluando dónde meter IA en tu empresa y no quieres comprometer presupuesto en un proyecto que termine en cajón, podemos hacer la auditoría: dos o tres semanas, scoring honesto sobre tus candidatos reales, y un roadmap que tu comité pueda firmar o rechazar con datos delante.
