Un compliance officer no pierde en la primera pregunta sobre IA. Pierde en la segunda: cuando resulta que la respuesta a la primera pregunta era incompleta. "Qué sistemas de IA utiliza su organización" se puede responder con una lista extraída del portafolio de TI. La pregunta que viene después — "es esa la lista completa" — es la pregunta en la que fracasan la mayoría de los expedientes de compliance.
No: qué herramientas de IA ha adquirido la organización. Sí: qué sistemas de IA se utilizan realmente, por quién, para qué decisiones, y sobre la base de qué evaluación de riesgo. Son cuatro preguntas, no una. La primera es una lista de compras. Las otras tres exigen que las personas cuenten lo que hacen, incluido lo que no han hecho aprobar. Un compliance officer que solo tiene la lista de compras tiene una falsa sensación de cobertura — y eso es más arriesgado que no tener cobertura en absoluto, porque se reporta como completo.
Los empleados que utilizan una herramienta de lenguaje o de análisis sin adquirirla a través de TI no dejan ningún rastro de ello en un registro de activos. Sí dejan un rastro en lo que producen: informes, comunicación con clientes, asesorías. La brecha entre lo que está registrado y lo que se utiliza no suele ser una infracción deliberada. Es el resultado de una organización que encuentra una herramienta más rápido de lo que recorre un proceso de aprobación. Compliance no puede cerrar esa brecha con una prohibición más estricta — eso solo desplaza el uso fuera del campo de visión. La brecha se cierra preguntando sin que haya una sanción sobre la respuesta. Quien teme una anotación en su expediente no cuenta lo que utiliza; cuenta lo que cree que usted quiere oír.
Un risk manager quiere saber cuál es el tamaño de la exposición. Un compliance officer quiere eso, más algo adicional: ¿puedo demostrar que hemos seguido el proceso, incluso si el resultado resulta ser discutible a posteriori? Ese es otro tipo de carga probatoria. No se trata solo de la clasificación de un sistema, sino del rastro: quién evaluó esto, en qué momento, con qué información, y si esa evaluación se repitió cuando el sistema cambió. Los sistemas de IA se actualizan sin previo aviso; una clasificación de hace medio año dice poco sobre el sistema de hoy. Compliance debe, por tanto, poder mostrar no solo un resultado, sino un proceso que siga en marcha.
"Tenemos una política de IA" no es una respuesta a la pregunta de si esa política cubre algo. Un documento de política que nunca se ha contrastado con lo que realmente se utiliza es una declaración de intenciones, no una declaración del estado real de las cosas. Lo que un compliance officer necesita es un inventario que se conecte con las categorías de riesgo existentes — la misma clasificación que ya se utiliza para otros riesgos operativos — de modo que la IA no quede como un tema aparte y exótico junto al resto del marco de riesgo, sino integrado en él.
El compliance officer rara vez trabaja esto solo. La pregunta de qué sistemas se consideran de alto riesgo y qué carga probatoria corresponde a ello se relaciona con lo que debe saber un General Counsel sobre el riesgo de IA desde la perspectiva de la responsabilidad y las obligaciones contractuales. La pregunta de si la organización puede rastrear técnicamente qué sistemas están en funcionamiento corresponde a lo que debe saber un CIO sobre el riesgo de IA. Y la pregunta de si este tema llega a la mesa del consejo antes de que escale corresponde a lo que debe saber un consejero sobre el riesgo de IA. Compliance es a menudo la parte que debe reunir estas tres líneas sin ser ella misma propietaria de la tecnología o del contrato.
El contenido normativo — qué obligaciones exactas se aplican, por categoría de riesgo, con qué plazos — se encuentra en otro lugar y cambia. Esta página describe el mecanismo: cómo saber qué está en funcionamiento, cómo lo clasifica y cómo demuestra que el proceso se ha seguido. Un compliance officer que busca el texto legal actualizado no lo encontrará aquí.
Cuánta IA en la sombra tiene una organización depende del sector, la cultura y con qué rigor se han aplicado las prohibiciones anteriores. Una prohibición más estricta suele correlacionarse con más uso oculto, no con menos. Ese patrón no es igual en todas partes: en la construcción el foco está en el cálculo de proyectos y la planificación, mientras que en el sector de instalaciones se trata más a menudo del diagnóstico de mantenimiento y el análisis de averías. El inventario debe hacerse, por tanto, por organización; un promedio nacional dice poco sobre su propia exposición.
El Responsible AI Scan identifica lo que realmente se utiliza, lo clasifica según función y nivel de riesgo, y entrega un conjunto de governance que se conecta con la estructura de riesgo existente — sin adelantarse a lo que ya se ha establecido en otro lugar. Este scan está en construcción. Quien tenga interés en esto puede inscribirse en la lista de espera; no se ofrece nada que aún no esté terminado.
Quien una vez sabe qué sistemas de IA están en funcionamiento, a menudo se topa con la pregunta siguiente: qué significa eso para la dotación de personal y la distribución de tareas. Ese es un cálculo distinto de la clasificación de riesgo, y es el que hace FTE TO AI con el werkscan, que calcula por tarea qué parte del trabajo puede ser asumida por la IA.
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.