Le organizzazioni pensano spesso che il loro ruolo sia fisso: noi siamo utilizzatori, il fornitore è il fornitore, punto. Questa presunzione spesso non è corretta, oppure è corretta oggi e non lo è più domani. Il ruolo che un'organizzazione ha rispetto a un sistema di IA non è una caratteristica fissa dell'organizzazione. È il risultato di ciò che accade con il sistema: chi lo crea, chi lo modifica, chi lo immette sul mercato, e con quale nome. Se uno di questi fattori cambia, può cambiare anche il ruolo, e con esso gli obblighi corrispondenti.
Ciò rende la classificazione non un'istantanea. Un ruolo correttamente stabilito al momento dell'acquisto può risultare errato un anno dopo, senza che internamente sia stata presa consapevolmente alcuna decisione.
La classificazione dipende da un numero limitato di fattori, ma questi fattori non sono tutti nelle mani della parte che utilizza il sistema. È rilevante, tra l'altro, se un sistema è sviluppato internamente o acquistato, se il sistema acquistato viene utilizzato senza modifiche o viene adattato, e se l'adattamento incide sul profilo di rischio del sistema. È rilevante anche con quale nome un sistema viene presentato all'esterno: un sistema che viene rivenduto o ulteriormente sviluppato con un proprio marchio può comportare un ruolo diverso rispetto al far funzionare senza modifiche un prodotto esterno. Per il confine preciso tra queste due posizioni è rilevante la pagina su cosa cambia quando un'organizzazione adatta autonomamente un modello acquistato, e per la domanda di base su quale dei due ruoli principali sia applicabile, c'è la pagina che spiega da cosa dipende esattamente la scelta tra fornitore e utilizzatore.
La classificazione non è quindi qualcosa che un'organizzazione stabilisce una volta e poi archivia. È una classificazione che deve essere nuovamente valutata non appena i fatti sottostanti cambiano.
Se il ruolo cambia, cambia anche ciò che viene richiesto a un'organizzazione. Una parte che è puramente utilizzatore ha obblighi diversi da una parte che è (co)responsabile della creazione di un sistema. Ciò non riguarda solo la documentazione. Riguarda anche dove all'interno dell'organizzazione debba risiedere la responsabilità per un sistema, chi ne riferisce, e quale livello di supervisione sia appropriato.
Questo cambiamento si riflette sulla domanda su quanto pesantemente un sistema debba essere valutato internamente. Un cambiamento di ruolo può portare a dover riesaminare il livello di rischio di un sistema che precedentemente era considerato gestibile — una domanda trattata separatamente nella pagina su cosa significa un livello di rischio elevato per l'organizzazione che utilizza o offre il sistema. Al contrario, un cambiamento di ruolo può anche far sì che un sistema rientri fuori dall'ambito di applicazione di determinati obblighi, oppure ci rientri appena. Quali applicazioni esattamente rimangono fuori dall'ambito e quali invece rientrano per un pelo, è illustrato nella pagina su quali tipi di applicazioni di IA rimangono fuori dall'ambito di applicazione degli obblighi.
I fattori che causano un cambiamento di ruolo si svolgono solitamente a un livello su cui il consiglio di amministrazione, il reparto legale o la gestione del rischio non hanno una visione automatica. Un team che effettua il finetuning di un modello acquistato sui propri dati. Un reparto che rilancia un prodotto chatbot esterno ai clienti con un proprio nome di prodotto. Un'integrazione che combina un modello di un fornitore con regole proprie e poi offre tale combinazione all'esterno. Nessuno di questi passaggi passa automaticamente attraverso un registro centrale, e l'elenco IT degli strumenti approvati solitamente non registra questo tipo di modifica, perché la modifica non viene riconosciuta come 'nuovo acquisto' ma come adattamento di qualcosa che era già stato approvato.
È per questo motivo che i cambiamenti di ruolo spesso diventano visibili solo quando qualcosa va storto, o quando viene richiesto conto dall'esterno. La domanda 'qual è il nostro ruolo in questo sistema' viene allora risposta retroattivamente, in un momento in cui il margine per apportare modifiche è più ridotto rispetto a quando la domanda fosse stata posta prima.
Poiché la classificazione può cambiare, la distinzione tra ciò che richiede attenzione in questo momento e ciò che deve essere nuovamente valutato in futuro è rilevante per la pianificazione del lavoro di governance. Non tutto ciò che un cambiamento di ruolo comporta richiede un'azione immediata; una parte è pianificabile. Quale parte lo sia, e quale parte non possa attendere, è trattato nella pagina su cosa deve essere affrontato ora e cosa può essere pianificato per un momento successivo. Per una sintesi compatta della questione della classificazione stessa, inclusi i punti di svolta più importanti, c'è la pagina che approfondisce le circostanze precise in cui un ruolo cambia.
La domanda su quale ruolo un'organizzazione abbia rispetto a un sistema di IA è vicina a un'altra domanda che riceve raramente la stessa attenzione: quale parte del lavoro effettivo nell'organizzazione è già svolta dall'IA, è pianificata per esserlo, o viene già assorbita senza che nessuno l'abbia registrato. Mentre la questione del ruolo riguarda la responsabilità rispetto a un sistema, la scansione del lavoro di FTE TO AI riguarda la ripartizione dei compiti in sé: per ogni compito viene calcolato quale parte possa essere assunta dall'IA, indipendentemente da quale ruolo l'organizzazione assuma formalmente al riguardo. Queste due domande si toccano, perché uno spostamento nella ripartizione dei compiti è spesso l'occasione per uno spostamento nel ruolo.
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.