El 95% de los pilotos de IA no llega a producción. El modelo no es el culpable
En la misma empresa conviven dos inteligencias artificiales. Una la aprueba el comité de dirección. La otra la paga cada empleado de su bolsillo. Adivina cuál genera valor hoy.
La primera tiene presupuesto, proveedor, cronograma y un piloto que lleva ocho meses «a punto de pasar a producción».
La segunda es un chat abierto en el móvil del jefe de mantenimiento, de la responsable de compras o del comercial. Lo usan para redactar informes, entender un contrato en inglés o resumir la ficha técnica de un proveedor nuevo.
La segunda funciona. La primera, casi nunca.
95%. Un estudio del MIT publicado en 2025 sobre adopción de IA generativa en empresa concluyó que la gran mayoría de pilotos corporativos no produce un impacto medible en la cuenta de resultados. Solo uno de cada veinte cruza a producción con resultados.
La cifra hizo ruido. Lo interesante no es el número. Es el motivo.
El modelo no es el culpable
Los modelos que usa el empleado en su móvil y los que hay detrás del proyecto corporativo son, a menudo, los mismos. La diferencia está en el envoltorio: cómo se conecta el modelo con los procesos, con los datos y con las reglas de la empresa.
El uso informal funciona por una razón sencilla. La persona aporta el contexto. Sabe de qué máquina habla, qué cliente tiene condiciones especiales, qué excepción aplica este mes. El modelo pone la redacción. La persona pone la verdad.
El proyecto corporativo tiene que aportar ese contexto de forma automática, a escala, sin que nadie lo revise línea a línea. Ahí es donde se rompe.
El chat funciona porque la persona pone el contexto. El piloto falla porque nadie ha decidido quién lo pone cuando la persona no está.
Tres formas de morir en fase piloto
- Vive fuera del flujo de trabajo. El piloto no está dentro del ERP, del CRM ni de la herramienta que el equipo abre cada mañana. Pide un paso extra. Nadie da ese paso dos veces.
- Lógica rígida escrita a mano. Reglas metidas en el prompt, excepciones parcheadas en código. Cada cambio de tarifa, de catálogo o de proveedor rompe algo que nadie sabe dónde está.
- Datos sin significado compartido. «Cliente» significa tres cosas en tres sistemas. «Disponible» es «en stock» para logística y «servible en plazo» para comercial. El modelo no tiene forma de saber cuál aplica.
Un asistente de cotización que responde con un tono impecable y el precio de la tarifa del año pasado no es un asistente. Es un riesgo bien redactado.
Donde más valor hay, menos se puede improvisar
Los procesos que de verdad mueven la cuenta de resultados son la planificación, las compras, el riesgo de crédito de clientes, el control de calidad, el cálculo de plazos de entrega.
Son exactamente los procesos que no puedes entregar a un sistema probabilístico sin red. Una respuesta «probablemente correcta» en un pedido de 40.000 euros no es una respuesta. Es una incidencia con fecha de llegada.
Hoy la IA es más fácil de aplicar justo donde menos importa.
Ese es el reto real. Y no se resuelve cambiando de proveedor ni esperando al siguiente modelo.
La primera estrategia de IA es una estrategia de datos
Antes de pedirle a un modelo que decida algo, la empresa tiene que hacer tres trabajos que no salen en ninguna demo:
- Conectar los datos. Cada artículo, cliente, activo y proveedor con un identificador único que signifique lo mismo en el ERP, el PIM, el CRM y el sistema de almacén.
- Darles significado explícito. Qué es un artículo sustitutivo, qué condiciones tiene un cliente, qué relación hay entre un producto, el cliente que lo compra y el proveedor que lo sirve. Ese mapa de conceptos y relaciones, escrito para que una máquina lo entienda, es lo que se llama una ontología. Los datos conectados según ese mapa forman un grafo de conocimiento.
- Escribir las reglas donde se puedan auditar. No en el prompt. En una capa que se pueda consultar, versionar y validar.
Con eso resuelto, el modelo trabaja sobre un contexto fiable. Y lo más importante: su respuesta se puede comprobar contra las reglas antes de que llegue al cliente.
El modelo aporta la creatividad. La estructura aporta la verdad. Sin la segunda, la primera es un peligro.
Ni jaula ni barra libre
Hay dos maneras de equivocarse, y las he visto las dos en empresas reales.
- Demasiada estructura. Cada caso nuevo exige un desarrollador. El sistema se vuelve tan rígido que nadie lo usa.
- Demasiado poca. Respuestas plausibles e incorrectas. Deriva silenciosa que nadie detecta a tiempo.
- El punto de equilibrio. El grafo dice qué es verdad en tu empresa. El modelo decide cómo usarlo para responder.
A esa combinación de lo determinista y lo probabilístico se le llama sistema neuro-simbólico. El término asusta. La idea es sencilla: el equipo trabaja rápido y con libertad, pero el sistema impide que se cuele un dato que no cumple las reglas.
Eso es lo que necesita la IA en la empresa. No más inteligencia. Mejores barandillas.
Antes de aprobar el próximo piloto, cinco preguntas
- ¿Qué proceso concreto cambia, y quién lo usa cada día?
- ¿De qué sistemas lee datos, y qué significa exactamente cada campo que consume?
- ¿Dónde viven las reglas de negocio: en el prompt o en un sitio auditable?
- ¿Cómo se valida una respuesta antes de que llegue al cliente?
- ¿Qué métrica de la cuenta de resultados movemos, y cuándo la vamos a medir?
Esta es mi apuesta
Las empresas que cierren la brecha no serán las que elijan el mejor modelo. Los modelos se igualan cada trimestre. Serán las que hayan conectado sus datos y escrito el mapa de su propio negocio antes que la competencia.
Ese mapa no se compra. Se construye. Y es lo único de todo el proyecto que el competidor no puede copiar.
Menos demos. Más datos conectados. Y una pregunta en cada comité: si mañana el piloto funciona perfecto, ¿de dónde saca la verdad?