Toda organización con cierto tamaño ya tiene una estructura de riesgos. Un comité de riesgos, una función de auditoría, una línea de reporte hacia el consejo, un formato en el que los riesgos se clasifican y se siguen. Quien coloca un nuevo proceso junto a eso, específico para la IA, con su propio comité, su propio calendario y su propio lenguaje, obtiene en menos de un año un proceso que ya nadie completa. No porque no se considere importante la IA, sino porque una segunda estructura compite con la primera por tiempo, atención y mandato. La estructura existente casi siempre gana, porque está integrada en las evaluaciones, los ciclos de funcionamiento y las agendas del consejo. La estructura nueva queda fuera de eso.
La pregunta, por tanto, no es cómo construir una estructura de gobernanza de IA. La pregunta es cómo la IA obtiene un lugar dentro de la estructura que ya existe.
La mayoría de las estructuras de riesgo cuentan ya con una serie de elementos fijos: un inventario de riesgos que se actualiza periódicamente, una clasificación según gravedad y probabilidad, un responsable por riesgo, una línea de escalamiento hacia un nivel superior cuando se sobrepasa un límite, y un informe al consejo en momentos fijos. Esa es la estructura en la que la IA debe encajar, no al lado de ella.
Eso significa que una aplicación de IA no debe figurar en un registro de IA aparte, sino como elemento de riesgo en el registro existente, con los mismos campos que cualquier otro riesgo: responsable, gravedad, probabilidad, mitigación, fecha de estado. La clasificación por nivel de riesgo que corresponde a un inventario de uso de IA debe conectar con la escala que ya se utiliza para el riesgo operativo, no con una escala nueva inventada solo para la IA. Quien lea lo que un cio debe saber sobre el riesgo de la ia verá que precisamente esa conexión es donde suele fallar: una puntuación de riesgo de IA técnicamente correcta que nadie puede comparar con el resto del registro de riesgos.
Dos cosas hacen que la integración sea difícil. La primera es el lenguaje. Los gestores de riesgo trabajan con conceptos como impacto, probabilidad y medida mitigadora. Los proveedores de IA y los equipos técnicos trabajan con versiones de modelo, datos de entrenamiento y métricas de rendimiento. Un conjunto de gobernanza escrito únicamente en el lenguaje técnico no lo lee el comité de riesgos. Un conjunto de gobernanza escrito únicamente en el lenguaje de riesgos no lo completa el responsable técnico. El conjunto debe ser legible en ambas direcciones: suficientemente técnico para ser correcto, suficientemente directivo para calar. Ese principio vuelve a aparecer en una política de ia que se lee: un documento que se conecta con la forma en que las personas ya leen y deciden, en lugar de exigir una nueva manera de leer.
Lo segundo es el ritmo. Un comité de riesgos se reúne en un ciclo fijo, a menudo trimestral o mensual. El uso de la IA cambia más rápido: un equipo empieza esta semana con una herramienta nueva, sin que a eso le preceda una reunión. El conjunto de gobernanza no debe depender, por tanto, del ciclo de reuniones para funcionar. Debe existir un mecanismo más ligero que absorba las desviaciones entre los momentos fijos, y que solo se confirme formalmente en el siguiente ciclo. Cómo funciona ese mecanismo en la práctica se describe en rutas de escalamiento que funcionan: una ruta suficientemente corta como para usarse antes de que se reúna el siguiente comité trimestral.
Un conjunto de gobernanza que se conecta con una estructura de riesgos existente contiene, en líneas generales: un elemento de inventario por aplicación de IA con responsable y clase de riesgo, un enlace con la ruta de escalamiento existente para que una desviación no desaparezca en un canal aparte, y un lugar fijo en el informe periódico al consejo. No como un capítulo aparte sobre IA, sino como una línea en la tabla que el consejo ya conoce. Cómo puede verse ese informe sin introducir un formato nuevo se describe en cómo obtener un informe de una página para el consejo integrado en lo que ya circula.
El contenido de las propias reglas, qué cae exactamente bajo cada nivel de riesgo y qué plazos corresponden a ello, se establece en otro lugar y cambia; esta página trata sobre el mecanismo que da a ese contenido un lugar dentro de la estructura existente, no sobre el texto de esas reglas.
La integración solo funciona si el inventario es correcto desde el principio. Y este solo es correcto si las personas se atreven a decir qué utilizan. Quien, al completar el elemento de riesgo, siente que una respuesta honesta conduce a una anotación en una evaluación, no la completa honestamente. El conjunto de gobernanza debe, por tanto, dejar claro desde la primera versión que el objetivo es la visión de conjunto, no la sanción. Sin ese compromiso, una parte del uso queda fuera de vista, y la conexión con la estructura de riesgos se construye sobre una lista incompleta. Lo que un directivo debe saber sobre esto antes de que comience el primer inventario se describe en lo que un directivo debe saber sobre el riesgo de la ia.
Esta integración trata sobre riesgo, responsabilidad y reporte: garantiza que lo que hace la IA sea visible y gestionable dentro de la estructura que ya existe. Otra pregunta, que sigue lógicamente una vez que existe esa visión de conjunto, es qué puede realmente asumir la IA dentro de ese trabajo. El escáner de trabajo de FTE TO AI calcula, por tarea, qué parte del trabajo puede transferirse a la IA, como paso siguiente una vez que el lado de la gobernanza está en orden.
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.