Quién debe liderar el gobierno de IA en una empresa

El problema no es que falte una política. Es que no hay un nombre

En casi todas las empresas donde reviso un sistema de IA que ya está corriendo, la conversación llega al mismo punto muerto. Pregunto quién decidió que ese agente pudiera responder sin revisión humana, y la respuesta se convierte en un recorrido por el organigrama. TI solo habilitó el acceso a la base de datos. Operaciones dice que el pedido bajó de gerencia. Legal se enteró después. Gerencia confió en que el equipo sabía lo que hacía. Cuatro áreas, cuatro versiones, cero nombres.

Esa ambigüedad no es un accidente administrativo, es cómoda. Mientras el sistema funciona, nadie necesita ser el dueño. El primer incidente cambia todo: un cliente recibe una respuesta que no debía, un dato sensible sale por donde no correspondía, o un agente ejecuta una acción que nadie puede explicar. Ahí la empresa descubre que la responsabilidad repartida entre cuatro áreas es responsabilidad de nadie.

Qué es el gobierno de IA y cómo se define qué puede hacer la IA sola es otra conversación, desarrollada en otro lugar del playbook. Acá la pregunta es más incómoda y más organizacional: quién en tu empresa tiene el mandato de tomar esas decisiones, con qué autoridad, y qué pasa si esa persona no existe.

Liderar el gobierno de IA es poder frenar algo en producción

Liderar esto no es redactar un documento de principios ni presidir un comité mensual. Es tener la autoridad concreta de decir: este proceso no se suelta todavía, este agente pasa a modo supervisado, esta integración se apaga hasta que entendamos qué pasó. Si la persona a cargo no puede ejecutar ninguna de esas tres frases sin pedir permiso a otros tres niveles, no lidera el gobierno de IA: lo documenta.

De ahí sale la prueba más rápida para distinguir a un líder de gobierno de IA de un responsable nominal. Pregúntale qué haría si mañana el sistema empieza a dar respuestas erróneas a clientes. Si contesta «tendría que escalarlo a», la autoridad está en otro lado y el gobierno también. Si contesta «lo paso a revisión manual y aviso a comercial», ahí sí hay un dueño.

El otro componente es entender el proceso, porque la autoridad formal no alcanza. Quien decide hasta dónde llega la IA en cobranzas tiene que saber cómo funciona cobranzas: dónde se pierde plata, qué excepción aparece cada semana, qué cliente se molesta y por qué. Sin eso, cualquier límite que ponga va a ser arbitrario, y los límites arbitrarios se rompen apenas molestan a alguien con más peso.

Por qué en la mayoría de empresas esto termina sin dueño

No es negligencia, es un incentivo mal repartido. El rol tiene costo visible y beneficio invisible: quien lo toma frena proyectos, dice que no en reuniones donde todos están entusiasmados, y queda expuesto igual si algo sale mal. Si todo funciona, nadie lo felicita por los incidentes que no ocurrieron. Con ese balance, es lógico que nadie levante la mano.

• Llegó por proyecto, no por decisión estructural. La IA entró como piloto de un área y el gobierno se quedó pegado a ese piloto. Cuando el uso se expandió, nadie actualizó quién decide.
• Se confundió con el proveedor. La empresa asumió que quien implementó también se hace cargo de los límites. El proveedor documenta, pero no responde ante el directorio ni ante los clientes.
• Quedó en un comité. Repartir la responsabilidad entre cinco áreas suena prudente y produce cero decisiones rápidas. Un comité revisa; un dueño decide.
• Nadie tiene tiempo asignado. Se lo dieron a alguien «además de sus funciones», sin quitarle nada del plato. En la práctica se atiende solo cuando ya explotó algo.
• No está en los objetivos de nadie. Si la responsabilidad no aparece en la evaluación de desempeño de una persona concreta, no existe por más que figure en un organigrama.

El patrón de fondo es el mismo que veo con los datos y con los procesos: la empresa adopta la tecnología mucho más rápido de lo que adapta su estructura de decisión. El sistema corre a la velocidad del software y la responsabilidad sigue corriendo a la velocidad de las reuniones.

Qué pasa cuando cae en el área equivocada

Cada área que toma este rol lo deforma según su lógica interna. No es que alguna sea mala opción en abstracto: es que cada una tiene un sesgo predecible, y si conoces el sesgo puedes compensarlo.

Cuando lo toma Legal

Legal es excelente identificando exposición y pésima estimando costo de oportunidad. El resultado típico es un gobierno construido sobre el peor escenario: cero autonomía, revisión humana en todo, un formulario por caso de uso. La empresa queda protegida en el papel y paralizada en la operación, y como el proceso pesa tanto, los equipos empiezan a usar IA por fuera. El gobierno demasiado estricto no elimina el riesgo, lo empuja a la sombra.

Cuando lo toma TI

TI resuelve bien accesos, permisos, logs y trazabilidad, y suele traducir el gobierno a una lista de controles de infraestructura. El problema es que las decisiones difíciles acá no son técnicas, son de negocio. Si un agente puede ofrecer un descuento sin aprobación no es una pregunta de permisos, es política comercial. Cuando esto vive solo en TI, el sistema queda impecablemente auditado y nadie definió qué es un resultado aceptable.

Cuando lo toma Operaciones

Es, en mi experiencia, el mejor punto de partida en empresas medianas: operaciones conoce los procesos por dentro y siente el dolor de los errores primero. Su sesgo es otro, prioriza que el flujo no se detenga, y si el sistema está sacando volumen la tentación de no frenarlo es fuerte. Necesita un contrapeso explícito: la obligación de reportar incidentes hacia arriba aunque se hayan resuelto solos.

Cuando lo toma la Dirección General

Tiene la autoridad completa y ese es su valor real: nadie discute una decisión de gerencia general. Su límite es el tiempo y la distancia del detalle operativo. Si la dirección toma el rol de forma nominal pero no revisa nada, el gobierno se vuelve una firma de trámite. Funciona cuando retiene la decisión sobre los límites de alto impacto y delega la operación diaria a alguien metido en el proceso.

Cómo se evalúa a quien lidera esto: por criterio, no por título

Acá va la regla que aplico sin excepción, y que va contra el instinto de recursos humanos: a quien lidera el gobierno de IA se le evalúa por su criterio sobre procesos y por su capacidad de decidir, no por títulos ni por certificaciones de compliance. Una certificación demuestra que alguien estudió un marco de referencia. No demuestra que sepa cuándo un agente debe frenarse en tu operación, ni que tenga el carácter para sostener un no incómodo frente a un gerente que quiere lanzar ya.

La entrevista que uso no admite respuestas de manual. Le pongo delante un proceso real de la empresa, con sus excepciones y su desorden, y le pido tres cosas: qué parte le soltaría hoy a la IA, qué parte no soltaría nunca, y qué haría el día que el sistema falle un viernes a las 6 de la tarde. Las respuestas separan a quien entiende operación de quien memorizó vocabulario.

• Puede describir el proceso antes de hablar de la IA. Si empieza por la herramienta y no por el flujo de trabajo, no va a saber dónde poner los límites.
• Distingue error tolerable de error inaceptable. Quien trata todo como crítico bloquea la empresa; quien no distingue nada termina explicándole a un cliente una respuesta absurda.
• Ha dicho que no antes, y lo sostuvo. Pregúntale por un caso concreto donde frenó algo que la organización quería lanzar. Si no tiene ninguno, no sabes cómo actúa bajo presión.
• Sabe qué información necesita para decidir. Pide trazabilidad, casos reales y datos de error antes de opinar, no después.
• Se hace responsable en voz alta. La frase «yo autoricé esto» es la señal más difícil de fingir y la más valiosa del perfil.
• Tiene peso interno suficiente. Aunque el criterio sea excelente, si no puede frenar un proceso sin negociar con tres niveles, el rol es decorativo.

Nada de esto aparece en un currículum. Aparece en cómo responde a un caso real de tu empresa. Por eso una búsqueda basada en el título del cargo o en la lista de certificaciones suele traer al candidato equivocado: alguien que sabe redactar la política pero no sabe aplicarla el día que cuesta dinero.

Lo que este rol no es y lo que no va a resolver

Poner un dueño no arregla los problemas de fondo, solo hace que tengan a quién reportarse. Si tus procesos no están documentados, si los datos están sucios, si nadie sabe cuál es el flujo real de una cotización, esta persona no va a poder poner límites sensatos, porque no hay un proceso claro que limitar. La IA no arregla una operación desordenada, la expone más rápido, y este rol recibe esa exposición primero.

• No es un rol técnico. No necesita configurar un modelo. Necesita saber qué decisión de negocio se está delegando y qué pasa si sale mal.
• No es un freno permanente. Un gobierno que solo dice que no falla igual que uno que solo dice que sí. La función es decidir, en ambas direcciones.
• No reemplaza al responsable de cada proceso. El dueño de cobranzas sigue siéndolo. Este rol define el marco de autonomía, no opera el área.
• No se resuelve contratando. En empresas medianas suele ser un mandato para alguien que ya está adentro y conoce la casa, no una vacante nueva.
• No se copia de una empresa más grande. Un esquema diseñado para una corporación con área de riesgo propia es inaplicable en una empresa de ochenta personas.

Cómo saber si el gobierno de IA tiene dueño de verdad

No lo mides con la existencia de una política ni con la cantidad de reuniones del comité. Lo mides con señales de comportamiento en la operación, y todas son verificables en una tarde preguntando a la gente correcta.

• Cuando preguntas quién autorizó que un proceso corra sin supervisión, recibes un nombre y no un área.
• Existe al menos un caso del último trimestre donde alguien frenó o restringió un sistema de IA ya en producción, y quedó documentado quién lo decidió.
• El tiempo entre que se detecta un comportamiento raro y que alguien decide sobre él se mide en horas, no en la próxima reunión mensual.
• Los responsables de cada proceso saben a quién escribirle cuando algo se ve mal, sin tener que averiguarlo.
• Las decisiones de límites quedan escritas con fecha y autor, de forma que en seis meses se pueda reconstruir por qué se permitió lo que se permitió.
• Cuando entra un caso de uso nuevo, pasa por esa persona antes de tocar datos de clientes, no después del lanzamiento.

Si ninguna de estas señales aparece, la conclusión es directa: tienes un documento de gobierno y no un gobierno. Y la diferencia entre las dos cosas se descubre siempre en el peor momento, cuando ya hay un cliente molesto, un dato expuesto o una decisión automática que nadie sabe explicar.