IA7 sept 2026

La última milla de la IA: que la adopción tire de la innovación, no al revés

Tiempo de lectura: 10 minutos


Cada semana sale un modelo nuevo que hace algo que el anterior no hacía, y eso está bien: la innovación en IA es real y la vamos a necesitar. Pero en la mayoría de empresas con las que hablo el problema no es que falte tecnología. Tienen licencias, han hecho un piloto, han visto una demo que impresiona. Y siguen sin poder responder a una pregunta sencilla: ¿qué ha cambiado en el negocio y en cómo trabaja la gente?

A esa distancia entre lo que la tecnología ya puede hacer y lo que de verdad ha cambiado en una organización la llamo la última milla de la IA. Y la tesis de este artículo es que no se recorre empujando más innovación hacia dentro, sino al revés: haciendo que un problema con dueño, una medida y un proceso rediseñado tiren de la tecnología que hace falta. Es la idea de arrastre (pull) del modelo de producción que inventó Toyota, aplicada a la adopción de IA.

En resumenPor qué te importa: ya tienes licencias, pilotos y demos de IA, y dirección empieza a preguntar qué ha cambiado. Qué aporta este artículo: que el freno no está en los modelos sino en seis frenos de adopción no técnicos, y que se superan invirtiendo el orden habitual (que el problema tire de la tecnología, como en el modelo de producción que inventó Toyota). Qué te llevas: una forma de medir el impacto en dos caras (negocio y personas), una regla contra el autoengaño y un plan de cuatro semanas para montarlo en un proceso de tu empresa.

Empujar o tirar: dos formas de que la IA entre en una empresa

El modelo de producción que inventó Toyota tiene una idea sencilla que explica casi todo lo que sale mal en la adopción de IA. En un sistema de empuje (push), cada etapa produce todo lo que puede y lo manda a la siguiente, haya demanda o no. En un sistema de arrastre (pull), nada se produce hasta que la etapa siguiente lo pide. El primero llena almacenes; el segundo entrega lo que hace falta cuando hace falta.

La IA entra hoy en la mayoría de organizaciones en modo empuje. El proveedor saca un modelo, se compran licencias para todos, se monta un piloto para "ver qué se puede hacer" y la capacidad sale a buscar un problema que la justifique. Es exactamente el almacén lleno: mucha tecnología disponible y poca demanda real que la consuma.

Dos formas de que la IA entre en una empresa: en modo empuje la tecnología entra primero (proveedor, licencias, piloto sin dueño, y ahora qué) y se mide actividad; en modo arrastre entra primero el problema con dueño, la medida de impacto y el proceso rediseñado, que tiran de la capacidad de IA que hace falta

En modo arrastre el orden se invierte. Primero un problema concreto con alguien que lo sufre. Después la medida que dirá si se ha resuelto. Luego el proceso rediseñado: quién hace qué, qué deja de hacerse, quién revisa. Y solo entonces la capacidad de IA que ese proceso necesita, que a menudo es más modesta de lo que la demo prometía. La innovación sigue importando, pero entra porque algo tira de ella.

Para compartirLa IA no falla por falta de modelos. Falla porque entra en modo empuje: la tecnología busca un problema. Adoptar bien es lo contrario: el problema tira de la tecnología.

Qué es la última milla y por qué la recorre la organización

En logística, la última milla es el tramo final del reparto. El paquete ha cruzado medio mundo en contenedor a un coste ridículo por kilómetro, pero los problemas y el gasto se concentran en los últimos metros, entre la furgoneta y tu puerta. Es el tramo menos vistoso y el que decide si el envío ha llegado.

Con la IA pasa igual. El tramo largo está hecho y lo hace el proveedor: modelos, licencias, demos, incluso la formación genérica. El tramo corto lo tiene que recorrer la organización, y nadie lo puede hacer por ella: que la capacidad entre en un proceso concreto, la use una persona concreta cada día, cambie una decisión y alguien lo mida.

Dónde se pierde el impacto de la IA: el tramo largo (modelos, licencias, demos y pilotos, formación genérica) ya está hecho y lo hace el proveedor; la última milla (un proceso y un dueño, una medida, revisión humana, acuerdo de equipo) la recorre la organización y termina en impacto medible

Por eso un modelo mejor acorta el tramo largo, pero no recorre la última milla por ti. Y por eso el impacto tiene dos caras que hay que mirar a la vez: la del negocio (ventas, coste, tiempo de ciclo, decisiones) y la de las personas (qué han dejado de hacer, qué han aprendido a delegar, si trabajan con más criterio o solo más deprisa). Si una de las dos no se mueve, la otra no se sostiene.

Los seis frenos, y por qué ninguno es técnico

Los he ordenado como suelen aparecer: los tres primeros están en el arranque, los tres últimos en la escala. Casi siempre vienen en grupo.

1. Hay herramienta, pero no hay problema. El piloto nace de la licencia, no de un dolor. Se acaba con una lista de demos que nadie ha pedido. Un piloto sin un problema con nombre y sin un dueño que lo sufra no tiene forma de terminar bien, porque no hay nadie con motivos para llevarlo hasta el final.

2. Se cambia la herramienta y no el proceso. Alguien redacta con IA lo que antes redactaba a mano y el resto del flujo sigue igual: las mismas reuniones, las mismas aprobaciones, la misma cola. El tiempo que se ahorra en un paso se pierde esperando en el siguiente. Un acelerador enchufado a un freno de mano.

3. La gente dice que sí y sigue igual. Y hace bien, dentro de sus incentivos. Quien lleva quince años en un puesto y ha visto pasar tres transformaciones sabe que cambiar cómo trabaja tiene riesgo (equivocarse en público, quedar expuesto, perder la parte del trabajo en la que es bueno) y que no cambiar, de momento, no lo tiene. Nadie adopta nada mientras el riesgo de cambiar sea mayor que el de quedarse. Eso no se arregla con una charla motivacional; se arregla quitando riesgo con tres decisiones que alguien tiene que tomar en voz alta: que durante las primeras semanas los fallos del flujo nuevo los asume el equipo y no quien lo estrenó, que quede por escrito qué revisa siempre otra persona antes de que salga (para que esa revisión sea el proceso y no una sospecha), y que las horas de aprender estén en el calendario y descontadas de su carga de trabajo, no añadidas al final del día.

4. El gobierno llega tarde, o llega como freno. Dos versiones del mismo fallo. En una, nadie ha dicho qué se puede pegar en un chat y qué no, y cada equipo improvisa hasta el susto. En la otra, Legal escribe una política de diez páginas que en la práctica prohíbe todo, y la IA sigue usándose igual pero a escondidas. El gobierno útil se decide antes y cabe en una página: qué datos no salen, qué decisiones pasan siempre por una persona y quién responde. Lo desarrollo en Legalidad de la IA en la empresa y en los acuerdos de equipo para usar IA.

5. Se mide actividad, no impacto. Licencias activas, usuarios que han entrado, tokens consumidos, número de prompts. Todo eso sube en cualquier despliegue y no dice nada. "Mira cuánto usamos la IA" es la nueva versión de "mira cuántas horas hemos trabajado". Lo que importa cuesta más contar: qué decisión se ha tomado antes o mejor, cuántas horas han vuelto a la persona y en qué las ha empleado, qué ha dejado de hacerse.

6. La formación se compra como catálogo. Un curso genérico de IA para toda la plantilla, todo el mundo apuntado, y a las tres semanas la mitad no ha pasado de la segunda lección. No es falta de motivación: un curso "para todos" no le habla a nadie. La formación que se aprovecha es por rol, sobre el trabajo real de esa persona y con alguien al lado cuando toca aplicarla.

Para compartirSeis frenos frenan la IA en la empresa y ninguno es técnico: no hay problema, no se toca el proceso, la gente protege su puesto (con razón), el gobierno llega tarde, se mide actividad y la formación es de catálogo.
Un caso realEn 2025 acompañé a una empresa de distribución que quería poner un chatbot con IA. La idea salió de marketing, la llevaron a dirección y la pagaron de su propio presupuesto; en el piloto, sin embargo, solo estaban marketing y la consultora, así que el equipo de tecnología acabó decidiendo cosas que no le tocaban —qué podía responder el bot sin riesgo legal, qué decía la empresa sobre sí misma— porque no había nadie más a quien preguntar. Cuando dirección vio esos riesgos, paró el proyecto. Lo que propuse entonces no fue tecnología: un mapa de riesgos y otro de las personas a las que tocaba tener en la sala. Con esa conversación hecha, el alcance se replanteó y el proyecto se relanzó acotado a responder sobre el catálogo. El problema no era la falta de tecnología, sino unos objetivos demasiado amplios y un mal planteamiento de las partes interesadas en el proyecto.

Cómo se ve cuando el problema tira de la tecnología

Lo cuento con el caso que usamos en formación: GymTonic, una cadena de gimnasios, y GymApp, su app de socios. Nuria, la Product Owner, lleva meses usando IA para preparar el backlog. Su trabajo ha cambiado: llega al refinamiento con las historias ya desglosadas y las dudas anticipadas, y clasifica en una tarde el feedback de socios que antes tardaba una semana en leer.

Hasta ahí, la cara de las personas. La cara del negocio empezó cuando dirección hizo la pregunta incómoda: "¿y eso qué ha cambiado?". La respuesta honesta fue: de momento, nada medible. El equipo entregaba igual de rápido porque el cuello de botella nunca estuvo en preparar historias; estaba en la aprobación de marketing de cada cambio en la app. La IA había acelerado el paso que ya era rápido. Modo empuje, con la mejor intención.

Lo que recorrió la última milla no fue un modelo mejor. Fue darle la vuelta al orden: elegir una sola medida (cuántos días pasaban desde que un socio pedía algo hasta que lo tenía en la app), rediseñar el paso de aprobación (qué cambios podía decidir Nuria sola y cuáles no) y acordar con el equipo qué revisaba una persona siempre. Solo entonces la IA tuvo un sitio donde hacer diferencia, en la clasificación del feedback que alimentaba esas decisiones. Y la conversación en el comité dejó de ser sobre la IA y pasó a ser sobre el tiempo de respuesta al socio. Que es de lo que iba desde el principio.

Qué medir para saber si has llegado

No hace falta un cuadro de mando. Hace falta una medida por cada cara, elegida antes de empezar, y una regla que evite el autoengaño.

Qué medir para saber si has llegado: en la cara del negocio, una sola medida elegida antes (tiempo de ciclo de algo que el cliente nota, coste del proceso completo, una decisión tomada con un dato nuevo, propuestas cerradas); en la cara de las personas, cuatro preguntas (qué has dejado de hacer, qué haces con ese tiempo, en qué te fías de la IA y en qué no, si sabrías explicarlo a un compañero); y la regla: si no puedes decir qué ha dejado de hacerse, no ha habido adopción

Para el negocio, una de estas, la que toque a tu proceso: el tiempo de ciclo de algo que el cliente nota (una propuesta, una respuesta, un cambio en el producto), el coste de un proceso completo y no de una tarea, o una decisión que ahora se toma con un dato que antes no había. Si es venta, cuántas propuestas se cierran, no cuántas se redactan.

Para las personas, las preguntas se hacen a la gente, no al sistema: qué has dejado de hacer, qué haces ahora con ese tiempo, en qué te fías de la IA y en qué no, y si sabrías explicar a un compañero cómo la usas. Si nadie sabe contestar, la adopción es de licencia, no de trabajo.

Para compartirSi no puedes decir qué ha dejado de hacerse, no ha habido adopción de IA. Añadir IA encima del trabajo de siempre solo produce gente más cansada que hace más cosas.

Un plan de cuatro semanas para montar el arrastre

Lo que sigue es el mínimo que he visto funcionar para pasar de empuje a arrastre en un proceso. No es un programa de transformación: es un experimento acotado que, si sale bien, se copia al siguiente proceso y, si sale mal, te enseña por qué en un mes en vez de en un año.

SemanaQué hacesQué tienes al final
1 · ElegirUn proceso donde el dolor sea evidente y el dueño lo sufra. Una medida de negocio y las cuatro preguntas a las personas, acordadas antes de tocar nada.Un problema con nombre, un dueño y una línea base medida a mano.
2 · RediseñarDibujar el flujo actual con las personas que lo hacen. Decidir qué deja de hacerse, dónde revisa siempre una persona y quién responde. Un acuerdo de equipo de una página: qué datos no salen y qué se marca como borrador de IA.El proceso nuevo en una hoja, con el punto de revisión humano marcado.
3 · EquiparSolo ahora: la capacidad de IA que ese flujo necesita, montada por quien lo va a usar, con formación para ese rol sobre ese proceso. Y las tres decisiones del freno 3, dichas en voz alta: quién asume los fallos, qué revisa siempre otra persona y qué horas de aprender van al calendario.Las personas del proceso trabajando en el flujo nuevo, con criterio de qué revisan.
4 · Medir y decidirComparar la medida con la línea base. Hacer las cuatro preguntas. Decidir en el comité: copiar al siguiente proceso, ajustar, o parar y decir por qué.Una decisión de negocio con dato, no una demo.

Dos avisos que evitan los errores más comunes. El primero: la semana 3 va después de la 2, no antes; si compras la herramienta primero, vuelves al modo empuje aunque hayas elegido bien el problema. El segundo: parar también es un resultado. Un proceso donde la IA no compensa, con el dato delante, vale más que tres pilotos vivos que nadie se atreve a cerrar.

Lo que no recomiendo es esperar al siguiente modelo. Llegará, será mejor, y tu última milla seguirá exactamente donde la dejaste.

Preguntas frecuentes

¿Qué es la última milla de la adopción de IA? Es el tramo entre "el modelo puede hacerlo" y "alguien en mi empresa lo hace cada día, se mide y cambia una decisión". El tramo largo (modelos, licencias, demos) lo hace el proveedor; la última milla (proceso, dueño, medida, revisión humana) la recorre la organización.

¿Qué significa adoptar la IA en modo arrastre (pull)? Que el orden se invierte: primero un problema concreto con dueño, después la medida de impacto y el proceso rediseñado, y solo entonces la capacidad de IA que ese proceso necesita. Es la idea de arrastre del modelo de producción que inventó Toyota: nada se produce hasta que algo lo pide. El modo empuje es el contrario, y es el habitual: se compran licencias y la tecnología sale a buscar un problema.

¿Cómo se mide el impacto de la IA en una empresa? En dos caras a la vez. Negocio: una sola medida elegida antes de empezar, como el tiempo de ciclo de algo que el cliente nota, el coste de un proceso completo o una decisión tomada con un dato nuevo. Personas: preguntas directas sobre qué han dejado de hacer y en qué se fían. Licencias activas, usuarios y tokens miden actividad, no impacto.

¿Por qué los pilotos de IA no escalan? Porque suelen nacer de la herramienta y no de un problema con dueño, porque cambian una tarea sin rediseñar el proceso, y porque nadie fijó antes qué medida diría si funcionaban. Sin esas tres cosas no hay motivo para llevarlos hasta el final ni criterio para cerrarlos.

¿Hay que esperar a un modelo mejor antes de adoptar la IA? No. La capacidad actual sobra para la mayoría de trabajos de oficina: redactar, resumir, clasificar, extraer datos, preparar borradores. Lo que falta casi siempre es el trabajo de adopción, y ese no lo hace el siguiente modelo.

Si quieres saber dónde está tu organización en esto, el diagnóstico del gobierno de la IA es gratuito y tarda diez minutos; y si ya habéis pasado por pilotos que no escalaron, en IA sin resultados explico cómo trabajo con direcciones para montar el arrastre.

FormaciónLos seis frenos de este artículo se trabajan por rol en tres cursos: Gobernanza de IA para dirección (del AI Act al sistema que no frena), Liderar el desarrollo asistido por IA para responsables técnicos, e IA para Product Owners para quien prepara el producto. Los tres cierran en decisiones de negocio, no en demos.

Recursos relacionados

RECURSO GRATIS

¿Te ha servido? Llévate esto.

Recursos prácticos que reflejan nuestra forma de trabajar. Sin compromiso, sin pop-ups molestos.