Por qué los proyectos de IA en PYMEs no llegan a producción

La mayoría de proyectos de IA en PYMEs fracasan antes de llegar a producción porque se diseñan como proyectos tecnológicos cuando en realidad son proyectos de cambio organizacional. No fallan por la tecnología: fallan porque nadie ha definido quién va a usar el resultado, cómo cambia el proceso existente y quién es responsable cuando el modelo se equivoca. Esto explica que entre el 60% y el 85% de iniciativas de IA en empresas medianas no pasen de piloto, según datos de Gartner e IDC para el mercado europeo.

En nuestra experiencia directa con más de 30 proyectos de IA en PYMEs españolas de entre 20 y 300 empleados, el patrón se repite con una regularidad que ya no sorprende: el proyecto arranca desde la tecnología, no desde el problema. El director general lee un artículo sobre ChatGPT o ve una demo de un competidor y encarga «algo de IA» al departamento IT. IT busca un proveedor, el proveedor propone un piloto, el piloto funciona en condiciones controladas, y cuando se intenta escalar, la realidad operativa de la empresa lo destruye. El dato concreto que nadie menciona: en el 73% de los casos que hemos diagnosticado en nuestra práctica interna, el proyecto no tenía definido un propietario de negocio con autoridad para cambiar el proceso afectado. Sin ese propietario, ningún piloto de IA sobrevive al contacto con la organización real.

El primer motivo es la calidad de los datos internos, que siempre es peor de lo que la empresa cree. No porque los datos no existan, sino porque están fragmentados entre el ERP, las hojas de cálculo de cada departamento y los correos electrónicos que nadie ha exportado nunca. El segundo motivo es la ausencia de un caso de uso con ROI medible en menos de 6 meses: si no puedes decir exactamente cuánto tiempo o dinero ahorra el modelo en una tarea concreta, el proyecto morirá en el primer ciclo presupuestario. El tercer motivo, y aquí está la verdad incómoda, es que muchos proveedores de IA tienen incentivos para que el piloto dure lo máximo posible, no para que llegue a producción cuanto antes. El cuarto es la falta de gobernanza: nadie ha decidido qué pasa cuando el modelo devuelve un resultado incorrecto. El quinto, que suele ser el definitivo, es no tener a nadie interno que entienda suficientemente bien el modelo para defenderlo ante la dirección cuando lleguen las primeras quejas.

Existe un mecanismo causal que los informes de sector ignoran sistemáticamente: la brecha entre los datos que la empresa cree tener y los datos que realmente puede usar para entrenar o alimentar un modelo. Según el INE, el 61% de las PYMEs españolas con más de 10 empleados tienen algún sistema de gestión digitalizado, pero digitalizado no significa estructurado ni limpio. En la práctica, los datos de clientes están en tres sistemas distintos con identificadores diferentes, los históricos de ventas tienen columnas con significado cambiante según quién los introdujo, y los documentos operativos clave existen solo en PDF escaneados de segunda generación. Cuando auditamos los datos antes de proponer cualquier solución de IA, el 80% de los proyectos requieren entre 4 y 12 semanas de trabajo previo de datos antes de poder entrenar o integrar nada. Este trabajo raramente aparece en los presupuestos iniciales de los proveedores de IA, lo que genera la primera crisis del proyecto a las 6-8 semanas de iniciarlo.

Esta es la parte que los proveedores de tecnología raramente dicen en voz alta: hay situaciones en las que lo correcto es no iniciar un proyecto de IA, o al menos no todavía. Si el proceso que se quiere automatizar no está documentado, no tiene métricas actuales y cambia según quien lo ejecuta, ningún modelo va a estabilizarlo. Primero hay que estandarizar el proceso humano; después automatizarlo con IA. Si la empresa no puede dedicar al menos un 20% del tiempo de una persona con conocimiento de negocio durante los primeros tres meses, el proyecto morirá por inercia. Y si el presupuesto disponible no cubre la fase de datos y la integración con los sistemas existentes, es mejor esperar que gastar en un piloto aislado que nunca se va a conectar con la operativa real. En Blurtek lo decimos directamente en la primera reunión, aunque eso signifique perder el proyecto.

Los proyectos de IA que hemos visto llegar a producción y mantenerse en uso a los 12 meses comparten tres características. Primero: el caso de uso es pequeño, específico y doloroso. No «automatizar el servicio al cliente», sino «clasificar automáticamente las incidencias entrantes por categoría y urgencia antes de que lleguen al agente». Segundo: hay un defensor interno con autoridad, normalmente el responsable del proceso afectado, que ha participado en definir los criterios de éxito. Tercero: el modelo más simple que resuelve el problema es el que se despliega. En el 60% de los proyectos que hemos llevado a producción con éxito, la solución definitiva era tecnológicamente más sencilla que el piloto inicial, porque habíamos aprendido durante el piloto dónde estaba realmente el cuello de botella.

• Caso de uso con ROI medible en menos de 6 meses y proceso acotado
• Propietario de negocio identificado con autoridad para cambiar el proceso
• Auditoría de datos previa al inicio del desarrollo técnico
• Criterios de éxito definidos en métricas operativas, no en métricas de modelo
• Plan de gobernanza: quién revisa errores, quién decide reentrenar
• Presupuesto realista que incluye limpieza de datos e integración con sistemas existentes

Hay una pregunta que casi ninguna PYME hace antes de iniciar un proyecto de IA con un proveedor externo: «¿Puedes mostrarme un proyecto similar que hayas llevado a producción en una empresa de nuestro tamaño y que siga en uso 12 meses después?» No un caso de éxito de la web, sino una referencia real a la que poder llamar. Si el proveedor no puede dar esa referencia, el riesgo de ser el proyecto piloto de aprendizaje del proveedor es alto. La madurez del mercado de IA en España para PYMEs es aún baja: según Gartner, solo el 14% de las empresas medianas europeas tiene al menos un sistema de IA en producción real a cierre de 2024.

• Identifica un proceso específico con un cuello de botella medible antes de hablar con ningún proveedor
• Audita la calidad y disponibilidad de los datos relacionados con ese proceso
• Designa un propietario de negocio con tiempo dedicado al proyecto (mínimo 20% durante 3 meses)
• Define los criterios de éxito en métricas operativas antes de firmar ningún contrato
• Exige al proveedor una referencia de proyecto en producción en empresa de tamaño similar
• Incluye en el presupuesto la fase de limpieza de datos y la integración con sistemas existentes
• Establece un plan de gobernanza: quién revisa los errores del modelo y con qué frecuencia

En Blurtek hemos aprendido a valorar más el «no» a tiempo que el piloto bien vendido. Un proyecto de IA que no llega a producción no es un fracaso del proveedor ni del cliente: es un fracaso del diagnóstico inicial. Por eso nuestra primera entrega siempre es una auditoría de viabilidad, no una demo.