Del lado de quien pide la evidencia al lado de quien tiene que sostenerla

Definir qué evidencia debe presentar un sistema de IA para aprobarse, y traducir ISO/IEC 42001, el Reglamento de IA y el RGPD a controles que otro tendrá que acreditar después, tiene algo asimétrico: la norma exige la evidencia, uno la traduce a controles, otro tiene que sostenerlos. En este proyecto personal ocupo los dos lados humanos: el que traduce la norma a controles verificables y el que tiene que sostenerlos, contra un sistema propio y con proveedores reales.

Así nació este proyecto, Estar Informado: un proyecto editorial de análisis donde una cadena de agentes de IA generativa investiga, redacta, edita y verifica cada artículo, y donde un editor humano —yo— es el único punto de decisión sobre qué se publica. Proyecto personal sin ánimo de lucro ni comercial, en el que la publicación no es el objetivo, sino el instrumento: un sistema en producción real, con proveedores con DPA vigente y contenido publicándose bajo obligaciones que de verdad aplican.

La pregunta no era “¿puede una IA escribir artículos?” —esa ya está respondida y no es interesante. Era otra: si la IA generativa va a producir contenido informativo a escala, ¿qué controles hacen falta para que sea fiable y trazable, y no solo plausible? Y sobre todo: qué pasa cuando intentas responderla en código en lugar de en un documento de política.

ISO 42001: la parte que no se puede documentar por adelantado

La lectura habitual de la norma la trata como un catálogo de controles a evidenciar. Construyendo el sistema entendí que su valor está en otra parte: en la cláusula 10.2 —no conformidad y acción correctiva— que obliga a detectar un fallo, corregir su causa y revisar el criterio cuando la operación demuestra que no bastaba. Es la parte que una auditoría documental casi nunca verifica de verdad, porque exige un historial de no conformidades, no una política. Un auditor que lee tu registro de no conformidades y lo encuentra vacío no está viendo un sistema perfecto: está viendo uno que no se está operando.

El historial de este pipeline no es halagador, y por eso vale. Ningún agente funcionó bien a la primera, y fallaban de una forma concreta: no producían texto obviamente malo, sino texto plausible con el detalle desplazado —una fecha inferida de donde no se podía inferir, una afirmación atribuible a una fuente convertida en hecho verificado al reformularla. De ahí salió todo el cuerpo de umbrales, reglas de rechazo y verificaciones deterministas que hoy tiene el sistema —lo que la cláusula 8 (operación) llama controles operacionales sobre el ciclo de vida—. Ninguno estaba en el diseño inicial: cada uno existe porque un artículo concreto obligó a escribirlo. El human-in-the-loop no es solo el control que impide que un error llegue al lector: es el punto donde se detectan los fallos que ningún paso automático ve, y de donde sale cada nueva regla correctiva.

RGPD: el DPA se lee, no se presume

La decisión de gobernanza con más impacto técnico no vino de un análisis de riesgos: vino de leer los documentos legales que casi nadie lee. Antes de fijar cada proveedor de inferencia verifiqué su Data Processing Addendum: que no entrene con el contenido enviado, que la garantía cubra el plan self-serve y no solo el corporativo, que existan garantías de transferencia internacional bajo el Capítulo V (art. 44 y siguientes).

Un proveedor quedó descartado porque su nivel gratuito usa el contenido para entrenar sus modelos: un tratamiento con finalidad propia que yo no instruí ni autoricé. Eso rompe la relación de encargado del tratamiento del art. 28 —que exige tratar los datos solo bajo instrucciones documentadas del responsable— y, en el fondo, vulnera el principio de limitación de la finalidad del art. 5.1.b: los datos se envían para obtener una inferencia, no para mejorar el modelo de quien la presta. Y solo se detecta leyendo el documento, no la ficha comercial.

Tener DPA y estar cubierto por él no son lo mismo, y la diferencia suele estar en qué plan contrataste. Lo que además aplica es el principio de minimización del art. 5.1.c —datos adecuados, pertinentes y limitados a lo necesario—: una regla del sistema penaliza incluir datos personales de terceros no relevantes en el cuerpo de las noticias. (Y no: el art. 22 no aplica aquí. Publicar un artículo no produce efectos jurídicos ni significativos sobre una persona identificada. Invocarlo sería inflar el argumento.)

Reglamento de IA: aplicar lo que no te obliga

Este pipeline no es un sistema de alto riesgo bajo el Reglamento de IA. Decirlo importa, porque vestir un proyecto propio con artículos que no le aplican destruye la credibilidad del resto. Precisamente por eso implementé de todos modos controles reservados a los sistemas de alto riesgo —o que legítimamente podría haberme ahorrado— para medir su coste real:

• Trazabilidad (art. 12 y 19): registro automático de la decisión de cada agente durante todo el ciclo de vida —entrada, salida y duración— por el art. 12, y conservación de esos registros durante 180 días, por encima del mínimo de seis meses que fija el art. 19. Es lo que convierte “hay supervisión humana” en una afirmación con registro detrás, no una frase de la página “Sobre nosotros”.
• Divulgación de contenido sintético (art. 50): aviso visible de contenido generado por IA en el texto, y marcado legible por máquina en la imagen mediante metadatos IPTC (DigitalSourceType: trainedAlgorithmicMedia), verificable con exiftool o cualquier lector C2PA.

El matiz que más me hizo pensar de todo el proyecto: el art. 50.4 exime de divulgar cuando el contenido pasa por revisión humana o control editorial y una persona física o jurídica asume la responsabilidad editorial de la publicación. Es decir, el diseño human-in-the-loop que adopté por convicción técnica es, palabra por palabra, la condición que el legislador europeo fija para eximir de la obligación. Aun así divulgo. (En rigor, el marcado técnico de la imagen recae sobre el proveedor del modelo generativo por el art. 50.2, no sobre el medio que lo usa; lo aplico igual.) Conviene no confundir las capas: el art. 50.4 obliga a transparencia sobre el origen —que el lector sepa que hubo IA—, no a veracidad. Contra la desinformación no protege el etiquetado, sino la verificación previa a publicar: el Verificador, las reglas que rechazan la cita ausente en la fuente, el punto de corte humano. Etiquetar es una capa; verificar es otra.

Y el hallazgo que más me sorprendió: el sobrecoste de exceder el mínimo exigible fue marginal frente al coste de construir el pipeline. “El cumplimiento por diseño es caro” resiste mal el contacto con un proyecto real. Lo caro es añadirlo después.

Por qué el human-in-the-loop no es una concesión al regulador

La primera versión tenía autopublicación: tras diez aprobaciones manuales, publicaba directo. Lo eliminé por completo —y no por prudencia genérica. Confirmé empíricamente que un modelo revisando su propio trabajo no detecta sus propias fabricaciones: aprobaba citas plausibles que no existían en la fuente. Si el criterio con el que los agentes se aprueban entre sí tiene un punto ciego compartido, diez aprobaciones seguidas no demuestran que el sistema funciona: pueden demostrar que el punto ciego es estable.

Hay un detalle que me sorprendió al releer la norma después: el propio art. 14 nombra este modo de fallo. Su apartado 4.b obliga —en sistemas de alto riesgo— a que el supervisor humano permanezca consciente de la “tendencia a confiar en exceso en la salida del sistema”, el sesgo de automatización. Es exactamente lo que un contador de aprobaciones consecutivas induce. El legislador puso nombre a lo que yo había descubierto rompiéndome contra ello.

La corrección arquitectónica fue separar por diseño quién redacta de quién revisa —Editor, Curator y Verificador corren sobre cadenas de modelos deliberadamente distintas a la del Writer—, y aun así el punto de corte humano se queda. Porque el riesgo real no es el fallo ruidoso y aislado, sino la degradación silenciosa a escala: contenido que suena bien, cita fuentes reales, tiene el formato correcto, y va acumulando distorsiones pequeñas que ningún paso automático de la propia cadena está en posición de detectar, porque todos comparten origen. Por eso esto es human-in-the-loop, no human-on-the-loop —la distinción que el art. 14 del Reglamento vuelve operativa—: la persona no supervisa desde fuera un proceso que podría avanzar sin ella. Decide dentro del flujo, o el flujo no avanza.

La fiabilidad aparente es precisamente el fallo que obliga a un humano a sostener el criterio, no a firmarlo. Y es ese fallo —no el regulador— el que convierte al human-in-the-loop en supervisión desde el diseño: la figura no acompaña al sistema, lo hace fiable; sin ella, la arquitectura produce plausibilidad sin nada que la distinga de la verdad.

Qué me llevo

Una forma distinta de mirar el gate. Lo que un marco documental produce por defecto es evidencia que deja constancia, no evidencia que discrimina: un DPA firmado frente al plan concreto que ese DPA cubre; una política de supervisión humana frente al punto exacto del flujo donde esa persona decide. Solo la segunda de cada par detecta algo.

La gobernanza de IA es viable como restricción de arquitectura, no solo como política documental: cada obligación aquí —art. 28, art. 5, art. 44 del RGPD; art. 12, art. 14, art. 50 del Reglamento de IA; cláusulas 8 y 10 de ISO 42001— se tradujo en un componente de código verificable. Pero traducirla exige haber pagado el coste al menos una vez. Los resultados son preliminares —un solo sistema, un solo operador, sin auditoría independiente—; no es una validación generalizable, sino algo más útil: un sistema real con historial de fallos y correcciones reales que puedo poner sobre la mesa en cualquier conversación sobre gobernanza aplicada.