La oferta de empleo decía «AI Governance Manager» y la descripción era, párrafo por párrafo, la de un delegado de protección de datos con dos frases sobre inteligencia artificial pegadas al final. No es un caso aislado: es el patrón con el que el mercado está cubriendo la función. Se da por hecho que quien viene de protección de datos o de cumplimiento normativo ya tiene media carrera hecha en gobernanza de IA. Es medio verdad y medio trampa, y la diferencia solo se ve desde dentro de un sistema que lleva meses corriendo en producción.
La tesis en una línea: las tres funciones que se confunden a diario —DPO, responsable de cumplimiento y responsable de gobernanza de IA— no se delimitan por el organigrama, se delimitan por el objeto que supervisa cada una. El dato personal, el marco normativo, el ciclo de vida del sistema. Confundirlas no es un problema de títulos en una tarjeta: es la razón por la que, cuando un agente se equivoca, la reunión se va cuarenta minutos sin que nadie pueda decir quién responde.
La diferencia entre DPO y AI Governance Manager está en el objeto, no en el organigrama
Las tres funciones responden preguntas distintas porque vigilan cosas distintas. El DPO vigila un tratamiento: que haya base legal, que el dato sea el mínimo necesario, que la persona sepa que existe. El responsable de cumplimiento vigila un marco: que la empresa esté dentro de la norma que la obliga, sea sectorial, societaria o laboral. El responsable de gobernanza de IA vigila un sistema a lo largo del tiempo: con qué datos se construyó, qué decide, cuánto se degrada, quién lo aprueba y quién lo apaga. Son tres objetos y tres relojes diferentes.
| Función | Objeto que supervisa | Norma de referencia | Pregunta que contesta |
|---|---|---|---|
| DPO / Delegado de protección de datos | El tratamiento de datos personales | RGPD, arts. 37 a 39 | ¿Este tratamiento es lícito y proporcionado? |
| Responsable de cumplimiento | El marco normativo que obliga a la empresa | Sectorial, societario, laboral | ¿Estamos dentro de la norma que nos aplica? |
| Responsable de gobernanza de IA | El ciclo de vida del sistema de IA | Reglamento Europeo de IA, arts. 10 y 26 | ¿Este sistema se puede desplegar, y quién responde si falla? |
En una empresa de sesenta personas las tres pueden ser la misma persona, y no pasa nada: la función no obliga a un puesto. Lo que sí rompe es dar por supuesto que cubrir un objeto cubre los otros dos. Un tratamiento impecable desde protección de datos puede sostener un sistema que lleva cuatro meses equivocándose en uno de cada doce casos sin que nadie lo haya medido, porque ese error no es un problema de dato personal: es un problema de ciclo de vida.
Qué supervisa exactamente un DPO, y dónde se le acaba el perímetro
El artículo 39 del RGPD enumera cinco funciones del delegado de protección de datos: informar y asesorar, supervisar el cumplimiento en materia de protección de datos, asesorar sobre la evaluación de impacto y supervisar su aplicación, cooperar con la autoridad de control y actuar como punto de contacto de esa autoridad. Las cinco cuelgan del mismo objeto, el tratamiento de datos personales. Esa es la delimitación legal, no una interpretación nuestra: puede consultarse en las preguntas frecuentes sobre el delegado de protección de datos de la AEPD. Ámbito: Unión Europea y España.
Ahora pon dos fallos reales al lado. Un agente que clasifica tickets entrantes y enruta mal uno de cada doce, con lo que el cliente espera dos días más de lo que debería. Un agente que cotiza con una tabla de precios que se quedó atrás en la última revisión. En ninguno de los dos hay un dato personal en riesgo, y en los dos hay dinero y confianza perdidos. El DPO no tiene ahí nada que supervisar, y eso no es un fallo del DPO: es que el fallo cae fuera de su objeto. Lo que sí cae dentro del objeto de la gobernanza de IA, desde el primer día, es el alcance con el que ese agente puede tocar tus sistemas: el detalle está en qué permisos darle a un agente de IA.
Por qué venir de cumplimiento es media carrera y no carrera hecha
El Reglamento Europeo de IA lo dice con una precisión que conviene leer entera. El artículo 26.2 establece que los responsables del despliegue «encomendarán la supervisión humana a personas físicas que cuenten con la competencia, la formación y la autoridad necesarias, así como con el apoyo necesario». Fuente: artículo 26 del Reglamento (UE) 2024/1689, texto consolidado. Tres patas, no una. Y la norma no se conforma con que exista un responsable en el organigrama: pide que esa persona entienda el sistema, haya sido formada en ese sistema concreto y pueda actuar sobre él.
Aquí está la trampa del atajo. Quien viene de cumplimiento aporta la tercera pata casi entera —autoridad, y la costumbre de dejarlo escrito, que no es poco— y aporta mucho de la primera cuando el riesgo es normativo. Lo que no aporta por defecto es competencia sobre el sistema: saber qué significa una salida, en qué condiciones se degrada, qué pinta tiene una respuesta plausible y equivocada, cuánto cuesta un falso positivo frente a un falso negativo en ese proceso. Eso no se lee, se adquiere operando. Media carrera hecha, entonces, es exacto. El problema empieza cuando se contrata como si fuera la carrera completa y el hueco se descubre el día del primer incidente.
Dónde empieza de verdad la obligación: artículos 10 y 26
La conversación sobre gobernanza de IA suele empezar por el artículo 10, que regula los datos y su gobernanza: los conjuntos de entrenamiento, validación y prueba, sus criterios de calidad, el análisis de sesgos y la trazabilidad del origen. Es un artículo decisivo, pero habla sobre todo de quien construye el sistema. Y la mayoría de las empresas no construye: despliega. Compra, configura, conecta a sus datos y lo pone a trabajar. Para ellas el artículo que aprieta es el 26, el de los responsables del despliegue, y ese orden —primero dónde encajas, después qué te obliga— es el que ordena todo lo demás. La versión larga, con el marco completo, está en la guía de gobernanza y control de la automatización con IA.
Tres apartados de ese mismo artículo 26 dibujan la función mejor que cualquier descripción de puesto. El apartado 5 obliga a vigilar el funcionamiento, a informar al proveedor y a la autoridad de vigilancia del mercado cuando haya riesgo y a suspender el uso del sistema, y a comunicar de inmediato los incidentes graves. El apartado 6 obliga a conservar los registros generados automáticamente durante al menos seis meses. Y el apartado 9 remite a la evaluación de impacto del artículo 35 del RGPD. Ese último es la costura: la evaluación de impacto es el único punto donde los dos objetos se tocan de verdad, y por eso es el documento que DPO y gobernanza de IA firman juntos en vez de por separado.
El aplazamiento del Ómnibus no te regala dos años
El calendario del alto riesgo se movió. El Reglamento (UE) 2026/1744, el llamado Ómnibus Digital sobre IA, publicado en el Diario Oficial de la Unión Europea, traslada las obligaciones de los sistemas de alto riesgo autónomos al 2 de diciembre de 2027 y las de los integrados en productos ya regulados a agosto de 2028; el seguimiento del calendario de aplicación publicado por el Future of Privacy Forum lo detalla por bloques. Lo que sigue en pie en agosto de 2026 ya lo desarrollamos en el AI Act se aplazó, pero tu chatbot sigue teniendo que avisar y no lo repetimos aquí. Ámbito: Unión Europea.
El punto operativo es otro, y es el que casi nadie saca del aplazamiento: la fecha que se mueve es la del incumplimiento, no la del problema. Y hay un detalle que lo vuelve urgente igualmente. Si la norma te va a pedir al menos seis meses de registros, un sistema que empieza a registrar la semana en que la obligación entra llega con el expediente vacío, que a efectos prácticos es lo mismo que llegar sin registros. El reloj de la evidencia se enciende antes que el del cumplimiento, y ese es el único argumento que hace falta para no esperar a 2027.
Las dos preguntas que delimitan la función mejor que cualquier descripción de puesto
Las descripciones de puesto de esta función se parecen todas porque están escritas desde la norma. Si quieres saber si la tienes cubierta de verdad, no mires el documento: haz dos preguntas sobre un sistema concreto, el que más dinero mueve, y escucha si la respuesta tarda.
- ¿Quién firma el despliegue? No quién lo aprobó en un comité, sino quién puso su nombre en la decisión de que ese sistema saliera a producción con ese alcance y esos permisos. Si la respuesta es un órgano colegiado, nadie firma. Si la respuesta es «el proveedor lo certifica», tampoco: el proveedor responde del producto, el responsable del despliegue responde del uso.
- ¿Quién responde cuando falla? Y dentro de esa, la única que de verdad separa la supervisión del teatro: ¿quién puede apagarlo sin pedir permiso? El artículo 26 pide autoridad, y la autoridad sin la facultad de parar es una firma decorativa. Si para desconectar el agente hay que esperar al comité del jueves, el sistema no está supervisado: está acompañado.
Las dos preguntas tienen una propiedad útil: se contestan con un nombre o no se contestan. Un marco de gobernanza puede estar impecable en PDF y fallar las dos. Si quieres ver el salto de la política escrita a la política que se ejecuta, lo desarrollamos en tu política de uso de IA está en un PDF y tu agente no sabe leerlo.
Cuándo NO necesitas un AI Governance Manager
Con un sistema en producción, un proceso y un responsable que lo conoce de memoria, nombrar un responsable de gobernanza de IA es prematuro, y lo que compras con ese nombramiento no es un control: es un comité. La gobernanza pesada antes de tiempo tiene un coste concreto y medible, que es el de las semanas que el primer caso de uso tarda en salir mientras se redacta el marco que lo va a regular. El perfil completo de la función, con su escalera de seniority y lo que pide el mercado, está en la ficha de AI Governance Lead.
El umbral no es una cifra de plantilla, es un síntoma: el día en que nadie puede enumerar de memoria todos los agentes que corren en la empresa, la función ya hace falta, tenga nombre o no. Y antes de la función va el censo, porque una política no se aplica a una flota que no está contada: eso lo discutimos en el inventario de agentes que tu empresa no tiene.
Qué haría yo el lunes
- Lista los sistemas de IA que están corriendo y, al lado de cada uno, un nombre. No el equipo: la persona. Las casillas vacías son tu diagnóstico, y normalmente son más de las que esperas.
- Para los dos que más dinero mueven, contesta por escrito las dos preguntas. Una frase cada una. Si no caben en una frase, todavía no están contestadas.
- Separa en un folio el objeto del DPO y el objeto de la gobernanza de IA para esos dos sistemas, y marca el punto donde se cruzan: la evaluación de impacto. Ese es el único documento que firman los dos.
- Enciende el reloj de los registros hoy, aunque la obligación sea de 2027. Seis meses de histórico no se pueden retroactivar, y es lo único de esta lista que depende del calendario y no de ti.
La gobernanza de IA no se resuelve fichando un título, se resuelve decidiendo quién firma y quién apaga, y dejando rastro de las dos cosas. Si quieres montar esa función sin pasar seis meses escribiendo el marco antes de controlar nada, es exactamente lo que hacemos en gobernar los agentes de IA de tu empresa: el rastro, los permisos y la cadena de responsabilidad primero, y el documento después, que es el orden en el que de verdad funciona.