Has externalizado la IA, no el riesgo

Hay una frase que se dice en las reuniones de contratación y que suena razonable: el sistema es del proveedor, así que el riesgo es suyo.

Es falsa, y el sitio por donde falla no es el que la gente espera. No falla en el reparto de obligaciones del contrato, que suele estar bien hecho. Falla antes: la exposición no nace del rol respecto al sistema de IA, nace de la relación con el cliente.

Quien contrata un servicio con IA de un tercero para atender a sus clientes responde ante esos clientes y ante su supervisor. No haber escrito una línea de código no cambia eso.

Un caso público que lo enseña entero

En la web de Peloton funcionaba un chat operado por un proveedor tercero. Peloton ni construyó ni entrenó el sistema. Según la demanda colectiva, el proveedor grabó y almacenó las conversaciones y las usó para mejorar sus propios modelos. Un juez federal dejó prosperar la reclamación contra Peloton, no contra el proveedor. Las partes desistieron después de forma conjunta, sin hacer públicos los términos.

Es jurisprudencia estadounidense y no se cita como fundamento en Europa. Sirve para otra cosa: es la estructura exacta del problema (servicio externalizado, IA del proveedor, tu cliente al otro lado) y demuestra que el argumento no es teórico.

El anclaje europeo, que es lo que sí sostiene el razonamiento aquí, está en el RGPD. Si el proveedor usa las conversaciones con tus clientes para entrenar sus modelos, actúa para finalidad propia, y el artículo 28(10) lo convierte en responsable respecto de ese tratamiento. Que aparezca un segundo responsable no te quita de en medio: la responsabilidad frente al interesado y frente al supervisor sigue siendo tuya.

De ahí sale una regla contractual concreta, y es de las que se olvidan por dónde se escribieron primero: la prohibición de usar tus datos para entrenamiento tiene que cubrir todos los supuestos. Lo habitual es que esté escrita para los servicios donde se procesa documentación y no para aquellos donde se procesan conversaciones con clientes, que es donde el riesgo es mayor.

El bumerán de la personalización

El segundo mecanismo es más silencioso, porque lo dispara una buena decisión de producto.

El artículo 25 del AI Act contempla que quien modifica sustancialmente un sistema de alto riesgo, lo comercializa bajo su propia marca o cambia su finalidad prevista pase a asumir las obligaciones de proveedor. Detrás de eso vienen evaluación de conformidad, documentación técnica y vigilancia poscomercialización, que es un orden de magnitud más trabajo del que tenía quien solo desplegaba.

Un ajuste fino con datos propios para que el sistema funcione mejor puede cruzar esa línea. Y en general lo hace el equipo que menos motivos tiene para saber que existe.

La pregunta incómoda no es si el rol puede cambiar. Es quién tiene encomendado detectar que ha cambiado. Si esa tarea no está asignada a una persona con nombre, el cambio de rol no se descubre cuando ocurre: se descubre en una revisión, meses después, con la documentación por hacer y sin plazo.

Por qué la cláusula no cierra el asunto

Hay dos reclamaciones públicas más que ilustran el punto, y conviene tomarlas como lo que son (ilustrativas, aunque no aplicables aquí).

En una, la reclamación se admitió contra el proveedor de la herramienta de selección por una teoría de agencia, pese a que el contrato asignaba la decisión al empleador. En otra, la discusión fue si la puntuación que producía la herramienta cuenta como un informe sujeto a una normativa de crédito, en cuyo caso el empleador hereda obligaciones que no sabía que tenía.

Distintas jurisdicciones, distintas normas, misma lección: los tribunales todavía no tienen una teoría estable de reparto de responsabilidad en estos servicios, y mientras no la tengan, la cláusula describe lo que las partes acordaron pero no determina dónde cae la responsabilidad.

Lo que el contrato te da es un derecho a exigir. Y un derecho que nadie ejerce no existe. Si nadie tiene encomendado ejercerlo, recategorizar el servicio cuando cambia y responder cuando llega la reclamación, el contrato es un documento, no un control.

La reversibilidad no tiene suelo normativo

Esta es la parte que falta en casi todos los marcos de externalización, y no por descuido: es que no viene de ninguna norma.

En sectores regulados, el plan de salida ya es exigible en las externalizaciones importantes. El Data Act estableció además derechos de cambio de proveedor para los servicios de tratamiento de datos. Pero no hay equivalente para modelos, pesos afinados, librerías de prompts ni marcos de evaluación. Ahí no hay derecho por defecto: se escribe en contrato o no existe.

La capa de IA que le falta a un plan de salida son tres cosas:

• Exportación de logs e histórico de interacciones en formato portable, no en el formato propietario del proveedor.
• Preaviso de cambios materiales de modelo, con plazo suficiente para valorarlos antes de que estén en producción.
• Prohibición de retención de datos tras la terminación, con evidencia de borrado.

Sin las tres, el plan de salida cubre la infraestructura y deja fuera lo único que no se puede reconstruir.

Qué exigirle al proveedor, y el criterio que cierra la lista

Lo que hay que pedir en la cualificación, antes de firmar:

• Uso previsto declarado.
• Categorías de datos de entrenamiento.
• Limitaciones conocidas.
• Resultados de pruebas por caso de uso relevante, no agregados. Una métrica global no dice nada sobre tu caso.
• Modos de fallo.
• Notificación de actualizaciones materiales.
• Logs y registros en formato compatible con tu propia monitorización, no con la del proveedor.

Y el criterio de cierre, que vale más que la lista entera: si el proveedor no puede aportar esto, eso es el riesgo en si mismo. No es una incomodidad del proceso de compra ni una pega de los de gobierno. Es un hallazgo de la cualificación, y se documenta como tal.

Una última cosa, sobre montar programas

Cuando aparece un frente nuevo (un reglamento, un supervisor que pregunta, un cliente que exige) la reacción instintiva es preguntarse si hace falta un programa nuevo.

Casi nunca hace falta. La pregunta que produce mejores decisiones es la otra: ¿qué añade esto a nuestro programa? Una base de gobierno única con las regulaciones mapeadas encima cuesta menos y envejece mejor que un programa por norma, y evita el segundo censo paralelo, que es la forma más común de duplicar el trabajo sin ganar control.

Lo he escrito con más detalle en qué cubre cada marco y dónde se solapan. Aquí basta con el resumen: externalizar mueve el trabajo, no la responsabilidad. Y cuando esa responsabilidad acaba en un daño y alguien reclama, lo que decide quién paga ya no sale del AI Act: quién paga cuando un sistema de IA causa un daño.