Alfabetización en IA bajo el AI Act: una obligación que ya está en vigor

La alfabetización en inteligencia artificial ya no es una recomendación de recursos humanos ni una iniciativa amable para la intranet. Desde el 2 de febrero de 2025, el artículo 4 del Reglamento de IA de la Unión Europea obliga a proveedores y responsables del despliegue de sistemas de IA a adoptar medidas para garantizar un nivel suficiente de alfabetización en IA entre su personal y las personas que utilizan o gestionan esos sistemas por cuenta de la organización.

La obligación parece modesta porque no fija un número de horas, no crea un examen europeo y tampoco exige un certificado expedido por una academia homologada. Precisamente por eso puede resultar incómoda. El AI Act no permite resolverla comprando un curso genérico, enviando un PDF a toda la plantilla y archivando el porcentaje de finalización. El criterio es funcional: quienes operan o utilizan IA deben comprender sus capacidades, sus limitaciones y los riesgos que genera el uso concreto del sistema.

Para un CISO o un responsable de cumplimiento, la pregunta útil no es si la plantilla ha recibido formación sobre IA. Es otra: ¿puede la entidad demostrar que las personas que emplean Copilot, clasifican clientes con un modelo, revisan alertas antifraude o aprueban decisiones asistidas por IA saben cuándo confiar en el resultado, cuándo escalarlo y cuándo detener el proceso?

El artículo 4 no es una declaración de intenciones

El artículo 4 del AI Act exige a proveedores y deployers, es decir, responsables del despliegue, que adopten medidas para garantizar un nivel suficiente de alfabetización en IA de su personal y de otras personas que utilicen o gestionen sistemas de IA en su nombre. La norma añade cuatro criterios para determinar qué significa suficiente: los conocimientos técnicos, la experiencia, la educación y la formación de las personas; el contexto en el que se utiliza el sistema; y las personas o grupos sobre los que el sistema va a utilizarse.

La última parte cambia la conversación. No basta con enseñar cómo se escribe un buen prompt. Una persona que utiliza una herramienta generativa para resumir actas internas no afronta el mismo riesgo que quien usa un sistema que puntúa solicitudes de crédito, recomienda intervenciones médicas o filtra candidaturas laborales. La alfabetización exigible depende del impacto, del margen de autonomía del sistema, de la sensibilidad de los datos y de la posibilidad de que un error perjudique a una persona.

El artículo 4 forma parte del capítulo I del Reglamento, dedicado a las disposiciones generales. Su aplicación comenzó el 2 de febrero de 2025, conforme al artículo 113. En septiembre de 2026, por tanto, no estamos ante una obligación futura pendiente de desarrollo: lleva más de un año siendo aplicable. Que el Reglamento de IA conceda más tiempo para otras obligaciones no convierte la alfabetización en una tarea aplazable.

La Comisión Europea no ha impuesto un temario único porque sería difícilmente compatible con la variedad de usos cubiertos por el Reglamento. Una aseguradora, un hospital y una empresa de software pueden usar modelos con arquitecturas parecidas para finalidades regulatorias completamente distintas. La ausencia de un examen común no rebaja la exigencia; desplaza hacia cada organización la responsabilidad de definir el estándar adecuado y justificarlo.

Quién necesita formación y quién necesita algo más

El error más frecuente consiste en identificar alfabetización en IA con formación para toda la plantilla. La obligación puede alcanzar a una audiencia amplia, pero no exige la misma profundidad para todos. El análisis debe empezar por el inventario de sistemas y por los roles que intervienen en su ciclo de vida.

Un empleado que utiliza una herramienta generativa aprobada para redactar un borrador necesita conocer, como mínimo, las reglas internas de uso, los riesgos de introducir información confidencial, la posibilidad de obtener respuestas inventadas y el proceso para verificar los resultados. Un científico de datos que ajusta un modelo necesita dominar cuestiones adicionales: calidad y representatividad de los datos, deriva, validación, trazabilidad, métricas de error y controles de acceso. Quien valida una decisión automatizada con consecuencias para un cliente necesita comprender el significado de la salida, los límites del modelo y sus obligaciones de escalado.

En una entidad financiera, la segmentación práctica podría ser la siguiente:

• Usuarios generales: personal que emplea asistentes generativos o funciones de IA en tareas administrativas. Debe conocer la política de herramientas autorizadas, la protección de datos, la verificación humana y el canal de incidentes.
• Usuarios con impacto operativo: analistas de fraude, equipos de atención al cliente, recursos humanos, riesgos o marketing que reciben recomendaciones o clasificaciones de un modelo. Necesitan formación sobre falsos positivos, sesgos, explicabilidad operativa y prohibiciones de uso.
• Responsables de negocio y deployers: quienes deciden adquirir, configurar o poner en producción un sistema. Deben entender la clasificación regulatoria, las obligaciones contractuales, la supervisión humana, los registros y la gestión de cambios.
• Equipos técnicos: ingeniería, datos, seguridad y operaciones. Necesitan capacidades para probar, monitorizar, documentar y retirar sistemas, además de controles sobre dependencias, interfaces y datos.
• Comités y dirección: no tienen que programar un modelo, pero sí deben poder cuestionar una afirmación de precisión, comprender quién asume la responsabilidad y saber qué usos requieren una decisión formal.

Esta segmentación evita dos fallos opuestos. El primero es formar a todo el mundo con el mismo contenido superficial. El segundo es limitar la obligación a los desarrolladores, como si el riesgo desapareciera cuando el código pasa a manos del negocio. Muchos incidentes nacen en la configuración, en la interpretación de una salida o en el uso de datos para una finalidad distinta de la prevista. El modelo no firma contratos ni pulsa el botón de aprobar: lo hace una persona.

La clasificación del sistema determina el nivel de alfabetización

El AI Act distingue varias categorías de riesgo. El artículo 5 prohíbe determinadas prácticas, entre ellas ciertos usos de técnicas subliminales o manipuladoras, la explotación de vulnerabilidades y algunos sistemas de categorización biométrica. El artículo 6 y el anexo III identifican sistemas de alto riesgo en áreas como empleo, educación, crédito, servicios esenciales, aplicación de la ley, migración y justicia. Los sistemas de riesgo limitado quedan sujetos, entre otras obligaciones, a requisitos de transparencia del artículo 50 cuando resulten aplicables. Los modelos de propósito general tienen obligaciones específicas para sus proveedores en los artículos 51 y siguientes.

La alfabetización debe reflejar esa arquitectura. No tiene sentido impartir el mismo módulo a quien usa una aplicación de generación de texto y a quien supervisa un sistema de evaluación de solvencia. En el segundo caso, el contenido debería cubrir al menos el significado de la clasificación, la gestión de excepciones, los límites de las recomendaciones, la intervención humana y el procedimiento para impugnar o revisar resultados.

Para los sistemas de alto riesgo, el artículo 26 impone obligaciones al deployer, entre ellas utilizar el sistema conforme a las instrucciones de uso, asignar supervisión humana competente, pertinente, formada y con autoridad, monitorizar el funcionamiento y conservar determinados registros. Aunque el artículo 4 y el artículo 26 no son intercambiables, se refuerzan mutuamente. No puede existir una supervisión humana real si la persona designada no comprende qué puede hacer el sistema, qué no puede hacer y qué señales indican que está fallando.

Aquí aparece una distinción que muchas políticas internas pasan por alto: estar informado no equivale a ser competente. Leer una guía no demuestra que un analista sepa detectar una recomendación absurda, ni que un supervisor pueda reconocer un cambio de comportamiento después de una actualización del modelo. La prueba debe acercarse al trabajo real. Casos simulados, revisión de salidas, ejercicios de escalado y pruebas de comprensión suelen proporcionar una evidencia más sólida que un test de diez preguntas diseñado para maximizar la tasa de aprobados.

La obligación se cruza con GDPR, DORA y NIS2

El AI Act no sustituye las reglas que ya regulan el dato, el riesgo tecnológico o la seguridad. Para una organización europea, la alfabetización en IA debe encajar en controles existentes, no vivir en una carpeta separada con el nombre de un nuevo reglamento.

El artículo 22 del GDPR regula las decisiones basadas únicamente en tratamiento automatizado que produzcan efectos jurídicos o afecten significativamente a una persona. Cuando un sistema de IA participa en decisiones de crédito, contratación o acceso a servicios, la formación debe explicar cómo se identifica una decisión exclusivamente automatizada, qué intervención humana es genuina y cómo se atienden los derechos de la persona afectada. Llamar intervención humana a pulsar aceptar después de mirar una puntuación durante tres segundos no convierte el proceso en supervisión efectiva.

El artículo 35 del GDPR exige una evaluación de impacto relativa a la protección de datos cuando el tratamiento pueda entrañar un alto riesgo. La evaluación debería describir también las competencias de las personas que acceden a los resultados del sistema. Si el análisis de riesgos documenta datos sensibles, elaboración de perfiles o decisiones con efectos relevantes, pero la formación se reduce a una sesión genérica sobre prompts, hay una incoherencia difícil de defender ante una autoridad de protección de datos.

En el sector financiero, DORA añade otra capa operativa. Sus artículos 5 a 16 establecen requisitos de gestión del riesgo de las TIC, mientras que el artículo 28 regula la gestión del riesgo asociado a terceros proveedores de servicios TIC. Si una entidad utiliza un servicio de IA alojado por un tercero, la alfabetización no elimina las obligaciones de gobierno del proveedor. El personal debe saber qué datos pueden enviarse al servicio, qué controles contractuales existen, cómo se notifican incidentes y qué ocurre si el proveedor cambia el modelo o sus condiciones de uso.

El artículo 11 de DORA exige una política de continuidad de negocio y recuperación en materia de TIC; el artículo 12 trata de las políticas y procedimientos de respaldo y restauración. Para un sistema de IA integrado en atención al cliente o detección de fraude, la competencia del usuario incluye saber qué hacer cuando el modelo no está disponible, devuelve resultados degradados o cambia su comportamiento. La resiliencia no consiste en tener un plan que diga que se activará el modo manual. Consiste en que alguien sepa activarlo y pueda operar sin el sistema.

NIS2, en su artículo 21, exige medidas de gestión de riesgos de ciberseguridad, incluida la formación y las prácticas básicas de ciberhigiene. La formación sobre IA debería incluir amenazas específicas: extracción de instrucciones, fuga de datos mediante prompts, envenenamiento de datos, abuso de credenciales de API y manipulación de entradas. Un modelo puede estar correctamente configurado desde el punto de vista funcional y seguir siendo una vía de exfiltración si los usuarios desconocen qué información no deben introducir.

El resultado práctico es claro: el mismo programa puede alimentar el cumplimiento del artículo 4 del AI Act, el artículo 21 de NIS2 y los controles de riesgo TIC de DORA, pero solo si se diseñan objetivos y evidencias diferenciados. Una diapositiva con tres logotipos regulatorios no crea un control integrado.

Qué debe contener un programa defendible

Un programa razonable empieza con un mapa de usos, no con el catálogo de cursos del proveedor. El inventario debe identificar el sistema, su finalidad, el proveedor, los datos tratados, el área responsable, los usuarios, la clasificación preliminar de riesgo y las consecuencias de un fallo. También debe registrar si se trata de una herramienta generativa de propósito general, una función integrada en un producto o un sistema desarrollado internamente.

Después hay que construir una matriz de competencias. Para cada rol conviene documentar cuatro elementos: qué decisiones o tareas realiza la persona, qué riesgos debe reconocer, qué acción debe ejecutar ante una anomalía y qué evidencia demostrará que puede hacerlo. Esta última columna suele ser la olvidada. Sin ella, el programa se convierte en una colección de intenciones.

Los contenidos mínimos dependerán del uso, pero un programa para usuarios corporativos debería cubrir:

• qué sistema está utilizando y para qué finalidad ha sido aprobado;
• qué datos no pueden introducirse, incluidos datos personales, secretos empresariales o información sujeta a secreto profesional;
• cómo verificar exactitud, sesgo, actualidad y trazabilidad de una salida;
• cuándo está prohibido utilizar el sistema o cuándo es obligatorio escalar el caso;
• cómo registrar un error, una salida peligrosa, una fuga de información o un comportamiento inesperado;
• quién tiene autoridad para detener el uso y qué alternativa manual existe.

Para equipos técnicos y responsables de producto, el temario debe ir más lejos. Debe abarcar validación, pruebas adversariales, control de versiones, monitorización, gestión de cambios, datos de entrenamiento y evaluación de rendimiento por grupos relevantes. En sistemas de alto riesgo, la formación tiene que conectar con la documentación técnica del artículo 11 y el anexo IV, los registros del artículo 12 y las instrucciones de uso del artículo 13. No hace falta convertir a cada operador en un ingeniero de aprendizaje automático, pero sí impedir que opere como si la puntuación del modelo fuera una verdad objetiva.

La formación también debe actualizarse. Un cambio de modelo, de proveedor, de finalidad, de datos o de interfaz puede alterar el riesgo sin cambiar el nombre de la herramienta. Una entidad que certificó a sus usuarios en una versión anterior no puede asumir automáticamente que la competencia sigue intacta después de una actualización sustancial. El Reglamento no prescribe una periodicidad universal, por lo que la organización debe definir disparadores: incorporación a un rol, puesta en producción, cambio material, incidente, hallazgo de auditoría o modificación normativa.

La evidencia que probablemente pedirá un auditor

El artículo 4 no contiene un formato de registro equivalente al que el GDPR fija para determinadas actividades de tratamiento. Eso no significa que la organización pueda conformarse con una declaración de cumplimiento. Si una autoridad, un auditor interno o un comité de riesgos pregunta cómo se ha garantizado la alfabetización, la respuesta debería ser reconstruible.

Una carpeta de evidencias útil incluiría el inventario de sistemas y roles, el análisis que relaciona cada uso con un nivel de competencia, los materiales de formación, las fechas de asignación y finalización, los resultados de evaluaciones, las excepciones y los planes de refuerzo. Para sistemas relevantes conviene añadir ejercicios prácticos, actas de aprobación, registros de incidentes y pruebas de que la organización actualiza el contenido cuando cambia el modelo.

La evidencia no tiene que demostrar que nadie se equivoca. Tiene que demostrar que el error previsto se puede detectar y gestionar. Un ejercicio en el que un analista identifica una recomendación sesgada y la escala puede ser más valioso que un certificado de asistencia. Del mismo modo, un registro que muestra que un usuario perdió acceso a una herramienta después de no superar una evaluación de competencia es más defendible que una tasa de finalización del 100% obtenida mediante un cuestionario sin consecuencias.

Para evitar que el programa se convierta en una operación de cumplimiento cosmética, conviene separar tres métricas:

• Alcance: qué porcentaje de personas en roles identificados ha recibido el contenido correspondiente.
• Comprensión: qué resultados obtiene en pruebas o ejercicios alineados con sus tareas.
• Comportamiento: si utiliza los canales de escalado, evita herramientas no autorizadas y registra incidentes o excepciones.

La tercera métrica suele ser la más reveladora. Si nadie reporta errores durante meses en un sistema utilizado a gran escala, hay dos explicaciones posibles: el sistema funciona extraordinariamente bien o la organización ha diseñado un canal que nadie quiere utilizar. La formación debe explicar también las consecuencias de no reportar, la protección frente a represalias y la ruta de resolución.

Responsabilidad: quién responde cuando la formación falla

El artículo 4 coloca la obligación sobre el proveedor o el deployer, no sobre el empleado individual. Eso no impide asignar responsabilidades internas, pero sí dificulta la estrategia de culpar al usuario cuando una herramienta se despliega sin controles suficientes.

El área de cumplimiento debería interpretar la obligación y coordinarla con el inventario regulatorio. El negocio debe definir las finalidades y los roles. Tecnología y seguridad deben controlar la configuración, el acceso, los registros y los cambios. Recursos humanos puede administrar la formación, pero no debería decidir por sí solo qué significa competencia para un sistema que afecta a clientes. La dirección, por su parte, tiene que aprobar el nivel de riesgo aceptable y financiar las medidas necesarias.

El comité de IA —si existe— no debería limitarse a autorizar herramientas. Debe revisar incidentes, excepciones, cambios de riesgo y resultados de las evaluaciones. En organizaciones pequeñas, esas funciones pueden recaer en un comité de riesgos o en el responsable de cumplimiento. Lo importante no es el nombre del órgano, sino que haya una autoridad identificable con capacidad para detener un uso.

La contratación también importa. Si un proveedor ofrece una solución de IA que el personal utiliza en nombre de la entidad, el contrato debería aclarar las responsabilidades sobre documentación, formación, cambios de modelo, soporte, incidentes y acceso a información suficiente para la supervisión. DORA artículo 30 exige elementos contractuales esenciales para los servicios TIC en entidades financieras; la formación del cliente no reemplaza la diligencia sobre el proveedor, ni el proveedor puede convertir su documentación comercial en la única fuente de competencia interna.

La trampa de la formación genérica sobre inteligencia artificial

El mercado ya vende cursos que prometen alfabetización en IA en menos de una hora. Pueden servir como introducción, pero no resuelven por sí solos el artículo 4. La obligación no pregunta si alguien sabe definir un modelo fundacional. Pregunta si la organización ha adoptado medidas adecuadas al contexto y a las personas afectadas.

Un módulo genérico suele omitir cuestiones decisivas: qué modelo está aprobado, qué datos pueden utilizarse, qué finalidad se ha autorizado, quién revisa una salida, qué logs se conservan, cómo se solicita una nueva integración y qué ocurre cuando el sistema se equivoca. También suele presentar la alucinación como una curiosidad técnica y no como un fallo operativo que puede generar una transferencia incorrecta, una comunicación engañosa a un cliente o una decisión discriminatoria.

La solución no es rechazar todo contenido común. Es utilizarlo como capa inicial y añadir módulos por rol y por sistema. Un empleado puede completar una base común sobre riesgos, privacidad y seguridad; después debe resolver escenarios vinculados a sus tareas. Los equipos de crédito necesitarán casos de clasificación y explicación. Los de recursos humanos, casos de selección y datos sensibles. Los desarrolladores, pruebas y monitorización. Los ejecutivos, preguntas sobre responsabilidad, apetito de riesgo y decisiones de retirada.

También conviene enseñar cuándo no utilizar IA. Una cultura que premia la automatización por defecto acaba convirtiendo la herramienta en una autoridad informal. La alfabetización incluye reconocer que una tarea puede ser demasiado sensible, demasiado ambigua o demasiado poco documentada para delegarla en un sistema.

Qué deberían hacer ahora CISO y compliance

La primera decisión es aceptar que el cumplimiento no se puede medir con el número de licencias de formación contratadas. Hay que cruzar el inventario de herramientas con el inventario de personas. Si la entidad no sabe qué equipos utilizan asistentes generativos, plugins, APIs o funciones de IA integradas en aplicaciones empresariales, tampoco sabe a quién debe formar.

El siguiente paso es clasificar los usos por impacto, no por la etiqueta comercial del producto. Una herramienta llamada asistente puede resumir información pública o puede recomendar el bloqueo de una cuenta. El nombre no decide el riesgo; lo decide la finalidad y el efecto de la salida.

Después hay que asignar un estándar mínimo de competencia a cada rol y probarlo con situaciones reales. En sistemas que afectan a clientes, empleados o terceros, la prueba debería incluir al menos un caso de resultado incorrecto, uno de dato no permitido y uno de indisponibilidad. El objetivo es comprobar si la persona sabe parar, escalar y continuar por una vía segura.

Por último, la evidencia debe incorporarse al gobierno ordinario: revisiones de acceso, gestión de cambios, evaluaciones de impacto, auditoría interna, gestión de incidentes y revisiones de proveedores. Si el registro de formación vive separado del inventario de IA, del registro de tratamientos GDPR y del sistema de riesgos TIC, la entidad tendrá que reconstruir la historia cada vez que llegue una auditoría. Y las auditorías, como los incendios, suelen tener poca paciencia con los archivos incompletos.

La conclusión incómoda: alfabetizar no es enseñar a usar prompts

El artículo 4 del AI Act no pretende crear una nueva profesión ni convertir a cada empleado en especialista en modelos. Pretende evitar que personas sin conocimientos suficientes utilicen sistemas capaces de producir efectos relevantes como si fueran herramientas neutras.

La obligación está en vigor desde el 2 de febrero de 2025. Su alcance depende del sistema, del contexto y de las personas afectadas. Su cumplimiento no se acredita con un diploma genérico, sino con una combinación de inventario, análisis de roles, formación adaptada, pruebas prácticas, supervisión y evidencias mantenidas en el tiempo.

Para un CISO, el mensaje es directo: la alfabetización en IA forma parte del control de riesgo, no de la decoración cultural. Para compliance, el reto es traducir una obligación abierta en criterios demostrables sin inventar requisitos que el Reglamento no exige. Y para la dirección, la decisión consiste en asumir que desplegar una herramienta de IA también significa formar a quienes pueden equivocarse con ella, detectar cuándo se equivoca y tener autoridad para apagarla.

La tecnología puede generar una respuesta en segundos. La responsabilidad de decidir si esa respuesta merece confianza sigue siendo humana. El AI Act, en su artículo 4, exige que esa responsabilidad no recaiga sobre personas que fueron dejadas a oscuras.