Por Rafael Luque Ocaña

Cambias la finalidad de un sistema: ¿qué deja de ser cierto en todo lo que habías documentado?

Las obligaciones del Art. 26 están encadenadas. La clasificación decide quién supervisa, que decide qué registros importan, que decide a quién hay que informar. Cambia el primer eslabón y decae la mitad — sin que nada lo señale.

Casi todo lo que se escribe sobre gobernanza de IA describe cómo llegar a un estado: clasificar, documentar, designar responsables, guardar registros. Poco describe qué pasa después, cuando algo cambia.

Y cambia constantemente. Lo interesante es que el Art. 26 está construido en cadena, así que un cambio en un extremo hace decaer cosas en el otro — y en un proceso llevado a mano, nada señala qué quedó afectado.

La cadena, leída de arriba abajo

Léanse las obligaciones del responsable del despliegue en orden y aparece una dependencia que el artículo no explicita pero que su estructura impone:

La finalidad prevista determina la clasificación del sistema. La clasificación determina si el Art. 26 aplica siquiera. Si aplica, el 26(1) obliga a usarlo con arreglo a sus instrucciones con medidas técnicas y organizativas; el 26(2), a encomendar la supervisión a personas concretas; el 26(6), a conservar los registros que genere; y el 26(7), a informar a los trabajadores expuestos.

Cada eslabón se apoya en el anterior. Y de ahí sale la pregunta que casi nadie se hace: si cambia el primero, ¿qué pasa con los otros cuatro?

Tres cambios corrientes y su onda

Cambia la finalidad de uso. Una herramienta que ordenaba candidaturas por criterios administrativos pasa a puntuarlas por adecuación. La finalidad prevista es otra, luego la clasificación puede ser otra, luego puede aplicar el Art. 26 donde antes no aplicaba — y con él la designación de supervisión, los registros y la información a los trabajadores. Un cambio que en la práctica es activar una casilla del producto.

Cambia quién supervisa. La persona designada por el 26(2) se marcha o cambia de puesto. La obligación no se marcha con ella. Pero el documento que la nombraba sigue diciendo su nombre, y nada lo marca como caducado — y si la persona que queda no puede parar el sistema, la designación es nominal.

Cambia el sistema por debajo. El proveedor publica una versión con funciones nuevas. Las instrucciones de uso son otras, luego el «uso con arreglo a las instrucciones» del 26(1) se mide contra un texto distinto del que se leyó al desplegarlo.

En los tres casos, lo documentado sigue existiendo, legible y firmado. Solo ha dejado de describir la realidad.

Por qué a mano no se propaga

No es cuestión de diligencia. Es que la información necesaria para propagar no está en ningún sitio.

Para saber qué decae al cambiar la finalidad de un sistema, hace falta saber qué documentos, designaciones y decisiones dependían de esa finalidad. Esa relación —qué depende de qué— es exactamente lo que un conjunto de documentos separados no contiene. Cada uno describe su parte y ninguno sabe de los demás.

De modo que la propagación depende de que una persona recuerde la cadena entera en el momento en que ocurre el cambio. Y el momento en que ocurre el cambio suele ser una conversación operativa de cinco minutos que no pasa por esa persona.

Es el mismo modo de fallo que hace que un inventario en una hoja envejezca sin avisar: no se rompe nada, y por eso no se detecta. Aquí es peor en un aspecto — allí faltaba una fila; aquí lo que hay es coherente por dentro y falso por fuera.

La pregunta que lo convierte en un proceso

Hay una forma sencilla de meter esto en la operativa sin montar nada, y es cambiar el momento en que se pregunta.

En lugar de revisar periódicamente, enganchar una pregunta a los cambios que ya se comunican:

Cuando algo cambie en un sistema —para qué se usa, quién responde de él, a qué accede, qué versión corre— la pregunta es: ¿qué de lo que escribimos sobre él deja de ser cierto?

No hace falta responderla bien la primera vez. Hace falta que se haga, porque es la única que recorre la cadena hacia abajo. Y suele bastar con que la respuesta se anote junto al cambio, no en otro sitio.

Lo que conviene tener escrito, y es poco

Tres relaciones, no tres documentos.

Qué finalidad tiene cada sistema, con fecha. Es el primer eslabón; si no está fechado, no se puede saber si cambió.

Qué decisiones se apoyaron en esa finalidad. La designación de supervisión, la conclusión de clasificación, la decisión de qué registros conservar. Basta con nombrarlas.

Y quién se entera cuando algo cambia. No quién lo autoriza — quién recibe el aviso. Sin esa persona, los dos puntos anteriores describen una cadena que nadie recorre.

Nada de esto es exigible por ningún artículo, y conviene decirlo: el Reglamento pide el resultado —usar el sistema con arreglo a sus instrucciones, con supervisión encomendada y registros conservados—, no el mecanismo para mantenerlo cierto. El mecanismo es tuyo, y es la parte que decide si lo demás sigue siendo verdad dentro de un año.

Contenido con arreglo al artículo 26 del Reglamento (UE) 2024/1689, en la redacción dada por el Reglamento (UE) 2026/1744 (DOUE de 24/07/2026).

Este artículo tiene carácter informativo y no constituye asesoramiento jurídico.

Recibe análisis como este en tu correo

Novedades regulatorias y de producto de Alethexis. Sin ruido.

Acepto recibir comunicaciones de Alethexis: contenido sobre IA y regulación, y novedades de producto. Puedo darme de baja en cualquier momento.

Responsable: ALETHEXIS, S.L. (CIF B88758057). Finalidad: enviarte el boletín de Alethexis (contenido sobre IA y regulación, y novedades de producto). Base jurídica: tu consentimiento (Art. 6.1.a RGPD), que puedes retirar en cualquier momento. Conservación: hasta que te des de baja o 24 meses de inactividad. Derechos de acceso, rectificación, supresión, oposición, limitación y portabilidad: [email protected]. Puedes reclamar ante la Agencia Española de Protección de Datos (AEPD, www.aepd.es). Más información en la política de privacidad.