«El modelo base no lo hemos entrenado nosotros. De lo que lleve dentro, que responda quien lo hizo.»
Se lo he oído a gente que sabe construir software, y lo entiendo: es verdad a medias, que son las peores. No lo entrenaron ellos, cierto. Pero quien monta el sistema que decide sobre una persona es quien tiene que responder por él —entero, con las piezas que no hizo—. Y ese eres tú.
Coges un yogur del supermercado y, en el lateral, lleva su lista de ingredientes, su origen y su fecha. Un trámite tan rutinario que ni lo miras. Ahora dime: el modelo que decide sobre personas en tu empresa —a quién se entrevista, quién recibe el crédito, qué paciente se prioriza—, ¿lleva la suya?
La pregunta no es retórica. El día que un cliente, la autoridad de vigilancia del mercado o —si la cosa se tuerce— un juez te pregunte «¿de dónde viene esta decisión?», solo hay dos respuestas posibles: la enseñas, o la reconstruyes de memoria. La primera es evidencia. La segunda es un cuento. En la pieza que abrió esta serie dije que la evidencia se genera, no se redacta. Hoy cierro con el «cómo» —y con por qué ese «cómo» no termina en tu repositorio—.
El «cómo» es viejo conocido de cualquiera que haya puesto software en producción con cabeza, solo que aplicado al modelo. Cada vez que entrenas, el propio proceso emite un manifiesto firmado: con qué datos exactos, con qué versión de código, qué métricas dio, quién lo aprobó. No es un documento que alguien se siente a escribir después; es un subproducto del entrenamiento, como el ticket que escupe la caja. Y va firmado —criptográficamente— para que cualquiera pueda comprobar que no se ha tocado desde que se emitió.
Todo lo de las piezas anteriores cae aquí. La terna de la trazabilidad, los riesgos de tu sistema y cómo los trataste, la traza de cada anulación del supervisor: no son cinco expedientes sueltos que alguien junta a mano la víspera de la auditoría. Son entradas del mismo manifiesto, emitidas en el momento en que ocurren, atadas a la versión exacta del sistema que las produjo. El expediente técnico del anexo IV deja de ser una redacción y pasa a ser una consulta: ya está hecho, solo hay que leerlo.
Vuelvo a la frase del principio, porque es donde se decide la partida. Tu modelo no nació de la nada. Casi ningún sistema de IA se entrena hoy desde cero: se ensambla. Partes de un modelo de propósito general de un tercero, le pones encima tus datos —que a su vez vienen de algún sitio—, lo montas sobre librerías que no escribiste. Tu sistema es, en buena parte, piezas de otros. Y el Reglamento de IA, como vimos en el primer capítulo, te hace responsable del conjunto: montar el caso de uso te convierte en su proveedor, con todo lo que eso arrastra.
El problema es de cuentas claras. Para demostrar que tu sistema es conforme, tienes que poder responder por las piezas que no hiciste. ¿Con qué se entrenó el modelo base que usas? ¿Esos datos respetaban los derechos de quien los creó? ¿La librería de turno arrastra un sesgo que heredas sin saberlo? Si no sabes de dónde viene cada pieza, no puedes demostrar nada del conjunto —y «confía en mí» no es una respuesta válida ante un evaluador—.
En ciberseguridad este problema ya se resolvió con una idea sencilla: la lista de materiales —el inventario de todo lo que entra en tu producto, de dónde viene y con qué versión—. La IA necesita la suya: una lista de materiales de tu modelo (un ML-BOM). Qué modelo base, y con qué procedencia; qué conjuntos de datos, y con qué licencia; qué dependencias. Encadenada eslabón a eslabón y firmada en cada uno. No es burocracia: es lo que convierte «creo que es conforme» en «aquí está la cadena, compruébala».
La ley ya está montando su mitad de esa cadena. El proveedor del modelo de propósito general que tú integras está obligado (artículo 53) a publicar un resumen del contenido con el que lo entrenó —la Oficina Europea de IA ya ha publicado la plantilla— y a tener una política que detecte y respete la reserva de derechos del artículo 4(3) de la Directiva de derechos de autor en el mercado único digital. Esa información es el primer eslabón de la tuya: la consumes, la encadenas a tu manifiesto y, donde el de aguas arriba sea opaco, lo dejas escrito. Un hueco declarado es honesto; un hueco tapado es el que te hunde en la auditoría.
Aquí conviene afinar, porque dos casos casi calcados no te dejan el mismo trabajo. Pon que eliges entre dos modelos base equivalentes para tu caso. Si integras el propietario, su proveedor te debe entregar a ti, como integrador, la documentación del anexo XII: qué sabe hacer el modelo, qué no, cómo se integra, con qué se entrenó. Si integras su gemelo publicado con licencia libre y de código abierto, esa entrega decae: el artículo 53 exime de ella a los modelos abiertos. De lo que no los exime —y esto se lee mal a menudo— es del resumen público del contenido de entrenamiento ni de la política de derechos de autor. Esas dos las debe igual. Y si el modelo tiene riesgo sistémico, la exención entera se cae.
Mismo modelo por dentro, distinto trabajo para ti. Porque tus obligaciones no se mueven ni un milímetro: tu expediente sigue exigiéndote documentar de qué modelo preentrenado partiste y cómo lo integraste. Con el propietario, ese eslabón te llega servido. Con el abierto tienes los pesos y la arquitectura a la vista, pero el hueco de los datos de entrenamiento y de las limitaciones lo rellenas —o lo declaras— tú. Eso es responder por las piezas que no hiciste: no es un principio, es trabajo con nombre y apellidos.
Así que esto es lo que defiendo. La conformidad de la IA de alto riesgo no es un documento que se redacta el último día: es evidencia que se emite por construcción y se encadena por toda la cadena de suministro. Cada entrenamiento, un manifiesto firmado. Cada pieza de fuera, su procedencia. De punta a punta, verificable por terceros, no por confianza. Llevar ese trabajo al mismo flujo donde vive el modelo es lo que vengo llamando GovOps; y a la capa que resulta —gobernanza demostrada, no prometida— la llamo aseguramiento: la que prueba lo que la gobernanza se limita a declarar.
Con esto cierro las cinco preguntas que abrí hace unas semanas. El jueves recapitulo la serie entera —por qué documentar no es lo mismo que probar— y abro lo que viene. Si construyes IA que decide sobre personas, te espero ahí.
El yogur lleva su lista porque un día decidimos que quien se lo come tiene derecho a saber qué lleva dentro. Tu modelo decide sobre personas. La confianza no se declara: se verifica. Pruebas, no promesas.
— Rodrigo