Tiempo de lectura: 6 minutos
La forma más habitual de "adoptar la IA" en una empresa media es esta: alguien de dirección ve una demo, se compran licencias para todo el mundo, se manda un correo animando a usarlas y, seis meses después, nadie sabe decir qué ha cambiado. No es que la tecnología falle. Es que se ha empezado por la última columna de la tabla que vas a ver más abajo.
Este artículo es un plan en una tabla. Cinco filas con las dimensiones en las que una organización tiene que moverse, cinco columnas con las fases por las que pasa, y en cada casilla la pregunta que tiene que poder responder antes de seguir. Está pensado para una empresa media: entre cincuenta y mil personas, sin equipo de datos propio, con gente que ya usa IA por su cuenta y con un comité de dirección que empieza a preguntar.
- Por qué te importa: tienes presión para "hacer algo con la IA" y la opción fácil (licencias para todos) es la que menos resultado da.
- Qué aporta este artículo: un mapa de cinco dimensiones (estrategia, personas, procesos, tecnología, gobierno) por cinco fases (diagnóstico, piloto, formación, transformación, soporte), con la actividad clave de cada casilla, la señal que te dice cuándo pasar de fase y los errores que comete la mayoría.
- Qué te llevas: saber en qué columna estás de verdad, qué te falta para pasar a la siguiente y cómo usar la tabla en una sesión de dirección de noventa minutos.
En qué columna estás de verdad
Antes de la tabla, cuatro preguntas. Contesta sí o no, sin trampas.
- ¿Tienes una lista escrita de problemas del negocio con dueño, no de herramientas que "podríamos probar"?
- ¿Hay al menos un caso en marcha con una métrica y una fecha en la que se decide si sigue o se para?
- ¿La gente que usa IA a diario sabe qué delegar y qué revisar, y lo tiene por escrito?
- ¿Algún proceso funciona ya de forma distinta y se mide el resultado, no el volumen?
Si has dicho no a la primera, estás en Diagnóstico, aunque tengas licencias. Si has dicho sí a las dos primeras y no a la tercera, estás entre Piloto y Formación. Solo si has dicho sí a las cuatro estás en Transformación. La mayoría de las empresas con las que hablo se sitúan dos columnas más a la derecha de donde están, y esa es la primera corrección útil del plan.
El mapa: cinco dimensiones, cinco fases
Las filas son las dimensiones en las que tiene que moverse la organización, no solo tecnología. Las columnas van en orden: Diagnóstico → Piloto → Formación → Transformación → Soporte. Formación va antes que Transformación porque no se escala lo que la gente no sabe hacer, y Soporte es donde se vive después: no es una fase que se cierra.
| Diagnóstico | Piloto | Formación | Transformación | Soporte | |
|---|---|---|---|---|---|
| Estrategia y casos de uso | Inventario de problemas con dueño, no de herramientas | Un caso, una métrica, una fecha de decisión | Directivos: qué puede y qué no puede hacer la IA hoy | OKR que la IA ayuda a ejecutar, no a inflar | Revisión trimestral: qué sigue, qué se para |
| Personas y organización | Quién usa ya IA por su cuenta (y a escondidas) | Un equipo voluntario, no uno designado | Alfabetización para todos; rol a rol para quien la usa a diario | Roles nuevos: quién revisa, quién decide qué es "bueno" | Comunidad interna y acuerdos revisados en cada retro |
| Procesos y producto | Dónde se pierde el tiempo de verdad, no dónde se cree | Rediseñar un proceso, no acelerar el actual | Product owners y equipos: evals, Definición de Done, criterio | Del piloto al proceso: leer, decidir, descartar | Métricas de resultado, no de volumen |
| Tecnología y datos | Qué datos hay, dónde, y quién puede tocarlos | Agente por fuera (API) antes que sistema nuevo | Ingeniería de contexto para quien construye | Sistema de registro con IA solo si el techo lo justifica | Observabilidad, coste por ejecución, evals en el pipeline |
| Gobierno y riesgo | Mapa de riesgos y de partes interesadas | Política de uso de una página, antes del piloto | Qué exige el AI Act según tu caso | Quién responde de cada decisión automatizada | Registro de incidentes y revisión de permisos |
Una casilla no es una tarea que se marca como hecha. Es una pregunta que la organización tiene que poder responder en esa fase. Si en la casilla "Piloto × Gobierno" no puedes decir qué dice tu política de uso, no es que te falte un documento: es que vas a hacer un piloto en el que nadie sabe qué puede hacer la IA sin revisión.
Cada columna tiene una señal de paso
Lo que convierte la tabla en un plan y no en un catálogo es que cada columna termina con una señal. Si no la tienes, no has terminado la fase, por mucho que el calendario diga otra cosa.
- Sales de Diagnóstico cuando tienes una lista corta de problemas con dueño y una idea de qué datos hay para cada uno. No cuando tienes una lista de herramientas.
- Sales de Piloto cuando el caso tiene una métrica que se mueve (o no), una fecha y una decisión tomada: sigue, cambia o se para. Un piloto que "sigue en marcha" a los seis meses no es un piloto, es un proyecto sin dueño.
- Sales de Formación cuando quien usa la IA a diario puede decir qué delega, qué revisa y qué no toca, y lo tiene por escrito en los acuerdos del equipo.
- Sales de Transformación cuando al menos un proceso funciona de forma distinta y lo que se mide es el resultado para el cliente o el negocio, no cuántas cosas se han generado.
- De Soporte no se sale. Se revisa cada trimestre qué sigue, qué se para y qué nuevo caso entra por la izquierda de la tabla.
Lo que hace la mayoría
La fila que no está en la tabla. Una línea por columna, porque el error es siempre el mismo y siempre parece razonable en el momento.
- En Diagnóstico: comprar licencias antes de saber qué problema resuelven. La herramienta busca un problema que la justifique, y lo encuentra en forma de demos que nadie pidió.
- En Piloto: un piloto sin dueño, sin métrica y sin fecha. Lo lleva "el equipo de innovación" o "el que más sabe", y por eso nadie puede decidir si ha funcionado.
- En Formación: formar en herramientas y no en criterio. Todo el mundo sabe escribir un prompt; nadie sabe cuándo el resultado no sirve.
- En Transformación: escalar la demo. Lo que funcionó con una persona voluntaria y motivada se manda a toda la empresa con las mismas fechas y el mismo proceso, y lo que llega es volumen sin revisión.
- En Soporte: medir tokens, licencias activas y "casos de uso lanzados". Es decir, actividad. Lo que importa —si el proceso es mejor, si el cliente lo nota, si la gente entiende lo que se genera— no sale en ningún panel.
Si te reconoces en tres de las cinco, no estás solo: es el patrón que describo en la última milla de la adopción de IA, y tiene arreglo. Empieza por volver a la columna que te corresponde.
Estrategia y casos de uso: que el problema tire
Esta fila decide todas las demás. Si la estrategia es "usar IA", cualquier cosa vale y nada se puede evaluar. Si la estrategia es "reducir a un día el tiempo de respuesta a una oferta", la IA entra donde hace falta y se sabe si ha servido.
En Diagnóstico, el trabajo es hacer un inventario de problemas, no de herramientas: dónde se pierde tiempo, dónde se decide tarde, dónde el cliente espera. Cada problema con un dueño con nombre. Las 7 preguntas que un directivo debería hacerse sobre la IA son una buena forma de arrancar esa conversación en un comité.
En Piloto, se elige un solo problema, se le pone una métrica y una fecha en la que se decide. En Formación, quien dirige necesita entender qué puede y qué no puede hacer la IA hoy, sin marketing: el curso gratuito de Fundamentos de IA en la práctica está pensado para eso.
En Transformación, la estrategia se conecta con la ejecución: si trabajas con OKR, la IA aparece en los resultados clave que ayuda a mover, no como objetivo en sí misma (OKR + IA: objetivos que la IA ayuda a ejecutar, no a inflar). Y en Soporte, una revisión trimestral con una sola pregunta por caso: ¿sigue, cambia o se para?
Personas y organización: quién hace qué
La segunda fila es la que más se salta, y la que más se paga después. La IA ya está en tu empresa aunque no la hayas comprado: alguien la usa para resumir reuniones, otro para redactar correos, y ninguno lo dice. El Diagnóstico empieza por saber quién la usa ya y para qué, sin castigar a nadie por ello.
Para el Piloto, un equipo voluntario funciona mucho mejor que uno designado: quien quiere probar aguanta las primeras semanas de fricción; quien fue elegido, no. En Formación, dos niveles distintos: una alfabetización básica para toda la plantilla (gratuita, dos horas, qué es y qué no es), y formación rol a rol para quien la va a usar a diario: product owners, quien lidera equipos de desarrollo, dirección.
En Transformación aparecen roles que antes no existían: quién revisa lo que se genera, quién decide qué significa "bueno", quién es el dueño de cada agente. Sin eso, la deuda cognitiva entra por defecto. Y en Soporte, una comunidad interna (aunque sea un canal y una reunión al mes) y unos acuerdos de equipo que se revisan en cada retrospectiva, no que se firman una vez.
Procesos y producto: que cambie el trabajo, no solo la herramienta
Esta fila es la diferencia entre adoptar la IA y comprarla. Se puede formar a todo el mundo, tener licencias y una política, y seguir trabajando exactamente igual, solo que generando más.
En Diagnóstico, mide dónde se pierde el tiempo de verdad, no dónde se cree: casi siempre es en esperar, revisar y decidir, no en escribir. En Piloto, el objetivo es rediseñar un proceso, no acelerar el actual; si el resultado del piloto es "hacemos lo mismo en menos tiempo", el cuello de botella solo se ha movido.
En Formación, los equipos que construyen necesitan tres cosas concretas: criterios de aceptación ejecutables (evals), una Definición de Done que diga qué cambia cuando la IA escribe, y criterio para decidir qué entra y qué se descarta.
En Transformación, el trabajo es converger: leer lo que se genera, decidir qué es bueno y tirar el resto. Y en Soporte, métricas de resultado —qué ha cambiado para el cliente y el negocio— en lugar de métricas de volumen. Mientras dirección solo vea entregas, pedirá entregas.
Tecnología y datos: el contexto antes que el modelo
La fila que más titulares se lleva y la que menos decide. La tecnología que hace falta para una empresa media ya existe y es asequible; lo escaso es el contexto: los datos limpios, las reglas del negocio escritas y el acceso a los sistemas.
En Diagnóstico: qué datos hay, dónde están, quién puede tocarlos y en qué estado. Este inventario suele ser la sorpresa del plan, y es lo que decide qué pilotos son posibles. En Piloto, la regla es probar por fuera antes de tocar nada: un agente conectado por API a tus sistemas actuales es barato, rápido y te dice hasta dónde llegas sin cambiar de plataforma.
Cuándo un agente aporta valor y cuándo no lo cuento en este artículo, y qué es un agente por dentro, en Anatomía de un agente de IA.
En Formación, quien construye necesita ingeniería de contexto: el contexto es la mayor parte del resultado, y hay una guía gratuita para empezar. En Transformación, y solo si el piloto por fuera ha topado con el techo del sistema actual, se plantea un sistema de registro con IA: es una decisión de negocio, no de tecnología.
Y en Soporte, lo que hace falta para que un agente no se rompa sin que nadie lo toque: observabilidad, coste por ejecución y evals en el pipeline (la dinámica de los agentes de IA).
Gobierno y riesgo: quién responde de qué
La fila que a una empresa media le parece "de grandes" y que es la que la protege. No hace falta un comité de ética. Hace falta que, cuando algo salga mal, haya una respuesta a "quién responde de esto" que no sea "lo generó la IA".
En Diagnóstico, un mapa de riesgos y de partes interesadas de una página: qué puede salir mal, a quién afecta, quién tiene que estar en la mesa. Es el paso que, en el caso real que cuento en la última milla, hizo que un piloto parado volviera a arrancar con un alcance sensato.
En Piloto, una política de uso de una página, antes de empezar: qué puede generar la IA sin revisión, qué exige lectura, qué no se automatiza. En Formación, saber qué exige el AI Act según tu caso concreto; la lista de comprobación te sitúa en diez minutos, y cómo lo preparamos en nuestra propia web es el ejemplo pequeño y real.
En Transformación, cada decisión automatizada tiene un responsable con nombre. Y en Soporte, un registro de incidentes y una revisión periódica de qué permisos tiene cada agente.
Si quieres apoyarte en marcos reconocidos en lugar de inventar el tuyo, tres referencias que no venden nada: el marco de gestión de riesgos de IA del NIST, la norma ISO/IEC 42001 de sistemas de gestión de IA, y la página oficial del AI Act de la Comisión Europea. El curso de Gobernanza de IA traduce todo eso a un sistema que no frene.
Cómo usar la tabla en una sesión de dirección
La tabla no sirve para leerla: sirve para rellenarla en una sala. Noventa minutos, con dirección, tecnología y la persona que mejor conoce la operación.
| Paso | Qué se hace | Qué sale |
|---|---|---|
| 1. Situarse (15 min) | Cada persona contesta las cuatro preguntas del principio por escrito, sin hablar. Se comparan. | La columna real en la que está la empresa, y el desacuerdo, que es lo más útil. |
| 2. Rellenar la columna actual (30 min) | Solo esa columna, las cinco filas. Para cada casilla: ¿podemos responder a la pregunta? ¿Quién lo sabe? | Las dos o tres casillas vacías que explican por qué la adopción no avanza. |
| 3. Elegir un problema (20 min) | Del inventario de estrategia, uno solo. Con dueño, métrica y fecha de decisión. | El piloto siguiente, o el actual redefinido para que tenga las tres cosas. |
| 4. Repartir las cinco filas (15 min) | Una persona por dimensión, con nombre. No un comité: cinco dueños. | Quién trae qué a la siguiente revisión. |
| 5. Fijar la revisión (10 min) | Fecha del siguiente repaso de la tabla, en el calendario, antes de salir. | La cadencia que evita que el plan sea un documento. |
Dos avisos. El primero: la tentación en el paso 3 es elegir tres problemas "porque son urgentes". Uno. Los otros dos entran cuando el primero tenga su decisión. El segundo: el paso 4 es el que se salta, y sin él la tabla vuelve a ser un documento en una carpeta. Cinco nombres, no un equipo.
Preguntas frecuentes
¿Por dónde empieza una empresa media a adoptar la IA?
Por el diagnóstico, no por las licencias: un inventario de problemas del negocio con dueño, una foto de qué datos hay y quién puede tocarlos, y saber quién usa ya la IA por su cuenta. Con eso se elige un solo piloto con métrica y fecha de decisión. Comprar herramientas antes de tener esa lista es la forma más habitual de gastar sin resultado.
¿Cuánto dura un piloto de IA y cuándo se considera terminado?
Entre seis y doce semanas, y termina en una fecha fijada de antemano con una decisión: sigue, cambia o se para. Lo que lo define no es la duración sino que tenga dueño, métrica y fecha. Un piloto que lleva meses "en marcha" sin decisión no es un piloto: es un proyecto sin dueño.
¿Qué formación en IA necesita una empresa que no es tecnológica?
Dos niveles. Una alfabetización básica para toda la plantilla (qué es, qué no es, qué se puede delegar y qué revisar), y formación rol a rol para quien la usa a diario: product owners, quien lidera equipos, dirección. Formar en herramientas concretas sin formar en criterio produce gente que sabe escribir un prompt y no sabe cuándo el resultado no sirve.
¿Hace falta un comité de ética o de gobierno de IA en una pyme?
No hace falta un comité. Hace falta una política de uso de una página que el equipo haya discutido (qué genera la IA sin revisión, qué exige lectura, qué no se automatiza), un responsable con nombre para cada decisión automatizada y un registro de incidentes. El AI Act añade obligaciones concretas según el caso de uso, y hay listas de comprobación para saber cuáles aplican.
¿Es mejor comprar una herramienta con IA o construir algo propio?
Primero probar por fuera: un agente conectado por API a los sistemas actuales dice hasta dónde se llega sin cambiar nada, y en muchos casos es suficiente. Solo si ese piloto topa con el techo del sistema (no puede escribir con permisos finos, no accede al histórico, no se puede extender) tiene sentido plantear un sistema propio o una migración, y esa es una decisión de negocio, no de tecnología.
¿Cómo se mide si la adopción de IA está funcionando?
Con métricas de resultado, no de actividad: qué ha cambiado para el cliente o el negocio en el proceso donde se ha metido la IA (tiempo de respuesta, errores, decisiones tomadas antes), y si la gente entiende lo que se genera. Licencias activas, tokens consumidos o "casos de uso lanzados" miden que se usa, no que sirve.
Por dónde seguir
Si quieres una foto de en qué columna está tu organización antes de la sesión, el diagnóstico organizativo de IA tarda media hora y sale con las dimensiones ya separadas. Si el problema es justificar la formación ante dirección, la calculadora de retorno de la formación da un número que se puede discutir.
Y si prefieres que la sesión de noventa minutos la facilite alguien de fuera, es exactamente lo que hacemos en formación y acompañamiento para empresas.
Recursos relacionados
- La última milla de la adopción de IA
- Política de uso de IA para tu empresa (plantilla)
- 7 preguntas que un directivo debería hacerse sobre la IA
- Acuerdos de equipo para usar IA
- Del sistema que guarda al sistema que hace
- IA sin gobernanza es un riesgo: cómo Scrum y OKR amplifican (y protegen) tu IA
- Estudio: cómo usan la IA los equipos de producto