La alfabetización en IA no es un curso, es un músculo organizativo.

Un certificado puede demostrar que alguien asistió a una lección. No puede demostrar si una organización puede reconocer un sistema de IA, cuestionar sus...

La alfabetización en IA no es un curso, es un músculo organizativo.

La frase legal que cambia la reunión

El 24 de julio de 2026, el Diario Oficial de la Unión Europea publicó el Ómnibus Digital sobre IA. Entre sus modificaciones figuraba un pequeño cambio en el artículo 4 de la Ley de Inteligencia Artificial. La obligación se mantiene, pero la ley ya no pide a las organizaciones que prometan un nivel de alfabetización en IA prescrito o universal para cada persona. Los proveedores y los responsables del despliegue deben adoptar medidas que favorezcan el desarrollo de la alfabetización entre su personal y entre otras personas que operen o utilicen sistemas de IA en su nombre. La modificación también señala que la Comisión y los Estados miembros deben apoyar esos esfuerzos, y que el Consejo de IA debe trabajar en pos de objetivos comunes.

Eso es un cambio jurídico. También es una cuestión de gestión. Si no existe una puntuación universal de examen, ¿qué hace una organización seria cuando incorpora un sistema de IA a un proceso real? No puede responder solo con un certificado. Un certificado puede demostrar que alguien completó una lección. No puede demostrar que esa persona sepa distinguir un borrador de una política aprobada, reconocer cuándo un modelo sale de su tarea, pedir las pruebas que respaldan una recomendación, detener un flujo de trabajo o encontrar al responsable que pueda modificarlo. La parte interesante de la alfabetización comienza cuando la presentación de diapositivas se ha quedado en silencio.

Las propias preguntas y respuestas de la Comisión Europea lo expresan con una claridad inusual. No existe un formato único para la alfabetización en IA ni un requisito de certificado específico. La organización debe considerar su papel, el riesgo y la finalidad del sistema, los conocimientos y la experiencia de las personas implicadas, y el contexto en el que se utiliza el sistema. Debe conservar un registro interno de la formación u otras iniciativas de orientación, pero un registro de asistencia no es lo mismo que la capacidad que esas iniciativas pretenden desarrollar.

Por tanto, la alfabetización en IA se entiende mejor como un músculo que se ejercita. Un músculo no se demuestra teniendo un carné de gimnasio. Se construye con un esfuerzo repetido y contextual, y se hace visible cuando la situación resulta incómoda. Una organización alfabetizada puede nombrar el sistema que utiliza, indicar qué se le permite hacer al sistema, advertir cuándo las pruebas son débiles, preguntar quién puede verse afectado y derivar un caso incierto a una persona con autoridad para decidir. Eso es menos glamuroso que un acto de lanzamiento. También es donde la ley se encuentra con el trabajo cotidiano.

Este artículo trata de ese trabajo cotidiano. No es un programa de curso ni un asesoramiento jurídico. Es una manera de separar tres cosas que a menudo van unidas: la concienciación, la competencia y la autoridad. Sigue las preguntas que surgen cuando una administración pública, una empresa, una escuela o un equipo profesional intenta hacer útil la IA sin entregar su criterio a una pantalla. Los ejemplos proceden de la orientación pública europea y de la práctica institucional documentada. Cualquier situación inventada se marca como hipotética, porque una historia no es una prueba por el mero hecho de que en ella aparezca una oficina verosímil.

La alfabetización es una práctica, no una insignia

La palabra alfabetización llegó al debate sobre la IA cargada de demasiado equipaje. Puede sonar a introducción básica para quienes aún no han aprendido el vocabulario importante. También puede sonar a etiqueta de cumplimiento que se puede colocar a una persona y archivar. Ninguna de las dos interpretaciones es útil. La alfabetización es la capacidad de leer una situación lo bastante bien como para actuar en ella. Leer un libro sobre un idioma no es lo mismo que entender una carta dirigida a ti. Leer una definición de sistema de IA no es lo mismo que saber si la herramienta que tienes delante está haciendo una predicción, recuperando un registro, generando una continuación, clasificando opciones o controlando un paso de un flujo de trabajo.

La explicación actual de la Comisión sobre el artículo 4 empieza por el lugar adecuado: las organizaciones deben desarrollar una comprensión general de qué es la IA, cómo funciona, qué sistemas utilizan y qué oportunidades y peligros aportan esos sistemas. Eso es un comienzo, no una meta. La comprensión general le da a una persona un mapa. El mapa solo resulta útil cuando se vincula a una tarea, un rol, una fuente de evidencia y una consecuencia.

Pensemos en un hipotético equipo de contratación que revisa una herramienta que resume las presentaciones de los proveedores. La concienciación permite al equipo reconocer que la herramienta produce texto generado y que puede cometer errores. La competencia permite a un revisor comprobar si el resumen conserva las exclusiones, las condiciones y las fechas, y compararlo con las presentaciones subyacentes. La autoridad determina qué ocurre cuando el resumen está incompleto. ¿Puede el revisor rechazarlo? ¿Puede el equipo exigir al proveedor que exponga los pasajes de origen? ¿Puede alguien pausar la evaluación mientras se investiga el problema? Sin autoridad, la competencia se convierte en una preocupación privada que el flujo de trabajo es libre de ignorar.

La distinción importa porque las organizaciones suelen formar en la capa más fácil. Explican qué es un modelo, muestran algunos ejemplos y piden a las personas que acepten una política de uso. Las personas se van con palabras nuevas y los mismos incentivos de siempre. Si la rapidez se premia y el cuestionamiento se trata como una obstrucción, quien detecta un problema aprende a callarse. La organización puede entonces declarar un alto nivel de concienciación mientras sus decisiones permanecen intactas. La insignia es real. La alfabetización es decorativa.

Una visión basada en la práctica plantea una pregunta distinta: ¿qué debería poder notar y hacer una persona en el punto donde un sistema de IA toca su trabajo? La respuesta varía según el rol. Una persona que interactúa con un servicio público necesita saber cuándo interviene una máquina, qué se puede impugnar y dónde pedir una vía humana. Un gestor de casos necesita comprender la finalidad del sistema, la evidencia, la incertidumbre y la vía de anulación. Un responsable necesita decidir si la tarea es adecuada para la automatización y si el equipo tiene tiempo para revisar el resultado. Un desarrollador necesita conocer el límite entre datos y modelo, los modos de fallo y los registros que deben sobrevivir a un cambio. Llamar a todo esto un curso oculta las diferencias que hacen seguro el trabajo.

La nueva redacción legal deja espacio para esa variación. El Reglamento (UE) 2026/1744 establece que la alfabetización en IA debe comenzar en la educación y la formación y continuar a lo largo del aprendizaje permanente. También reconoce que los distintos proveedores y responsables del despliegue afrontan cargas y contextos diferentes. Esto no es una invitación a no hacer nada. Es una invitación a dejar de fingir que un único examen puede medir la capacidad de actuar con responsabilidad en todos los sistemas, sectores y grupos de personas afectadas.

La práctica tiene otra propiedad útil: revela las carencias sin avergonzar a las personas por tenerlas. Una persona puede entender que un modelo de lenguaje predice continuaciones probables y aun así no saber cómo un sistema de recuperación concreto selecciona los documentos. Un responsable de datos puede entender la procedencia y aun así carecer de permiso para modificar el índice. Un responsable puede saber que un humano debe supervisar un sistema de alto riesgo y aun así no tener tiempo asignado para una revisión significativa. Son carencias de diseño, no fallos morales personales. Una organización alfabetizada las hace visibles para poder repararlas.

La alfabetización en IA se hace visible cuando un uso del sistema deja el siguiente uso mejor comprendido, no solo cuando una persona completa una lección.

La conciencia es la puerta, no la sala

A menudo se descarta la conciencia porque suena a algo blando. Eso es un error. Las personas no pueden cuestionar un sistema que no saben nombrar, y no pueden nombrar un sistema si cada pieza de software se describe como inteligente. La conciencia da a una organización un vocabulario compartido para separar un modelo de una interfaz, una predicción de una decisión, una fuente de un resumen, una instrucción de un contenido recuperado, y una indicación de confianza de una evidencia de corrección.

El vocabulario no necesita ser grandioso. Necesita ser lo bastante preciso para evitar un error de categoría. Un buscador, una comprobación de elegibilidad basada en reglas, un clasificador, un asistente generativo y un agente de flujo de trabajo pueden aparecer en el mismo catálogo de productos. Sus mecanismos y riesgos son distintos. Si el personal lo llama todo IA y se detiene ahí, pierde las preguntas que deberían seguir. ¿Qué datos ve el sistema? ¿Cuál es su propósito previsto? ¿Qué devuelve? ¿Quién actúa sobre el resultado? ¿Qué errores importan? ¿Qué se puede deshacer? ¿A qué personas afecta aunque nunca toquen la interfaz?

La conciencia también incluye el entorno social. La guía de la UNESCO para la IA generativa en educación e investigación describe la capacidad humana como parte de un enfoque centrado en las personas. Sitúa la comprensión técnica junto a la privacidad, la equidad, la inclusión, la diversidad lingüística y cultural, y el uso significativo. La cuestión no es que cada empleado deba convertirse en investigador de políticas. La cuestión es que un sistema no se vuelve neutral cuando se coloca en una aplicación familiar. El mismo párrafo generado puede ser una ayuda de redacción inofensiva en un contexto y una decisión sin revisar en otro.

Una persona consciente del contexto puede oír la diferencia entre una petición de ayuda y una delegación de autoridad. Pida al sistema que sugiera preguntas para una reunión y el usuario sigue siendo el autor de la reunión. Pídale que decida qué residente recibe un servicio escaso y el sistema habrá entrado en un territorio moral y legal distinto. Las palabras en la pantalla pueden parecer similares. El límite de la tarea no lo es. La conciencia es el hábito de notar que el límite se ha movido.

Las instituciones públicas necesitan esta conciencia de forma especialmente disciplinada. Sus sistemas pueden afectar a personas que no pueden optar por no participar, que no saben qué herramientas automatizadas intervienen, o que no pueden permitirse un segundo intento tras un error. Un equipo de servicio necesita por tanto algo más que una declaración general de que la IA puede ser inexacta. Necesita un vocabulario para explicar la vía que una persona puede seguir cuando el sistema se equivoca, cuando faltan datos, o cuando la respuesta nunca debería haberse automatizado.

Las empresas necesitan el mismo vocabulario por razones menos visibles. Un proveedor puede describir un sistema de clasificación como apoyo a la decisión, mientras que el proceso del cliente trata la clasificación como una decisión porque nadie tiene tiempo de revisarla. Un equipo de marketing puede usar una herramienta de traducción para borradores internos y luego copiar el resultado en un aviso público sin una segunda comprobación. Un equipo de contratación puede calificar una puntuación de selección como una mera conveniencia y usarla discretamente para descartar candidatos. La conciencia revela estos cambios antes de que queden enterrados en un diagrama de flujo de trabajo.

Por tanto, la conciencia debe evaluarse mediante un lenguaje propio de la organización. Pida a un equipo que describa un sistema sin usar las palabras inteligente, automatizado o automático. Pregunte qué información recibe, qué produce y quién puede modificar el resultado. Si la explicación se vuelve vaga, la organización ha detectado una necesidad de formación útil. El ejercicio es sencillo, pero la sencillez tiene una larga historia de ser subestimada por quienes disfrutan de un panel de control complicado.

La competencia lleva asociada una tarea

La competencia exige más que el reconocimiento porque es específica. Una persona no es simplemente competente con la IA. Es competente para realizar una tarea definida con un sistema definido en unas condiciones definidas. Las preguntas y respuestas de la Comisión vinculan repetidamente la alfabetización con el contexto y la finalidad del sistema, el conocimiento de las personas implicadas y el riesgo del uso. Esa es una mejor descripción de la competencia que una lista de trucos genéricos de indicaciones.

Para un usuario corriente, la competencia puede significar saber qué información se puede introducir, qué resultado requiere comprobación, cómo conservar el material de origen y cuándo detenerse. Puede incluir la capacidad de distinguir una respuesta generada de un pasaje recuperado, de inspeccionar el enlace detrás de una afirmación, de detectar un matiz omitido y de notificar un fallo en términos que otra persona pueda reproducir. Son habilidades prácticas. No exigen que el usuario implemente un transformador, pero sí exigen algo más que creer que el sistema ha leído la política de la organización.

Para un revisor, la competencia incluye la capacidad de cuestionar el resultado. El revisor necesita un conjunto de pruebas que se asemeje al trabajo real, una forma de ver qué evidencia utilizó el sistema y una declaración clara de qué se considera un resultado aceptable. Si la tarea afecta a un derecho público o al sustento de una persona, el revisor también necesita conocimientos suficientes del ámbito para reconocer una respuesta gramaticalmente impecable pero sustancialmente errónea. La fluidez es una propiedad de la interfaz. La competencia es un juicio sobre la tarea.

Para un gestor, la competencia incluye decidir si la tarea debe automatizarse en absoluto. Esa decisión requiere comprender el trabajo que hay detrás de la etiqueta. Una tarea puede ser repetitiva y aun así contener una excepción crucial. Una decisión puede ser rutinaria para un profesional experimentado y aun así ser demasiado trascendente para delegarla sin una vía de recurso visible. Un proceso puede ser técnicamente medible y socialmente inapropiado de optimizar. Los gestores que no se plantean estas preguntas dejan el diseño en manos del proveedor y de los ajustes predeterminados.

Para un ingeniero, la competencia incluye hacer inspeccionable el límite del sistema. ¿Qué versión del modelo se ejecutó? ¿Qué datos estaban disponibles? ¿Qué llamadas a herramientas se permitieron? ¿Qué política o indicación se aplicó? ¿Qué condición de incertidumbre o rechazo se alcanzó? ¿Qué ocurre cuando una fuente está desactualizada, es contradictoria o falta? El personal técnico no tiene que resolver todas las cuestiones de gobernanza, pero sí debe evitar que el sistema borre la información que la gobernanza necesitará más adelante.

Las disposiciones de alto riesgo de la Ley de IA hacen que esto sea concreto. Las preguntas y respuestas de la Comisión señalan que los responsables del despliegue de sistemas de alto riesgo deben garantizar que el personal que trabaja con esos sistemas en la práctica esté formado para manejarlos y para asegurar la supervisión humana. Simplemente colocar instrucciones junto a la herramienta no es suficiente. Las personas que realizan el trabajo necesitan la habilidad y las condiciones prácticas para utilizar el mecanismo de supervisión. Si el operador no puede comprender la salida o no puede interrumpir el proceso, la palabra humano en supervisión humana se convierte en un sustantivo decorativo.

La competencia crece cuando la organización permite que las personas practiquen con limitaciones reales. Un equipo de privacidad puede trabajar con una solicitud hipotética que contenga datos personales y decidir qué puede entrar en el sistema. Un equipo de servicios públicos puede ensayar una denegación y una escalada sin utilizar el caso de un residente real. Un equipo de producto puede reproducir un modelo modificado frente a un conjunto de evaluación fijo y discutir qué diferencias importan. Estos ejercicios no son evidencia de que un despliegue futuro será seguro. Son un ensayo para las decisiones que la seguridad requiere.

Hay un límite importante. La competencia no puede compensar la falta de evidencia. Un revisor altamente cualificado no puede verificar una afirmación cuando la fuente ha desaparecido, ni un operador bien formado puede anular un sistema si la interfaz no ofrece ninguna opción de anulación. La formación puede exponer la ausencia, pero no puede llenarla por la fuerza del entusiasmo. Las organizaciones a veces responden a un control que falta programando otro curso. El calendario se convierte en un monumento al control que nunca se construyó.

La autoridad es la mitad que falta

La autoridad es la parte de la alfabetización en IA que las organizaciones prefieren dejar implícita. Se refiere a quién puede decidir, quién puede negarse, quién puede pausar un proceso, quién puede modificar una regla y quién asume las consecuencias cuando un sistema se equivoca. La autoridad no es lo mismo que la antigüedad. Una persona con antigüedad puede aprobar un sistema y aun así no poder inspeccionar su evidencia. Un trabajador de primera línea puede ver un problema primero y aun así que le digan que solo un proveedor puede cambiarlo.

La supervisión humana a menudo se describe como si una persona de pie junto a un panel de control fuera suficiente. No lo es. La supervisión necesita una persona con el tiempo, el conocimiento y la autoridad para comprender la salida, reconocer cuándo está fuera del alcance e intervenir. Los requisitos de alto riesgo de la Ley de IA hacen explícito el punto de la formación, pero el principio subyacente se aplica más ampliamente. Una persona no puede ejercer supervisión sobre un proceso que trata la intervención como un fallo de eficiencia.

Considere un servicio de vivienda hipotético que utiliza una herramienta para clasificar las solicitudes entrantes para su revisión. Al sistema se le puede permitir sugerir un orden, pero la organización aún tiene que decidir qué sucede cuando el registro de origen está incompleto, cuando las circunstancias de un residente no encajan en las categorías o cuando la regla de ordenación entra en conflicto con un deber legal. Un equipo alfabetizado no solo sabe que el modelo puede equivocarse. Sabe quién puede detener la cola, quién puede hacer una excepción, qué registro se conserva y cómo se informa al residente de lo sucedido. El ejemplo es deliberadamente hipotético. Su propósito es mostrar que la autoridad es una propiedad del flujo de trabajo, no un rasgo de personalidad.

La autoridad también tiene una dirección inversa. Las personas afectadas por un sistema necesitan una vía para cuestionarlo, incluso cuando nunca eligieron el sistema. Un cliente, estudiante, paciente, solicitante o residente puede no necesitar comprender las matemáticas internas del modelo. Sí necesitan saber si una máquina estuvo involucrada, qué tipo de decisión influyó, qué oficina humana puede revisar el resultado y qué información ayudaría a esa revisión. La alfabetización pertenece tanto a la persona que recibe el resultado como a la persona que opera la herramienta.

Por eso la escalada no es un castigo. Es una vía de información para los casos que la ruta automatizada no puede absorber con seguridad. Un registro de escalada útil indica qué se le pidió al sistema, qué evidencia vio, qué devolvió, por qué se cuestionó el resultado y quién decidió qué ocurrió después. No necesita convertir cada interacción ordinaria en un expediente legal. Sí necesita conservar el contexto suficiente para que un fallo repetido se haga visible en lugar de descartarse como una queja aislada de un usuario.

La autoridad debe ensayarse antes del despliegue. ¿Quién pulsa el botón de detención? ¿Quién puede aprobar un modelo nuevo? ¿Quién puede cambiar un umbral? ¿Quién es el responsable de una fuente de datos en disputa? ¿Quién puede comunicar a un proveedor que una salida no es aceptable? ¿Quién informa a las personas afectadas? ¿Quién decide si el sistema vuelve a funcionar después de un incidente? Si las respuestas son nombres en lugar de roles, el planteamiento es frágil. Las personas se van, cambian de puesto o están en una reunión. Los roles pueden sobrevivir a un calendario.

La respuesta más humana no siempre es delegar más decisiones en un profesional ya ocupado. La autoridad tiene un coste. Exige tiempo, acceso a la evidencia, respaldo de la dirección y un proceso que no castigue la negativa prudente. Si una organización concede una autoridad nominal sin estas condiciones, crea un chivo expiatorio en lugar de una supervisión. La persona pasa a ser responsable de un resultado que no estaba en condiciones de influir. Es un patrón de gestión conocido con una interfaz nueva.

La disciplina de las fuentes que sustenta cada respuesta

La alfabetización en IA suele centrarse en las salidas porque las salidas son lo que la gente ve. La parte más difícil es aprender a preguntar qué entró en el sistema. Una respuesta generada puede ser fluida mientras el conjunto de fuentes está desactualizado, incompleto, no autorizado o mezclado con material que nunca debió guiar la tarea. Un sistema de recuperación puede devolver un párrafo relevante de una versión equivocada de una política. Un resumen puede omitir la frase que contiene una excepción. Un prompt puede contener una instrucción disfrazada de documento. La disciplina de las fuentes es el hábito de tratar las entradas como material sujeto a normas, no como contexto conveniente.

Las personas no necesitan conocer todos los detalles de implementación para practicar la disciplina de las fuentes. Sí necesitan hacerse un conjunto breve de preguntas. ¿Cuál es la fuente? ¿Quién es su responsable? ¿Cuándo era válida? ¿Es autoritativa para esta tarea? ¿Se ha transformado? ¿Puede el sistema mostrar el pasaje o el registro que dio forma a la respuesta? ¿Qué datos se excluyeron y por qué motivo? ¿Qué debería ocurrir cuando dos fuentes discrepan? Estas preguntas son útiles tanto para un asistente de políticas como para una herramienta de búsqueda clínica, un compañero de código o un servicio público de información.

Una fuente no es autoritativa solo porque sea fácil de recuperar. Las carpetas compartidas contienen borradores. Las bases de datos contienen duplicados. Un resumen generado por un modelo puede haberse indexado como si fuera un registro primario. Una traducción puede haber perdido un matiz jurídico. Un documento puede estar vigente y aun así quedar fuera de la finalidad para la que el sistema tiene permitido usarlo. La alfabetización convierte estas distinciones en parte del trabajo habitual, no en una preocupación especializada que solo aparece después de una queja.

La disciplina de las fuentes también cambia la forma de hablar de la confianza. Una salida con alta confianza no es una prueba sólida si falta la fuente pertinente. Una salida prudente puede ser el resultado responsable cuando el conjunto de fuentes está incompleto. La organización no debería entrenar a los usuarios para premiar la certeza fluida y castigar una negativa útil. Si el sistema no puede responder dentro de la evidencia permitida, el siguiente paso puede ser localizar al responsable de la fuente, pedir un juicio humano o acotar la pregunta.

The source path should be visible at the right level. A user may need a link to the policy passage. A reviewer may need the version and transformation history. An auditor may need the complete input lineage. The information can be layered without being hidden. A tool that shows only a green confidence badge asks the user to trust an abstraction. A tool that shows the evidence and its limits lets the user exercise judgement.

This is also a literacy issue for procurement. A buyer should ask whether the supplier can describe the data boundary, export records, preserve version history, and explain what happens when a source is withdrawn. These are not only technical requirements. They determine whether the organisation can learn from an error. If the contract gives the buyer an answer but not the evidence behind it, the buyer has purchased prose and retained the risk.

Escalation is a form of knowledge

Organisations often treat escalation as a sign that the system has failed to deliver efficiency. A better view is that escalation is how the organisation learns where automation stops being trustworthy. Every escalation contains information about the boundary between the task and the world. The case may be unusual, the source may be defective, the policy may be ambiguous, the interface may have hidden a condition, or the workflow may have assigned authority to the wrong person.

A good escalation route is specific. It tells the user what to record, who receives the case and what response to expect. It distinguishes a missing source from a suspected harmful output, and a technical outage from a policy conflict. The distinction is not paperwork for its own sake. It allows the organisation to repair the correct layer. Re-training a model cannot fix a missing legal source. Updating a policy cannot fix an interface that gives nobody the ability to stop.

Escalation must be safe for the person who uses it. If a worker is measured only on speed, every escalation looks like a personal cost. If a public-service employee risks criticism for delaying a case, the system will accumulate silent overrides rather than visible records. Management has to make the prudent route legitimate. The alternative is a culture in which people are literate enough to see the problem and disciplined enough to hide it.

The European Commission’s own internal measures, described in its Article 4 questions and answers, are instructive because they extend beyond a single course. The Commission says it has developed an internal competency framework for basic AI literacy, learning packages for different groups including generalists, managers and developers, a portal with tool-specific resources, question-and-answer sessions, a community of practice, a monthly newsletter and an AI Champions network. These are not presented as a universal template, and the Commission notes that its internal framework may change as common objectives evolve. The important idea is the network: knowledge has a route through the organisation.

A community of practice is useful because it turns isolated questions into shared memory. A person can ask why a system behaved oddly, compare the answer with another team’s experience, and find someone who understands the domain. That does not replace formal ownership. It makes ownership easier to locate. A newsletter can point to a new risk, but it cannot decide whether a local workflow should change. An AI champion can help a team learn, but should not become the only person who knows how the system works.

La escalada también debería retroalimentar la formación. Si la misma confusión aparece repetidamente, ya no se trata de una laguna de conocimiento individual. Puede significar que la interfaz induce a error, que la política no es clara, que la evidencia no está expuesta o que el límite de funciones es incorrecto. La organización puede entonces actualizar la capa correspondiente. La formación es una opción. Una etiqueta mejor, un valor predeterminado más seguro, un registro adicional o una ruta de aprobación modificada pueden ser más eficaces.

Esa retroalimentación es el motivo por el que la metáfora del músculo importa. Un músculo crece con la resistencia. Las escaladas son la resistencia en un flujo de trabajo de IA. Elimínelas para que el panel parezca tranquilo y la organización perderá las señales que la habrían fortalecido. Un sistema silencioso puede ser saludable. También puede ser un sistema cuyos usuarios han dejado de informar de lo que ven.

Los hábitos pesan más que los eventos

Un curso es un evento. La alfabetización es un patrón de pequeños comportamientos que se repiten antes, durante y después de usar un sistema. Antes de usarlo, las personas identifican la tarea, el propósito, los datos permitidos, las personas afectadas y la autoridad que sigue siendo humana. Durante el uso, comprueban la evidencia, detectan la incertidumbre, registran las decisiones importantes y escalan cuando el sistema sale de su límite. Después del uso, revisan los resultados, conservan los registros pertinentes y reparan la fuente, la política, la formación o el sistema cuando el mismo problema vuelve a aparecer.

Estos hábitos deben estar integrados en el trabajo. Una indicación que pida la fuente detrás de una respuesta es más útil que un cartel que diga sea crítico. Un campo obligatorio para la persona responsable de la decisión es más útil que una diapositiva de formación sobre la rendición de cuentas. Un control de detención visible es más útil que un párrafo que recuerde al personal que conserva la responsabilidad. Los controles no sustituyen al criterio, pero pueden facilitar que se ejerza un buen criterio un martes por la tarde.

Los hábitos también deben adaptarse al ritmo del trabajo. Una oficina de información pública no puede completar una auditoría larga para cada borrador de bajo impacto. Un flujo de trabajo crítico para la seguridad no puede tratar una comprobación visual rápida como una supervisión significativa. La organización debe definir niveles de evidencia y revisión que se correspondan con la tarea y sus posibles consecuencias. La cuestión es la proporcionalidad, no el minimalismo. Una tarea pequeña con un gran efecto sobre otra persona merece más cuidado que una tarea grande sin consecuencias significativas.

Existe una diferencia útil entre una regla y un hábito. Una regla dice no introduzca datos confidenciales en una herramienta no aprobada. Un hábito pregunta, antes de abrir la herramienta, qué datos son realmente necesarios y si el propósito permite su uso. Una regla dice que una persona debe revisar una recomendación. Un hábito pregunta si quien revisa tiene la evidencia, el tiempo y la autoridad para que esa revisión sea real. Una regla dice informe de los incidentes. Un hábito detecta los cuasi accidentes antes de que se conviertan en incidentes notificables y los trata como material de aprendizaje.

Los hábitos pueden observarse sin convertir a las personas en sujetos de vigilancia. La organización puede comprobar si un flujo de trabajo expone su fuente, si se utiliza una ruta de escalada, si los cambios en el modelo desencadenan una revisión y si los registros pueden reproducirse. No debe confundir un número elevado de clics con un alto nivel de alfabetización. Una persona puede marcar todas las casillas y aun así malinterpretar la decisión. La observabilidad es útil cuando mide las condiciones para el juicio, no cuando recompensa la apariencia de cumplimiento.

El repositorio de prácticas de alfabetización de la Oficina de IA sigue esta lógica práctica. La Comisión describe más de cuarenta iniciativas de empresas y del sector público, incluidos el aprendizaje electrónico, la formación presencial, los bootcamps y la colaboración entre la industria y el mundo académico. También afirma que copiar una práctica del repositorio no crea automáticamente una presunción de cumplimiento. Ese descargo es importante. Una práctica puede ser una idea útil sin ser prueba de que otra organización ha gestionado su propio contexto.

Lo que puede tomarse prestado es el hábito de preguntarse cómo una práctica está conectada con el trabajo. ¿Llega a las personas que operan el sistema? ¿Cubre los riesgos de la tarea? ¿Da a las personas una vía para cuestionar y corregir? ¿Cambia cuando el sistema o el contexto cambian? ¿Crea un registro que ayude a la organización a aprender? El formato puede variar. Las preguntas deben permanecer.

Las personas sobre las que se utiliza un sistema

La alfabetización en IA suele dirigirse al personal porque es la audiencia más fácil de reunir en una sala. La ley y el interés público son más amplios. La explicación de la Comisión pide a las organizaciones que consideren a las personas o grupos sobre los que se utilizan sus sistemas. Esa frase mantiene a la persona afectada dentro de la conversación de diseño incluso cuando nunca ve el modelo, nunca consintió el despliegue y nunca recibió la invitación a la formación.

Para las personas afectadas, la alfabetización significa un tipo diferente de acceso. Puede que necesiten saber que un sistema automatizado ha influido en un servicio, qué tipo de influencia tuvo, qué información se consideró y cómo solicitar una revisión. Los derechos y avisos exactos dependen del sistema y de la ley aplicable. El principio general es estable: una persona no debería tener que entender el aprendizaje automático antes de poder impugnar una decisión que le importa.

La comunicación forma parte del control. Un aviso lleno de términos técnicos puede ser formalmente transparente y prácticamente inútil. Una explicación breve que nombre el propósito, la vía humana y la limitación puede hacer más por la capacidad de actuar. La organización debería probar la explicación con las personas que la necesitan, no solo con los ingenieros que construyeron el sistema. La claridad no es una cualidad decorativa. Decide si una impugnación puede comenzar.

El lenguaje también importa aquí. La guía de la UNESCO sitúa la diversidad lingüística y cultural dentro de su enfoque centrado en las personas para la IA generativa. Un aviso traducido puede seguir fallando si pierde la distinción entre una invitación y una obligación, o si utiliza un término que las personas no reconocen en el servicio al que intentan acceder. La alfabetización incluye, por tanto, la capacidad de preguntar si el mensaje sobrevivió a la traducción y si la persona puede usarlo para actuar.

Las instituciones públicas deberían ser especialmente cuidadosas con la idea del uso informado. Las personas no se vuelven informadas porque una página web incluya una divulgación. Se vuelven informadas cuando la explicación llega en el punto donde afecta a su elección, cuando la vía humana es real y cuando la institución puede mostrar qué hizo con la información que recibió. La carga es mayor cuando la institución tiene poder y la persona no tiene una alternativa práctica.

Las empresas se enfrentan al mismo problema en los servicios de atención al cliente y de empleo. Una empresa puede formar a fondo a su personal y aun así dejar a los clientes sin poder entender por qué una puntuación afectó a su solicitud. Un lugar de trabajo puede formar a los directivos y aun así dejar a los trabajadores sujetos a un sistema de programación que no pueden cuestionar. La alfabetización está incompleta cuando la organización entiende su herramienta pero la persona que soporta sus consecuencias se queda con una caja negra y un formulario de contacto genérico.

Diseñar para las personas afectadas también mejora el sistema. Las preguntas de residentes, pacientes, solicitantes y trabajadores a menudo revelan suposiciones que las pruebas internas pasaron por alto. La cuestión no es si cada queja es correcta. La cuestión es si la organización puede distinguir un desacuerdo individual de un patrón que señala una fuente de datos defectuosa, un umbral injusto o una explicación engañosa. Una vía para la impugnación es también una vía para la evidencia.

Una institución pública debe enseñar sus propios límites

Las instituciones públicas tienen una función docente incluso cuando no se consideran a sí mismas educadoras. Cada servicio automatizado enseña a las personas lo que la institución considera normal, demostrable y cuestionable. Un sistema que solo acepta pruebas estructuradas enseña a los ciudadanos que sus vidas deben ajustarse a un formulario. Un sistema que devuelve una explicación generada sin una vía humana les enseña que la institución ha delegado su responsabilidad. Un sistema que declara claramente sus límites enseña una lección distinta: la tecnología puede ayudar a una función pública, pero no la sustituye.

Las directrices éticas actualizadas de la Comisión Europea para el uso de la IA y los datos en la enseñanza y el aprendizaje ofrecen un ejemplo público y concreto de esta labor docente. Las directrices se dirigen principalmente a docentes y personal educativo, tanto a quienes tienen poca o ninguna experiencia previa como a quienes poseen competencias digitales avanzadas. La actualización de 2026 añade escenarios prácticos, un glosario actualizado y el contexto jurídico que abarca la AI Act y el RGPD. La forma es educativa, pero el principio se traslada bien: las personas necesitan definiciones, preguntas y ejemplos que les ayuden a tomar una decisión basada en el contexto.

Las directrices no convierten a los docentes en responsables de cumplimiento normativo. Ayudan al personal educativo a comprender los posibles beneficios, los riesgos ocultos y las responsabilidades que conlleva el uso de la IA y los datos en el entorno de los estudiantes. Esa distinción es importante. Una buena alfabetización no convierte a un profesional en alguien que desconfía de toda herramienta. Le proporciona la comprensión suficiente para decidir dónde una herramienta ayuda, dónde necesita límites y dónde la relación humana debe seguir siendo primordial.

Un consejo escolar hipotético ilustra la diferencia. Si compra un asistente de redacción y ofrece una demostración general, los docentes pueden aprender a producir material con rapidez. Si además pregunta qué datos de los estudiantes entran en el sistema, cómo se comprueba el material generado, cómo puede un alumno impugnar una marca automatizada y quién puede detener la herramienta, el consejo está construyendo competencia institucional. La segunda conversación puede ser más lenta. También es la conversación que hace responsable a la primera.

Las instituciones públicas deberían publicar su propio aprendizaje en la medida en que lo permitan la confidencialidad y la seguridad. Una breve descripción del propósito de un sistema, sus límites probatorios, su vía de revisión y sus limitaciones conocidas puede ayudar a los ciudadanos, al personal y a los proveedores a hablar del mismo objeto. La documentación pública también ofrece a la sociedad civil y a los órganos de supervisión algo concreto que cuestionar. Una vaga promesa de innovación responsable deja que todos discutan sobre el tono.

Hay una dimensión democrática en todo esto. La alfabetización en IA se describe a veces como un programa de capacitación laboral, como si los ciudadanos fueran solo futuros empleados. Los ciudadanos también son votantes, pacientes, inquilinos, padres, solicitantes, vecinos y personas cuyos datos aparecen en el flujo de trabajo de otra persona. Su capacidad para comprender y cuestionar los sistemas automatizados forma parte de la capacidad pública necesaria para el control democrático. Una sociedad que solo puede hablar de la IA a través de demostraciones de proveedores ha externalizado su vocabulario.

La educación es un ensayo organizativo

Las escuelas y las universidades son lugares naturales para hablar de la alfabetización en IA, pero la lección no debería quedarse en el aula. La orientación de la UNESCO señala que la IA generativa cambia más rápido que muchos marcos normativos nacionales y pide que la capacidad humana siga ese ritmo. Esa no es una razón para meter a toda prisa cada herramienta en la enseñanza. Es una razón para enseñar a las personas a evaluar herramientas, proteger datos, reconocer límites y preguntarse quién se beneficia de un uso concreto.

La Comisión Europea y la OCDE presentaron en junio de 2026 un marco de alfabetización en IA para la educación primaria y secundaria. El marco se describe como una referencia común para centros educativos, docentes, directivos, responsables políticos y diseñadores de aprendizaje, con margen para adaptarse a los contextos locales. Una referencia común resulta útil porque reduce la tentación de definir la alfabetización como aquella función que un proveedor determinado vende. La adaptación es igualmente importante porque un centro educativo, un instituto de investigación y un servicio público no se enfrentan a las mismas tareas ni atienden a las mismas personas.

La educación puede modelar los hábitos que las organizaciones necesitarán después. El alumnado puede comparar una explicación generada con una fuente, documentar qué ha cambiado, cuestionar una respuesta segura de sí misma y debatir cuándo debe seguir siendo responsable un ser humano. El profesorado puede hacer visible la incertidumbre en lugar de tratarla como un fallo de la clase. Los equipos directivos pueden incorporar las cuestiones de contratación y de datos a la decisión, en lugar de dejarlas en manos de una persona entusiasta con una cuenta gratuita.

Estas prácticas no pretenden que los niños y las niñas asuman la gobernanza de los sistemas comerciales. Pretenden dotar a las personas de un vocabulario duradero antes de incorporarse a entornos laborales e instituciones públicas donde lo que está en juego puede ser mayor. Las personas adultas necesitan la misma oportunidad. Un directivo que aprendió a contrastar las fuentes en la escuela puede aplicar ese hábito en una reunión de contratación. Una ciudadana que sabe que un modelo puede equivocarse pero aun así influir puede pedir la vía correcta dentro de un servicio público.

La educación también demuestra por qué la alfabetización no puede reducirse a la competencia técnica. Un docente puede aprender cómo genera texto un modelo y aun así tener que decidir si su uso cambia la relación con un alumno. Una investigadora puede comprender el proceso de entrenamiento de un modelo y aun así tener que comprobar los derechos y los consentimientos en los datos. Un estudiante puede manejar un sistema de forma impresionante y aun así tener que reconocer cuándo ese sistema no es una fuente adecuada. El juicio humano es una habilidad, no un residuo que queda después de la lección técnica.

Las universidades y los colegios profesionales pueden ayudar conectando disciplinas. La alfabetización en IA pertenece al derecho, la gestión de datos, el diseño, la ética, el trabajo, la administración pública, la salud y la ingeniería, no a una sala donde una especialidad explica el futuro a las demás. El objetivo no es convertir a cada persona en experta en todos los campos. Es hacer posible que las personas expertas reconozcan dónde termina su propio campo y dónde hay que invitar a otro.

Lo que la Comisión se aplica a sí misma

Existe una diferencia útil entre una política que dice a otros qué hacer y una institución que describe lo que hace internamente. Las preguntas y respuestas del artículo 4 de la Comisión incluyen lo segundo. Describen una política interna para una plantilla con competencias en IA, un marco básico de competencias en alfabetización en IA, paquetes de aprendizaje para personal generalista, mandos intermedios y personal de desarrollo, recursos específicos por herramienta, sesiones de preguntas y respuestas, una comunidad de práctica, un boletín mensual y una red de personas embajadoras de la IA.

Nada de esto debe tratarse como una plantilla mágica. La propia Comisión afirma que el marco interno puede cambiar a la luz de futuras recomendaciones. Las prácticas son un ejemplo de una institución que trata la alfabetización como un sistema de apoyo y no como un evento único. Un marco proporciona lenguaje. Los distintos paquetes de aprendizaje reconocen distintos roles. La orientación específica por herramienta conecta el aprendizaje con el trabajo. Una comunidad da salida a las preguntas. Las personas embajadoras crean una vía a través de la organización sin convertirse en las únicas depositarias del conocimiento.

El ejemplo contiene también una advertencia silenciosa. El programa se describe en términos de aprendizaje fomentado y recursos prácticos, no como prueba de que cada empleado pueda realizar con seguridad todas las tareas de IA. Ese es el límite honesto. Una organización puede desarrollar capacidades y aun así tener carencias. Puede ofrecer formación y aun así descubrir que un flujo de trabajo carece de una anulación. Puede publicar orientación y aun así necesitar revisarla cuando cambia una herramienta, una ley o una tarea.

El repositorio público de la Comisión hace explícito ese mismo límite. Reúne ejemplos para apoyar el aprendizaje y el intercambio, pero reproducir una práctica no crea automáticamente una presunción de cumplimiento. Merece la pena repetir esa frase porque las organizaciones suelen copiar un formato visible y dejar atrás el razonamiento invisible. Un taller intensivo puede ser útil en un lugar e irrelevante en otro. Un módulo de aprendizaje electrónico puede llegar a todos y no cambiar a nadie. Una comunidad de práctica puede florecer en un entorno de investigación y necesitar una forma distinta en un centro de atención al público.

La cuestión práctica para cualquier organización no es si su programa se parece al de la Comisión. Es si las personas pueden usar lo que aprendieron en el momento en que el sistema les pide que emitan un juicio. Si pueden, el programa está conectado con el trabajo. Si no pueden, la organización ha construido una biblioteca sin puerta.

Un mapa de capacidades para una organización corriente

Conviene mapear la alfabetización por capacidades y no por asistencia. El mapa debe mostrar qué necesita hacer la organización, quién realiza cada parte, qué evidencia la respalda y qué autoridad sigue siendo humana. Una organización pequeña puede dibujarlo en una página. Una más grande puede necesitar un registro conectado a sistemas, roles y ciclos de revisión. La forma importa menos que mantener visibles las relaciones.

La primera capacidad es el reconocimiento. La organización puede enumerar los sistemas de IA que proporciona, despliega o utiliza en nombre de otra persona, y describir su finalidad en lenguaje corriente. Sabe qué herramientas son experimentales, cuáles están aprobadas, cuáles están integradas en un servicio de un proveedor y cuáles entraron a través de una cuenta individual. El reconocimiento no es vigilancia de la curiosidad de cada empleado. Es una forma de impedir que un uso trascendente se oculte tras una categoría de contratación o una solución entusiasta.

La segunda es la evidencia. Para cada tarea, la organización sabe qué datos recibe el sistema, qué fuentes son autorizadas, cómo se comprueban la actualidad y los permisos, y qué registros sobreviven a la transformación. Puede distinguir una sugerencia generada de un registro de origen y un resultado de evaluación de un resultado de producción. La evidencia es la parte de la alfabetización que convierte una afirmación en algo que otra persona pueda inspeccionar.

La tercera es el juicio. La organización puede indicar qué acciones puede realizar el sistema, cuáles puede sugerir y cuáles siguen siendo decisiones humanas. Define las condiciones que exigen una negativa, una escalada o una revisión. Hace visible la disyuntiva cuando un camino más rápido ofrece menos evidencia o menos oportunidad de impugnación. El juicio no es un argumento contra la automatización. Es la parte del diseño que dice para qué sirve la automatización.

La cuarta es la autoridad. Se asignan roles para la aprobación, la supervisión, la titularidad de los datos, la gestión de incidentes, la comunicación con las personas afectadas, la impugnación al proveedor y la retirada. Los roles tienen acceso y tiempo. Una persona con un título pero sin vía para detener o cambiar el sistema no es un mecanismo de supervisión. Un buzón de escalada sin responsable es un buzón de sugerencias con traje formal.

La quinta es el aprendizaje. La organización registra qué preguntaron las personas, dónde falló el sistema, qué supuestos cambiaron y qué se reparó. Actualiza la formación cuando cambia la tarea, pero también cambia la interfaz, la vía de evidencia, la política o el contrato cuando esa es la mejor solución. El aprendizaje no es un informe retrospectivo que se guarda junto al sistema. Es el sistema volviéndose más honesto sobre sus límites.

Un mapa de capacidades mantiene visibles a las personas, la evidencia y la autoridad que rodean a un sistema de IA. Es un mapa del trabajo, no un registro de asistentes.

Cómo lograr que el ciclo sobreviva a un trimestre ajetreado

La mayoría de los programas de alfabetización fracasan de la manera más corriente. El lanzamiento cuenta con buena asistencia, los materiales están pulidos y, de pronto, vuelve el trabajo urgente. Llegan nuevas herramientas a través de un proveedor, un equipo copia un prompt de otro equipo, cambia una política o aparece una actualización del modelo en una nota de versión. La organización sigue hablando de alfabetización como si el curso original siguiera presente. No lo está. El sistema se ha movido mientras el aprendizaje permanecía quieto.

La primera protección es un desencadenante claro para la revisión. Un cambio en el modelo, la fuente de datos, el propósito, la población afectada, el proveedor, el umbral o la ruta humana debería llevar a alguien a preguntarse si la práctica existente sigue siendo adecuada. El desencadenante no tiene que crear un comité para cada cambio menor. Tiene que evitar que un cambio material se trate como mantenimiento cuando altera la autoridad o el riesgo.

La segunda protección es la propiedad local. Una oficina central de IA puede ofrecer orientación, pero la persona más cercana a la tarea suele ver primero el desajuste entre el sistema y el trabajo. Esa persona necesita una ruta designada para hacer preguntas, informar de un problema y recibir una respuesta. La propiedad local también evita que el programa se convierta en un conjunto de principios abstractos que nadie pueda traducir al caso de mañana.

La tercera protección es un pequeño conjunto de preguntas reutilizables. ¿Qué está haciendo el sistema? ¿Qué evidencia está utilizando? ¿Qué puede cambiar? ¿A quién afecta? ¿Qué nos haría detenernos? ¿Quién puede cambiarlo? ¿Qué registro nos permitirá entender el resultado más adelante? Estas preguntas pueden aparecer en la contratación, la revisión de diseño, la orientación al personal, un aviso público, un formulario de incidentes y un ejercicio de formación. La repetición no es un defecto cuando la pregunta es el control.

La cuarta protección es el tiempo. Las organizaciones suelen pedir a las personas que ejerzan su criterio en los huecos entre otras tareas. Eso hace que la acción correcta parezca ineficiente. Si se espera que un revisor verifique una recomendación generada, la carga de trabajo debe incluir esa verificación. Si se espera que un trabajador eleve una preocupación, el horario debe permitirlo. Si se espera que un responsable revise un nuevo modelo, el puesto debe incluir la revisión. De lo contrario, la organización habrá convertido la alfabetización en una actividad voluntaria y se sorprenderá cuando escaseen los voluntarios.

La quinta protección es un final visible del bucle. Una escalada no debe desaparecer en una bandeja de entrada. La persona que la planteó debe saber si el caso fue aceptado, qué cambió y quién asume el siguiente paso, con los límites de privacidad y seguridad. Un pequeño acuse de recibo puede tener más fuerza que otra política porque demuestra que la organización trata el criterio como parte del trabajo, no como una interrupción del mismo.

Las métricas pueden ayudar, pero deben elegirse con cuidado. Cuente cuántos sistemas tienen un responsable, cuántas tareas tienen un límite de evidencia declarado, cuántos cambios activaron una revisión, cuántas escaladas recibieron respuesta y con qué frecuencia se reparó una fuente o una política. No utilice porcentajes de finalización como indicador de comprensión. Un cien por cien de finalización puede coexistir con cero autoridad. Un porcentaje más bajo puede revelar que la organización ha dejado por fin de fingir que una sola lección sirve para todos.

La mejor medida no es un número. Es la calidad de la siguiente pregunta. Tras el programa, ¿puede un equipo cuestionar un resultado seguro sin que le digan que el modelo es solo una herramienta? ¿Puede identificar la fuente y la evidencia que falta? ¿Puede decir qué haría que el flujo de trabajo se detuviera? ¿Puede una persona afectada llegar a una revisión humana? ¿Puede la organización cambiar el sistema sin perder el historial de lo ocurrido? Si la respuesta mejora, el músculo se está ejercitando.

Lo que un certificado no puede decirle

Un certificado puede decirle que una persona completó una actividad identificada. Eso puede ser útil para la orientación, el registro o el desarrollo profesional. No puede decirle si la actividad coincidía con el sistema que tenía delante la persona, si esta tuvo ocasión de practicar, si la organización expuso su evidencia, si la autoridad era real o si el sistema cambió después. Esas preguntas pertenecen a la organización y al trabajo.

La distinción no es un argumento contra los cursos. Los cursos pueden ofrecer un punto de partida común, especialmente cuando se necesita rápidamente un vocabulario nuevo. Pueden explicar mecanismos, contexto jurídico y riesgos recurrentes. Pueden ayudar a quienes han quedado excluidos de las conversaciones técnicas a entrar en ellas sin tener que fingir que ya saben las respuestas. El problema comienza cuando el curso se trata como el resultado y no como un instrumento dentro de una práctica más amplia.

Un buen curso debería hacer más exigente el siguiente uso. Debería dejar a las personas con preguntas que puedan formular, evidencia que puedan inspeccionar, límites que puedan enunciar y vías que puedan utilizar cuando el sistema no basta. Debería hacer que un responsable se sienta menos cómodo ante una afirmación vaga y que un trabajador tenga más confianza en una negativa prudente. Debería hacer más visibles las propias lagunas de la organización. El aprendizaje que solo produce confianza no ha producido necesariamente alfabetización.

La redacción actual de la ley ayuda porque se niega a definir una única línea de meta para cada persona. El artículo 4 pide ahora a los proveedores y a los responsables del despliegue que adopten medidas que favorezcan el desarrollo. El considerando de la enmienda dice que la alfabetización debería ser una prioridad estratégica con independencia de las obligaciones reglamentarias y de las posibles sanciones. Esa es una base más sólida que una carrera hacia una puntuación universal. Dice a las organizaciones que desarrollen capacidad porque su trabajo lo exige, no porque un certificado pueda acallar una lista de verificación.

Nuestra pequeña nota

En Dweve, nuestra pequeña contribución es Ground truth, una guía ciudadana gratuita y basada en el navegador sobre la IA. No es un certificado y no puede alfabetizar a una organización por sí sola. Es un lugar donde practicar el vocabulario compartido que se describe aquí: qué hace un sistema, qué evidencia utiliza, qué límites importan y dónde permanece el juicio humano. Lo mencionamos como ejemplo del material que creamos, no como prueba de un resultado organizativo. La prueba tiene que aparecer en el trabajo, en las preguntas que hace la gente y en las decisiones que se les permite cambiar.

La lección

La alfabetización en IA no es el momento en que una persona termina un curso. Es el momento en que una organización puede ver lo que hacen sus sistemas y puede seguir actuando cuando la respuesta es incierta. La conciencia nombra el sistema y su contexto. La competencia conecta el conocimiento con una tarea y su evidencia. La autoridad hace posible el juicio y la intervención. Los hábitos mantienen vivas esas capacidades cuando cambian la herramienta, la política, los datos o las personas.

La posición europea es cada vez más clara. El artículo 4 de la Ley de IA sigue siendo una responsabilidad organizativa, pero la legislación actual no prescribe un nivel individual ni un certificado concretos. La orientación de la Comisión apunta al contexto, el riesgo, el rol y las personas afectadas. Su propio programa interno combina marcos, aprendizaje específico por rol, orientación sobre herramientas, una comunidad y una vía para las preguntas. Las directrices educativas y la orientación de la UNESCO sitúan la capacidad humana, los derechos y el uso significativo junto a la comprensión técnica. Ninguna de estas fuentes promete un atajo. Ese es precisamente su valor.

Para un organismo público, el trabajo consiste en hacer visible y utilizable la vía humana. Para una empresa, en conectar la formación con la evidencia, la responsabilidad y la capacidad de rechazar un flujo de trabajo deficiente. Para una escuela, en enseñar a las personas a cuestionar un sistema antes de que el sistema les pida que confíen en él. Para una persona afectada por una decisión, en tener una forma de entender lo que ha ocurrido y solicitar una revisión sin tener que aprender primero el vocabulario del proveedor.

El músculo crece cuando la organización practica antes de que llegue la consecuencia: reconocer, cuestionar, comprobar, decidir, escalar y reparar. No habrá un certificado final que diga que el trabajo está hecho. Eso no es una laguna en el programa. Es el punto. Un sistema vivo necesita un juicio vivo, y el juicio vivo es algo que una organización tiene que seguir ejercitando.

Fuentes