Formar en IA por roles, no con un curso para todos

Nota de actualización. Este artículo describe el Reglamento (UE) 2024/1689 según el texto vigente en noviembre de 2025. Las obligaciones de alfabetización en IA pueden haber cambiado desde entonces. Antes de aplicarlas en tu organización, consulta la versión consolidada en EUR-Lex y valídala con tu área Legal o de Cumplimiento.

Cuando una organización decide formar a su gente en IA, la respuesta habitual es un curso en línea para todo el personal: una hora de conceptos generales, algunos ejemplos de uso y un cuestionario al final. Es fácil de lanzar y fácil de reportar. También es insuficiente. La persona de dirección que aprueba un caso de uso, el analista que usa un asistente para redactar informes y el ingeniero que integra un modelo en un proceso crítico no necesitan saber lo mismo, ni con la misma profundidad.

Este artículo propone un programa de formación diferenciado por roles: qué necesita saber cada grupo, con qué profundidad, en qué formato y cómo comprobar que lo aprendió. El objetivo no es formar más, sino formar mejor a cada perfil.

Por qué un curso único no funciona

Un curso pensado para todos termina en el mínimo común. Para quien nunca usó una herramienta de IA puede ser útil; para quien desarrolla con modelos todos los días es tiempo perdido. Y, lo más importante, deja huecos en los perfiles que más riesgo concentran.

Los errores más costosos con la IA rara vez vienen de no saber qué es un modelo de lenguaje. Vienen de decisiones concretas tomadas sin el criterio adecuado: un usuario que pega datos de clientes en una herramienta no autorizada, un equipo de desarrollo que no evalúa el sistema antes de publicarlo, un área de riesgo que no sabe qué preguntar en la revisión, una dirección que aprueba un caso de uso sin entender sus límites. Cada uno de esos errores pide una formación distinta.

Hay además un problema de credibilidad. Un curso genérico que se completa con un clic produce un indicador de cumplimiento (porcentaje de personal formado) que dice poco sobre la capacidad real de la organización. Si un auditor o un regulador pregunta cómo te aseguras de que tu personal entiende los riesgos de los sistemas de IA que usa, ese porcentaje no alcanza como respuesta.

La alfabetización en IA ya es una obligación

En la Unión Europea, el Reglamento (UE) 2024/1689 de inteligencia artificial incluye en su artículo 4 una obligación de alfabetización en materia de IA. Los proveedores y los responsables del despliegue de sistemas de IA deben adoptar medidas para que su personal, y las demás personas que operan o usan esos sistemas en su nombre, tengan un nivel suficiente de alfabetización en IA. El propio artículo pide tener en cuenta sus conocimientos técnicos, su experiencia, su educación y formación, el contexto en que se usarán los sistemas y las personas sobre las que se usarán. Esta disposición forma parte del capítulo I del Reglamento, que se aplica desde el 2 de febrero de 2025.

Dos puntos de esa redacción son relevantes para el diseño del programa. Primero, el nivel "suficiente" se mide en relación con el contexto: no es el mismo para todos. Segundo, la obligación alcanza a quienes usan los sistemas, no solo a quienes los construyen. Un programa por roles es la forma natural de responder a ambos.

Para organizaciones en España, la obligación aplica directamente si son proveedoras o responsables del despliegue de sistemas de IA. Para organizaciones en Latinoamérica, puede aplicar si operan en el mercado europeo, y en todo caso es una referencia útil mientras cada país define su propio marco. Si te afecta y en qué medida es una pregunta para tu área legal.

Los marcos de gestión apuntan en la misma dirección. ISO/IEC 42001 exige que la organización determine la competencia necesaria de las personas que trabajan en el sistema de gestión de la IA y que esas personas tomen conciencia de la política de IA y de su propio papel. El NIST AI Risk Management Framework, dentro de su función Gobernar, incluye que el personal y los socios reciban formación en gestión de riesgos de la IA acorde con sus funciones. Si ya trabajas con ISO/IEC 42001, el programa de formación por roles es parte de la evidencia que vas a necesitar; lo tratamos en ISO/IEC 42001 en la práctica.

Cinco perfiles, cinco necesidades

Proponemos cinco grupos. Cada organización puede ajustar los límites, pero conviene no tener muchos más: un programa con quince variantes es difícil de mantener.

La tabla siguiente resume qué necesita cada perfil. Las duraciones son ilustrativas y dependen del punto de partida de cada organización.

Rol	Qué necesita saber	Formato sugerido	Cómo medirlo
Dirección	Qué puede y qué no puede hacer la IA, riesgos principales, obligaciones regulatorias, cómo se aprueba y se supervisa un caso de uso	Sesiones breves con casos de decisión, por ejemplo dos horas por trimestre	Calidad de las decisiones: casos aprobados con riesgos y métricas documentados
Usuarios de negocio	Herramientas autorizadas, qué datos se pueden usar y cuáles no, cómo verificar un resultado, cuándo escalar	Módulo corto y práctico con ejercicios en las herramientas reales de su trabajo	Ejercicios prácticos aprobados, incidentes de uso indebido, consultas al canal de soporte
TI y operación	Cómo se despliegan y monitorean los sistemas de IA, permisos, registros, respuesta a incidentes con IA	Talleres técnicos y ejercicios sobre procedimientos operativos	Simulacros de incidentes, runbooks actualizados, tiempos de respuesta
Desarrollo y datos	Diseño, evaluación y pruebas de sistemas de IA, calidad de datos, seguridad de aplicaciones con modelos, documentación	Formación técnica profunda, laboratorios y revisión entre pares	Revisiones de código y de evaluación, hallazgos de seguridad, calidad de la documentación
Riesgo, seguridad y cumplimiento	Marcos de referencia, riesgos específicos de la IA, cómo revisar y auditar un sistema, qué evidencia pedir	Formación especializada y participación en revisiones reales acompañadas	Calidad de las revisiones, hallazgos relevantes, criterios documentados

Algunas precisiones sobre cada grupo:

• Dirección no necesita entender cómo funciona un modelo por dentro, pero sí saber qué preguntas hacer antes de aprobar una inversión y qué responsabilidad asume la organización al desplegar un sistema.
• Usuarios de negocio son el grupo más numeroso y el que más riesgo cotidiano concentra. Su formación debe ser concreta: qué herramienta, para qué, con qué datos. Los principios generales sin aplicación se olvidan rápido.
• TI y operación necesitan tratar los sistemas de IA como cualquier otro servicio en producción, con sus particularidades: comportamiento no determinista, dependencia de datos y permisos que pueden ampliar lo que un agente es capaz de hacer. Las barreras de seguridad para agentes de IA son un buen contenido para este grupo.
• Desarrollo y datos es el grupo que necesita más profundidad. Además de la parte técnica, debe dominar la preparación de datos; los criterios de datos listos para IA son un punto de partida.
• Riesgo, seguridad y cumplimiento necesitan suficiente conocimiento técnico para no depender por completo de lo que les cuente el equipo que construye. Lo desarrollamos en el CISO frente a la IA.

Formato: menos aula, más práctica

El formato importa tanto como el contenido. Algunos criterios que recomendamos:

• Usa las herramientas reales. Un ejercicio sobre el asistente que la organización autorizó enseña más que una demostración sobre una herramienta genérica.
• Trabaja con casos propios. Los ejemplos deben salir de los procesos de la organización, con datos ficticios, no de casos de otros sectores.
• Divide en piezas cortas. Varias sesiones breves y espaciadas funcionan mejor que una jornada completa una vez al año.
• Actualiza con frecuencia. Las herramientas y los riesgos cambian rápido. Un contenido que no se revisa en un año probablemente esté desactualizado.
• Forma referentes. En cada área, una o dos personas con formación más profunda pueden resolver dudas del día a día y detectar usos que conviene escalar.

Cómo medir que funcionó

El porcentaje de personas que completó el curso es un indicador de actividad, no de resultado. Sirve para demostrar cobertura, pero no capacidad. Recomendamos combinarlo con tres tipos de medida:

1. Evaluación práctica. En lugar de un cuestionario de opción múltiple, un ejercicio en el que la persona tiene que hacer algo: verificar un resultado, decidir si un dato se puede usar, revisar un caso de uso.
2. Indicadores operativos. Datos que ya existen en la organización y que la formación debería mover: incidentes de uso indebido de herramientas de IA, calidad de las solicitudes de nuevos casos de uso, hallazgos en revisiones de seguridad.
3. Revisión periódica. Una vez al año, como mínimo, revisar el programa con las áreas de Riesgo y Cumplimiento: qué cambió en las herramientas, en los riesgos y en la regulación, y qué contenidos hay que actualizar.

Conviene guardar la evidencia de forma ordenada: quién recibió qué formación, cuándo, con qué contenido y con qué resultado. Esa evidencia sirve para una auditoría de ISO/IEC 42001 y para demostrar, si te lo piden, cómo cumples con la obligación de alfabetización.

Por dónde empezar

Un plan razonable para lanzar el programa sigue estos pasos:

1. Inventariar los sistemas y herramientas de IA en uso y quién los usa.
2. Asignar a cada persona un rol de formación según su relación con esos sistemas.
3. Empezar por los grupos de más riesgo: usuarios de negocio con acceso a herramientas generativas y equipos que construyen sistemas.
4. Definir el contenido mínimo y la forma de evaluación de cada rol antes de producir materiales.
5. Registrar la evidencia y revisar el programa con Riesgo y Cumplimiento al menos una vez al año.

La formación por roles cuesta algo más de diseñar que un curso único, pero produce lo que el curso único no consigue: personas que toman mejores decisiones con la IA en su trabajo concreto. Antes de dar por cerrada la interpretación de las obligaciones regulatorias que te aplican, valídala con Legal y Cumplimiento, y coordina el programa con Recursos Humanos.