Spesso esiste già un documento intitolato procedura di escalation. Contiene uno schema con freccette, un elenco di nomi e qualche soglia. Il problema non è che il documento manchi. Il problema è che nessuno lo apre nel momento in cui serve.
Non accade per mancanza di volontà. Accade perché esiste già un percorso lungo il quale i problemi arrivano ai vertici: il line manager che segnala l'incidente IT, il compliance officer che parla con il business, il team leader che porta il proprio problema al proprio responsabile. Quel percorso esiste, viene usato ogni giorno e funziona — per le cose per cui è pensato. Un nuovo percorso di escalation specifico per gli incidenti IA diventa quindi una seconda strada accanto a una strada già battuta. In caso di dubbio, tutti scelgono la strada che conoscono.
Un percorso di escalation separato dalla struttura esistente richiede al collaboratore prima di riconoscere che si tratta di un incidente IA, poi di ricordare che per questo vale un altro processo, e infine di prendersi la briga di seguire quel processo invece di chiamare semplicemente il proprio responsabile. Ogni passaggio di questa catena è un momento in cui il percorso viene abbandonato.
A ciò si aggiunge una seconda ragione, meno visibile ma altrettanto determinante: chi segnala una deviazione non vuole finire subito sul modulo incidenti dell'organizzazione. Se escalare equivale a essere ritenuti responsabili, non si escala. Questo vale per un collaboratore che ha usato uno strumento IA non approvato, e vale per un manager che ha fatto funzionare un modello senza che nessuno ne fosse a conoscenza. Un percorso di escalation che viene effettivamente usato è un percorso in cui la prima segnalazione non è un giudizio, ma un segnale.
Un percorso di escalation che funziona descrive tre cose, e non di più.
Chi osserva qualcosa — un collaboratore, un cliente, una parte esterna — deve sapere a chi rivolgersi senza dover prima capire se si tratta di una questione IA o di una normale questione operativa. Il percorso si allinea al punto di segnalazione già esistente, con una ramificazione aggiuntiva nel momento in cui risulta che l'IA è coinvolta.
Chi prende la decisione — se qualcosa viene interrotto, adattato o segnalato a un'autorità di controllo — deve essere stabilito prima che l'incidente si verifichi. Non come titolo di funzione astratto, ma come nome, con un sostituto. Un'escalation che si blocca su un mandato vuoto non è un'escalation.
Cosa succede successivamente a chi segnala deve essere chiaro. Se un secondo processo consiste solo in un obbligo di segnalazione senza chiarezza sulle conseguenze per chi segnala, viene evitato. È esattamente lì che si nasconde l'IA ombra: non nei sistemi che l'IT conosce, ma negli strumenti che qualcuno ha iniziato a usare senza segnalarlo, perché segnalare sembrava una confessione.
La soluzione non è un documento più voluminoso. È un percorso di escalation che utilizza la struttura già esistente — il punto di segnalazione, la linea di escalation, il comitato rischi — e vi aggiunge una ramificazione specifica per l'IA nei punti in cui fa la differenza. Come funziona esattamente questo allineamento, anche per la politica più ampia e l'elenco delle decisioni dell'organo di controllo, è descritto in come ottenere una politica IA che viene letta perché è integrata in ciò che esiste già e in come ottenere un elenco delle decisioni di oversight che si allinea al ritmo decisionale esistente. Entrambi i documenti toccano lo stesso punto: un processo che sta accanto all'organizzazione viene ignorato; un processo che ne fa parte viene seguito.
Questo principio non vale solo per l'escalation. Vale per l'intera struttura di governance intorno all'IA. Chi vuole sapere come si presenta questo in modo più ampio — come la classificazione del rischio si allinea alle categorie di rischio esistenti, come allinearsi alla struttura di rischio esistente evita che nasca una burocrazia parallela — trova lì il principio sottostante. Lo stesso vale per la rendicontazione verso l'alto: una rendicontazione al board di una pagina funziona solo se le escalation che contiene sono state effettivamente segnalate. E senza un'osservazione continua di ciò che cambia, ogni percorso di escalation diventa obsoleto entro un anno; cosa significhi questo in pratica è illustrato in monitoraggio che produce risultati.
Un percorso di escalation può essere scritto solo quando si sa cosa può escalare. Finché nessuno sa quale IA è in funzione nell'organizzazione — incluso ciò che non è stato approvato — il documento rimane teorico. La Responsible AI Scan non parte quindi dal percorso di escalation, ma dall'inventario: cosa è in funzione, chi lo usa e quale livello di rischio gli corrisponde. Solo su questa base è possibile scrivere un percorso di escalation che si allinea a ciò che esiste già, invece che a ciò che dovrebbe esistere sulla carta.
I percorsi di escalation riguardano ciò che va storto con l'IA già in uso. Un'altra domanda, altrettanto poco considerata, è dove l'IA potrebbe assumere direttamente il lavoro stesso. La scansione del lavoro di FTE TO AI calcola per ogni attività quale parte del lavoro si presta a questo, indipendentemente dal fatto che ciò avvenga già o debba ancora essere organizzato.
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.