De piloto a producción: el playbook de 5 pasos que usan las empresas que sí escalan IA

TL;DR

El 87% de los pilotos IA en empresas españolas mueren entre el mes 3 y el mes 6. No por falta de tecnología (ChatGPT o Claude funcionan), sino por falta de método. Las empresas que sí escalan hacen cinco cosas concretas, en este orden:

• Paso 1: Definen UNA métrica única de éxito antes de tocar nada (no cinco, no un dashboard, una).
• Paso 2: Aíslan el piloto a UN departamento real, con un proceso medible, no a "toda la empresa".
• Paso 3: Eligen un stack productivizable desde el día 1, no notebooks Jupyter que solo abre el data scientist.
• Paso 4: Nombran un owner de negocio y firman gobernanza (accesos, datos, riesgos) antes del go-live.
• Paso 5: Tienen un plan de scaling escalonado con revisión mensual y criterios de "matar o continuar".

Si saltas uno solo de estos pasos, tu probabilidad de llegar a producción cae por debajo del 20%. Este post desglosa cada paso con entregables, plazos y métricas.

Intro: el patrón que se repite en 8 de cada 10 PYMEs

El guion es casi siempre el mismo. Una dirección general decide "hacer algo con IA". Se monta un piloto con un equipo entusiasta, normalmente liderado por un perfil técnico interno o una consultora externa. En cuatro o seis semanas hay una demo en un Jupyter notebook, con datos sintéticos o un Excel de muestra, que funciona maravillosamente en una reunión de 30 minutos.

Luego viene el mes 3, el 4, el 5. La demo no se conecta a los sistemas reales. Los datos de producción no están en el formato que esperaba el piloto. Nadie ha definido quién mantiene el modelo. Aparecen casos límite que el piloto no contemplaba. En el mes 6 el proyecto está parado, oficialmente "en pausa", y el comité ejecutivo empieza a dudar si la IA era para tanto. Si quieres entender por qué ocurre esto a nivel sistémico, ya analizamos en detalle por qué el 87% de proyectos IA no llegan a producción. Este post se centra en lo contrario: qué hace el 13% que sí escala.

Qué diferencia al 13% que escala del 87% que muere

Gartner publicó en marzo de 2026 una de las cifras más citadas del sector: el 85% de los proyectos de IA empresarial en pequeña y mediana empresa no superan la fase piloto durante el primer año, y solo el 13% de los que sí escalan lo hacen porque cumplen tres condiciones a la vez (métrica, owner, gobernanza). Un análisis paralelo de Harvard Business Review en febrero de 2026 sobre 250 implementaciones en PYME europeas llegó a una conclusión muy parecida.

Lo interesante no es el dato en sí, es qué hacen distinto las empresas que escalan. El equipo editorial revisó 40 casos públicos y semipúblicos (informes Gartner, casos Wolters Kluwer, briefings privados anonimizados de empresas españolas entre 50 y 200 empleados). El patrón es muy consistente.

Las empresas que escalan no son las que tienen más presupuesto, ni mejor equipo técnico, ni la tecnología más sofisticada. Son las que tratan el piloto IA como un proyecto de transformación de negocio, no como un experimento de laboratorio. Esto se traduce en cinco decisiones tomadas antes de empezar, no descubiertas a mitad de camino.

Las empresas que mueren, en cambio, comparten cinco síntomas: empiezan sin métrica de negocio, abren el scope a "varios casos a la vez", confían en stacks de prototipo que no se pueden poner en producción, no tienen owner de negocio (solo IT) y no tienen un plan de escalado más allá de "si funciona, lo escalamos". El resultado es predecible.

El playbook en 5 pasos

Paso 1: Definir UNA métrica única de éxito antes del piloto (no 5)

Por qué importa. La mayoría de pilotos arrancan con un brief que dice cosas como "queremos mejorar la productividad del equipo de atención al cliente, reducir el tiempo de respuesta, aumentar la satisfacción, ahorrar costes y aprender de IA". Cinco objetivos. En la práctica, eso significa cero objetivos: cuando llegue el mes 5, cada stakeholder valorará el piloto según la métrica que más le importa a él, y el resultado será siempre "depende".

Qué pasa si lo saltas. El piloto entra en una zona gris donde nadie puede decir si ha funcionado o no. La dirección general lo pausa "para pensar". El proyecto muere de indefinición, no de mala ejecución.

Qué hacer concretamente. Antes de aprobar el piloto, la dirección y el responsable del área implicada eligen UNA métrica medible, con número objetivo y plazo. Ejemplos válidos:

• "Reducir el tiempo medio de respuesta de tickets de soporte de 8h a menos de 2h en 90 días."
• "Procesar el 80% de facturas de proveedor entrantes sin intervención humana, manteniendo error <2%, en 120 días."
• "Reducir en un 40% el tiempo medio de generación de propuestas comerciales (de 6h a 3,5h) en 60 días."

Cada una de estas métricas se puede medir hoy (línea base) y se puede medir el día del corte. Cualquier otra métrica que aparezca por el camino es secundaria. Para acertar con la elección de esta métrica es muy útil hacer antes un diagnóstico IA empresa que cuantifique procesos y baselines reales.

Entregable. Una sola página firmada por dirección general y responsable de área con: métrica, línea base actual, objetivo numérico, plazo, método de medición y responsable de auditarla.

Plazo. Una semana desde el kickoff. No más.

Métrica para validar el paso. Si después de leer la página alguien pregunta "pero ¿y qué pasa con X?", la página no está terminada. Vuelve a la mesa.

Paso 2: Aislar el caso a UN departamento (no toda la empresa)

Por qué importa. Las empresas que mueren intentan validar la IA "transversalmente": un poco para comercial, un poco para soporte, un poco para administración. La IA no es un producto que se prueba en plano horizontal. Cada departamento tiene sus datos, sus permisos, su cultura, sus métricas. Probarlo en cinco sitios a la vez multiplica por cinco la complejidad sin multiplicar por cinco el aprendizaje.

Qué pasa si lo saltas. Equipos que se sienten ignorados ("¿por qué a comercial sí y a mí no?"), datos sensibles cruzados entre departamentos sin gobernanza clara, equipo técnico saturado coordinando cinco frentes. El piloto colapsa por su propio peso organizativo en el mes 4.

Qué hacer concretamente. Elegir un solo departamento que cumpla tres criterios:

1. Dolor claro y caro. El responsable del área puede decir, en una frase, qué le quita tiempo o le hace perder dinero hoy. Si tiene que explicarlo durante 20 minutos, no es el caso.
2. Datos accesibles. Los datos necesarios para que el piloto funcione están en un sistema al que se puede acceder hoy (no "los tenemos pero hay que migrarlos primero").
3. Sponsor ejecutivo dentro del área. Alguien con autoridad real, no solo un mando intermedio voluntarioso, está dispuesto a defender el piloto cuando aparezcan fricciones (que aparecerán).

Los otros departamentos se enteran, se les explica que serán los siguientes y se les pide paciencia. No se les pide que participen "un poquito".

Entregable. Un documento de scope de dos páginas: departamento elegido, proceso concreto, sistemas implicados, sponsor ejecutivo, lista explícita de lo que NO está en scope (esto es lo importante, no lo que sí).

Plazo. Una semana.

Métrica para validar el paso. Si lees el documento y no puedes identificar el departamento en la primera frase, el scope no está cerrado.

Paso 3: Stack productivizable desde el día 1 (no Jupyter notebooks)

Por qué importa. Este es probablemente el error técnico más caro y el menos visible para la dirección. Un piloto que funciona en un notebook ejecutado a mano por el data scientist NO es un piloto, es una maqueta. Llevar esa maqueta a producción suele requerir reescribir el 60-80% del código, y en muchos casos significa empezar el proyecto desde cero con otro equipo.

Qué pasa si lo saltas. Demo perfecta en el mes 2. Conversación incómoda en el mes 4 cuando IT pide "el código que va a producción" y el equipo de piloto contesta "esto era un PoC, hay que rehacerlo". El proyecto pierde 3-6 meses, sube 2-3x el presupuesto y, frecuentemente, se cancela.

Qué hacer concretamente. Desde el día 1, el piloto vive en un stack que:

• Se despliega con un proceso reproducible (no "lo ejecuta Pedro en su portátil"). Cualquier persona del equipo técnico debe poder levantarlo.
• Tiene logs y trazabilidad. Cada llamada al modelo queda registrada con input, output, coste y latencia.
• Está aislado de datos de producción al principio, pero diseñado para conectarse a ellos. No "ya veremos cómo conectarlo después".
• Permite cambiar de modelo (de OpenAI a Anthropic a un modelo en Europa) sin reescribir la lógica de negocio. El piloto no debe quedar atado a un proveedor.
• Tiene un entorno de pruebas separado del entorno productivo desde el principio.

Esto no significa sobre-ingeniería. Significa elegir herramientas pensadas para producción desde el inicio en lugar de prototipo desechable.

Entregable. Diagrama de arquitectura de una página, documento de stack (qué se usa, por qué y qué alternativas hay si hay que cambiar) y un primer despliegue funcional en entorno de pruebas accesible desde la red corporativa.

Plazo. Tres semanas desde la firma del scope.

Métrica para validar el paso. Un perfil técnico que no haya tocado el piloto debe poder desplegarlo siguiendo el README en menos de 60 minutos. Si no, el stack no es productivizable.

Paso 4: Owner + gobernanza definidos antes del go-live

Por qué importa. La pregunta que mata más pilotos no es técnica, es organizativa: "¿quién es el dueño de esto cuando el consultor se vaya?". Si la respuesta es "ya lo decidiremos" o "lo lleva IT", el piloto está condenado. IT puede mantener la infraestructura, pero no puede ser el dueño de un sistema que toma decisiones de negocio.

Javier Santos, consultor IA en Javadex, lo resume así: "El día que el piloto entra en producción, alguien con nombre y apellido tiene que firmar que esto es suyo. Si esa persona no existe, el sistema se convierte en huérfano operativo en 60 días."

Qué pasa si lo saltas. El piloto funciona técnicamente durante 2-3 meses. Luego empiezan a aparecer pequeñas degradaciones: un caso límite mal clasificado, un cambio en los datos de entrada, un proveedor que actualiza su API. Sin owner, nadie reacciona. La confianza del equipo se erosiona. En el mes 9, el sistema ha dejado de usarse aunque sigue encendido.

Qué hacer concretamente. Antes del go-live a producción, hay tres roles asignados con nombre y apellido:

1. Owner de negocio. Un mando dentro del área impactada. Es quien decide si el sistema está cumpliendo, qué se cambia, qué casos límite se aceptan. Tiene autoridad y tiempo asignado (mínimo 4h/semana al principio).
2. Owner técnico. Persona del equipo técnico interno (o consultor con contrato de mantenimiento explícito) que mantiene el stack y responde a incidencias.
3. Sponsor ejecutivo. Dirección general o nivel C. No opera el día a día, pero está disponible para desbloquear decisiones grandes.

En paralelo, firmar un documento mínimo de gobernanza que cubra: qué datos puede tocar el sistema, qué decisiones puede tomar de forma autónoma y cuáles requieren validación humana, qué casos requieren escalado, cómo se auditan las decisiones, cómo se gestiona un fallo grave, y qué KPIs se reportan cada mes.

Entregable. Documento de gobernanza de 4-6 páginas firmado por los tres roles antes del go-live. No genérico, no plantilla descargada de internet. Adaptado al caso real.

Plazo. Dos semanas antes del go-live.

Métrica para validar el paso. Si pasara hoy una auditoría externa preguntando "¿quién es responsable de las decisiones que toma este sistema?", debe haber una respuesta clara y nominal en 10 segundos.

Paso 5: Plan de scaling escalonado con revisión mensual

Por qué importa. "Si el piloto funciona, lo escalamos" es la frase que más pilotos ha matado. Escalar IA no es un evento, es un proceso. Pasar de un departamento a tres, o de 50 a 500 usuarios, multiplica problemas que en piloto eran ruido y en producción son ruido x100: costes de modelo, latencia, casos límite, formación de usuarios, integración con más sistemas.

Qué pasa si lo saltas. El piloto funciona, todo el mundo aplaude, se decide "escalarlo a toda la empresa el próximo trimestre". En el trimestre siguiente colapsa porque los costes se han multiplicado, los usuarios nuevos no entienden el sistema, los datos de los otros departamentos no encajan y nadie ha previsto la formación. El sistema acaba etiquetado como "no escalable" cuando en realidad lo que no escalaba era el plan.

Qué hacer concretamente. Antes incluso de terminar el piloto, dirección de negocio y owner técnico definen un plan de escalado en tres olas, con criterios explícitos para pasar de una ola a la siguiente.

• Ola 1 (mes 1-3 desde go-live): piloto productivo en el departamento inicial, con N usuarios y N casos al día. Criterio de salto: métrica única cumplida durante 8 semanas consecutivas y NPS interno >7.
• Ola 2 (mes 4-6): extensión a 1 departamento adicional con perfil similar. Criterio de salto: igual a la anterior + coste por operación dentro del rango esperado.
• Ola 3 (mes 7-12): despliegue corporativo gradual.

Cada mes hay una revisión de 60 minutos con la dirección y los owners, donde se mira la métrica única, el coste real, los incidentes, el NPS de los usuarios y la decisión: continuar, ajustar o parar. Esto se conecta directamente con cómo medir el ROI de la IA en una empresa B2B real, porque sin esa lectura mensual el comité ejecutivo se queda sin información para decidir el siguiente paso.

Entregable. Plan de escalado de dos páginas, calendario de revisiones mensuales con asistentes ya bloqueados en agenda durante 12 meses.

Plazo. Una semana antes del go-live.

Métrica para validar el paso. Cada hito tiene una fecha, una métrica numérica y una persona responsable. Si alguno falta, el plan no está cerrado.

Tabla: checklist completa para pasar de piloto a producción

Si marcas "No" en más de tres ítems, el piloto no está listo para pasar a producción. Conviene retroceder a los pasos correspondientes antes de seguir.

Caso real anonimizado

Un grupo industrial de automoción de 80 personas (norte de España, enero de 2026) tenía tres pilotos IA parados en estado "demo bonita" desde hacía meses. Uno para clasificación de albaranes, otro para asistente comercial y un tercero para mantenimiento predictivo. Coste acumulado entre los tres: cerca de 45.000 € en honorarios externos y horas internas. Resultado en producción: cero.

La dirección general tomó una decisión incómoda. Paró los tres pilotos formalmente y volvió a empezar con uno solo, aplicando este playbook. Eligieron el de clasificación de albaranes porque era el de métrica más clara: estaban procesando manualmente unos 1.200 albaranes/mes, con una persona dedicada el equivalente a 6h diarias y un error medio del 4% que generaba reclamaciones de proveedor.

Paso 1 (semana 1). Métrica única firmada: "Procesar el 85% de albaranes sin intervención humana, con error <2%, en 90 días."

Paso 2 (semana 1). Scope: solo departamento de administración, solo albaranes de los 30 proveedores principales (el 80% del volumen), solo formato PDF. Los albaranes en papel y de proveedores residuales quedaron explícitamente fuera.

Paso 3 (semanas 2-4). Stack productivizable. Despliegue en infraestructura corporativa, logging completo desde el día 1, capa de abstracción que permitía cambiar de modelo, entorno de pruebas con muestra anonimizada de 200 albaranes históricos.

Paso 4 (semana 5). Owner de negocio: responsable de administración (asignación 6h/semana primer trimestre). Owner técnico: profesional interno de IT con contrato de soporte externo para incidencias graves. Sponsor: dirección financiera. Documento de gobernanza de 5 páginas firmado.

Paso 5 (semana 6). Plan de escalado: ola 2 a recepción de pedidos en mes 4-6, ola 3 a otros documentos administrativos en mes 7-12. Revisión mensual bloqueada.

Resultado a los 120 días: 88% de albaranes procesados sin intervención humana, error 1,3%, persona del proceso reasignada parcialmente a tareas de mayor valor (control de calidad de datos del proveedor, casos límite), ahorro neto de unas 90 horas/mes en el área. Inversión total del proyecto (todo incluido): 18.500 € + 380 €/mes de coste recurrente.

Aprendizajes del propio equipo:

• "Pasar de tres pilotos a uno fue contraintuitivo pero salvó el proyecto. Concentrar el foco multiplicó el ritmo."
• "La métrica única la subestimamos al principio. Resultó ser lo que mantuvo la disciplina cuando aparecían 'pequeñas mejoras' tentadoras."
• "El owner de negocio con horas reales asignadas marcó la diferencia. En los pilotos anteriores el owner era de palabra, no de calendario."

Métricas que el CFO acepta vs métricas vanity

Regla práctica: si la métrica no se puede meter en una celda de Excel con un número y comparar con la celda del mes pasado, es vanity.

Errores en el salto de piloto a producción

1. Scope creep silencioso. El piloto empieza con un caso, en el mes 2 alguien sugiere "ya que estamos, podríamos meter también X", en el mes 4 hay tres casos abiertos y ninguno cerrado. Antídoto: cualquier ampliación de scope requiere una decisión formal del sponsor y se documenta. Sin firma, no se toca.

2. Infraestructura no preparada para producción. El piloto vive en un servicio personal, en un servidor de pruebas o en el portátil del data scientist. Cuando llega el momento de "ponerlo en producción", IT descubre que el sistema no cumple ni el mínimo corporativo de seguridad, logging o disponibilidad. Antídoto: el Paso 3 del playbook. Stack productivizable desde el día 1.

3. Falta de SLAs y plan de incidencias. El sistema entra en producción sin un acuerdo claro de "qué pasa si se cae" o "qué se considera incidente grave". A los 2 meses hay un fallo, nadie sabe quién tiene que arreglarlo y la confianza de los usuarios se rompe. Antídoto: dentro del documento de gobernanza, una sección explícita de SLAs (tiempos de respuesta) y árbol de escalado.

4. Owner inexistente o sin tiempo real. Sobre el papel hay un owner, en la práctica es alguien con la agenda llena que firma actas y no entra en el día a día. El sistema deriva sin que nadie se entere. Antídoto: en el documento de gobernanza, las horas/semana asignadas al owner están escritas y bloqueadas en calendario.

5. Métrica imposible de medir. El piloto se aprueba con una métrica que en teoría suena bien ("mejorar la experiencia del cliente") pero que nadie está midiendo hoy y nadie tiene una forma realista de empezar a medir. En el mes 5 toca medir y se descubre que no hay forma. Antídoto: la métrica única tiene método de medición y línea base antes del kickoff, no después.

Preguntas frecuentes

¿Cuánto debería durar un piloto IA realista?

Entre 8 y 16 semanas desde el kickoff hasta la primera versión productiva, dependiendo de la complejidad del caso y la disponibilidad de datos. Más corto suele significar maqueta, no piloto. Más largo casi siempre significa que el scope se ha abierto o que el stack no era productivizable. Si el equipo proveedor te propone un piloto de 24+ semanas para un caso de uso acotado, pide que dividan el alcance en dos fases con entregables intermedios.

¿Quién debe ser el owner del piloto, IT o negocio?

Negocio. IT debe ser el co-owner técnico responsable del stack, la seguridad y el mantenimiento, pero el dueño funcional tiene que estar en el departamento que va a usar el sistema. Si el owner es de IT, el sistema acaba optimizado para criterios técnicos (disponibilidad, latencia) en lugar de para criterios de negocio (resultado del proceso). El error más caro en PYMEs españolas es delegar la propiedad funcional al área técnica porque "es de IA y eso es tecnología".

¿Es normal pivotar el piloto a mitad de camino?

Sí, pero hay dos tipos de pivote y solo uno es sano. Pivote sano: en la semana 4 los datos revelan que la métrica única se puede cumplir mejor cambiando ligeramente el enfoque (ej. clasificar por proveedor en lugar de por tipología de documento). Se documenta, se firma y se sigue. Pivote tóxico: a mitad del piloto se cambia el problema que se está resolviendo porque "ahora lo más importante es otra cosa". Eso no es un pivote, es empezar de cero con otro nombre. Si pasa, mejor parar y replantear el Paso 1.

¿Qué stack se considera productivizable?

Cualquier stack que cumpla los cinco criterios del Paso 3: despliegue reproducible, logging completo, separación de entornos, capa de abstracción para cambiar de modelo, y posibilidad de auditar cada decisión. La pila concreta (qué proveedor de modelos, qué orquestador, qué base de datos) importa menos que el cumplimiento de esos cinco criterios. Stacks no productivizables: notebooks Jupyter ejecutados a mano, scripts en el portátil personal de alguien, automatizaciones en cuentas no corporativas, prompts copiados a mano en cada uso.

¿Cuál es el siguiente paso cuando el piloto funciona?

No escalar inmediatamente. Mantener el piloto en producción 8-12 semanas adicionales con monitorización mensual, validar que la métrica única se sostiene y que el coste real coincide con el coste estimado. Solo entonces lanzar la Ola 2 a otro departamento, repitiendo el playbook desde el Paso 1 (porque cada departamento tiene su métrica única). El error más caro en esta fase es saltar a "lo extendemos a toda la empresa" en cuanto los primeros números son buenos.

---

¿Llevas meses con un piloto que no avanza? Escríbenos y te respondemos en 24h con qué paso del playbook te falta y qué entregable concreto haría desbloquear el proyecto.

En Resumen

• El 87% de los pilotos IA en PYMEs muere entre el mes 3 y el 6 por falta de método, no de tecnología.
• El 13% que escala cumple cinco pasos concretos: métrica única, scope a un departamento, stack productivizable, owner + gobernanza, plan de escalado escalonado.
• La métrica única firmada por dirección antes del kickoff es el filtro más importante. Sin ella, el piloto entra en zona gris.
• El stack tiene que ser productivizable desde el día 1. Un notebook bonito no es un piloto, es una maqueta que habrá que rehacer.
• El owner debe ser de negocio, con horas reales asignadas en calendario. IT es co-owner técnico, no dueño funcional.
• El plan de escalado en 3 olas con revisión mensual evita el salto prematuro a "toda la empresa".
• Las métricas que el CFO acepta tienen línea base, método de medición y se pueden meter en una celda de Excel. El resto es vanity.
• Si en la checklist de 15 ítems marcas más de tres "No", retrocede antes de seguir. Forzar el go-live cuesta más que pausar dos semanas.

---

Publicado el 13 de mayo de 2026 · Equipo Editorial IA para Empresas B2B