Operar un programa de AI Literacy
En un artículo anterior compartí tres ideas sobre lo que entiendo por AI Literacy. Que el contenido importa menos que el criterio. Que el formato importa tanto como el contenido. Que la formación no termina nunca.
Eso describía el qué. No el cómo.
Las preguntas operativas por privado surgieron pronto cuando publiqué su versión previa en LinkedIn hace meses. Personas con responsabilidad real, normalmente en transformación digital, riesgo o compliance, preguntando lo mismo con palabras distintas: vale, te creo. ¿Y ahora cómo lo hago?
Esta es la respuesta que no doy en una sesión formal, porque es larga y porque parte de ella solo tiene sentido cuando ya llevas un año dentro.
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 governance.
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.