¿Reentrenar un modelo te convierte en «fabricante» de IA?

Una guía sin dolor por la frontera de la «modificación sustancial» del Reglamento de IA en el sector financiero.

Imagina la escena, porque pasa muy a menudo. Un banco mediano compra a un proveedor externo el sistema de inteligencia artificial con el que puntúa a sus clientes: el famoso scoring crediticio. El sistema llega con todo en regla —marcado CE, documentación técnica, declaración de conformidad—, el banco lo enchufa a su proceso de riesgo y lo usa siguiendo las instrucciones. Hasta aquí todo claro: el banco es responsable del despliegue, o deployer, de un sistema de alto riesgo.

Pasan unos meses. El equipo de ciencia de datos hace lo que haría cualquier equipo competente: reentrena el modelo con los impagos que se han ido acumulando. Y ahí salta la pregunta que encabeza la lista de dudas de las entidades: al reentrenar, ¿seguimos siendo responsables del despliegue, o nos hemos convertido en proveedores sin enterarnos?

No es una duda menor. De la respuesta depende que el banco siga con el régimen llevadero del artículo 26 o que herede, de golpe, el paquete completo de obligaciones del proveedor (artículo 16): evaluación de conformidad, sistema de gestión de la calidad, documentación técnica, marcado CE, registro en la base de datos de la UE y vigilancia del producto durante todo el ciclo de vida de la herramienta. La diferencia está en la naturaleza: es la distancia que hay entre usar un producto hecho por otro y perfectamente regulado y, de repente, adquirir la posición de fabricante. Y como las obligaciones de alto riesgo son exigibles desde agosto de 2026, esto ya no es un debate filosófico.

Lo inquietante es que este salto casi nunca se da con premeditación. Nadie firma un acta que diga «desde hoy nos convertimos en fabricantes de IA». Se cruza normalmente sin querer, cuando una tarea que el equipo de datos vivió como rutina resulta que no lo era. Y precisamente porque se cruza sin querer, es importante que no lo perdamos de vista.

Primero, ¿qué es «reentrenar» y por qué se hace?

Un modelo de scoring no es más que una receta estadística que ha estudiado miles de casos pasados —quién pagó y quién no— y, con ese aprendizaje, le pone una nota al siguiente solicitante. ¿Cómo estudia? Le damos datos de cada cliente —variables o features: edad, ingresos, historial, antigüedad laboral…— y el modelo aprende cuánta importancia dar a cada uno. A esa importancia se le llama peso: en un buen modelo la nómina pesa mucho y el código postal poco (entre otras cosas, porque darle peso al barrio se acerca a la discriminación). Y para no engañarse a sí mismo, el modelo estudia con una parte de los casos y se examina con otra que no ha visto; así comprobamos que de verdad ha aprendido y no se limita a recitar de memoria. Esta forma de hacerlo en dos partes es algo habitual en la ciencia de datos.

El problema es que el mundo económico trae episodios que no pueden pronosticarse: llega una crisis, sube la inflación, cambian los hábitos de pago. El modelo, que aprendió con datos de ayer, empieza a fallar con la realidad del momento. A eso se le llama deriva o drift: el modelo «envejece», como un reloj que se va atrasando.

Reentrenar es, sencillamente, volver a sentar al modelo a estudiar con los datos recientes para que recupere actualidad. Y aquí conviene distinguir tres cosas que suenan parecidas pero no lo son:

Recalibrar es afinar, volver a poner el reloj en hora pero sin tocar la receta: mismos ingredientes, ajustarlo de forma precisa. Reponderar es cambiar cuánta importancia (peso) le da el modelo a cada dato —por ejemplo, que la nómina cuente más y el código postal menos—, pero sin añadir datos nuevos. Y rediseñar de verdad es meter ingredientes nuevos, cambiar el motor o cambiar el grupo de clientes con el que aprendió.

La clave: no todo cambio es «sustancial»

¿Cuándo salta un banco de una casilla a la otra? Lo dice el artículo 25. El caso que nos importa es su letra b): si haces una modificación sustancial de un sistema de alto riesgo, te conviertes en proveedor y heredas el artículo 16. (Hay una prima hermana, la letra c), para cuando cambias la finalidad de un sistema y lo conviertes en alto riesgo; volveremos a ella.)

El Reglamento reparte los deberes según quién es quién. El proveedor (artículo 3.3) es quien fabrica el sistema y responde de que cumple la ley; es el equivalente al fabricante. El responsable del despliegue (artículo 3.4) es quien lo usa en su actividad; es el usuario profesional. Y al proveedor de alto riesgo le cae lo más pesado: gestión de riesgos continua (art. 9), calidad de los datos (art. 10), documentación técnica (art. 11), exactitud, solidez y ciberseguridad (art. 15), más toda la documentación de conformidad, marcado CE y vigilancia. El deployer tiene una lista mucho más corta de obligaciones (art. 26).

Todo depende, entonces, de qué es una «modificación sustancial». El artículo 3.23 la define con una prueba de dos condiciones que tienen que darse a la vez: (a) que el cambio no estuviera previsto ni planeado en la evaluación de conformidad inicial del proveedor, y (b) que además afecte al cumplimiento de los requisitos de alto riesgo (arts. 8 a 15) o cambie la finalidad para la que se evaluó el sistema.

Léelo otra vez, porque de aquí sale la conclusión que más tranquiliza y más se ignora: no todo cambio es sustancial, y ni siquiera todo reentrenamiento lo es. Un cambio que el proveedor ya había previsto no pasa el primer filtro. Y un cambio imprevisto que no toca los requisitos técnicos ni la finalidad tampoco pasa el segundo. La modificación sustancial vive solo en el cruce de las dos.

El considerando 128 y «la garantía del fabricante»

Aquí viene la pieza que lo resuelve. El considerando 128 dice que los cambios de un sistema que sigue aprendiendo tras su puesta en marcha —o sea, que se adapta solo— no son una modificación sustancial siempre que el proveedor los hubiera predeterminado y evaluado de antemano.

Vamos a simplificarlo: los modelos de machine learning están hechos para cambiar; así es como funcionan. Así que la pregunta útil no es «¿ha cambiado el modelo?» (casi siempre sí), sino «¿el cambio cabía dentro de lo que el proveedor ya había previsto y evaluado?».

A ese margen de cambio previsto me gusta verlo como «la garantía del fabricante». Piensa en la garantía de un coche: cubre el uso y el mantenimiento que el fabricante contempló —cambiar el aceite, pasar la revisión, conducir con normalidad—, pero se anula en cuanto le montas piezas por tu cuenta o trucas el motor. Con el modelo pasa lo mismo: la evaluación de conformidad del proveedor cubre ciertos reentrenamientos, ciertos rangos de recalibración, ciertas métricas que hay que mantener. Por ejemplo: «se reentrenará cada trimestre con datos de impago propios, sobre las mismas variables, siempre que el acierto no baje de tal umbral». Mientras te muevas dentro de esa cobertura, sigues siendo el usuario del producto y no cruzas ninguna frontera. El día que haces algo que el fabricante no cubrió —metes una fuente de datos nueva que no aparece por ninguna parte en la documentación—, la garantía salta y la responsabilidad pasa a ser tuya. Y ojo a quién redacta esa garantía: un proveedor diligente la define con generosidad y precisión; uno descuidado (o astuto) la deja confusa, de modo que cualquier retoque cae «fuera de cobertura» y empuja al banco hacia el papel de fabricante. Por eso esa garantía se negocia en el contrato, no se improvisa con los técnicos de ciencia de datos.

Cuatro escenarios para entenderlo

Bajemos al barro con cuatro casos que cubren casi todo lo que ocurre en la práctica. Sigo utilizando el ejemplo de la garantía del coche, que creo que aquí funciona muy bien.

Escenario 1: mantenimiento de rutina, dentro de la garantía. El banco reentrena con los impagos nuevos, corrige la deriva y ajusta parámetros, todo dentro del protocolo que el proveedor definió y evaluó. Es el equivalente a llevar el coche al taller oficial para el cambio de aceite y la revisión: exactamente lo que la garantía contempla. El cambio estaba predeterminado, no pasa el primer filtro del artículo 3.23 y no es modificación sustancial. Sigues siendo deployer. Aquí entra también una técnica muy común llamada champion-challenger: tienes al modelo titular (el champion) trabajando y, en paralelo, a un aspirante (el challenger) entrenándose; si el aspirante rinde mejor, entra al equipo. Mientras esa competición estuviera contemplada por el proveedor, sigues cubierto por la garantía.

Escenario 2: el reentrenamiento que truca el motor. Aquí ya no llevas el coche a la revisión: le montas piezas por tu cuenta. Metes variables predictivas nuevas que el proveedor no consideró, cambias el dataset de entrenamiento por otro muy distinto (por ejemplo, fuentes de datos alternativas o datos de comportamiento que antes no usabas), tocas la arquitectura o alteras su comportamiento de forma que afecta a su exactitud o robustez (art. 15), a la representatividad de los datos (art. 10) o al mapa de riesgos que el art. 9 había dibujado. Si eso no estaba previsto y además afecta al cumplimiento, se cumplen las dos condiciones: la garantía salta, hay modificación sustancial y, como el scoring sigue siendo de alto riesgo, te conviertes en proveedor por la letra b).

Un pequeño inciso sobre la arquitectura, que se entiende fácil si la explicamos como el tipo de motor del modelo. No es lo mismo una regresión logística —una fórmula transparente en la que puedes ver el peso de cada variable, el equivalente a un motor sencillo que cualquiera abre y entiende— que una red neuronal, mucho más potente pero opaca, una «caja negra» que acierta sin explicarte bien por qué. Cambiar de un motor a otro no es un ajuste cubierto: es rehacer el coche. Y, como veremos, esa opacidad tiene consecuencias jurídicas propias.

Ojo a los grises de este escenario, que son los que más se consultan. Mover el umbral de corte —la nota de aprobado a partir de la cual concedes el crédito— es, en rigor, una decisión de política de riesgo, no una modificación del modelo: es como decidir a qué velocidad conduces o cuánto cargas el maletero, no tocas el motor. No cambia la receta, aunque sí tiene efectos sobre las personas y activa cautelas de no discriminación y protección de datos. Reponderar sobre las mismas variables suele quedar cubierto por la garantía si el proveedor lo tuvo en cuenta. En cambio, el feature engineering —inventar predictores nuevos combinando datos— o cambiar la población con la que se entrenó el modelo se acercan al núcleo de lo sustancial, porque tocan la representatividad de los datos y la validez de la evaluación hecha.

Escenario 3: cambio de finalidad, o usar el coche para lo que no estaba homologado. Aquí no hace falta ni tocar la mecánica: basta con cambiarle el uso. Coges un sistema evaluado para medir solvencia y lo usas para pricing dinámico, para detectar fraude o para segmentar comercialmente; o lo aplicas a un colectivo o un producto para los que no se diseñó. Es como coger el coche familiar y meterlo a competir en circuito: el motor es el mismo, pero el uso ya no es el homologado. Aunque los requisitos técnicos no se resientan, se dispara el segundo brazo del 3.23 (la finalidad) y hay modificación sustancial. Y si con ese cambio conviertes en alto riesgo algo que no lo era, entra la letra c). La finalidad no es un detalle decorativo: es uno de los cimientos sobre los que se hizo la evaluación de conformidad.

Escenario 4: fine-tuning de un modelo fundacional, o construirte el coche tú mismo. Partes de un modelo de propósito general —uno de esos modelos gigantes que ya «saben de todo»— y lo especializas con tus datos para montar tu scoring. Aquí ya no compras un coche terminado con su garantía: coges un chasis genérico y le montas tú la carrocería. Eso ya no es «reentrenar un sistema conforme»: es construir uno nuevo. Difícilmente podrás decir que solo despliegas un producto ajeno; materialmente estás fabricando el sistema de alto riesgo, y con toda probabilidad serás su proveedor (el considerando 109 apunta justo a estos proveedores posteriores de la cadena). Aquí la frontera ya está cruzada desde el minuto uno.

La moraleja de los cuatro escenarios: el acto técnico de reentrenar, por sí solo, no decide nada. Meter mano al coche puede ser una revisión cubierta o una manipulación que anula la garantía, según lo que dijera el manual. El mismo reentrenamiento te deja como deployer o te convierte en proveedor según caiga dentro o fuera de la garantía y según toque o no los requisitos o la finalidad. «No previsto ni planeado en la evaluación de conformidad inicial» remite, al final, a un documento —la documentación del proveedor—, no a una característica propia del cambio. Por eso esto es, antes que técnico, contractual.

La otra capa: RGPD y el caso SCHUFA

Faltaría una pata si dejáramos fuera la protección de datos, porque puntuar a personas es, por definición, tratar datos personales para decidir sobre ellas. El enganche es el artículo 22 del RGPD: derecho a no ser objeto de decisiones basadas solo en tratamiento automatizado que te afecten de forma significativa. La sentencia del TJUE de 7 de diciembre de 2023 (caso SCHUFA, C-634/21) lo dejó clarísimo: generar de forma automática un valor de probabilidad de impago es ya una «decisión individual automatizada» del artículo 22 cuando de ese número depende, de manera determinante, que el banco te dé o te niegue el crédito.

¿Qué tiene que ver con reentrenar? Que tu modelo vive bajo dos marcos a la vez: el Reglamento de IA (que lo disciplina como producto) y el RGPD (que disciplina la decisión que sale de él). Un reentrenamiento que mueva de verdad el comportamiento del modelo no solo puede empujarte hacia el estatuto de proveedor; también puede obligarte a actualizar la información que diste a los clientes sobre la lógica del tratamiento, tus evaluaciones de impacto y las garantías del artículo 22 del RGPD.

Y aquí reaparece la caja negra. El artículo 22 lleva de la mano un cierto derecho a que te expliquen la lógica de la decisión. Si cada reentrenamiento cambia esa lógica, tienes que ser capaz de contar, en cada momento, por qué el modelo puntúa como puntúa. Un modelo transparente lo pone fácil; una red neuronal opaca te obliga a añadir herramientas de explicabilidad para no quedarte sin nada que contarle al cliente —ni al juez—. Por lo tanto, la elección técnica de motor no es solo cosa de ingenieros; tiene consecuencias legales muy concretas. La gobernanza aquí es fundamental.

¿Y si cruzas la línea? Obligaciones y multas

Si al reentrenar incurres en modificación sustancial, no ganas una obligación más: ganas un estatuto entero. Pasas a ser proveedor y te caen todas las obligaciones del artículo 16: nueva evaluación de conformidad por lo modificado, documentación técnica al día, sistema de gestión de la calidad, declaración UE y marcado CE, registro en la base de datos de la Unión y vigilancia poscomercialización. Y un detalle incómodo: el proveedor original deja de responder de la conformidad de ese sistema (aunque siga obligado a cooperar y darte acceso técnico). De esta manera te has quedado sin la garantía del fabricante en todo aquello que cambiaste: ya no podrás escudarte en él para todo.

Para un banco mediano, el salto es enorme, porque las obligaciones del proveedor presuponen capacidades de un fabricante de IA, no de un usuario. Y lo peor es hacerlo sin querer: te descubres en incumplimiento sobrevenido por un reentrenamiento que el equipo consideró rutinario. ¿El precio? El artículo 99 prevé multas de hasta 15 millones de euros o el 3 % del volumen de negocio mundial anual, la cifra que sea mayor. (La escala sube a 35 M€ o el 7 % para las prácticas prohibidas del art. 5, y baja a 7,5 M€ o el 1 % por dar información incorrecta a las autoridades.) Y para una entidad financiera la factura no acaba en la multa: está lo reputacional y la mirada, cada vez más atenta, de los supervisores sobre la gobernanza de sus modelos.

Cómo no cruzar la línea sin querer: cinco palancas

La buena noticia: esta frontera no se gobierna desde el modelo, sino desde el expediente que lo rodea. Y eso se puede preparar antes. Cinco palancas:

Uno, el contrato con el proveedor. El artículo 25.4 lo convierte en una pieza del sistema, así que aprovéchalo para negociar la letra pequeña de la garantía: qué reentrenamientos y recalibraciones puedes hacer sin romper la conformidad, qué cambios exigen validación del proveedor y qué queda excluido. Un buen contrato convierte una zona confusa en seguridad jurídica.

Dos, un protocolo interno de gestión del cambio con compuerta jurídica. En ciencia de datos esto se llama gobernanza de MLOps: el «quirófano» con protocolos donde se opera al modelo. Antes de desplegar cada reentrenamiento relevante, pásalo por las dos preguntas del 3.23: ¿estaba previsto y planeado? ¿afecta a los requisitos o cambia la finalidad? Documentar la respuesta es lo que te permite clasificar cada cambio y actuar.

Tres, trazabilidad. Guarda el rastro de qué datos usaste, qué parámetros tocaste, qué métricas preservaste y por qué consideraste el cambio «previsto». Eso no solo gobierna la frontera hacia dentro: es tu prueba ante el supervisor si algún día te discute la calificación.

Cuatro, coordinación continua con el proveedor. El deber de cooperación del artículo 25.2 no es para el día del conflicto: consúltale ante cualquier cambio que roce el límite de la garantía. La relación deja de ser una compraventa cerrada y pasa a ser colaboración continuada. Olvídate de los egos de tu equipo de ciencia de datos.

Cinco, no perder de vista lo demás. Con independencia de esta frontera, te siguen tocando la supervisión humana (art. 26), la evaluación de impacto sobre derechos fundamentales (art. 27, muy relevante en scoring) y las garantías del artículo 22 del RGPD a la luz de SCHUFA.

Para cerrar

La respuesta a la pregunta del principio es tranquilizadora y exigente a la vez: reentrenar un modelo no te convierte, por sí solo, en proveedor. Lo que te convierte es reentrenar fuera de la garantía que el proveedor predeterminó y evaluó, o hacerlo de un modo que toque los requisitos de alto riesgo o cambie la finalidad. La recalibración de rutina te mantiene como deployer; el reentrenamiento que se sale y compromete la conformidad te empuja al exigente estatuto del proveedor, multas del artículo 99 incluidas.

La idea de fondo, si te quedas con una sola: la frontera no la traza el modelo, la traza el expediente. Y ahí está la gracia del asunto para nosotros, los juristas. El equipo técnico reentrena; el jurista que entiende de qué va técnicamente el reentrenamiento es quien sabe trazar la frontera y responder de ella. Traducir la fontanería del modelo a categorías jurídicas —y hacerlo antes, en el contrato y el protocolo, no cuando el supervisor ya está preguntando— es, hoy, una de las funciones de más valor que un abogado puede ofrecer al sector financiero.