El patrón se repite en empresas de distinto tamaño: en el mes 1 hay euforia (licencias, kickoff, demos), en el mes 2 hay uso irregular, y en el mes 3 el rollout de IA “sigue vivo” solo en el slide de transformación. No es que la tecnología haya fallado: falló la adopción. Este artículo explica por qué se enfrían los rollouts y, sobre todo, qué capacitar primero para que el uso no dependa de dos early adopters.

Si estás en la etapa de presupuesto y herramientas, también te sirve mirar cuánto cuesta implementar IA en una empresa y la guía de cómo implementar IA en empresas y equipos. Acá nos enfocamos en el hueco que más duele: skills + ownership.

El mes 3 no es un misterio: es predicción

Al inicio, la novedad sostiene el uso. Después aparecen fricciones normales: no hay tiempo protegido, nadie sabe qué está “bien” como output, IT/seguridad pone límites tardíos, y el manager no incorpora la IA al estándar del equipo. Sin un plan de capacitación por rol, la herramienta queda como juguete opcional.

Un rollout sin capability building es solo procurement. Comprás acceso; no comprás cambio de trabajo. Por eso empresas muy distintas terminan contando la misma historia: “lo probamos, no pegó”.

Cinco razones frecuentes del enfriamiento

1) Empezaron por la tool, no por el proceso

“Les dimos Copilot / Gemini / ChatGPT” no es una estrategia. Sin un proceso piloto (reporte semanal, atención, content ops, análisis comercial), cada persona improvisá prompts sueltos y no hay aprendizaje colectivo. El conocimiento queda atrapado en chats privados.

2) Capacitación genérica sin anclaje al puesto

Un webinar de “intro a la IA” ayuda a bajar miedo, pero no cambia el día a día. Hace falta literacy más práctica situada: ejemplos del área, criterios de calidad, y un entregable del trabajo real. Sin eso, la gente vuelve a lo conocido apenas aparece presión de deadlines.

3) No hay ownership claro

Si People compra, IT habilita y el área “usa si quiere”, el rollout no tiene dueño. Alguien tiene que ser accountable del outcome del piloto (suele ser el líder de área + un sponsor ejecutivo liviano). Sin nombre y apellido, no hay seguimiento.

4) Políticas y datos llegan tarde

A las pocas semanas aparecen dudas: ¿qué datos puedo pegar? ¿qué revisa un humano? ¿qué queda registrado? Si la gobernanza llega como freno y no como enablement, la gente vuelve al Excel de siempre. Mejor una página clara temprano que un mail restrictivo tarde.

5) Se mide vanidad, no transferencia

Contar seats o logins no dice si mejoró un proceso. Sin evidencia de uso aplicado, direction corta el presupuesto o lo congela “hasta más adelante”. Medí entregables y observación de managers, no solo dashboards de vendor.

Qué capacitar primero (orden que suele funcionar)

No arranques por “prompt engineering avanzado para todos”. Priorizá en este orden:

1. AI literacy mínima compartida — qué es un modelo, límites, alucinaciones, privacidad básica. Objetivo: mismo vocabulario.

2. Uso seguro y criterios de calidad por área — qué se puede / no se puede cargar; cómo revisar outputs; cuándo escalar a humano.

3. Práctica en un proceso piloto — un workflow con dueño, ejemplos buenos/malos, y un entregable semanal.

4. Automatización liviana (después) — cuando ya hay criterio humano, recién tiene sentido conectar flujos (por ejemplo con enfoques de AI Automation) sin multiplicar errores.

5. Agentes / casos avanzados — solo cuando hay ownership, datos y monitoreo. Antes es teatro.

Por rol: no capacites igual al manager y al operador

• Managers: diseñar el estándar del equipo, revisar calidad, proteger tiempo, reportar evidencia.

• ICs / operadores: ejecutar el flujo, documentar prompts útiles, detectar fallas.

• People: orquestar el journey, medir transferencia, cuidar cambio cultural.

• IT / seguridad: enablement (accesos, entornos, políticas claras), no solo veto.

Si capacitás a todos con el mismo deck, el manager no sabe qué exigir y el operador no sabe qué estándar cumplir. Ahí empieza el mes 3.

Diseño anti-mes-3: un piloto de 6–8 semanas

1. Elegí un proceso con dolor visible y datos accesibles.

2. Definí outcome en una frase (comportamiento o entregable).

3. Formá al equipo del piloto (literacy + práctica), no a toda la compañía.

4. Publicá un playbook corto interno (pasos, ejemplos, límites).

5. Revisá con el sponsor a las 3–4 semanas: ¿hay transferencia o solo curiosidad?

6. Recién ahí escalá a otro equipo o sumá automatización.

Este ritmo evita el clásico “big bang de licencias” que se apaga solo. También te da una narrativa sana para direction: aprendemos en chico, medimos, después escalamos.

Señales tempranas de que vas bien (cualitativas)

• Los managers piden el entregable del flujo en la reunión de equipo.

• Aparece un repositorio compartido de ejemplos (no solo prompts sueltos en chats).

• IT recibe preguntas de enablement (“cómo hago X con seguridad”) más que pedidos de bloqueo reactivo.

• People puede mostrar evidencia de transferencia sin inventar métricas.

Qué mirar si tu rollout ya está flojo

• ¿Hay un dueño de proceso con nombre y apellido?

• ¿Existe un playbook o solo chats sueltos?

• ¿Los managers piden el uso en el trabajo, o es opt-in eterno?

• ¿La política de datos está escrita en una página o vive en el folklore?

• ¿Qué evidencia de transferencia podrías mostrar mañana sin inventar métricas?

Si tres o más respuestas son “no”, no necesitás más seats: necesitás capacitación con anclaje y governance liviana.

Qué no capacitar primero (aunque suene innovador)

• Agentes autónomos para toda la compañía sin playbook humano.

• “Prompt engineering avanzado” antes de criterios de calidad y privacidad.

• Fine-tuning o desarrollos caros cuando todavía no hay uso básico sostenido.

• Certificaciones masivas sin un proceso piloto que las ancle.

Estas apuestas suelen verse bien en un roadmap, pero aceleran el enfriamiento: suben la complejidad antes de que exista hábito. Primero literacy y proceso; después sofisticación.

Cómo hablarle a dirección sin inventar métricas

En vez de prometer un retorno mágico, pedí un piloto con outcome en una frase, evidencias de transferencia (entregables más observación de managers) y un criterio de seguir o no a las seis u ocho semanas. Si el piloto no muestra uso aplicado, no escalás asientos: ajustás capacitación y ownership. Esa narrativa es más creíble que un dashboard de logins.

También ayuda separar presupuesto de licencias y presupuesto de capability. Si solo financiás la herramienta, el mes tres está casi escrito. Si financiás formación anclada al proceso, el rollout tiene chance de sobrevivir a la novedad inicial.

Rol del sponsor en las primeras ocho semanas

El sponsor no necesita facilitar talleres. Necesita pedir el outcome en las reuniones, proteger tiempo de práctica y remover blockers de acceso a datos o herramientas. Sin esa presión positiva, el piloto se convierte en hobby de early adopters y el resto del equipo espera a que baje la espuma de la novedad. Un buen sponsor también ayuda a People a narrar evidencia sin inventar métricas: qué se vio, qué falta validar, qué se escala.

FAQ

¿Conviene pausar las licencias?

No necesariamente. Conviene pausar la expansión y concentrar uso + formación en el piloto. Ampliar seats sin capability multiplica el problema.

¿Un curso introductorio alcanza?

Alcanza para literacy. No alcanza para adopción. Combiná base (por ejemplo un recorrido de introducción a la inteligencia artificial) con práctica en el proceso del área.

¿Cuánto tarda en “prender”?

Con sponsorship y tiempo protegido, suele verse uso sostenido en semanas. Sin eso, el mes 3 se siente igual en cualquier industria.

Si tu empresa ya compró herramientas y el uso se está enfriando, pedí una llamada sin costo con Coderhouse Empresas: armamos juntos qué capacitar primero y cómo recuperar el rollout con un piloto medible.