“Necesitamos un curso de IA para toda la empresa.” Es uno de los pedidos más comunes que recibe un equipo de People, y también uno de los que más fácil se resuelve mal. El problema no es la intención, que es buena, sino el supuesto que hay detrás: que la inteligencia artificial se aprende igual sin importar el rol.

Un manager y un programador pueden usar herramientas parecidas, pero lo que necesitan aprender es muy distinto. Uno tiene que decidir dónde aplicar la IA, cómo liderar su adopción y cómo evaluar riesgos. El otro tiene que integrarla en su forma de construir software con calidad y seguridad. Ponerlos en el mismo curso suele dejar a los dos insatisfechos: el programador se aburre en la parte introductoria y el manager se pierde en la técnica.

En esta guía te mostramos qué necesita cada rol, dónde se cruzan y cómo diseñar rutas de capacitación que respeten esas diferencias sin fragmentar a la empresa.

Qué cambia con la IA en el trabajo de cada rol

Antes de hablar de contenidos, conviene mirar qué cambia en el día a día. Esa es la base de cualquier diseño por rol.

• Para un manager, la IA cambia cómo se toman decisiones, cómo se organiza el trabajo del equipo y qué se le puede pedir a cada persona. También agrega nuevas responsabilidades: definir qué está permitido, qué datos no se comparten y cómo se revisan los resultados.

• Para un programador, la IA cambia cómo se escribe, revisa y prueba el código. Los asistentes de programación aceleran tareas, pero también introducen nuevos riesgos: código que parece correcto y no lo es, dependencias inseguras o soluciones que nadie del equipo entiende del todo.

Los dos roles necesitan criterio. Pero el criterio de cada uno se aplica sobre problemas distintos.

Qué necesita aprender un manager

Un manager no necesita saber programar un modelo ni dominar cada herramienta. Necesita entender lo suficiente para tomar buenas decisiones y liderar a su equipo. Una ruta para líderes suele cubrir:

• Fundamentos sin tecnicismos: qué hace bien la IA generativa, dónde falla y por qué sus respuestas tienen que revisarse.

• Detección y priorización de casos de uso: cómo identificar tareas de su área donde la IA aporta valor y cuáles conviene dejar como están.

• Riesgos y uso responsable: datos sensibles, propiedad intelectual, sesgos y políticas internas.

• Liderar la adopción: cómo acompañar al equipo, qué pedir, cómo reconocer buenas prácticas y cómo evitar que la herramienta quede sin uso.

• Uso propio: aplicar la IA en sus propias tareas de gestión, como preparar reuniones, sintetizar información o redactar documentos.

• Medición: qué evidencia mirar para saber si la adopción está funcionando.

El formato también importa. Los líderes suelen tener poca disponibilidad, así que funcionan mejor las sesiones cortas, con casos de su industria y mucho espacio para preguntas.

Qué necesita aprender un programador

La IA para programadores es un mundo en sí mismo. Un developer ya convive con herramientas de IA, muchas veces por iniciativa propia. Lo que necesita no es una introducción, sino práctica guiada para usarlas con criterio profesional. Una ruta técnica suele incluir:

• Asistentes de código en el flujo real: cómo pedir, cómo iterar y cuándo no conviene usarlos.

• Revisión y calidad: cómo detectar errores sutiles, mantener estándares del equipo y no aceptar código que no se entiende.

• Testing con IA: generar casos de prueba, cubrir bordes y validar comportamientos.

• Seguridad: qué información no se comparte con herramientas externas, cómo evaluar dependencias sugeridas y cómo evitar vulnerabilidades comunes.

• Integración de modelos en productos: uso de APIs, diseño de prompts dentro de aplicaciones, manejo de costos y latencia.

• Automatización y agentes: cuándo tiene sentido delegar tareas en flujos automatizados y cómo supervisarlos.

Para este perfil, lo que más rinde es trabajar sobre el stack y los repositorios reales del equipo, o sobre ejercicios que se les parezcan mucho. Los ejemplos genéricos se agotan rápido.

Manager vs programador: la comparación lado a lado

Dónde se cruzan los dos caminos

Diseñar rutas por rol no significa que cada área aprenda en una isla. Hay una base común que conviene compartir:

• Políticas de uso: qué herramientas están aprobadas y qué datos no se comparten.

• Vocabulario común: para que un manager y un developer puedan conversar sobre un caso de uso sin malentendidos.

• Expectativas realistas: qué se puede esperar de la IA y qué no.

Y hay un momento donde los caminos deberían volver a juntarse: el proyecto aplicado. Cuando un manager define un caso de uso y un equipo técnico lo construye, la capacitación deja de ser teoría y se convierte en trabajo real. Ese cruce suele ser el punto donde más se nota el valor del programa.

¿Y el resto de los roles?

El ejemplo del manager y el programador es el más claro, pero la lógica aplica a toda la empresa. Marketing necesita IA para contenido, segmentación y análisis de campañas. Data necesita automatizar reportes y trabajar con modelos. Atención al cliente necesita resolver consultas con criterio y consistencia. Para los perfiles no técnicos, te puede servir este roadmap práctico de AI literacy por rol.

Cómo diseñar las rutas por rol paso a paso

1. Diagnosticá antes de diseñar. Relevá qué usa hoy cada equipo, con qué nivel y para qué. Lo explicamos en cómo diagnosticar nivel y stack antes del programa.

2. Definí una base común corta. Políticas, vocabulario y expectativas. Una o dos sesiones alcanzan.

3. Armá rutas específicas. Una para líderes, una técnica y, si hace falta, una por área funcional.

4. Diseñá un proyecto cruzado. Que líderes y equipos técnicos trabajen sobre el mismo caso de uso.

5. Medí con evidencia por rol. No le pidas lo mismo a un manager que a un developer: cada ruta tiene sus entregables.

Si la empresa ya compró herramientas y el uso no despega, este enfoque por rol también ayuda. Lo desarrollamos en cómo pasar de “les dimos la herramienta” al uso real.

Errores frecuentes al capacitar en IA por rol

• Un único curso para todos. Es más simple de gestionar, pero rinde menos en cada rol.

• Dejar afuera a los líderes. Si el manager no entiende qué aprende su equipo, no va a saber qué pedirle.

• Subestimar a los developers. Darles una introducción que ya conocen es la forma más rápida de perder su atención.

• Fragmentar sin base común. Si cada área aprende reglas distintas, aparecen inconsistencias y riesgos.

Preguntas frecuentes

¿Conviene que managers y programadores compartan alguna sesión?

Sí, la base común y el proyecto aplicado son buenos momentos para trabajar juntos. El resto del contenido rinde más por separado.

¿Qué pasa con los tech leads, que son un poco de los dos?

Suelen necesitar la ruta técnica y una parte de la ruta de liderazgo, en especial adopción, riesgos y medición. Son perfiles clave para que el programa funcione.

¿Cuántas rutas por rol son razonables?

Depende del tamaño y la diversidad del equipo. Para arrancar, dos o tres rutas bien diseñadas suelen ser suficientes. Después se puede sumar especificidad.

Diseñá una capacitación en IA que respete cada rol

Un curso de IA para toda la empresa es un buen punto de partida, pero rara vez alcanza. Si querés armar rutas por rol para tus líderes, tus equipos técnicos y el resto de las áreas, agendá una asesoría gratuita con el equipo de Coderhouse Empresas y lo diseñamos juntos.