Cuando tu proveedor añade un subencargado de IA y el ajuste se activa solo
El 23 de junio de 2026, Microsoft añadió OpenAI a su lista de subencargados. El 9 de julio la opción quedó disponible. El 24 de julio se activó para todos los usuarios de los clientes comerciales elegibles, salvo en las organizaciones que hubieran seleccionado expresamente No users antes de esa fecha.
Lo interesante no es el caso. Es el patrón, porque se va a repetir: un cambio en la cadena de suministro de IA que no requiere que nadie en tu organización lo apruebe, y cuyo valor por defecto es que sí.
Este artículo no va de un ajuste concreto de un producto concreto. Va de qué se mueve en tu gobierno cuando la cadena cambia por debajo, y de por qué los mecanismos que la mayoría de organizaciones tienen montados no lo detectan.
Lo que cambia no es quién ve tus datos
La reacción instintiva ante un cambio así es preguntarse si un tercero nuevo accede a la información. Es la pregunta menos útil, porque la respuesta suele estar contratada y ser correcta: el proveedor sigue siendo tu encargado, el subencargado opera bajo su supervisión, y el acuerdo de tratamiento de datos alcanza a la cadena.
Lo que cambia es más sutil y más caro de descubrir tarde: el conjunto de garantías deja de ser el mismo, y tu documentación sigue describiendo el anterior.
En este caso concreto, la propia documentación del proveedor lo dice con precisión, y merece leerse despacio porque es el tipo de párrafo que decide una auditoría. Las condiciones del producto y el acuerdo de protección de datos aplican salvo lo indicado en la sección de exclusiones. Los modelos operados por el subencargado están incluidos en la frontera europea de datos salvo lo indicado en la documentación sobre transferencias parciales. Y quedan excluidos de los compromisos de procesamiento dentro del país cuando estos sean aplicables.
La lista de exclusiones añade cuatro ausencias concretas: no hay certificación FedRAMP High, no hay declaración de conformidad PCI DSS, no hay certificación HITRUST CSF, y no hay informe SOC 1 Type 2.
Ese último punto es el que hace que esto sea un asunto de gobierno y no de administración de sistemas. Si tu evaluación de proveedor se apoyaba en un informe SOC 1 Type 2, esa afirmación dejó de ser cierta para una parte del servicio sin que se modificara ni una línea de tu contrato. La garantía no se retiró: se quedó fuera del tramo nuevo de la cadena.
Por qué el inventario no lo ve
Aquí está el fallo estructural, y no se arregla mantiendo mejor el inventario.
La mayoría de inventarios de sistemas de IA registran sistemas: nombre, dueño, caso de uso, categoría de riesgo, estado. Cuando un proveedor incorpora un subencargado, ninguno de esos campos cambia. El sistema se sigue llamando igual, lo usa la misma gente para lo mismo, y su categoría de riesgo es la que era. La fila del inventario sigue siendo literalmente correcta el día después del cambio.
Lo que se ha quedado obsoleto es un campo que en muchos inventarios no existe: quién procesa por debajo del proveedor, y bajo qué condiciones. Un inventario sin ese campo no puede detectar este tipo de cambio por bien mantenido que esté, y su corrección aparente es justamente lo que impide que nadie lo revise.
Escribí sobre por qué un inventario es un ejercicio de desambiguación y sobre el inventario como primer entregable de un programa. Esto añade una columna a esa conversación: un inventario que solo mira hacia dentro describe la mitad del sistema.
El control existe, y está en manos de quien no decide
En este caso el ajuste existe, es granular (se puede limitar por usuarios o por grupos) y se apaga en cuatro clics. El problema no es la ausencia de control.
El problema es que tocarlo exige un rol administrativo, y quien tiene ese rol no suele ser quien responde del registro de actividades de tratamiento, de la evaluación de impacto ni del inventario de IA. Cuando la organización no ha escrito quién decide sobre un cambio de este tipo, ocurre una de dos cosas: lo decide por omisión alguien que no tiene el mandato, o lo decide el valor por defecto del proveedor.
Esta es la misma cuestión que desarrollé al hablar de dónde colgar la función de gobierno de IA y de órganos que decidan de verdad: el gobierno de IA se juega menos en el organigrama y más en si alguien tiene mandato explícito sobre decisiones que hoy se toman en una consola de administración.
Y conviene decir la parte incómoda: no activarlo también es una decisión, con su coste. Desactivar el subencargado puede dejar sin acceso a modelos y funcionalidades que el negocio ya está usando. Lo que no es aceptable es que ninguna de las dos opciones se haya decidido.
El disparador tiene que ser la lista, no el calendario
La revisión anual de proveedores se diseñó para contratos que cambiaban una vez al año. La cadena de subencargados de un servicio de IA cambia con la cadencia del producto, que hoy se mide en semanas.
Una revisión anual que se cruce con este calendario descubre el cambio, en el mejor de los casos, once meses tarde. Y lo descubre por casualidad, porque nadie fue a buscarlo.
Lo que funciona es invertir el disparador. Los proveedores serios publican su lista de subencargados y ofrecen mecanismo de notificación de cambios: eso es lo que hay que vigilar, con un dueño nominal, y no la fecha de la próxima revisión. Cada alta en esa lista se trata como un cambio que hay que valorar, aunque la valoración acabe siendo que no afecta, porque el registro de que se valoró y no afectaba es exactamente la evidencia que después pide un auditor.
Es también la razón por la que trato el gobierno de IA como un sistema adaptativo y no como un proyecto con fecha de fin. Un programa cuya cadencia de revisión es más lenta que la cadencia de cambio de aquello que revisa está describiendo el pasado con mucha formalidad.
La revisión corta, cuando pasa
Cuando aparece un alta de subencargado en un servicio que usas, esto es lo que rinde, y cabe en una tarde:
Uno. Cuál es el estado hoy, no cuál debería ser. Mirar el ajuste y anotar en qué posición está. Si nadie lo tocó, está en el valor por defecto del proveedor, y ese valor es un dato, no una decisión tuya.
Dos. Qué afirmaciones de tu documentación han dejado de ser ciertas. No revisar el documento entero: buscar las frases concretas sobre localización del tratamiento, certificaciones del proveedor, retención y subencargados, y comprobar cada una contra la documentación nueva.
Tres. Quién decide, con nombre. Si no está escrito, esa es la primera salida de la revisión, y vale más que la decisión concreta de este caso.
Cuatro. Documentar la decisión en ambos sentidos. Activado o desactivado, con fecha, motivo y quién. Un ajuste apagado sin rastro escrito se vuelve a encender en la siguiente migración y nadie sabrá que se decidió lo contrario.
Cinco. Dejar montado el disparador, para que el siguiente cambio no dependa de que alguien leyera la nota adecuada.
Ninguno de los cinco pasos exige herramienta nueva ni presupuesto. Exige que alguien tenga el encargo, que es normalmente lo que falta.
Preguntas frecuentes
¿Qué significa que un proveedor añada un subencargado de IA? Significa que una parte del tratamiento que tenías contratada con un proveedor pasa a ejecutarla, total o parcialmente, un tercero bajo su responsabilidad. El proveedor sigue siendo tu encargado y responde ante ti, pero la cadena se alarga y con ella cambian los sitios por donde pasan los datos y las garantías que acompañan a cada tramo. El artículo 28(2) del RGPD lo permite mediante autorización previa específica o general del responsable, y cuando la autorización es general obliga al encargado a informar de cualquier cambio previsto en la incorporación o sustitución de otros encargados, dando al responsable la oportunidad de oponerse.
¿Un cambio de subencargado obliga a rehacer la evaluación de impacto? Obliga a revisarla, y a rehacerla solo si cambia alguno de los supuestos sobre los que se construyó. La pregunta útil no es si hay que repetir el ejercicio entero, sino cuál de las afirmaciones que sostienen la evaluación ha dejado de ser cierta: dónde se procesa, con qué certificaciones, bajo qué compromisos de localización, con qué política de retención. Si ninguna se mueve, basta con dejar constancia de la revisión y de por qué no cambia nada. Si alguna se mueve, lo que hay que actualizar es esa, no el documento entero.
¿Por qué mi inventario de sistemas de IA no detecta estos cambios? Porque la mayoría de inventarios registran sistemas, no cadenas de suministro. Cuando un proveedor incorpora un subencargado, el sistema no cambia de nombre, ni de dueño, ni de caso de uso, ni de categoría de riesgo: la fila del inventario sigue siendo literalmente correcta después del cambio. El campo que se ha quedado obsoleto es uno que en muchos inventarios ni existe, el de quién procesa por debajo del proveedor y bajo qué condiciones. Un inventario que no tenga ese campo no puede detectar el cambio, por bien mantenido que esté.
¿Quién debería decidir sobre la activación de un subencargado de IA? El problema de fondo es que quien puede tocar el ajuste y quien responde de sus consecuencias suelen ser personas distintas. El control técnico vive en una consola de administración y exige un rol administrativo; la responsabilidad sobre el registro de actividades de tratamiento, la evaluación de impacto y el inventario de IA vive en otro sitio. Cuando la organización no ha escrito quién decide sobre este tipo de cambios, la decisión la acaba tomando por omisión quien no tiene el mandato, o directamente el valor por defecto del proveedor.
¿Qué disparador de revisión funciona para los cambios de subencargados? Un disparador ligado a la lista de subencargados del proveedor, no al calendario. Las revisiones anuales de proveedores se diseñaron para contratos que cambiaban una vez al año, y la cadena de subencargados de los servicios de IA cambia con la cadencia del producto. Lo que funciona es suscribirse a la lista publicada de subencargados de cada proveedor crítico, asignar un dueño nominal a esa vigilancia y tratar cada alta como un cambio que hay que valorar, aunque la valoración acabe siendo que no afecta.
¿Basta con desactivar el ajuste y olvidarse? Desactivarlo es una decisión legítima, y olvidarse no. Cualquiera de las dos opciones, activar o desactivar, es una decisión sobre el tratamiento de datos de la organización y tiene que quedar documentada con fecha, con motivo y con quién la tomó. Un ajuste desactivado sin rastro escrito se vuelve a activar en la siguiente migración, en el siguiente cambio de administrador o en la siguiente actualización que reordene la consola, y nadie sabrá que alguna vez se decidió lo contrario.