Avete una lista di strumenti AI approvati. La domanda non è se quella lista sia corretta, ma se significhi ancora qualcosa. Un collaboratore che accelera un'attività con un chatbot che non è sulla lista non lo segnala come incidente. Non lo segnala perché non lo percepisce come un incidente. La risposta che non dovete accettare è quindi "abbiamo una politica AI e una lista approvata" — perché questa frase non dice nulla su ciò che avviene fuori da quella lista, ed è probabilmente la parte più grande.
Come CIO, siete voi a dover spiegare perché un incidente AI non era emerso prima, mentre il resto dell'organizzazione presume che l'IT abbia il quadro completo. Quel quadro esiste per i sistemi acquisiti. Non esiste per il plugin che un team ha installato autonomamente, la versione di prova che qualcuno ha attivato, o il modello arrivato insieme a uno strumento di assistenza clienti. Il rischio per voi non è che l'AI venga usata — questo accade comunque — ma che siate voi gli ultimi a saperlo, nel momento in cui le cose sono già andate storte.
Un inventario accurato cambia la vostra posizione. Invece di reagire a incidenti che non avevate previsto, potete indicare in anticipo dove si trovano i rischi e perché. Questa è anche la base per avviare, all'interno dell'organizzazione, il dialogo con il General Counsel, che osserva la stessa AI ombra da una prospettiva diversa, e con il risk manager, che vuole inserirla nella struttura di rischio esistente invece di creare un percorso separato.
La lista IT registra ciò che è stato acquisito e approvato. L'AI ombra nasce dove questi due passaggi vengono saltati: un collaboratore trova uno strumento, lo usa, e non riporta nulla perché non sembra esserci nulla da riportare. Non è negligenza — è la conseguenza di un processo di acquisizione che non è stato progettato per tenere traccia di ciò che le persone adottano da sole. Più grande è l'organizzazione e più i team lavorano in autonomia, più grande può essere la differenza tra la lista e la realtà. Quanto sia piccola quella differenza dipende da quanta libertà hanno i team di scegliere autonomamente gli strumenti e da quanto questo comportamento sia già visibile — un dato numerico su questo non esiste, solo la tendenza.
L'unico modo per sapere cosa viene realmente usato è chiederlo alle persone che lo utilizzano. Funziona solo se la risposta non comporta conseguenze per chi la dà. Se chiedete "usi strumenti AI non approvati" con un tono che ricorda un colloquio di valutazione, otterrete la risposta che la lista IT aveva già fornito: no. Se lo chiedete senza legarlo a conseguenze, con l'obiettivo di capire invece di correggere, emerge un quadro che corrisponde davvero alla prassi. Questa distinzione — chiedere senza conseguenze contro chiedere con conseguenze — è la differenza tra un inventario che ha valore e un esercizio che non dice nulla a nessuno.
Una lista di strumenti utilizzati è un punto di partenza, non un punto d'arrivo. Non ogni applicazione AI comporta lo stesso rischio. Uno strumento che riscrive testi per uso interno è diverso da uno strumento che contribuisce a decidere sull'accettazione di un cliente o sulla valutazione del personale. Classificare per ruolo — cosa fa il sistema — e per livello di rischio — qual è l'impatto se qualcosa va storto — è necessario per sapere dove concentrare l'attenzione. Senza classificazione, ogni applicazione AI appare uguale in un rapporto, e questo è esattamente il quadro che non aiuta a convincere un consiglio di amministrazione.
Come CIO avete probabilmente già un quadro di rischio per sistemi IT, sicurezza informatica e fornitori. La governance AI funziona meglio se si collega a quella struttura piuttosto che diventare un quadro separato a fianco. È anche ciò con cui si confrontano il compliance officer e il responsabile del programma AI: troppe iniziative AI separate che non comunicano tra loro, mentre il consiglio di amministrazione si aspetta proprio un'unica risposta coerente su cosa sta accadendo e cosa si sta facendo in merito.
Ciò che l'AI ombra significa varia da settore a settore. Nel settore delle costruzioni la questione si presenta diversamente rispetto al settore degli impianti, e vale la pena vedere come si configura la governance AI nel settore delle costruzioni o come si presenta nel settore degli impianti prima di supporre che un unico approccio vada bene ovunque.
La Responsible AI Scan che produce questo risultato — inventario, classificazione, un set di governance collegato alla vostra struttura esistente — è in fase di sviluppo. Chi vuole già iniziare può iscriversi alla lista d'attesa; non esiste ancora un prodotto pronto da offrire, e preferiamo scriverlo onestamente piuttosto che promettere qualcosa che non c'è ancora.
Non appena sapete quale AI viene utilizzata e con quale rischio, segue naturalmente la domanda successiva: quale parte del lavoro stesso potrebbe essere un compito per l'AI, e quale no. È una domanda diversa dalla gestione del rischio — riguarda la capacità, non l'esposizione — e la scansione del lavoro di FTE TO AI la calcola per singola attività, in modo che sappiate non solo cosa è già in funzione, ma anche dove l'AI potrebbe assumere direttamente 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.