All'interno di molte organizzazioni esiste un elenco fisso di applicazioni che sarebbero "fuori scope". Un suggerimento di testo in un elaboratore di testi, un filtro antispam, un chatbot che risponde solo sulla base di una FAQ fissa. L'assunto è che queste applicazioni siano troppo piccole, troppo vecchie o troppo innocue per rientrare nella governance. Questo assunto a volte è corretto. Non è sempre corretto, e raramente lo resta.
Se qualcosa è fuori scope non è una proprietà della tecnologia. È una classificazione che deriva da cosa fa il sistema, per chi, e con quale effetto se qualcosa va storto. Lo stesso suggerimento di testo che oggi è fuori scope perché propone a un dipendente solo una parola, può domani rientrare nello scope non appena finalizza e invia automaticamente email senza intervento umano.
Tre fattori determinano insieme se un'applicazione rientra o meno nello scope.
Il primo è la funzione: il sistema prende una decisione, oppure fornisce solo informazioni che una persona valuta? Uno strumento che classifica i candidati è più vicino allo scope di uno strumento che rende solo i curriculum consultabili tramite ricerca. In quale punto esatto di questo spettro si colloca un'applicazione, e perché, lo trova in l'analisi di cosa significa un livello di rischio elevato per la sua organizzazione.
Il secondo è il ruolo dell'organizzazione stessa. Chi acquista un sistema e lo utilizza senza modifiche si trova in una posizione diversa da chi lo costruisce, lo addestra o lo adatta autonomamente. La stessa applicazione può essere fuori scope per un'organizzazione e non per un'altra, semplicemente in base a chi porta quale responsabilità. Questa distinzione viene approfondita in la domanda se lei è fornitore o utilizzatore, e cambia non appena qualcuno nell'organizzazione adatta o riaddestra un modello, come descritto in cosa cambia se lei adatta un modello autonomamente.
Il terzo fattore è il tempo. Un sistema che ora è fuori scope può non esserlo più un anno dopo, non perché le regole sono cambiate, ma perché l'uso è cambiato. Un chatbot iniziato come fonte di informazioni può evolvere in un sistema che gestisce reclami. Il ruolo di un team o di un reparto rispetto a tale sistema si sposta di conseguenza, e quando ciò accade è descritto in quando cambia il suo ruolo e da cosa dipende.
La conseguenza di questi tre fattori è che "fuori scope" non è mai uno stato permanente. È una fotografia del momento che va riesaminata non appena cambia la funzione di un sistema, non appena l'organizzazione assume un ruolo diverso rispetto a quel sistema, o non appena l'uso si estende a qualcosa che non era previsto al momento dell'acquisto.
È esattamente qui che l'AI ombra disturba la classificazione. Un'applicazione registrata nell'elenco IT come "fuori scope" può nella pratica essere usata in un modo che non corrisponde più a tale classificazione. Un team che utilizza un modello linguistico per redigere bozze di comunicazioni ai clienti potrebbe anche usarlo per inviare risposte definitive senza segnalarlo. La classificazione sulla carta e l'uso nella pratica divergono quindi, e chi guarda solo alle licenze acquistate non vede questa differenza.
L'unico modo per averne una visione chiara è chiedere. Non a un sistema, ma alle persone che lo usano. Questo funziona solo se fare domande non equivale a un resa dei conti: chi teme conseguenze adatta la propria risposta o non ne dà affatto. Una classificazione basata esclusivamente sulle licenze acquistate manca quindi sistematicamente le applicazioni nate dall'uso pratico, e queste sono spesso proprio le applicazioni di cui nessuno sa più se sono ancora fuori scope o se ormai vi rientrano pienamente.
La domanda "questo è fuori scope" non può quindi essere risolta separatamente dalla domanda su cosa succede esattamente, chi decide in merito, e da quanto tempo la situazione è tale. Un inventario che registra questi tre fattori per ogni applicazione produce una classificazione che corrisponde alla situazione reale invece che all'assunto con cui un sistema è stato acquistato in origine. Cosa richiede attenzione già ora e cosa può essere pianificato con calma dipende dagli stessi fattori ed è trattato in la distinzione tra cosa è urgente ora e cosa può essere pianificato.
Una volta chiarito quali applicazioni rientrano nello scope e quale ruolo svolge la sua organizzazione al riguardo, emerge una domanda successiva che non riguarda la governance ma il lavoro: quale parte di un compito viene effettivamente svolta da tale applicazione, e quale parte resta lavoro umano? A questa domanda non risponde la scansione di governance. A questo scopo è pensata la scansione del lavoro di FTE TO AI, che calcola per ogni compito quale parte del lavoro può essere svolta dall'AI, offrendo così un quadro dell'impiego che sta dietro alla classificazione.
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.