Usted gestiona un registro de riesgos construido en torno a riesgos que se pueden identificar, ponderar y asignar. Riesgo operacional, riesgo de crédito, riesgo de cumplimiento: cada uno tiene un responsable, una medida de control, una línea de reporte. El riesgo de la IA no encaja de forma natural en ese patrón, porque el primer problema no es la ponderación. El primer problema es que usted no sabe qué está ponderando. Un equipo que utiliza un modelo de lenguaje para redactar borradores de dictámenes, un departamento que ha contratado una suscripción externa de IA fuera de las compras de TI, una macro de hoja de cálculo que entretanto se ha convertido en un modelo predictivo: estos no son casos marginales, aquí es donde está el riesgo, y no figura en ningún sitio.
Su pregunta no es "¿es la IA arriesgada". Su pregunta es: qué está funcionando, quién es responsable de ello, y con base en qué información puedo dar cuenta de ello ante el consejo de administración y el supervisor. La respuesta que usted no acepta es la tranquilización sin fundamento. "No hay nada especial en marcha" no es una respuesta a una pregunta de riesgo, es la ausencia de una respuesta. Un gestor de riesgos que transmite eso al consejo de administración, está transmitiendo que no se ha mirado, no que no hay nada.
La segunda respuesta que usted no acepta es la lista del sistema de gestión de TI como imagen completa. Esa lista muestra lo que se ha solicitado y aprobado. El uso de la IA surge en gran medida precisamente fuera de esa solicitud, porque una suscripción independiente, una extensión de navegador o una función integrada en software ya existente no se reconoce como "sistema nuevo". Quien quiera conocer el riesgo, debe entonces consultar no solo el panorama de sistemas, sino a las personas que hacen el trabajo, y eso requiere un enfoque distinto al de una auditoría de TI.
Como gestor de riesgos, usted conoce el patrón de subregistro en cualquier tema de riesgo en el que un empleado tenga algo que perder al responder con sinceridad. El uso de la IA es un ejemplo claro de ello: si informar sobre el uso de una herramienta va acompañado de la retirada del acceso, nadie volverá a informarlo. El inventario que produce resultados es el que pregunta sin vincular consecuencias a la respuesta. Esa es una habilidad distinta de lo que normalmente exige la gestión de riesgos, y es la razón por la que un inventario de IA en la sombra no se organiza como control, sino como sondeo.
Una vez que el uso está identificado, el siguiente paso no es evaluar al proveedor o el modelo. Es evaluar el rol que el sistema desempeña en un proceso. Una aplicación de IA que reformula texto conlleva un riesgo distinto al de una aplicación que participa en una decisión sobre un cliente, un empleado o una inversión. La misma tecnología, aplicada en otro rol, cae en otra clase de riesgo. Esa distinción es exactamente lo que necesita un registro de riesgos para poder situar el riesgo de la IA junto a los riesgos que ya contiene, sin crear un capítulo aparte y aislado sobre IA que nadie consulta.
A un gestor de riesgos no le interesa un nuevo marco junto al existente. El interés está en un conjunto de gobernanza que se conecte con la estructura de riesgos ya existente: la misma lógica de responsabilidad, las mismas vías de escalamiento, el mismo ciclo de reporte al consejo de administración. El riesgo de la IA tratado como tema aislado desaparece entre los informes habituales. El riesgo de la IA incorporado a la taxonomía de riesgos existente permanece visible en el lugar donde el consejo de administración ya mira.
En algún momento se le preguntará qué sabe sobre el uso de la IA en la organización, ya sea un supervisor, un auditor o el propio consejo de administración. La respuesta que resiste no es "todo está identificado", porque eso rara vez se puede sostener para un patrón de uso dinámico. La respuesta que resiste es un proceso demostrable: cómo se ha inventariado, qué clasificación se ha aplicado, qué acuerdos de gobernanza se derivan de ello, y con qué frecuencia se repite eso. Ese es un estándar distinto al de la exhaustividad, y es el estándar con el que normalmente ya se evalúa la gestión de riesgos.
Esta pregunta no se presenta de forma idéntica para cada rol dentro de la organización. Lo que necesita un responsable de cumplimiento de este inventario, puede leerlo en qué debe saber un responsable de cumplimiento sobre el riesgo de la IA, la cuestión de dirección de quien lidera el programa se aborda en qué debe saber un líder de programa de IA sobre el riesgo de la IA, y cómo aterriza este tema en el nivel del propio consejo de administración se describe en qué debe saber un directivo sobre el riesgo de la IA. Para la gestión de riesgos en sectores específicos, con sus propias cadenas y formas de supervisión, la imagen se ha precisado más en cómo es la gobernanza de la IA en la construcción y en cómo es la gobernanza de la IA en el sector de instalaciones.
El texto de las normas vigentes, con sus definiciones y plazos precisos, no figura en esta página y se mantiene actualizado en otro lugar. Lo que aquí se describe es el mecanismo: cómo pasar de un patrón de uso desconocido a un riesgo clasificable y reportable.
Un inventario del riesgo de la IA inevitablemente pone también algo más en evidencia: qué parte del trabajo ya está siendo realizada de hecho por la IA, y qué parte podría estarlo. Esa es una pregunta distinta a la gestión de riesgos, pero comparte la fuente. El escáner de trabajo de FTE TO AI calcula, por tarea, qué parte del trabajo puede ser asumida por la IA, y con ello se conecta exactamente con el inventario que la gestión de riesgos ya necesita ahora.
El Responsible AI Scan se encuentra actualmente en desarrollo. Quien desee utilizarlo en cuanto esté disponible, puede inscribirse en la lista de espera.
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.