Cómo se monta un programa de AI Literacy en una empresa, y cómo se sostiene
Un programa de AI Literacy que funciona en una empresa tiene cuatro rasgos operativos: espacios distintos para cada audiencia que decide sobre los mismos sistemas, una cadencia continua hecha sobre todo de conversaciones cortas, un mecanismo que convierte las dudas repetidas en material, y ningún catálogo de cursos que enseñar. Es también la forma más sólida de responder al artículo 4 del Reglamento (UE) 2024/1689, que desde el Reglamento (UE) 2026/1744 pide adoptar medidas para apoyar la alfabetización del personal teniendo en cuenta sus conocimientos, el contexto de uso y las personas sobre las que se usan los sistemas: las cuatro piezas son medidas de ese tipo.
Por qué un curso no basta lo explico en lo que pide el artículo 4 y lo que un curso no demuestra. Aquí va el cómo, que es lo que me preguntaron por privado cuando publiqué la primera versión de esa idea.
Formato modular por audiencia
Un programa vivo no es un curso multiplicado por veinte personas. Es un conjunto de espacios pensados para audiencias con responsabilidades distintas sobre los mismos sistemas.
Un comité de dirección no necesita el mismo material que un equipo de delivery. No porque uno sea más sofisticado que otro. Porque las decisiones que tienen que tomar son distintas, y el criterio que necesitan construir no es el mismo.
El comité necesita criterio para distinguir cuándo un caso de uso de IA es estratégico y cuándo es ruido del momento. El equipo de delivery necesita criterio para parar un despliegue cuando algo no encaja, sin esperar a que un comité valide su intuición. Negocio necesita criterio para formular el caso sin ocultar consecuencias incómodas. Legal necesita criterio para identificar qué obligaciones aplican antes de que el sistema esté en producción, no después.
Cuatro perfiles, cuatro programas distintos que comparten un mismo eje conceptual. Ejemplos distintos, ritmo distinto, ejercicios distintos.
Esto incrementa el trabajo de diseño. Es lo que cuesta tomarse en serio la palabra literacy.
Cadencia continua
Un curso ocurre una vez. Un programa vivo ocurre todas las semanas.
No siempre como sesión formal. La mayoría de las veces como conversación corta: alguien tiene un caso real esta semana, levanta la mano, lo discutimos en treinta minutos antes de que el caso avance a la siguiente fase. Esa conversación es formación. También es gobierno.
La frontera entre las dos cosas se vuelve borrosa con el tiempo. Es una buena señal.
La cadencia de sesiones más largas tiene su lugar: onboarding de equipos nuevos, repaso de regulación cuando cambia algo material, paradas para mirar de nuevo cuando el contexto del sector se ha desplazado lo suficiente. Son la minoría de las horas.
La mayoría del trabajo ocurre en bloques de quince o treinta minutos, en respuesta a preguntas reales, en ventanas que no estaban en ningún calendario.
Mecanismo de captura
Las preguntas que llegan no son ruido a procesar. Son el input más valioso del sistema.
Cuando alguien pregunta “¿esto que estoy haciendo entra en el AI Act?”, lo que está revelando no es su nivel de conocimiento. Está revelando un hueco en la documentación. Una ambigüedad en el criterio que dimos por cerrado. Un caso que el framework actual no tiene en cuenta. Esa pregunta es un defecto del sistema, en el sentido Six Sigma del término. Y como tal, vale más que cualquier indicador agregado.
Tengo un registro abierto desde 2023 donde incluyo las preguntas que se repiten. No las personas. Las preguntas. Cuando una se repite tres veces, se convierte en material formativo. Cuando se repite cinco, se convierte en una pieza interna que hay que reescribir.
Ese mecanismo es el motor del programa vivo. Sin él, lo que tienes es un curso que dura más tiempo del que debería.
Ausencia de catálogo
Un programa de AI Literacy bien operado no aparece en ningún sitio. No tiene página de inscripción. No emite certificados. No genera un informe trimestral que se pueda llevar al consejo con una métrica creciente y un gráfico bonito.
Lo que produce son decisiones distintas. Y las decisiones distintas no se ven en un dashboard.
Se ven cuando un equipo decide no desplegar un sistema que técnicamente estaba listo, porque alguien hizo la pregunta correcta en una sesión informal de hace cuatro meses. Se ven cuando una propuesta llega al comité ya con las preguntas difíciles incorporadas, en lugar de tener que pararla allí. Se ven cuando aparece un caso de uso nuevo y la conversación empieza por las consecuencias, no por la tecnología.
Esa ausencia de visibilidad es un problema real. La organización valora lo que mide, y los programas que no se miden con métricas convencionales se vuelven invisibles para las decisiones de inversión.
Lo que estoy aprendiendo, todavía con dudas, es que la métrica útil no es cuántas sesiones, ni cuántas personas formadas, ni cuántas horas. Es cuántas decisiones cambian por una conversación que ocurrió antes. Esa métrica no es fácil de detectar. Pero es la única que cuenta lo que el programa hace.
Por qué esto no se exporta como metodología
Hay una pregunta que me hacen mucho: ¿por qué no documentas todo esto como una metodología?
La respuesta corta es que ya lo he intentado. La larga es que la mayoría del valor del programa está en su acoplamiento con el contexto. La cadencia, el registro de preguntas, los criterios de escalado, los formatos: todo eso es resultado de tres años de iteración con personas, riesgos y un modelo de negocio que no son intercambiables con otros. Extraer la metodología y reempaquetarla perdería precisamente lo que la hace funcionar.
Eso no quiere decir que no se pueda enseñar. Quiere decir que cuando alguien me pide “el modelo”, lo honesto es decir que el modelo es un proceso, no un documento. Y que la parte transferible son los principios, no la receta.
En un año más de operación, con más sesiones, con más preguntas, con más casos que retan al sistema, no es el material lo que cambia.
Lo que cambia con este volumen adicional no es lo que pienso. Es lo seguro que estoy de lo que ya pensaba.