Casi dos tercios de las empresas encuestadas por McKinsey en 2025 todavía no habían empezado a escalar IA a nivel corporativo. Solo un tercio sí lo hizo.
La herramienta rara vez es el problema. El diseño del piloto, sí.
Lo que casi nadie dice en voz alta: se puede tener 50 empleados usando un chatbot y miles de prompts al mes. Y cero idea de si eso mueve algo real.
PwC le puso nombre a esto: teatro de pilotos. Actividad y aprendizaje, sin resultado de negocio sostenible.
Es el equivalente corporativo de comprar una escaladora elíptica. La usas dos semanas y la enseñas cuando viene alguien.
Siete meses después es un perchero carísimo. Nadie preguntó qué músculo se iba a fortalecer ni cómo se iba a medir.
El piloto no falla por la tecnología, falla por el diseño
Los errores al implementar inteligencia artificial en una empresa casi siempre empiezan igual: se compra la licencia antes de definir el problema.
“Metamos IA aquí” no es una estrategia. Es un acto reflejo con presupuesto.
PwC recomienda lo contrario: diseñar el flujo de trabajo antes de elegir la herramienta. Su ejemplo favorito es tan aburrido como efectivo.
El proceso de permisos de ausencia. Una IA puede validar elegibilidad, encaminar aprobaciones y notificar a las partes involucradas.
El valor no está en la IA. Está en haber eliminado los traspasos manuales que nadie cuestionaba porque “siempre se hizo así”.
Ese “siempre se hizo así” es el segundo error, y el más caro: automatizar un proceso que ya estaba roto.
Ponerle IA a cinco correos, tres aprobaciones y dos capturas duplicadas no arregla nada. Solo hace que el desastre corra más rápido y sea más difícil de auditar.

¿Por qué cientos de empleados usan IA y el negocio no lo nota?
Porque uso no es lo mismo que valor. McKinsey encontró que 64% de las empresas dice que la IA impulsa innovación.
Pero solo 39% le atribuye algún impacto al EBIT. Y en la mayoría de esos casos, ese impacto es menor al 5%.
La métrica que casi todos usan —licencias activas, prompts enviados, “productividad percibida”— mide entusiasmo, no resultado.
Deloitte lo confirmó con un dato incómodo: 54% de las empresas buscaba mejoras de productividad. Solo 38% le daba seguimiento real.
Es la diferencia entre “la gente usa la herramienta” y “el tiempo de ciclo bajó, el costo por transacción bajó”. Sin línea base previa, esa comparación es imposible.
Solo queda la percepción de que “algo mejoró”. Que es la forma elegante de decir que nadie sabe.
Los errores al implementar inteligencia artificial en una empresa se repiten en el mismo orden
| Error | Señal de alerta | Corrección |
|---|---|---|
| Empezar por la herramienta | El proyecto se llama “chatbot de RH”, no “reducir tiempo de respuesta” | Definir el cuello de botella antes de elegir tecnología |
| Automatizar un proceso roto | El flujo tiene los mismos pasos de hace cinco años, solo más rápidos | Rediseñar el proceso, no decorarlo |
| Sin dueño de negocio | TI o el proveedor son los únicos que hablan del proyecto | Asignar quién responde por adopción y resultado |
| Medir uso, no valor | Los reportes hablan de prompts, no de costo o tiempo de ciclo | Fijar línea base antes de encender el piloto |
| Ignorar excepciones | El piloto solo se probó con los casos fáciles | Probar con los casos raros, ambiguos y molestos |
NIST, en su marco de gestión de riesgo de IA publicado en enero de 2023, insiste en algo que suena obvio y casi nadie hace.
Gobernar, mapear, medir y gestionar el riesgo de forma continua. No como checklist de arranque que se firma una vez y se archiva.
Parte de ese gobierno es decidir con claridad qué se automatiza y qué se queda en manos de una persona. Ese criterio lo desarrollo en cómo implementar inteligencia artificial sin reemplazar a tu equipo.

¿Qué tiene que medir un piloto para probar algo real?
Antes de encender cualquier prueba, hay cinco preguntas que deberían responderse por escrito, no de memoria:
- ¿Cuál es la línea base actual —tiempo, costo, calidad— durante un periodo comparable?
- ¿Quién es el dueño de negocio que responde por el resultado, no solo por la implementación técnica?
- ¿Qué excepción o caso ambiguo dispara revisión humana obligatoria?
- ¿Qué indicador financiero u operativo, específico y verificable, definirá si esto escala, se rediseña o se cancela?
- ¿Las horas liberadas se reasignan a algo medible, o simplemente desaparecen en la agenda de alguien?
Esta última pregunta es la que casi nadie hace. Y la que más le duele responder a quien aprobó el presupuesto.
Es el miedo real detrás de todo esto: no que la IA no funcione, sino tener que explicarle a dirección por qué el gasto no se nota en ningún número.
Ese temor tiene solución, pero no es técnica. Es de diseño previo.
Un piloto con línea base, dueño de negocio y criterio de salida definido desde el día uno no necesita “demostrar” nada después. Los números ya están ahí, esperando la comparación.
Esto es justo lo que trabajo en conferencias con equipos directivos: cómo blindar una decisión de IA antes de que se convierta en la pregunta incómoda de la siguiente revisión de resultados.
Si tu equipo ya tiene tres pilotos corriendo y nadie sabe todavía cuál mueve algo real, ese es exactamente el punto de partida de una sesión con dirección.
Un piloto de IA no se evalúa por entusiasmo ni por número de prompts. Se evalúa por si un proceso concreto mejoró, contra una línea base que alguien se molestó en medir antes de empezar.
Supervisado por Santiago González y Musi.


