Un fornitore fornisce un pacchetto di contabilità, un sistema HR o uno strumento di assistenza clienti. C'è un contratto, un accordo sul trattamento dei dati, forse un audit di sicurezza. Poi il fornitore aggiunge, in un aggiornamento, una funzione di IA: classificazione automatica, suggerimenti di testo, un chatbot lanciato sui vostri dati. Le note di rilascio la definiscono un miglioramento. Nessuno nella vostra organizzazione ha avuto voce in capitolo, perché nessuno sapeva che stava arrivando.
Questo non è un'eccezione al modo in cui il software viene fornito. È diventato lo standard. I fornitori competono sulla funzionalità di IA e la integrano quanto prima possibile, spesso come parte di un abbonamento che già pagate. La domanda se questo rientri nei vostri accordi esistenti viene raramente posta prima che la funzione entri in produzione.
Un ufficio acquisti valuta un fornitore al momento dell'acquisto. Dopo, l'attenzione si sposta su fattura, uptime e supporto. Gli aggiornamenti funzionali passano fuori da quel processo, perché rientrano nella manutenzione, non in un nuovo acquisto. Chi dovrebbe segnalarlo? Il fornitore lo considera un miglioramento del prodotto. L'addetto agli acquisti non vede l'aggiornamento, o lo vede ma pensa che riguardi qualcun altro. L'utente nell'organizzazione nota soprattutto che un pulsante fa qualcosa di più intelligente e non si chiede se dietro ci sia un modello linguistico che elabora i dati esternamente.
Il modello ricorda quanto accade con un'estensione del browser con accesso alla vostra posta: l'accesso viene concesso in un momento in cui nessuno pensava all'IA, e resta poi attivo inosservato. Con i fornitori il problema di scala è maggiore, perché non riguarda un solo dipendente ma un'intera organizzazione esposta tramite un unico contratto.
Una disposizione contrattuale che imponga l'obbligo di segnalazione in caso di funzionalità di IA è utile per i nuovi contratti. Nei contratti esistenti la disposizione non c'è, e non è scontato che un fornitore la accetti con effetto retroattivo. Inoltre una clausola non risolve il problema del rilevamento: se nessuno controlla periodicamente cosa il fornitore ha effettivamente aggiunto, la segnalazione resta dipendente dalla disponibilità del fornitore a segnalare di propria iniziativa.
Quello che funziona è una rilevazione periodica fissa: un inventario ricorrente di quale funzionalità di IA ogni fornitore chiave fornisce in questo momento, distinto da quanto è stato valutato al momento dell'acquisto. Non è uno strumento giuridico ma una panoramica fattuale, che può poi essere verificata rispetto alla categoria di rischio del processo in cui il fornitore opera.
La stessa dinamica che mantiene in vita l'IA ombra tra i dipendenti si presenta anche qui, ma a livello di fornitori. Chi pone la domanda "utilizzate l'IA per questo" vuole una risposta onesta, non una reazione defensiva dell'account manager. Ciò significa che la domanda non deve essere posta come preludio alla risoluzione del contratto, ma come parte di un processo fisso in cui la risposta non ha conseguenze oltre alla classificazione. Si veda come funziona con i dipendenti che usano uno strumento che nessuno ha approvato: l'informazione utile emerge solo quando fare domande è separato dal punire.
Un elenco fornitori è un punto di partenza, non un punto di arrivo. Per ogni fornitore che ha accesso a dati di produzione, dati clienti o dati del personale è rilevante sapere se ormai contiene funzionalità di IA, cosa fa quella funzionalità con i dati, e se tale uso rientra nella stessa categoria di rischio per cui il fornitore era stato originariamente approvato. Un fornitore valutato cinque anni fa come basso rischio perché si limitava a fatturare, può ora eseguire un modulo che classifica automaticamente le fatture sulla base di un modello linguistico addestrato esternamente. Si tratta di una categoria di rischio diversa, anche se sulla fattura compare lo stesso nome.
Questo inventario non deve essere separato dal resto della governance dell'IA di un'organizzazione. La stessa classificazione applicata agli strumenti costruiti internamente o a una configurazione di prova che non è mai stata disattivata, deve essere applicata anche a ciò che i fornitori introducono. Una sola panoramica, una sola scala di rischio, indipendentemente dal fatto che l'IA sia stata costruita internamente, portata da un dipendente o aggiunta da un fornitore senza preavviso.
Una volta chiaro quale IA entra tramite i fornitori, nasce una domanda successiva che va oltre il solo rischio: cosa fa concretamente quell'IA con il lavoro che ora viene svolto da persone, e dove ciò si sovrappone a compiti che comunque si prestano già all'automazione. La scansione del lavoro di FTE TO AI calcola, per ciascun compito, quale parte del lavoro può essere presa in carico dall'IA, indipendentemente da quale fornitore o sistema la esegua alla fine. Ciò rende l'inventario che parte dal rischio utile anche per la domanda successiva: non solo cosa è in funzione, ma cosa vale realmente il 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.