Las puertas reales que cruza una IA
El comité dijo que sí. El modelo no salió.
No fue un fallo técnico. El pipeline estaba en verde, la documentación cerrada, el acta firmada por quien tenía que firmarla. Y aun así el despliegue se quedó parado semanas, porque faltaba un sí que no figuraba en ningún sitio: el de la persona que llevaba una operación que el modelo tocaba de refilón, a la que nadie había sentado en la mesa porque, sobre el papel, aquello no le correspondía.
Esa distancia entre el aprobado y el despliegue es donde vive de verdad la gobernanza. No en el acta. En las puertas que el acta no nombra.
El recorrido que dibujas y el que existe
Cualquier programa tiene su recorrido oficial. Evaluación de riesgo, revisión de sesgo, comité, checklist de cumplimiento, sign-off. Lo dibujas en una diapositiva con flechas y queda bien. Da sensación de control.
El problema es que ese diagrama es el mapa, y el mapa no es el territorio. El recorrido real de un modelo hasta que llega al usuario pasa por puertas que no salen en la diapositiva. Y muchas de esas puertas pesan más que el comité entero.
He visto programas impecables sobre el papel encallar ahí. No porque el proceso fuera malo, sino porque confundía la firma con la decisión. Una firma es un trámite. Una decisión la toma alguien que puede decir que no y que se va a salir con la suya. No siempre es la misma persona.
Las puertas que ningún framework recoge
Hay tres tipos de puerta que no aparecen en ninguna norma y que, en la práctica, deciden.
La primera es la persona que puede frenarlo sin estar en el organigrama del proyecto. El responsable de una operación adyacente. El equipo de seguridad que no participó en el diseño pero que tiene derecho de veto el día del despliegue. El área de negocio que de pronto entiende que esto le cambia un proceso suyo. Ninguno aparece en tu flujo de aprobación. Todos pueden pararlo.
La segunda es el sí informal que desbloquea de verdad. Hay aprobaciones que valen un acta y aprobaciones que valen una conversación de pasillo. Cuando una persona con peso real dice “esto tiene sentido” antes de que llegue al comité, el comité aprueba. Cuando no lo ha dicho, el comité encuentra pegas. El sí formal llega después; el que cuenta llegó antes, y no se documenta en ninguna parte.
La tercera, y la más difícil de leer, es el silencio que funciona como un no. Nadie se opone. Nadie firma tampoco. El expediente se queda en una bandeja sin que nadie diga por qué. En una organización madura aprendes a distinguir un silencio que es agenda saturada de un silencio que es un no que nadie quiere poner por escrito. Confundirlos te cuesta meses.
[ Aquí va tu caso real, anonimizado. Una situación concreta en la que el “aprobado” formal y la puerta real no coincidieron: qué se firmó, quién la cerró de hecho, cuánto costó. Es el punto donde la pieza deja de ser teoría y pasa a ser tuya. Si me das el caso, lo integro en este párrafo con tu voz. ]
Por qué esto hunde programas
La mayoría de los programas de governance que fracasan no fracasan por falta de proceso. Fracasan por exceso de confianza en el proceso.
Diseñas el recorrido formal, lo validas, lo apruebas, y das por hecho que el recorrido real es ese. Operas el mapa. Y el día del despliegue te encuentras una puerta que llevaba ahí todo el tiempo, cerrada, y que nunca pusiste en el diagrama porque sobre el papel no tenía que estar.
Entonces pasa una de dos cosas. O el programa aprende y empieza a mapear las puertas reales, o se defiende: añade más checklist, más firmas, más comité. Más mapa. Y el territorio sigue donde estaba.
He visto las dos reacciones. La segunda es la cómoda, porque produce artefactos que enseñar. También es la que garantiza que vuelva a pasar.
Qué hace distinto a quien sabe leerlas
La diferencia no es tener un proceso mejor. Es saber que el proceso es la mitad de la historia.
Quien sabe leer las puertas reales hace una cosa muy poco glamurosa antes de diseñar nada: pregunta quién puede parar esto. No quién tiene que aprobarlo. Quién puede pararlo. Son listas distintas, y la segunda casi nunca está escrita.
Después hace algo aún menos vistoso: convierte esas puertas en parte del recorrido. Sienta en la mesa al responsable de la operación adyacente antes de que sea tarde. Busca el sí informal antes del comité, no después. Y cuando hay un silencio, va y pregunta qué significa, en vez de esperar a que el calendario lo conteste por él.
Nada de eso sale en un framework. Ningún estándar te dice “identifica al gatekeeper que no está en tu diagrama”. Y sin embargo es lo que decide si tu modelo llega al usuario o se queda en una bandeja.
La madurez se mide en puertas explícitas
Si tuviera que dar una sola métrica de madurez de un programa, no sería el número de modelos evaluados ni la cobertura del checklist. Sería esta: cuántas de las puertas reales ha conseguido hacer explícitas.
Un programa joven opera el mapa y choca con el territorio una y otra vez. Uno maduro ha ido nombrando las puertas que antes eran tácitas, las ha metido en el recorrido, y ha reducido la distancia entre el aprobado y el despliegue. No porque tenga más proceso. Porque tiene menos sorpresas.
La gobernanza no consiste en dibujar el camino. Consiste en conocer las puertas que ya existen, las pongas tú o no. Y en sentarte, antes de empezar, a averiguar quién tiene la llave de cada una.