Usted tiene una lista de herramientas de IA aprobadas. La pregunta no es si esa lista es correcta, sino si todavía significa algo. Un empleado que agiliza una tarea con un chatbot que no figura en la lista no lo reporta como incidente. No lo reporta porque no lo percibe como un incidente. La respuesta que usted no debería aceptar es, por tanto, "tenemos una política de IA y una lista aprobada" — porque esa frase no dice nada sobre lo que ocurre fuera de esa lista, y eso es probablemente la mayor parte.
Como CIO, usted es quien debe explicar por qué un incidente de IA no se conocía antes, mientras el resto de la organización asume que TI tiene una visión completa. Esa visión existe para los sistemas que se han adquirido. No existe para el complemento que un equipo instaló por su cuenta, la versión de prueba que alguien activó, o el modelo que llegó incorporado en una herramienta de atención al cliente. El riesgo para usted no es que se use IA — eso sucede de todos modos — sino que usted sea el último en saberlo, en el momento en que ya salió mal.
Un inventario correcto cambia su posición. En lugar de reaccionar a incidentes que no vio venir, puede señalar de antemano dónde están los riesgos y por qué. Esa es también la base para mantener, dentro de la organización, la conversación con el General Counsel, que observa esa misma IA en la sombra desde otra perspectiva, y con el gestor de riesgos, que quiere integrarlo en la estructura de riesgos existente en lugar de crear un proceso aparte.
La lista de TI registra lo que se ha adquirido y aprobado. La IA en la sombra surge donde se omiten esos dos pasos: un empleado encuentra una herramienta, la usa, y no informa de nada porque no parece haber nada que informar. Eso no es negligencia — es la consecuencia de un proceso de adquisición que no fue diseñado para registrar lo que la gente adopta por su cuenta. Cuanto más grande sea la organización y cuanto más autónomamente trabajen los equipos, mayor puede ser la diferencia entre la lista y la realidad. Cuán pequeña sea esa diferencia depende de cuánta libertad tienen los equipos para elegir sus propias herramientas y de cuán visible sea ya ese comportamiento — no hay una cifra al respecto, solo la tendencia.
La única manera de saber qué se está usando realmente es preguntarlo a quienes lo usan. Eso solo funciona si la respuesta no acarrea consecuencias para quien la da. Si pregunta "¿usas herramientas de IA que no están aprobadas?" con un tono que recuerda a una evaluación de desempeño, obtendrá la misma respuesta que ya daba la lista de TI: no. Si lo pregunta sin vincularlo a ninguna consecuencia, con el objetivo de entender en lugar de corregir, surge una imagen que sí coincide con la práctica. Esa distinción — preguntar sin consecuencias frente a preguntar con consecuencias — es la diferencia entre un inventario que vale algo y un ejercicio que no le dice nada a nadie.
Una lista de herramientas utilizadas es un punto de partida, no un punto final. No todas las aplicaciones de IA conllevan el mismo riesgo. Una herramienta que reescribe texto para uso interno es distinta de una que interviene en la aceptación de un cliente o en la evaluación de un empleado. Clasificar según la función — qué hace el sistema — y según el nivel de riesgo — cuál es el impacto si algo sale mal — es necesario para saber dónde debe enfocar su atención. Sin clasificación, toda aplicación de IA se ve igual en un informe, y esa es exactamente la imagen que no ayuda a que un consejo de administración se involucre.
Como CIO, probablemente ya cuenta con un marco de riesgos para sistemas de TI, seguridad de la información y proveedores. La gobernanza de IA funciona mejor cuando se conecta con esa estructura que cuando se convierte en un marco aparte. Es también el problema con el que se topan el compliance officer y el responsable del programa de IA: demasiadas iniciativas de IA separadas que no se comunican entre sí, mientras el consejo espera precisamente una respuesta coherente sobre lo que está en juego y qué se está haciendo al respecto.
Lo que significa la IA en la sombra varía según el sector. En la construcción funciona de forma distinta que en el sector de instalaciones técnicas, y vale la pena ver cómo se configura la gobernanza de IA en la construcción o cómo se ve en el sector de instalaciones técnicas antes de asumir que un mismo enfoque sirve para todos.
El Responsible AI Scan que produce todo esto — inventario, clasificación, un conjunto de gobernanza que se conecta con su estructura existente — está en desarrollo. Quien quiera empezar con esto ya ahora puede inscribirse en la lista de espera; todavía no hay un producto terminado que ofrecer, y preferimos decirlo con honestidad antes que prometer algo que aún no existe.
En cuanto sepa qué IA se está usando y con qué riesgo, surge de forma natural la siguiente pregunta: qué parte del trabajo mismo podría ser una tarea para la IA, y qué parte no. Esa es una pregunta distinta a la gestión de riesgos — se trata de capacidad, no de exposición — y el escáner de trabajo de FTE TO AI lo calcula por tarea, para que no solo sepa qué está funcionando ya, sino también dónde la IA podría asumir el trabajo mismo.
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.