Los cuatro mensajes que un Board debería recibir sobre gobierno de IA
Llevo meses viendo charlas y mesas redondas sobre IA. En la mayoría hay un Consejo de Administración mencionado de pasada, como interlocutor abstracto al que hay que “concienciar”. Y casi siempre se le ofrecen los mismos tres mensajes: que hay que cumplir con la normativa, que el sesgo es un problema técnico que el equipo de datos resolverá, y que la ética importa porque “es lo que demandan los clientes”.
Todo cierto. Todo insuficiente.
Hace cinco años empecé a trabajar específicamente en gobierno de IA dentro de una compañía aseguradora. Antes, dos décadas en datos y operaciones. He construido comités, redactado políticas, formado a más de cien personas en alfabetización de IA, y, sobre todo, he visto cómo cambian las conversaciones con un Consejo cuando se les ofrece otro tipo de mensaje.
Estos son los cuatro que faltan en la mayoría de las presentaciones que veo. No son tesis nuevas. Son los que cambian el registro de la conversación. Si un Consejo los recibe con claridad, deja de pedir certezas imposibles y empieza a hacer las preguntas correctas.
1. Si el algoritmo discrimina, el problema no está en el código. Está en tu política.
Los riesgos éticos de un sistema de IA no son bugs. Son features que funcionan exactamente como fueron diseñadas. Un modelo de scoring que penaliza determinados códigos postales no está roto. Está optimizando lo que se le pidió optimizar, con los datos que se le dieron, y replicando los sesgos históricos que esos datos contienen.
Esto no se arregla con Python. Se arregla decidiendo, antes de que el modelo entre en producción, qué tipo de errores tu organización está dispuesta a cometer y cuáles no. Y esa decisión no es del equipo técnico. Es del Consejo, porque el coste reputacional y regulatorio de un error sistemático no recae sobre los data scientists. Recae sobre la marca.
Lo veo en cada revisión: cuando un comité técnico recibe un caso de uso, dedica la mayor parte del tiempo a discutir métricas de rendimiento y una fracción mínima a las implicaciones éticas. Cuando el Consejo recibe el mismo caso, la proporción debería invertirse. Casi nunca lo hace.
El primer mensaje, entonces, es operativo y no filosófico: el código solo ejecuta política. Si la política no existe, el código la inventa por defecto. Y la política por defecto suele ser la del modelo más eficiente, no la del modelo más justo.
2. Business owns the Outcome. IT only owns the Output.
Tu equipo de delivery construye un modelo con 95% de precisión. Lo presentan como un éxito técnico, y lo es. Pero el día que ese modelo deniega un seguro a una familia con quince años de historial limpio en la compañía, lo que se evalúa no es el accuracy. Es la decisión corporativa de delegar en un sistema automatizado un acto que afecta a personas concretas.
Esa decisión es del Consejo, no del equipo técnico. Por mucho que ellos hayan firmado el modelo, producen el output. Tú eres responsable del outcome. La diferencia entre las dos cosas es la diferencia entre “el modelo decidió” y “la compañía decidió usar el modelo”. La segunda es la única que un regulador o un cliente perjudicado va a aceptar como respuesta.
Operativamente esto tiene una consecuencia incómoda: el Consejo no puede delegar la aprobación de sistemas de IA de alto riesgo a un comité técnico. Puede recibir su análisis, su recomendación, su documentación. Pero la aprobación, especialmente cuando hay impacto sobre personas, sigue siendo suya. Si delega ese acto, está delegando algo que la normativa europea cada vez más explícitamente no le permite delegar.
Y nunca, nunca fue responsabilidad del departamento técnico. Aceptar que lo fuera fue un error estructural del sector. Corregirlo no es un cambio organizativo cosmético. Es la base sobre la que se construye cualquier marco de gobierno que funcione.
3. La neutralidad algorítmica es un mito. El silencio es una elección.
Existen más de veinte definiciones matemáticas de fairness en la literatura académica. Las más conocidas, como la paridad demográfica, la igualdad de oportunidades y la calibración entre grupos, son demostrablemente incompatibles entre sí. Es un teorema, no una opinión: no se pueden satisfacer las tres simultáneamente cuando los grupos comparados tienen distinta distribución de outcomes en los datos históricos.
Esto significa que en cualquier sistema de IA que afecte a decisiones sobre personas, la organización tiene que elegir qué definición de fairness va a optimizar. No puede “optimizar todas”, porque no es posible. Y si no elige, el modelo elige por ella, y suele hacerlo en función de lo que era estadísticamente más cómodo de calcular durante el entrenamiento.
Definir cuál es la noción de equidad que defiende la compañía es una decisión estratégica del mismo orden que definir la política de pricing o la política de inversión. No es ingeniería. No la toman los data scientists. La toma un Consejo, por escrito, y luego el equipo técnico la implementa.
El silencio sobre este punto es una decisión disfrazada. Si el Consejo no expresa qué fairness defiende la compañía, está aceptando, de facto, la fairness que produzca el modelo más eficiente. Y los modelos más eficientes, sin restricciones, tienden a optimizar el margen a corto plazo. Que es justo el indicador que un Consejo no debería querer ver acoplado a sus decisiones sociales.
Definir fairness es un acto de liderazgo, no de ingeniería. Y como cualquier acto de liderazgo, requiere asumir el coste de elegir.
4. El gobierno de la IA no es el freno. Es el volante.
Hay una creencia extendida en muchos comités directivos: la gobernanza ralentiza la innovación. Es comprensible que se piense, porque la primera versión de cualquier programa de governance suele consistir en añadir procesos de revisión donde antes no había. Y procesos nuevos, en organizaciones acostumbradas a moverse sin ellos, se viven como fricción.
Pero lo que veo, dentro y fuera de mi sector, apunta en dirección contraria. Las compañías con programas robustos de gobierno de IA despliegan más sistemas y los retiran menos. La razón es estructural: cuando un equipo sabe que existe un proceso claro de revisión, deja de añadir mitigaciones excesivas por miedo a la deriva del modelo. Construye con la confianza de que habrá un punto de control formal, no informal, antes de producción.
La gobernanza no ralentiza el time-to-market. Lo protege del time-to-incident, que es la métrica que de verdad importa cuando un sistema falla en público. Una semana extra de revisión vale más que seis meses de gestión de crisis.
El cuarto mensaje, entonces, va dirigido a la intuición que más cuesta cambiar: el governance no es lo que limita la velocidad. Es lo que la sostiene. Periodo.
Estos cuatro mensajes no resuelven el gobierno de IA de una compañía. Lo orientan. Operativizar un marco de gobierno de IA Responsable requiere comités con mandato real, políticas escritas con consecuencias claras, formación continua para los equipos que conviven con los sistemas, y métricas que midan decisiones cambiadas, no actividad realizada.
Lo que estos cuatro mensajes sí hacen es liberar al Consejo del rol pasivo en el que la conversación dominante sobre IA tiende a colocarlo. No es alguien a quien hay que “concienciar”. Es alguien que tiene que decidir, por escrito y con coste, qué tipo de empresa quiere ser cuando sus decisiones más sensibles se ejecuten parcial o totalmente con sistemas automatizados.
Hacer ese trabajo produce algo que ningún dashboard puede darte: la convicción de que el volante está en tus manos. Y, sobre todo, la posibilidad de explicarles a quienes te exigen rendir cuentas, sean reguladores o clientes, qué decisiones tomaste y por qué.