Un líder de programa de IA recibe habitualmente un único mandato: asegurar que la IA se adopte, que los equipos trabajen más rápido gracias a ella, que el programa muestre resultados. Rara vez se añade un segundo mandato: asegurar que todo lo que surge mientras tanto sea responsable. Aun así, se le juzga por ambos en cuanto algo sale mal. Ese es el núcleo de su riesgo: es responsable de un programa cuyos límites no conoce.
Lo que gana con la adopción —procesos más rápidos, equipos satisfechos, una historia de innovación visible— se contrapone a lo que pierde si algo sale mal: un incidente con una herramienta que no estaba en su lista, una auditoría que plantea preguntas que no puede responder, un consejo que pregunta por qué el programa no vio lo que ya estaba en marcha. Esa asimetría hace vulnerable su posición, incluso cuando el programa en sí funciona bien.
Su pregunta no es "qué herramientas de IA hemos aprobado". Esa lista la tiene, y suele ser más corta que la realidad. Su pregunta es: qué usan los equipos que no están en mi lista, y cómo consigo visibilidad sobre eso sin que la gente lo oculte. Un líder de programa que quiere fomentar la adopción no puede permitirse que los usuarios escondan sus herramientas por miedo a una corrección. Quien pregunta qué se está usando y después lo convierte en un problema, no obtendrá respuesta la próxima vez que pregunte. La gobernanza y la adopción trabajan aquí en sentido contrario si se aborda mal.
Una respuesta que no acepta es un bloqueo único: "El uso de IA no está permitido sin aprobación." Esa respuesta satisface a un auditor por un momento, pero traslada el uso a lugares que nadie ve. Es lo contrario de lo que un líder de programa quiere conseguir: quiere que el uso de IA sea visible y acompañado, no que pase a la clandestinidad. Una prohibición sin un mecanismo para reportar y aprender supone para él una pérdida, incluso si suena conforme sobre el papel.
Tampoco acepta una respuesta que trate todo por igual. Una herramienta que resume texto para uso interno no representa el mismo riesgo que una herramienta que toma decisiones automáticas sobre clientes o empleados. Sin distinción por rol y nivel de riesgo, un programa no puede priorizar, y un líder de programa que no puede priorizar no puede cumplir su mandato.
Lo que sí funciona es un inventario que empiece por lo que existe, no por lo que está aprobado. Eso significa preguntar a los equipos qué usan realmente, y hacerlo de una manera que no conlleve un ajuste de cuentas. Solo así aparece la IA en la sombra —los sistemas introducidos sin un proceso formal, a menudo porque aliviaban el trabajo y nadie vio motivo para esperar la aprobación.
Después sigue la clasificación: qué aplicación afecta a los clientes, cuál afecta solo al proceso interno, cuál toma decisiones sin un humano de por medio. Esa clasificación determina dónde debe ser estricta la supervisión y dónde puede seguir siendo ligera. Sin esa clasificación, un programa trata todo con la misma severidad o la misma ligereza, y ambas son un problema: la primera frena la adopción, la segunda deja riesgos sin gestionar.
La estructura de gobernanza que surge a continuación debe encajar con lo que ya existe dentro de la organización —los comités de riesgo existentes, las líneas de reporte existentes— y no ser un circuito nuevo al margen. Ahí es también donde un líder de programa se diferencia de otros roles en la organización: un consejero quiere saber lo que un consejero debe saber sobre el riesgo de la IA al nivel de la responsabilidad final, un CIO lo aborda desde los sistemas y el acceso, como se describe en lo que un CIO debe saber sobre el riesgo de la IA, y un General Counsel mira la responsabilidad legal y la obligación de documentación a través de lo que un General Counsel debe saber sobre el riesgo de la IA. Un líder de programa debe poder atender estas tres perspectivas sin perder su propia tarea: la adopción.
Qué obligaciones concretas se aplican a qué categoría de riesgo, y dentro de qué plazos, no es el tema de esta página. Ese texto cambia, se ajusta y se explica en otros lugares. Aquí se trata del mecanismo: cómo un programa obtiene visibilidad sobre lo que ocurre, cómo lo traduce a niveles de riesgo, y cómo lo demuestra de forma verificable ante el consejo y los supervisores, independientemente de lo que prescriba exactamente el texto normativo en un momento dado.
En cuanto queda claro qué está en marcha y quién es responsable de ello, surge otra pregunta: qué rendimiento se obtiene si ese trabajo se organiza bien. Es una pregunta que debe responderse por tarea, no por organización. El escáner de trabajo de FTE TO AI calcula a ese nivel qué parte del trabajo puede asumir la IA, de modo que un líder de programa no solo sepa qué está ocurriendo, sino también dónde añadir capacidad realmente supone una diferencia.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.