El gobierno de IA como sistema adaptativo

El cambio empezó sin que yo lo decidiera

En algún momento de 2022 dejé de pensar en el gobierno de IA como un proceso que había que implementar. Empecé a verlo como algo que había que lanzar.

No recuerdo una conversación concreta ni una decisión formal. Solo recuerdo que, durante una presentación, tuve clara la organización del backlog y, a partir de ahí, muchas cosas empezaron a encajar mejor.

Llevaba años aplicando Lean, Six Sigma y Agile a diferentes contextos de transformación. Mi acceso al gobierno de IA fue por la puerta de operaciones, no por la de la ética ni por la del derecho. Cuando llegué a este campo, la mayoría de la gente que escribía sobre esto venía de uno de esos dos sitios. Yo venía de otro. Sin pretenderlo, eso me obligó a mirar el problema con otras herramientas.

Lo primero que me llamó la atención fue que los frameworks disponibles asumían una estabilidad que ya no existía. Plantillas para clasificar riesgos. Pasos para aprobar despliegues. Comités con periodicidad fija. Documentos que se firmaban y se archivaban. Era el manual clásico de gobernanza corporativa trasplantado a la IA.

Y entendí pronto que ese trasplante no iba a funcionar.

Un proceso asume estabilidad. Define pasos. Reduce variabilidad. Aspira a controlar. Durante años eso ha estado funcionando razonablemente bien en otras áreas del mundo empresarial.

Pero la IA ha roto las premisas sobre las que se ha construido toda esa lógica. Sistemas que cambian continuamente. Modelos que evolucionan más rápido que los ciclos de aprobación. Regulación en movimiento. Responsabilidades difusas. Organizaciones que aún no saben exactamente qué necesitan gobernar.

En ese contexto, el gobierno clásico ya está llegando tarde. No por mala voluntad de quienes lo aplican, sino por diseño.

Y ahí aparece la primera incomodidad: las empresas necesitan más control sobre la IA precisamente cuando el control tradicional ha dejado de funcionar.

Cuando el proceso llega tarde por diseño

Cuando hablo con responsables de gobierno de IA en otras organizaciones, hay una queja que aparece casi siempre. El comité de revisión se reúne cuando el modelo ya está en producción. Las plantillas de evaluación de riesgo se rellenan después de que el equipo de delivery haya tomado las decisiones difíciles. Las políticas se publican cuando las prácticas ya están consolidadas.

La interpretación habitual es de voluntad: la gente no quiere gobernar, no prioriza, no entiende. He defendido esa lectura yo mismo durante un tiempo. La he abandonado.

El problema no es de voluntad. Es de diseño del proceso.

Un proceso de gobierno construido con la lógica clásica tiene tres rasgos que en otros contextos eran virtudes y en este contexto son defectos.

Primero, la secuencialidad. Se define un orden de pasos y se exige que se cumplan en ese orden. En un sistema estable eso reduce errores. En un sistema cambiante eso garantiza que cuando llegas al paso siete, los pasos uno a seis ya no describen lo que está pasando.

Segundo, la separación clara de responsabilidades. Cada área tiene su parte. Negocio define el caso de uso. Datos prepara la información. Tecnología construye el modelo. Compliance revisa el resultado. Es una división razonable en abstracto. En la práctica, cuando algo va mal a mitad de cadena, nadie está claramente a cargo de detener el flujo. Cada uno cumple su parte y sigue adelante.

Tercero, la documentación como prueba de gobierno. Si está documentado, está gobernado. La documentación deja huella, permite auditoría, sostiene compliance. Pero la documentación, por sí sola, no cambia decisiones. Quién no ha visto sistemas con documentación impecable que siguieron desplegándose después de que la propia documentación señalara problemas serios. Documentar no es decidir.

Ninguno de estos tres rasgos es estúpido. Cada uno responde a un problema real que la gobernanza clásica resolvió bien. El problema es que la IA no se parece al objeto para el que se diseñaron.

Un modelo en producción cambia cada vez que se reentrenan los datos. Los criterios de fairness varían entre regiones y entre productos. La regulación europea que aplica hoy va a tener nuevos actos delegados dentro de unos meses. El equipo que construye el sistema rara vez es el mismo que lo mantiene seis meses después.

Aplicar un proceso secuencial, con responsabilidades separadas y documentación como prueba, a un objeto que se comporta así, no es ineficiente. Es estructuralmente incapaz de gobernarlo.

Por eso muchos programas de AI Governance que sobre el papel están bien diseñados, en la práctica producen el resultado conocido: actividad, no decisiones.

Y aquí aparece la pregunta que durante un tiempo me retaba mentalmente día y noche. Si el proceso clásico no funciona, ¿qué lo sustituye?

La primera respuesta que encontré fue tratar el gobierno como un producto. Funcionó. Y, con el tiempo, he descubierto por qué solo en parte.

La metáfora del producto, y por qué se queda corta

En 2022 tomé una decisión que cambió cómo construíamos el programa interno. Dejé de tratarlo como un proceso. Lo traté como un producto.

No era un cambio semántico. Era un cambio de metodología.

Un proceso se diseña, se aprueba, se implementa, se audita. Un producto se lanza en versión mínima, aprende en contacto con el uso real, itera, corrige y convive con feedback contradictorio mientras está siendo usado.

La diferencia operativa es enorme. Un proceso se mide por su cumplimiento. Un producto se mide por su impacto. Un proceso falla cuando alguien no lo sigue. Un producto falla cuando nadie lo adopta. Un proceso pide una sola decisión: aprobado o no. Un producto pide muchas decisiones pequeñas a lo largo del tiempo: qué priorizamos, qué dejamos para después, qué hemos aprendido del último ciclo. Y no por último menos importante, cuánto tiempo transcurre desde la idea hasta la puesta en producción.

Operar así, ha permitido que el programa avance a su ritmo, implementando funcionalidades básicas primero, iterando cuando es necesario sobre ellas. La razón para estos avances no ha sido heroísmo del equipo. Ha sido que el modelo de producto resiste mejor el desorden real. Cuando aparece un caso de uso nuevo que no encaja en las plantillas, no se detiene todo el sistema. Generaba una nueva funcionalidad. Cuando una política se demostraba inaplicable, no se forzaba. Se iteraba.

Dentro del propio modelo, las disciplinas que llevaba años usando empezaron a funcionar al fin.

Lean me servía para identificar dónde el proceso de decisión sobre IA acumulaba waste. Un comité que se reúne cuando el sistema ya está en producción es waste, no falta de voluntad. La causa del defecto no es ética. Es de diseño del flujo. Quitarla cambia la conversación. Añadir lenguaje común también.

Six Sigma da las herramientas para definir qué es un defecto en el sistema de gobierno y medir su frecuencia. La mayoría de programas miden actividad: cuántos modelos tienen documentación, cuántas personas han hecho formación, cuántas reuniones se celebraron. Yo prefiero medir otra cosa: cuántas decisiones reales se modifican como consecuencia del programa. Eso requiere definir qué cuenta como decisión modificada, y eso es definir un defecto invertido.

Agile me da aporta siempre la tolerancia explícita al error controlado. Una política que intenta ser perfecta antes de desplegarse no se despliega. Las versiones intermedias generan aprendizaje. El coste de iterar es menor que el coste de paralizar.

Durante meses, todo esto fue suficiente. Teníamos sensación de avance continuo, el ruido bajaba, las decisiones empezaban a tener trazabilidad sin convertirse en burocracia. La metáfora de producto funcionaba.

Hasta que dejó de funcionar. Tenía carencias.

El problema no era la metáfora en sí. Era que un producto, en su definición clásica, tiene un usuario. Puede tener varios segmentos, pero comparten un eje de valor. Spotify tiene oyentes y artistas; sus intereses no son idénticos, pero sí compatibles dentro de una propuesta de valor común.

El gobierno de IA no funciona así.

Legal quiere reducir exposición. Negocio quiere velocidad. Compliance quiere trazabilidad. Data science quiere autonomía técnica. Security quiere minimizar superficie de riesgo. Los reguladores quieren evidencia. Los ejecutivos quieren escalar sin titulares negativos. Y todos creen, parcialmente, tener razón.

Los stakeholders del gobierno de IA no comparten un eje de valor. Tienen incentivos estructuralmente incompatibles. Si optimizas para uno, deterioras al menos a otro.

Eso convierte el gobierno en algo distinto a un producto. No es coordinación entre intereses convergentes. Es negociación continua bajo conflicto estructural.

Y aquí es donde la metáfora se rompió para mí.

Pensar en tensiones, no en pilares

La literatura de gobierno de IA suele organizarse en pilares. Riesgo, ética, compliance, transparencia, robustez técnica, supervisión humana. Es una estructura limpia y permite producir presentaciones convincentes.

He dejado de usarla.

No porque los pilares estén mal identificados. Están bien. El problema es que la imagen del pilar sugiere que cada uno de esos elementos sostiene una parte distinta del edificio y que el trabajo del gobierno consiste en construirlos en paralelo, cada uno con su responsable y su métrica.

La realidad de los entornos en los que he trabajado no se parece a eso. Los pilares no sostienen partes distintas. Tiran cada uno en una dirección. Lo que sostiene el sistema no es el pilar; es la tensión entre pilares.

Hay seis tensiones que escucho repetirse en cualquier organización que esté seriamente intentando gobernar IA.

La primera es acelerar sin perder capacidad de control. Cualquier mecanismo de control que se construya, si funciona, va a ralentizar algo en algún momento. Cualquier mecanismo de aceleración, si funciona, va a abrir riesgos que antes no existían. Esta tensión no se resuelve. Se calibra de forma continua.

La segunda es estandarizar sin destruir autonomía técnica. Los equipos de data science necesitan margen para tomar decisiones técnicas informadas que el modelo estándar no contempla. La estandarización mal calibrada genera o bien rebeldía silenciosa, o bien parálisis. La autonomía mal calibrada genera incoherencia entre proyectos y deuda de gobierno acumulada.

La tercera es explicar decisiones sin revelar más de lo que la organización puede sostener estratégicamente. La transparencia es un valor, pero tiene coste. Explicar por qué un modelo de scoring rechazó una solicitud puede convertirse en una ventaja para quien quiere manipularlo. La opacidad protege, pero erosiona legitimidad. Aquí no hay punto medio fijo. Hay decisiones contextuales que la organización tiene que aprender a tomar.

La cuarta es automatizar controles sin convertir el gobierno en burocracia invisible. Los controles automáticos son escalables pero crean una falsa sensación de seguridad. Cuando todos los checks están en verde, el comité humano deja de pensar. Sistemas donde el automatismo se convierte en el único filtro, y donde el filtro automático no detecta lo que cualquier persona con criterio habría detectado en cinco minutos de revisión.

La quinta es construir confianza sin prometer certeza. La gente quiere oír que el sistema es seguro, justo, fiable. No lo es del todo. Ningún sistema sociotécnico complejo lo es. La opción de prometer certeza es tentadora porque desbloquea adopción rápida. El precio es que cuando algo falle, y algo va a fallar, la promesa rota destruye más confianza de la que la promesa había construido.

La sexta, y la más incómoda, es transparencia que muestra contradicciones. Cuanto más transparente es una organización sobre cómo decide, más visibles se hacen las contradicciones entre lo que dice y lo que hace, entre lo que distintas áreas defienden, entre lo que la política escrita afirma y lo que el sistema realmente hace. Esconder las contradicciones ya no es viable. Mostrarlas exige una madurez organizacional que muchas empresas todavía no tienen.

Ninguna de las seis se resuelve. Se sostienen.

Pensar el gobierno como pilares lleva a intentar resolverlas. Pensarlo como sistema adaptativo lleva a calibrarlas, re-calibrarlas, vivir dentro de ellas sin pretender cerrarlas.

Eso cambia qué se mide. Si el gobierno fuera un proyecto, se medirían entregables. Si fuera un proceso, se mediría cumplimiento. Si fuera un producto, se medirían adopción y satisfacción. Como sistema adaptativo, lo que importa es otra cosa.

Lo que debería medirse es cuántas decisiones se modificaron como resultado del programa. Cuántos despliegues se detuvieron. Cuántos modelos cambiaron tras una revisión. Cuántas políticas se ajustaron después del primer contacto con un caso real. La métrica central del gobierno como sistema adaptativo es la capacidad demostrable del sistema para corregirse.

Si no se corrige, no es adaptativo. Es decoración con jerga nueva.

Por qué este trabajo necesita otro perfil

Si lo que describo os suena razonable, hay una consecuencia para quien lee desde dentro de una organización: el perfil dominante en gobierno de IA tiene que cambiar.

Hoy el campo lo ocupan, mayoritariamente, dos tipos de profesional. Los expertos en ética aplicada, que vienen de filosofía, sociología, estudios de tecnología y derechos digitales. Y los expertos en compliance regulatorio, que vienen del derecho, el riesgo y la auditoría. Las dos comunidades son imprescindibles. Sin ellas, el gobierno de IA no existe.

Pero solas no lo sostienen.

Lo que falta, en la mayoría de organizaciones que conozco, son perfiles que sepan diseñar sistemas operativos resistentes al cambio. Gente que haya hecho transformación digital de procesos, que entienda métricas de impacto, que haya tenido que sostener una iniciativa transversal con stakeholders enfrentados. En la mayoría de los casos, esa gente viene de operaciones, no de ética ni de derecho.

Mi propia trayectoria es ese tipo de cruce, y no la cuento como mérito personal sino como ilustración del hueco que el sector todavía no nombra bien. Lean Six Sigma, gestión de proyectos, transformación digital. Veinte años mejorando procesos, sistemas, consultas, antes de tocar IA. Cuando entré al campo, descubrí que las herramientas que traía resolvían problemas que la literatura existente trataba como bloqueos culturales.

Un comité que se reúne tarde no es un problema cultural. Es un defecto de diseño del flujo, y Lean tiene un siglo de práctica resolviéndolo.

Una métrica de gobierno que cuenta documentos en lugar de decisiones no es un fallo de voluntad. Es una definición incorrecta del defecto que se quiere medir, y Six Sigma tiene métodos concretos para corregirlo.

Un framework que llega completo antes de probarse no es un exceso de ambición. Es un patrón de diseño de proyecto que Agile abandonó hace veinte años por razones que aplican aquí sin modificaciones.

El sector ha tenido durante años una resistencia implícita a estas disciplinas, porque las asocia con eficiencia industrial y le da miedo que el lenguaje de optimización se aplique a cuestiones éticas. Esa preocupación es razonable. Pero el error inverso es peor: tratar el gobierno de IA como si solo necesitara reflexión normativa, sin la disciplina operativa que cualquier programa que aspira a sostenerse en el tiempo necesita.

Lo digo sin matices: si el gobierno de IA no incorpora a gente que sepa diseñar sistemas de decisión bajo restricciones, va a seguir produciendo documentos buenos y resultados modestos.

Esto también conecta con un tipo de habilidad que en otros textos he llamado liderazgo transversal. La habilidad de mover una iniciativa sin autoridad formal, dentro de una red de stakeholders con agendas distintas. Quien viene de operaciones, si ha hecho transformación digital seria, lo ha tenido que aprender por necesidad. Quien viene solo de la regulación o solo de la ética, frecuentemente no. Y el gobierno de IA, como he intentado mostrar, es exactamente esa clase de problema.

Lo que el modelo no resuelve

No quiero terminar este ensayo como si fuera una victoria. Sería deshonesto.

Tratar el gobierno como sistema adaptativo resuelve problemas reales del modelo de proceso y del modelo de producto. También crea problemas nuevos. Algunos de ellos son los que más tiempo me han costado, y me siguen costando.

El primero es la fricción con la cultura del entregable. Los Boards, los comités de dirección, los inversores cuando los hay, todos están acostumbrados a recibir entregables. Tienen un mes de junio y esperan ver el plan de gobierno aprobado. Tienen una auditoría externa y esperan ver el framework cerrado. Cuando lo que tienes que mostrar es un sistema que itera, en lugar de un documento que cierra, la primera reacción es desconfianza.

Esa desconfianza no es absurda. Quien aprueba un programa quiere saber qué se le entrega a cambio. Y un sistema vivo, aunque más útil, es estructuralmente menos legible que un proyecto con su fecha de cierre.

Una parte del trabajo de quien lidera gobierno de IA bajo este modelo es producir versiones legibles de algo que en su naturaleza no se cierra. Generar entregables intermedios que sirvan como hitos sin convertir el programa entero en proyecto. Saber traducir entre dos lenguajes culturales distintos, sin acabar mintiendo a ninguno de los dos.

El segundo coste es la resistencia de quienes esperan certidumbre. Los equipos técnicos quieren saber qué pueden y qué no pueden hacer. Las áreas de negocio quieren saber qué casos de uso van a ser aprobados y cuáles no. Compliance quiere saber qué controles van a estar en marcha en seis meses. Decir que la respuesta depende del caso, del contexto y del aprendizaje del propio sistema, es decir lo correcto, pero es también decir algo que produce frustración inmediata.

He aprendido a no suavizar esto. La frustración inicial es parte del modelo. Lo que la resuelve no es prometer certeza falsa. Es demostrar, ciclo a ciclo, que el sistema sí toma decisiones; solo que las toma a un ritmo y con una granularidad distintos al modelo anterior.

El tercer coste, y probablemente el más exigente, es la pedagogía interna que el modelo exige. No hablo de formación en gobierno de IA, que es otra cosa y la he escrito en otros sitios. Hablo de la pedagogía sobre el propio modelo de gobierno: explicar a cada interlocutor, en su lenguaje, por qué no se le va a entregar lo que pide en el formato en que lo pide.

Esa pedagogía no se delega. La hace quien lidera, y la hace cada vez. Si no la haces, el modelo se desvanece. Vuelve por inercia al modo proyecto, porque el modo proyecto es el default cultural de la organización.

Y un cuarto coste, más sutil, es propio. Trabajar dentro de tensiones que no se cierran tiene un peso emocional que la gestión clásica no tenía. Quien lidera un proyecto puede declarar éxito cuando entrega. Quien sostiene un sistema adaptativo no puede declarar éxito nunca del todo, porque siempre hay otra iteración pendiente. Aprender a vivir con esa apertura sin que se convierta en ansiedad o en cinismo es parte del trabajo.

No voy a romantizarlo. Hay días en que el modelo cansa. Pero la alternativa, en mi experiencia, es peor.

La pregunta operativa

La pregunta operativa de fondo no es si el gobierno de IA debería ser un proceso, un producto o un sistema adaptativo. Esa pregunta es metodológica y se contesta en debates.

La pregunta operativa de fondo es otra: cómo se sostiene un sistema de gobierno cuando el objeto que gobierna cambia cada seis meses.

Si la respuesta tiene forma de framework, es la respuesta equivocada. Los frameworks son útiles como puntos de partida; cuando se vuelven definitivos, se vuelven trampa.

Si la respuesta tiene forma de comité, es la respuesta equivocada también. Los comités producen actas; rara vez producen decisiones que cambien algo, salvo cuando están diseñados para que así sea, y la mayoría no lo están.

Si la respuesta tiene forma de tecnología, es la respuesta más equivocada de todas. No hay herramienta que sustituya la capacidad de un sistema organizacional para tomar decisiones bajo incertidumbre y corregirse cuando esas decisiones se demuestran erradas.

La respuesta tiene forma de manera de gestionar. Pequeñas iteraciones. Métricas de impacto, no de actividad. Tolerancia explícita al error controlado. Disposición a sostener tensiones sin pretender cerrarlas. Pedagogía interna constante. Y, como base, gente capaz de operar todo esto sin acudir cada semana al manual.

El gobierno de IA, gestionado así, no se parece a lo que el sector dibuja en sus presentaciones. Se parece más a otras infraestructuras vivas de la empresa: el sistema de calidad, el modelo de seguridad informática, las prácticas de gestión del cambio. Disciplinas que no se acaban, que no se entregan, que se sostienen.

Y que cuando se descuidan, no fallan ruidosamente. Fallan en silencio. Dejan de gobernar y siguen pareciendo gobierno hasta el día en que el contexto las expone.

Por eso vuelvo a la tesis con la que empecé.

Dejé de pensar el gobierno de IA como un proceso. Tampoco me basta verlo como un producto. Lo que queda es un sistema adaptativo.

O no gobierna.