A menudo ya existe un documento con el título procedimiento de escalado. Contiene un esquema con flechas, una fila de nombres y algunos valores umbral. El problema no es que falte el documento. El problema es que nadie lo abre en el momento en que se necesita.
Eso no ocurre por falta de voluntad. Ocurre porque ya existe una ruta por la que los problemas suben: el gerente de línea que informa el incidente de TI, el responsable de cumplimiento que habla con el negocio, el jefe de equipo que plantea su problema a su propio superior. Esa ruta existe, se usa a diario y funciona, para aquello para lo que está pensada. Una nueva ruta de escalado específica para incidentes de IA se convierte entonces en una segunda vía junto a una vía que ya funciona. Ante la duda, todos eligen la vía que conocen.
Una ruta de escalado que está separada de la estructura existente exige del empleado que primero reconozca que algo es un incidente de IA, luego recuerde que para eso aplica otro proceso, y después se tome la molestia de seguir ese proceso en lugar de simplemente llamar a su superior. Cada paso de esa cadena es un momento en el que se abandona la ruta.
A esto se añade una segunda razón, menos visible pero igual de determinante: quien informa de una desviación no quiere aparecer inmediatamente en el formulario de incidentes de la organización. Si escalar equivale a rendir cuentas negativas, no se escala. Esto se aplica tanto a un empleado que usó una herramienta de IA que no había sido aprobada, como a un gerente que puso en marcha un modelo sin que nadie lo supiera. Una ruta de escalado que sí se usa es una ruta en la que la primera notificación no es un juicio, sino una señal.
Una ruta de escalado que funciona describe tres cosas, y no más que eso.
Quien observa algo —un empleado, un cliente, una parte externa— debe saber a quién dirigirse sin tener que averiguar primero si se trata de una cuestión de IA o de una cuestión operativa normal. La ruta se conecta con el punto de notificación que ya existe, con una bifurcación adicional en el momento en que resulta que hay IA involucrada.
Quien toma la decisión —si algo se detiene, se ajusta o se notifica a un supervisor— debe estar establecido antes de que ocurra el incidente. No como cargo abstracto, sino con nombre, y con un sustituto. Una escalada que se atasca en un mandato vacío no es una escalada.
Lo que ocurre después con quien notifica debe estar claro. Si un segundo proceso consiste únicamente en una obligación de notificar sin claridad sobre las consecuencias para quien notifica, se evita. Ahí es precisamente donde se esconde la IA en la sombra: no en los sistemas que TI conoce, sino en las herramientas que alguien ha empezado a usar sin notificarlo, porque notificarlo se sentía como confesar.
La solución no es un documento más grueso. Es una ruta de escalado que utiliza la estructura que ya existe —el punto de notificación, la línea de escalado, el comité de riesgos— y le añade una bifurcación específica de IA en los puntos donde marca la diferencia. Cómo funciona exactamente esa conexión, también para la política más amplia y la lista de decisiones del órgano de supervisión, se describe en cómo conseguir una política de IA que se lea porque está integrada en lo que ya existe y en cómo conseguir una lista de decisiones de supervisión que conecte con el ritmo de toma de decisiones existente. Ambos documentos tocan el mismo punto: un proceso que está al lado de la organización se ignora; un proceso que está integrado en ella se sigue.
Este principio no se aplica solo al escalado. Se aplica a toda la estructura de gobernanza en torno a la IA. Quien quiera saber cómo se ve esto en un plano más amplio —cómo la clasificación de riesgos conecta con las categorías de riesgo existentes, cómo conectar con la estructura de riesgos existente evita que surja una burocracia paralela— encontrará ahí el principio subyacente. Lo mismo aplica al informe hacia arriba: un informe al consejo de una página solo funciona si las escaladas que contiene realmente se han notificado. Y sin una observación continua de lo que cambia, toda ruta de escalado queda obsoleta en un año; lo que eso significa en la práctica se explica en monitoreo que produce resultados.
Una ruta de escalado solo se puede redactar cuando se sabe qué puede escalar. Mientras nadie sepa qué IA está en funcionamiento dentro de la organización —incluyendo lo que no fue aprobado— el documento seguirá siendo teórico. Por eso, el Responsible AI Scan no empieza por la ruta de escalado, sino por el inventario: qué está en funcionamiento, quién lo usa y qué nivel de riesgo le corresponde. Solo a partir de eso se puede redactar una ruta de escalado que conecte con lo que ya existe, en lugar de con lo que debería existir sobre el papel.
Las rutas de escalado tratan sobre lo que sale mal con la IA que ya se usa. Otra pregunta, igualmente poco atendida, es dónde la IA podría asumir el trabajo mismo. El escáner de trabajo de FTE TO AI calcula, por tarea, qué parte del trabajo es apta para ello, independientemente de si eso ya ocurre o aún debe organizarse.
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.