Hay un tipo de conocimiento sobre gobierno de IA que no aparece en ningún framework
Hay un tipo de conocimiento sobre gobierno de IA que no aparece en ningún framework. Tampoco en los certificados de AI Governance Professional, por buenos que sean. Tampoco en la norma ISO/IEC 42001, por completa que esté. No es desprecio a esas referencias, las uso a diario y las recomiendo. Es una observación distinta: hay una capa de conocimiento operativo que solo se adquiere haciendo el trabajo, y rara vez se hace explícita.
Tampoco aparece en las conversaciones más generales sobre liderazgo transversal, aunque está íntimamente relacionado. Y tampoco se adquiere en condiciones cómodas.
Lo he aprendido liderando la implementación de un programa de gobierno de IA en un modelo distribuido, sin un área centralizada, coordinando equipos con agendas distintas y respondiendo ante múltiples stakeholders al mismo tiempo. Durante un tiempo lo viví como un obstáculo. Con el tiempo entendí que era el método.
Lo que sigue son aspectos de ese conocimiento que solo se nombran cuando alguien que los ha vivido se sienta a explicarlos. Ninguno se enseña en un curso. Todos se reconocen en cuanto se ponen en palabras.
Cuando no hay un área que lo respalde
La condición que hace posible este aprendizaje es muy concreta. No basta con trabajar en gobierno de IA. Hay que hacerlo sin la estructura de respaldo que normaliza el rol.
Cuando un programa de governance se construye con un área centralizada, un Chief AI Officer, un equipo dedicado y un mandato escrito por el Consejo, el trabajo cotidiano es distinto. Sigue siendo difícil, pero la dificultad es de implementación. Cada decisión tiene un canal formal y un respaldo jerárquico explícito.
Cuando se construye en un modelo distribuido, la dificultad cambia de naturaleza. Cada decisión exige negociación. Cada conversación exige construir el contexto desde cero. Cada acuerdo necesita ser sostenido activamente, porque no hay nada estructural que lo proteja entre una reunión y la siguiente.
Esa diferencia parece sutil cuando se enuncia en una página. No lo es en absoluto cuando se vive durante años. Define qué habilidades se desarrollan, qué clase de juicios aprendes a hacer y, sobre todo, qué entiendes por “gobierno” cuando alguien usa esa palabra.
No es el camino que elegiría para iniciarme en esta disciplina. Implica más exposición y más fricción de las que un modelo más institucionalizado provoca. Pero, para entender cómo funciona el gobierno de IA dentro de una organización real, con sus fricciones y sus inercias, no conozco una escuela más exigente.
La mayoría de los avances ocurren fuera de los comités
Lo primero que descubres en un entorno así es algo que la jerarquía formal tiende a ocultar: la mayoría de los avances reales no ocurren en los comités ni en los documentos. Ocurren en las conversaciones previas, en los acuerdos informales, en la confianza construida antes de que llegue el momento crítico.
En la teoría del gobierno corporativo, los comités son el lugar de la decisión. En la práctica, los comités son el lugar de la ratificación. La decisión se ha cocinado antes, en encuentros bilaterales, en pasillos, en correos breves entre dos personas que llevaban semanas alineándose sobre cómo plantear el tema.
Esto no es una crítica del modelo. Es una observación operativa que cambia cómo trabajas. Si entras a un comité pensando que es ahí donde se va a decidir, llegas tarde. Si entras sabiendo que el comité ratifica, dedicas la mayor parte de tu energía a las semanas previas y solo una fracción a la presentación. El primer modelo te sorprende. El segundo te permite influir.
En estructuras distribuidas esto se intensifica. Sin un área que centralice el gobierno, no hay un canal único de información. Lo que un equipo sabe lo aprende por proximidad, por relación, por iniciativa propia de quien la sostiene. Eso obliga a quien lidera el programa a hacer un trabajo que no aparece en ninguna descripción de puesto: mantener viva una red informal de interlocutores, en distintos niveles y en distintas áreas, sin la cual cualquier decisión formal carecería de tracción.
No se delega. No se documenta. Y, sin embargo, sin eso el programa no avanza.
El criterio de conseguir que otros decidan bien
En las descripciones convencionales del rol de gobierno de IA, lo central es la capacidad de tomar decisiones. Evaluar riesgo, clasificar sistemas, aprobar despliegues, definir políticas. Es trabajo de juicio, claramente, y requiere experiencia.
En estructuras distribuidas hay otra capa. No el criterio de quien decide, sino el de quien tiene que conseguir que otros decidan bien. Son habilidades diferentes. Y la segunda, en entornos complejos, es bastante más difícil.
Conseguir que otros decidan bien implica entender qué información necesita cada perfil, en qué formato y con qué nivel de detalle, para poder ejercer su juicio sin sentirse instrumentalizado. Exige calibrar cuándo dar una recomendación clara y cuándo dejar espacio para que la decisión la haga quien tiene la legitimidad formal. Y obliga a reconocer cuándo un acuerdo aparente esconde una resistencia real que se manifestará más tarde, en el momento más inoportuno.
Eso no se enseña como técnica. Se aprende cometiendo errores en condiciones donde el coste recae sobre ti, porque no hay una estructura jerárquica que diluya la responsabilidad. Cuando una decisión sale mal, no es de “el comité”. Es tuya, en la medida en que tú eras quien debía haber alineado las piezas para que el comité decidiera distinto.
Esa diferencia, entre el rol que decide y el rol que consigue que otros decidan bien, explica por qué a algunos profesionales sobradamente cualificados en lo técnico no les funciona el gobierno de IA dentro de una organización compleja. El conocimiento les sobra. Lo que les falta es haber operado el otro tipo de criterio.
Lo que no se nombra no existe
En estructuras formales, hay un área que institucionaliza el trabajo. El gobierno de IA existe porque hay un departamento, un equipo, un presupuesto. La continuidad del programa no depende exclusivamente de quien lo sostiene en un momento dado.
En estructuras distribuidas, lo que no se nombra no existe. No porque nadie lo vea, sino porque sin un área que lo institucionalice, el trabajo se disuelve en cuanto deja de tener quien lo sostenga. Si quien lidera el programa no comunica activamente lo que se está haciendo, por qué se está haciendo y qué se está consiguiendo, el programa pierde tracción a los seis meses.
Eso cambia la relación con la comunicación. Aprendes a hacerlo no como estrategia personal de posicionamiento, sino como parte de la gestión. Cada presentación, cada nota interna, cada correo donde compartes un avance, cumple una función que en una estructura formal harían el organigrama y el presupuesto. Le da existencia al programa para quienes no participan directamente en él.
A muchos profesionales, especialmente a los que vienen de un perfil técnico, esto les resulta incómodo. Lo viven como autopromoción, lo asocian a vanidad. En un modelo distribuido es exactamente lo contrario. Es parte de la disciplina. Si el programa no se ve, no existe. Y si no existe, en cuanto cambie una prioridad ejecutiva, alguien va a preguntar qué se está haciendo exactamente con lo que se invierte ahí y la respuesta será débil.
Hay una razón por la que este conocimiento no aparece en frameworks. Los frameworks describen estructuras, no las habilidades para operar dentro de ellas cuando esas estructuras todavía no existen.
No es el camino que elegiría para iniciarse en la disciplina. Si alguien me preguntara por dónde empezar en gobierno de IA, le recomendaría una organización con estructura formal de governance, aprender el oficio en condiciones razonables y, solo entonces, si tiene la inclinación, asumir la complejidad de los modelos distribuidos.
Pero quien ya está en uno, por elección o por circunstancia, conviene que sepa lo que está aprendiendo. No es solo trabajo. Es una forma específica de criterio que el sector necesita y que casi no se reconoce. Quien la desarrolla acaba teniendo una ventaja interpretativa sobre cómo funciona el gobierno de IA dentro de una organización real, que es difícil de adquirir por otra vía. La incomodidad es alta. La escuela también.