La alfabetización en IA ya no es un cursillo: Bruselas la convierte en control operativo, trazable y con dientes

La obligación ya está aquí, pero el mercado sigue leyéndola como si fuera una nota al pie. El artículo 4 del AI Act no pide que una empresa “forme algo” sobre inteligencia artificial y se dé por satisfecha. Pide bastante más: que proveedores y deployers de sistemas de IA adopten medidas para garantizar, en la medida de lo posible, un nivel suficiente de alfabetización en IA entre su personal y otras personas que operen o utilicen sistemas de IA por su cuenta. La frase parece inocua. No lo es.

La confusión ha venido por dos sitios. Primero, porque muchas organizaciones han tratado la AI literacy como un apéndice de formación generalista, casi una pieza cosmética para decorar el programa de compliance. Segundo, porque han circulado lecturas sobre supuestas reformas posteriores y “reencuadramientos” normativos que no pueden sostenerse con base verificable aquí. Si uno vuelve al texto conocido del AI Act, el punto sólido sigue siendo el mismo: el artículo 4 mantiene la exigencia de un nivel suficiente de alfabetización en IA. Ni menos, ni mágicamente evaporado.

Ese detalle importa porque cambia la conversación operativa. Ya no basta con preguntar si existe una política. La pregunta útil es otra: ¿puedes demostrar que las personas que seleccionan, parametrizan, supervisan, validan o usan un sistema de IA entienden sus límites, sus riesgos previsibles y su impacto sobre derechos, seguridad o decisiones de negocio? Si la respuesta es un PowerPoint de 45 minutos para toda la plantilla, vas justo. Muy justo.

Qué dice de verdad el artículo 4, sin adornos ni mitología regulatoria

El anclaje jurídico conocido es claro. El artículo 4 del AI Act obliga a proveedores y deployers de sistemas de IA a adoptar medidas para garantizar, en la medida de lo posible, un nivel suficiente de alfabetización en IA de su personal y de otras personas que se ocupen del funcionamiento y uso de sistemas de IA por cuenta de la organización. El propio artículo vincula esa obligación al contexto de uso, a los conocimientos técnicos, a la experiencia, a la educación y formación de esas personas y al contexto en el que se utilizarán los sistemas, así como a las personas o grupos sobre los que vayan a utilizarse.

Ese último inciso suele pasar desapercibido y, sin embargo, es el corazón del precepto. La obligación no se mide en abstracto. Se mide contra el riesgo y contra la función real de cada persona. Quien supervisa un sistema usado en recursos humanos no necesita la misma formación que quien compra una herramienta generativa para redactar textos de marketing. Y quien ajusta parámetros o valida salidas en un entorno sanitario o financiero, desde luego, no está en la misma liga que quien solo consume resultados auxiliares con riesgo limitado.

También conviene despejar dos errores frecuentes. El primero: no, el artículo 4 no se satisface necesariamente con formación técnica avanzada. “Alfabetización” no equivale a convertir a toda la plantilla en ingenieros de machine learning. El segundo: tampoco permite el teatro corporativo de siempre, esa liturgia de “sensibilización” que sirve para marcar una casilla pero no cambia conductas. El texto exige suficiencia respecto del rol y del contexto. Esa palabra, suficiente, es precisamente la que obliga a diseñar medidas proporcionales y defendibles.

Por qué el debate sobre “quién debe saber qué” es más incómodo de lo que parece

La discusión realmente complicada no es si hay que formar. Eso ya lo zanjó el legislador. La fricción está en delimitar a quién alcanza la obligación y con qué profundidad. El artículo 4 habla del personal y de otras personas que operen y utilicen sistemas de IA por cuenta de la organización. Esa redacción abre la puerta a una lectura funcional, no puramente laboral. Traducido: el perímetro relevante no se agota en la plantilla con contrato indefinido y correo corporativo.

¿Incluye esto a contratistas o prestadores de servicios? En muchos escenarios, la respuesta prudente es sí, al menos cuando actúan por cuenta de la entidad y tienen intervención real en la operación o uso del sistema. No hace falta inventar glosas exóticas para llegar ahí; basta con leer el artículo 4 con lógica operativa. Si una organización depende de terceros para configurar, operar, supervisar o explotar un sistema de IA en su nombre, dejarles fuera del programa de alfabetización convierte la obligación en papel mojado.

Donde conviene pisar el freno es en afirmaciones más expansivas que no pueden verificarse con seguridad, por ejemplo la inclusión automática de “clientes” como categoría expresamente citada por la Comisión o la idea de que tal inclusión vendría respaldada por referencias normativas concretas que aquí no encajan con el texto conocido. Puede haber supuestos en los que usuarios externos reciban información o instrucciones relevantes para un uso seguro y adecuado del sistema, pero eso no autoriza a presentar como doctrina cerrada algo que, en este contexto, no está sólidamente anclado. En regulación, la imaginación es cara.

La lectura más robusta, por tanto, es esta: la empresa debe identificar a todas las personas cuya intervención material influye en el funcionamiento, uso, supervisión o comprensión operativa del sistema dentro de su cadena de responsabilidad. A partir de ahí, asignarles un nivel de alfabetización acorde con el riesgo del caso de uso. Esa aproximación es jurídicamente defendible y, de paso, bastante más útil que discutir si alguien “encaja” en una etiqueta.

No es formación genérica. Es control operativo con nombre feo

Muchas empresas siguen tratando la AI literacy como si fuera una obligación blanda, casi cultural. Un primo simpático de la ética digital. Es un error. Leída en combinación con otras obligaciones del AI Act, la alfabetización en IA funciona como un control operativo previo para que el resto del edificio no se venga abajo.

Piensa en los sistemas de alto riesgo. El reglamento exige gobernanza documental, gestión de riesgos, calidad de datos en determinados supuestos, supervisión humana, instrucciones de uso y, para deployers, deberes específicos según el tipo de sistema y el contexto. Ese armazón depende de que las personas entiendan qué están manejando. La supervisión humana, por ejemplo, no vale mucho si quien la ejerce no sabe detectar alucinaciones, sesgos, degradación de rendimiento o salidas manifiestamente incoherentes. Tener un humano “en el bucle” que no comprende el sistema es una solución muy europea en el peor sentido: burocráticamente impecable, materialmente inútil.

Por eso el artículo 4 conecta de forma directa con la eficacia de otros mandatos. No es una isla. Si el proveedor debe diseñar el sistema de forma que pueda ser supervisado eficazmente, y si el deployer tiene que usarlo conforme a las instrucciones y con supervisión adecuada cuando proceda, alguien tendrá que entender tanto las capacidades como las limitaciones del sistema. Sin esa base, el cumplimiento posterior se convierte en una ceremonia de documentos.

La analogía más cercana en compliance no está en los cursos de conducta, sino en los controles de seguridad y resiliencia que exigen competencia demostrable. NIS2, en su artículo 21, obliga a adoptar medidas técnicas, operativas y organizativas apropiadas para gestionar riesgos de ciberseguridad. DORA, por su parte, obliga a las entidades financieras a disponer de marcos internos de gestión del riesgo TIC y de capacidades acordes con sus funciones críticas. En ambos casos, nadie serio sostendría que la obligación queda resuelta con un módulo e-learning indiferenciado para todo el mundo. Con AI literacy ocurre lo mismo, aunque algunas organizaciones aún no se hayan enterado.

El problema práctico: “nivel suficiente” suena flexible hasta que tienes que probarlo

A los juristas les gustan las normas abiertas cuando les dejan espacio para interpretar. A los equipos de cumplimiento les gustan bastante menos cuando deben demostrar, con evidencias, que la interpretación elegida era razonable. “Sufficient level of AI literacy” es una de esas expresiones. Tiene elasticidad, sí. Pero no es una invitación al minimalismo creativo.

La clave está en la trazabilidad. Si mañana un supervisor, un auditor interno o el consejo pregunta por qué la organización considera suficiente la alfabetización de determinado colectivo, la respuesta no puede ser “porque hicieron el curso”. Tiene que existir una lógica documentada que una cuatro elementos: el caso de uso, el riesgo, el rol de la persona y la medida adoptada.

Un ejemplo sencillo. Si una entidad usa IA para apoyo en admisión de clientes o prevención del fraude, quienes revisan alertas, escalan incidencias o validan decisiones necesitan entender al menos el objetivo del modelo o sistema, los principales errores posibles, los umbrales o criterios de revisión cuando existan, las limitaciones declaradas por el proveedor, el procedimiento de override y las consecuencias de aceptar la salida sin contraste. Eso ya es alfabetización en IA aplicada al rol. No hace falta que sepan derivar una función de pérdida, pero sí que entiendan dónde puede romperse el sistema y qué deben hacer cuando eso ocurra.

Ahora cambia el caso de uso: una herramienta generativa interna para redactar borradores de comunicaciones no regulatorias. El nivel suficiente puede ser mucho más básico: comprender que el sistema puede inventar hechos, reproducir información errónea, introducir sesgos o exponer datos si se alimenta con contenido inadecuado. La obligación persiste, pero la intensidad cambia. Eso es precisamente lo que el artículo 4 permite al vincular la alfabetización al contexto de uso y a las personas afectadas.

Donde el AI Act se cruza con GDPR, NIS2 y gobernanza interna

Una de las lecturas más pobres del AI Act consiste en aislarlo del resto del mapa regulatorio. Funciona fatal sobre el papel y peor aún en la práctica. La alfabetización en IA tiene efectos directos sobre privacidad, ciberseguridad, gestión de terceros y gobierno corporativo.

Empieza por protección de datos. Si un sistema de IA trata datos personales, el desconocimiento operativo puede traducirse en infracciones bastante clásicas: uso de datos para fines incompatibles, cargas de información sensible en herramientas no autorizadas, falta de base jurídica clara para determinadas operaciones, imposibilidad de atender derechos o evaluación deficiente de riesgos para los interesados. El GDPR no menciona “AI literacy” como tal, pero sí impone responsabilidades que dependen del comportamiento humano informado. El artículo 5 exige principios como minimización y limitación de la finalidad; el artículo 25, protección de datos desde el diseño y por defecto; el artículo 32, medidas de seguridad apropiadas; el artículo 35, evaluaciones de impacto cuando el tratamiento pueda entrañar alto riesgo. Si quienes implementan o usan IA no entienden qué hace la herramienta con los datos, la organización queda vendida en todos esos frentes.

Pasa algo parecido con NIS2. El artículo 21 obliga a medidas de gestión de riesgos que incluyen políticas de análisis de riesgos y seguridad de los sistemas de información, gestión de incidentes, continuidad de negocio, seguridad en la cadena de suministro, prácticas básicas de ciberhigiene y formación en ciberseguridad. Cuando una organización introduce sistemas de IA en procesos críticos, la alfabetización en IA se convierte en un complemento natural de esas medidas. No sustituye la formación en seguridad, pero la refuerza: ayuda a identificar abuso de credenciales en herramientas de IA, exposición de datos en prompts, dependencia excesiva de servicios de terceros o automatizaciones mal entendidas que amplifican incidentes.

Y luego está la gobernanza. El consejo de administración todavía tiende a escuchar “AI training” y pensar en una campaña de cultura corporativa. Mala noticia: el tema sube mucho más arriba. Si la empresa usa IA en funciones sensibles, la alfabetización es un asunto de control interno. Afecta a la fiabilidad de decisiones, al apetito de riesgo, al sistema de tres líneas y a la capacidad del órgano de dirección para ejercer supervisión informada. Un consejo que aprueba el despliegue de IA sin exigir un mapa de roles, riesgos y competencias está comprando exposición regulatoria a ciegas. No será el primer consejo que descubre tarde que la innovación salía más cara con letra pequeña.

La tentación de resolverlo con un curso único para todos

Si hay un atajo que seduce a departamentos de cumplimiento, recursos humanos y compras por igual, es este: adquirir una formación estándar, asignarla a toda la plantilla y archivar los certificados. El problema es que ese enfoque choca frontalmente con la lógica del artículo 4.

La obligación está pensada para ser contextual. Un curso único puede servir como capa mínima de sensibilización general, pero no como respuesta completa cuando existen usos materiales de IA en áreas con impacto operativo, regulatorio o sobre personas. La empresa que se quede ahí tendrá una evidencia formal y una defensa sustantiva bastante débil.

Lo razonable es construir al menos tres capas. Primera, una alfabetización base para empleados que puedan interactuar con herramientas de IA de uso general: qué es el sistema, qué riesgos básicos presenta, qué datos no deben introducirse, cuándo deben escalar una duda y qué usos están prohibidos por política interna. Segunda, una capa funcional para quienes usan IA en procesos de negocio concretos: límites del sistema, controles, validación humana, documentación y procedimientos de incidente. Tercera, una capa especializada para perfiles de riesgo elevado: compliance, legal, seguridad, responsables de producto, validación de modelos, auditoría interna y mandos que aprueban despliegues o excepciones.

No hace falta presentar esto como una revelación mística. Es simple proporcionalidad. Y, además, encaja mejor con cómo ya se gestionan otras obligaciones regulatorias. Nadie serio da la misma formación SOX a toda la empresa, ni la misma formación de privacidad a un desarrollador que a un recepcionista. Con IA, la idea es la misma, solo que el mercado aún está en esa fase entrañable en la que pretende descubrir principios que llevan décadas funcionando en compliance.

Qué evidencias sí sostienen una posición defensable

Cuando una obligación es abierta, la calidad de la evidencia importa más que el número de documentos. Un repositorio lleno de políticas huecas no impresiona a nadie que sepa leer. Si quieres una posición mínimamente sólida frente a auditoría, supervisión o litigio, necesitas pruebas que muestren diseño, implementación y revisión.

La primera evidencia útil es un inventario de casos de uso de IA, aunque sea por categorías, vinculado a funciones, unidades responsables y nivel de riesgo interno. Sin saber dónde está la IA, no hay forma seria de decidir qué alfabetización requiere cada colectivo. La segunda es una matriz de roles y competencias. No un catálogo idealizado, sino una relación práctica entre tareas reales y conocimientos mínimos exigidos. La tercera son contenidos adaptados: materiales, sesiones, instrucciones de uso, guías de revisión, criterios de escalado. La cuarta, registros de realización y evaluación. Y la quinta, quizá la más olvidada, pruebas de revisión periódica cuando cambian el sistema, el proveedor, el caso de uso o el marco de control.

Esto enlaza con otro punto delicado: la alfabetización no se agota en formación ex ante. Si el sistema cambia, la medida puede dejar de ser suficiente. Un modelo nuevo, una funcionalidad adicional, un cambio en la interfaz o una ampliación del uso a otra población afectada puede alterar por completo la evaluación. Aquí es donde muchas organizaciones pinchan: gestionan la IA como si fuera software estático y olvidan que la suficiencia del conocimiento humano también se degrada.

La prueba más convincente, en todo caso, no suele ser el certificado. Suele ser el comportamiento. Si ante una salida dudosa el usuario sabe detener, revisar, documentar y escalar; si el responsable de negocio sabe cuándo no debe confiar en el sistema; si el equipo legal o de privacidad entiende qué preguntas hacer al proveedor; entonces la alfabetización empieza a parecerse a lo que el artículo 4 pretendía. Todo lo demás se parece más a una pieza de teatro corporativo con final previsible.

La zona gris de terceros: donde casi todos tienen más riesgo del que admiten

El AI Act no se aplica en el vacío contractual. Buena parte de los despliegues reales dependen de proveedores cloud, integradores, consultoras, vendors de software empresarial o servicios embebidos en herramientas más amplias. Esa realidad complica la alfabetización en IA porque reparte tareas críticas entre varias manos y difumina responsabilidades operativas.

La solución no pasa por descargarlo todo sobre el proveedor. Un vendor puede aportar documentación, instrucciones de uso, advertencias, límites conocidos e incluso formación. Pero el artículo 4 sigue apuntando a proveedores y deployers respecto de las personas que operan o usan el sistema por su cuenta. Si tu organización despliega una herramienta y la integra en un proceso propio, no puede escudarse indefinidamente en que “el fabricante no explicó bastante”. La diligencia exigible incluye traducir ese material al contexto real de uso y asegurarse de que las personas relevantes lo comprenden.

Aquí DORA ofrece una lección útil, aunque pertenezca a otro sector y tenga otra lógica normativa. El reglamento obliga a las entidades financieras a gestionar el riesgo de terceros TIC de forma estructurada, con registros, evaluación previa, cláusulas contractuales y supervisión continuada; véanse, entre otros, los artículos 28 y siguientes sobre gestión del riesgo de terceros TIC. La moraleja extrapolable es sencilla: cuando una obligación operativa depende de terceros, el regulador no premia la ingenuidad contractual. Quiere ver gobierno, trazabilidad y capacidad interna de control.

Aplicado a IA, eso implica al menos revisar contratos, anexos técnicos e instrucciones de uso para identificar qué asume el proveedor y qué debe internalizar la entidad. También conviene exigir materiales formativos útiles, no folletos de marketing con dibujos de cerebros azules. Y, sobre todo, verificar que los equipos internos entienden los límites del producto adquirido. La fascinación por la “solución llave en mano” ha arruinado más de un programa de control.

Lo que no puede afirmarse con seguridad, y por qué eso también importa

Parte del ruido alrededor de la AI literacy ha venido de afirmaciones normativas demasiado concretas que, en ausencia de texto verificable, conviene retirar o tratar con extrema prudencia. No es una cuestión menor. Cuando una organización construye su programa de cumplimiento sobre una lectura dudosa de una supuesta reforma, el problema ya no es interpretativo; es de base.

Por eso, afirmaciones como que una modificación posterior habría eliminado la referencia a un nivel “suficiente” de alfabetización, o que el artículo 4 habría sido rehecho para imponer a la Comisión, a los Estados miembros o al AI Board determinados mandatos adicionales de orientación a través de plataformas específicas, no deben presentarse como hechos si no pueden sostenerse con texto normativo fiable. Con el material verificable aquí, el punto seguro sigue siendo el texto conocido del artículo 4 del AI Act: existe una obligación de adoptar medidas para garantizar, en la medida de lo posible, un nivel suficiente de alfabetización en IA.

Para algunos lectores esto puede sonar excesivamente cauteloso. No lo es. En regulación tecnológica, un matiz mal apoyado se convierte muy rápido en una política interna mal diseñada, un programa formativo mal dirigido y, después, una defensa frágil cuando algo falla. La prudencia bien entendida no resta profundidad. Evita vender humo con membrete europeo, que es una industria bastante consolidada.

Cómo debería reaccionar una empresa ahora mismo

Si tu organización ya usa IA, incluso de forma limitada, la respuesta correcta no es esperar a que llegue una guía milagrosa que convierta el artículo 4 en una checklist de cinco líneas. Eso sería cómodo. También irresponsable. La obligación es suficientemente clara como para empezar ya con un enfoque basado en riesgos.

El primer paso es identificar usos reales, no solo herramientas oficialmente aprobadas. La IA escondida en suites ofimáticas, plataformas de atención al cliente, sistemas de fraude, recursos humanos o analítica comercial también cuenta. El segundo es clasificar esos usos por impacto: decisiones sobre personas, tratamiento de datos personales, procesos regulados, dependencia de salidas automatizadas, capacidad de supervisión humana. El tercero es mapear quién toca qué: usuarios finales, supervisores, responsables de negocio, soporte técnico, seguridad, legal, compliance, procurement y terceros que operan por cuenta de la entidad. El cuarto es definir conocimientos mínimos por rol y caso de uso. Y el quinto, implantar medidas con evidencia y revisión.

Ese diseño no requiere convertir la empresa en un seminario académico. Requiere disciplina. A veces bastará con instrucciones operativas muy concretas y sesiones breves bien enfocadas. Otras veces exigirá formación más intensa, validaciones periódicas o restricciones de uso hasta que determinados equipos demuestren comprensión suficiente. Lo decisivo no es la sofisticación formal, sino la adecuación al riesgo y la capacidad de probarla.

También conviene integrar la AI literacy en procesos existentes. Si ya tienes un marco de aprobación de herramientas, una evaluación de proveedores, una DPIA bajo GDPR, un control de cambios, una matriz de formación obligatoria o un esquema de tres líneas, úsalo. Levantar un programa paralelo solo porque la obligación suena nueva suele acabar en duplicidades, lagunas y una colección de reuniones bastante prescindibles.

La objeción típica: “pero el artículo 4 es demasiado vago”

Es verdad. El artículo 4 es abierto. Pero de ahí no se sigue que sea inocuo. Hay normas vagas que duermen durante años porque nadie las conecta con riesgos reales o con expectativas supervisoras. Esta no tiene pinta de ser una de ellas. Precisamente porque la IA se está colando en procesos sensibles, la pregunta sobre la competencia humana alrededor del sistema va a aparecer una y otra vez, ya sea en auditoría, en reclamaciones, en incidentes de privacidad, en investigación interna o en discusión con el proveedor.

Además, la vaguedad no es una anomalía en regulación tecnológica. GDPR está lleno de estándares abiertos: medidas apropiadas, riesgo, proporcionalidad, estado de la técnica. NIS2 también trabaja con ese lenguaje. DORA, aunque más detallado, tampoco resuelve cada decisión de implementación. Las organizaciones maduras no esperan a que el legislador les dibuje el procedimiento exacto; construyen una interpretación razonable, la documentan y la revisan. Las inmaduras esperan la guía definitiva. Suele llegar cuando ya van tarde.

La objeción más honesta no es que el artículo 4 sea vago, sino que obliga a hacer trabajo incómodo: inventariar usos, ordenar propietarios, distinguir niveles de riesgo y aceptar que no toda adopción de IA puede escalar al ritmo que querría negocio. Ahí está la fricción real. La alfabetización en IA, bien hecha, ralentiza ciertos despliegues. Y quizá ese sea precisamente el punto.

Mi lectura: el artículo 4 parece modesto, pero puede convertirse en una palanca regulatoria seria

No creo que la AI literacy vaya a ser el primer titular sancionador por sí sola. Sí creo que puede convertirse en una palanca muy eficaz para evaluar si una organización controla de verdad sus sistemas de IA o solo los ha adornado con documentación. Como pasó con la formación en privacidad o con la supervisión de terceros en ciberseguridad, la obligación aparentemente blanda termina revelando la calidad del control interno.

Cuando una empresa no puede explicar quién usa la IA, con qué criterios, bajo qué límites y con qué comprensión mínima, el problema rara vez se queda en la formación. Suele haber desorden de inventario, gobierno difuso, compras sin evaluación suficiente, dependencia acrítica del proveedor y una fe entrañable en que “si algo falla ya lo revisará alguien”. Es una estrategia regulatoria tan sólida como parece.

Por eso el artículo 4 merece más atención de la que está recibiendo. No porque convierta a todos en expertos en IA. Ni porque esconda, al menos con el texto verificable aquí, alguna reforma secreta o arquitectura institucional nueva. Merece atención porque obliga a traducir la adopción de IA a términos de competencia humana demostrable. Y ahí se separan las organizaciones que pilotan de las que simplemente improvisan con presupuesto.

Qué hacer el lunes por la mañana

Si tuviera que resumirlo en una instrucción ejecutiva, sería esta: deja de pensar en AI literacy como formación y empieza a tratarla como control. Revisa el artículo 4. Cruza ese mandato con tus usos reales de IA. Identifica roles, riesgos y personas afectadas. Diseña medidas proporcionales. Conserva evidencia. Repite el ejercicio cuando cambie el sistema o el contexto.

Ese enfoque no elimina toda la incertidumbre interpretativa. Tampoco hace falta. Lo que sí hace es darte una posición defendible frente al texto vigente conocido del AI Act y frente al resto del ecosistema regulatorio con el que convive: GDPR para datos personales, NIS2 para gestión del riesgo de ciberseguridad, DORA si eres entidad financiera y marcos internos de control si tienes un consejo que prefiere enterarse antes de que llegue el problema.

La ironía final es que una obligación redactada en términos tan aparentemente modestos puede acabar siendo una de las pruebas más reveladoras sobre la madurez real de una organización ante la IA. Porque cualquiera puede comprar una herramienta. Bastantes menos pueden demostrar que la gente que la usa entiende de verdad lo que tiene entre manos.