Prima che un livello di rischio, un obbligo o una misura di governance acquisti significato, deve essere chiaro quale ruolo svolge la sua organizzazione. Chi immette un sistema di AI sul mercato ha responsabilità diverse rispetto a chi utilizza un sistema costruito da un'altra parte. Il termine usato per questo è noto: fornitore rispetto a utilizzatore. Ma la classificazione in sé non è fissata in un organigramma. Dipende da cosa fa un'organizzazione con uno specifico sistema, e questo può variare per sistema, per reparto e per momento.
La domanda centrale non è chi ha acquistato o installato il sistema, ma chi lo ha immesso sul mercato o lo rende disponibile sotto il proprio nome. Un'organizzazione che acquista e utilizza software come fornito è generalmente utilizzatore. Un'organizzazione che sviluppa un sistema, lo fa sviluppare sotto il proprio nome, o modifica un sistema esistente in modo tale che diventi funzionalmente qualcosa di diverso, può con ciò finire nel ruolo di fornitore. Quest'ultimo punto è spesso quello in cui le organizzazioni si sbagliano: effettuare il fine-tuning di un modello, costruire un proprio livello sopra un sistema esterno, o addestrare un chatbot sui propri dati può far cambiare il ruolo senza che nessuno lo percepisca come una scelta consapevole. Cosa conta esattamente come una modifica che cambia il ruolo è descritto su cosa cambia se adatta lei stesso un modello.
La maggior parte delle organizzazioni non sono esclusivamente fornitore o esclusivamente utilizzatore. Una banca che impiega un modello linguistico esterno per il servizio clienti è in questo utilizzatore, ma se la stessa banca rende disponibile un modello di rischio sviluppato internamente a un altro reparto o a un cliente, per quel sistema si crea un ruolo di fornitore. Ciò significa che la classificazione deve essere effettuata per ogni applicazione, non una sola volta per l'intera organizzazione. Un inventario che registra per sistema chi lo ha costruito, chi lo ha modificato e chi lo utilizza è quindi il solo modo per rispondere a questa domanda in modo strutturale piuttosto che occasionale.
Il ruolo non è una caratteristica fissa di un'organizzazione ma uno status soggetto a cambiamento. Un fornitore può modificare il proprio sistema in un modo che incide sul profilo di rischio. Uno sviluppatore interno può sviluppare ulteriormente uno strumento interno fino a qualcosa che viene offerto fuori dall'organizzazione. Un sistema entrato in origine come semplice strumento può, dopo un aggiornamento, svolgere compiti che lo collocano in un'altra categoria di rischio. In quali momenti questo cambiamento si verifica concretamente e cosa significa per chi è allora responsabile è illustrato su quando cambia il suo ruolo. Per le organizzazioni che vogliono capire cosa comporta in pratica uno spostamento verso un livello di rischio più elevato, cosa significa un livello di rischio elevato per la sua organizzazione offre un ulteriore approfondimento.
Non ogni applicazione indicata come intelligenza artificiale rientra nell'ambito per cui la ripartizione dei ruoli è rilevante. Alcuni sistemi rimangono fuori dall'ambito per cui è stata creata questa classificazione, ed è per un'organizzazione altrettanto importante sapere cosa rimane fuori dall'ambito quanto sapere cosa vi rientra. Altrimenti si spende tempo a classificare qualcosa che non necessitava di classificazione, oppure qualcosa viene trascurato perché sembrava troppo piccolo. Quali applicazioni rimangono fuori da questo ambito e perché è descritto su quali applicazioni rimangono fuori ambito.
La determinazione del ruolo è un primo passo, non l'esito di un percorso di governance. Dopo la classificazione segue la domanda su cosa debba effettivamente accadere per ogni ruolo e ogni livello di rischio, e questa domanda si divide in due categorie: ciò che richiede attenzione immediata e ciò che può essere pianificato su un termine più lungo. Queste due categorie vengono spesso confuse tra loro, con la conseguenza che le questioni urgenti rimangono in sospeso mentre il tempo viene dedicato a qualcosa che non è ancora urgente. Una panoramica di ciò che ha priorità è disponibile su cosa serve ora e cosa può essere pianificato. Chi desidera approfondire ulteriormente la questione della ripartizione dei ruoli, con i criteri precisi che determinano il confine tra fornitore e utilizzatore, trova questo approfondimento su è lei fornitore o utilizzatore: da cosa dipende.
Questa classificazione ha senso solo se viene applicata a ciò che effettivamente opera nell'organizzazione, non a ciò che figura in un elenco approvato. I sistemi introdotti senza autorizzazione contano comunque, e il ruolo corrispondente deve essere determinato altrettanto bene. Ciò richiede un inventario che vada oltre l'amministrazione IT.
Una volta chiarito quale ruolo svolge un'organizzazione per ogni sistema, l'attenzione si sposta naturalmente su un'altra domanda: cosa fanno effettivamente questi sistemi, e quale parte del lavoro sostituiscono. Questa domanda si trova al di fuori della scansione di governance, ma vi si collega direttamente. La scansione del lavoro di FTE TO AI calcola per compito quale parte del lavoro può essere svolta dall'AI, offrendo così un quadro dell'impatto di un sistema oltre a quello degli obblighi che lo riguardano.
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.