Molte organizzazioni presumono che il loro ruolo sia fisso: sono utenti di un sistema costruito da un fornitore, e gli obblighi che ne derivano sono chiari e permanenti. Questa presunzione è spesso corretta, ma non sempre. Il ruolo che un'organizzazione ha nei confronti di un sistema di AI non è un'etichetta fissa. È il risultato di ciò che accade effettivamente con il sistema, e questo risultato può spostarsi senza che venga firmato un nuovo contratto o effettuato un nuovo acquisto.
La classificazione di un ruolo dipende da una serie di elementi fattuali, non da come un fornitore chiama il sistema o da come un reparto interno lo posiziona internamente. È rilevante, tra l'altro, chi ha immesso il sistema sul mercato, chi utilizza effettivamente il sistema all'interno di un proprio processo, e chi ha modificato il sistema dopo la consegna. Conta anche sotto quale nome il sistema viene presentato all'esterno, e se un'organizzazione fornisce il sistema ad altri senza utilizzarlo essa stessa. Questi elementi determinano insieme se un'organizzazione agisce come fornitore, come utente, o come parte che si colloca in una posizione intermedia.
Il motivo per cui questo è rilevante per la governance è che il ruolo determina quali obblighi spettano a quale parte. Un'organizzazione che è solo utente ha responsabilità diverse da un'organizzazione che agisce di fatto come fornitore. Cosa esattamente ci si aspetta da ciascun ruolo è descritto altrove; qui si tratta del meccanismo che determina quale ruolo si applica, e dell'individuazione del momento in cui tale meccanismo produce un risultato diverso rispetto a prima.
Un ruolo non è collegato a un sistema per tutta la sua durata di vita. È collegato a ciò che accade effettivamente in un determinato momento. Ciò significa che la stessa organizzazione, per lo stesso sistema, può rientrare in un ruolo diverso in due momenti diversi. Alcune situazioni in cui questo accade: un team che effettua il finetuning di un modello acquistato sui propri dati, un reparto che rietichetta un sistema e lo offre con il proprio nome ad altri reparti, oppure un'organizzazione che fornisce a un cliente o partner un sistema originariamente destinato all'uso interno. In ciascuno di questi casi il ruolo effettivo si sposta, anche se all'esterno cambia poco.
Ciò che cambia nella pratica non è astratto. Determina chi è responsabile della documentazione, chi deve dimostrare che un sistema fa ciò che dichiara di fare, e chi deve intervenire se qualcosa va storto. Maggiori informazioni su cosa cambia esattamente quando un modello viene modificato sono descritte in la pagina sulle modifiche a un modello. Questo spostamento è uno degli esempi più chiari di come un ruolo cambi senza che vi sia una decisione consapevole a monte.
Il motivo per cui questo argomento è rilevante non solo dal punto di vista giuridico, ma anche organizzativo, è che un cambiamento di ruolo avviene spesso inosservato. Un team che modifica un modello pensa a un miglioramento tecnico, non a un cambiamento di responsabilità. Un reparto che trasferisce uno strumento a un altro reparto pensa alla comodità, non a un nuovo ruolo come fornitore. Una governance che guarda solo a ciò che è stato acquistato non rileva sistematicamente questi spostamenti.
Questo è collegato alla domanda su quali applicazioni rientrino esattamente in una normativa e quali no; tale confine è trattato in la pagina sull'ambito di applicazione. Un sistema che era fuori ambito al momento dell'acquisto può rientrare nell'ambito non appena il ruolo dell'organizzazione cambia. Ciò significa che non è sufficiente effettuare una verifica una tantum al momento dell'acquisto; la verifica deve adattarsi a ciò che accade effettivamente con un sistema.
Anche il livello di rischio di un'applicazione può cambiare insieme a un cambiamento di ruolo. Cosa significhi esattamente un livello di rischio elevato per gli obblighi di un'organizzazione, e da cosa ciò dipenda, è illustrato in la pagina sulle conseguenze di un livello di rischio elevato. Un'organizzazione che, a seguito di un cambiamento di ruolo, viene improvvisamente considerata fornitore di un sistema con un livello di rischio elevato, ha responsabilità diverse rispetto a quando era solo utente dello stesso sistema.
Per individuare i cambiamenti di ruolo prima che diventino un problema, un'organizzazione deve sapere quali sistemi esistono, chi li modifica e chi li trasferisce a chi. Ciò richiede un inventario che vada oltre l'elenco approvato dall'IT, e un luogo fisso dove vengono registrate le decisioni relative a modifiche, trasferimenti e rietichettature. Un tale luogo fisso, e le domande correlate, sono descritti in la pagina su un elenco di decisioni di supervisione.
La Responsible AI Scan è stata costruita per rendere visibili questi spostamenti: quali sistemi sono effettivamente in funzione, chi li utilizza, chi li ha modificati, e quale ruolo ne deriva in questo momento. Lo strumento che supporta questo è in fase di sviluppo; chi desidera utilizzarlo può iscriversi alla lista d'attesa.
Un cambiamento di ruolo non riguarda solo la governance. Se un sistema passa da strumento occasionale a qualcosa che assume in modo strutturale una parte di un compito, cambia anche la domanda su quanto lavoro quel sistema effettivamente svolga e quanto ne rimanga alle persone. La scansione del lavoro di FTE TO AI calcola per ciascun compito quale parte del lavoro può essere assunta dall'AI, rendendo così visibile dove un cambiamento di ruolo nella governance coincide con uno spostamento effettivo nella distribuzione del lavoro.
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.