Divulgazione della versione del modello IA: cosa deve sapere il consiglio

Quando un consiglio approva un'analisi generata dall'IA, la versione del modello che l'ha prodotta diventa parte della base di prove della decisione. Questa guida illustra uno standard di divulgazione in una sola riga, un test di rilevanza per stabilire quando l'aggiornamento del modello di una piattaforma richiede di informare il consiglio, e le domande ai fornitori che rendono la responsabilità a livello di versione applicabile in concreto.

Tre cose che il consiglio deve capire e una che non deve: deve sapere che la versione è bloccata, registrata e recuperabile; deve disporre di un test di rilevanza per sapere quando prestare attenzione a un aggiornamento; e deve avere le domande giuste da porre ai fornitori. Non deve capire come funziona il modello.

Le analisi generate dall'IA sono diventate discretamente un input di routine nei pacchetti di documenti per il consiglio. La supervisione formale non ha tenuto il passo. Quando ISS-Corporate ha esaminato le dichiarazioni proxy delle società S&P 500, ha rilevato che solo circa il 15% delle aziende forniva qualsiasi divulgazione sulla supervisione dell'IA da parte del consiglio, e soltanto l'1,6% comunicava un'esplicita responsabilità di supervisione a livello di intero consiglio o di comitato.^[1]

• Solo circa il 15% delle società S&P 500 comunica un qualche livello di supervisione del consiglio sull'IA nelle dichiarazioni proxy.
• Solo l'1,6% comunica una responsabilità esplicita di supervisione a livello di intero consiglio o di comitato.
• Gli obblighi di trasparenza dell'articolo 50 del regolamento IA europeo si applicano a partire dal 2 agosto 2026, richiedendo la divulgazione dei contenuti generati dall'IA e la marcatura leggibile da una macchina degli output generativi.^[2]

La domanda più acuta e in gran parte irrisolta è: quale versione del modello ha prodotto l'analisi, e cosa succede alla responsabilità quando la piattaforma aggiorna silenziosamente quel modello dopo che il consiglio ha approvato? I consigli che non riescono a rispondere a questa domanda non sono in grado di ricostruire ciò che hanno approvato, nemmeno in linea teorica.

Il modello è un input portante dell'analisi stessa: influenza come i problemi vengono strutturati, quali inquadrature vengono portate alla luce, come vengono soppesate le prove e in quale linguaggio vengono scritte le conclusioni. Eseguire lo stesso brief su una versione diversa del modello può produrre un documento materialmente diverso.

Una ricerca sul regression testing per i sistemi di IA generativa ha costruito un benchmark di 80 casi di test per lingua su otto categorie di attività e ha riscontrato che i modelli più recenti migliorano generalmente la correttezza in media, ma i miglioramenti possono essere modesti e disomogenei, e una versione più recente potrebbe migliorare complessivamente ma peggiorare inaspettatamente su input o attività specifiche.^[3]

Tre proprietà che dipendono dalla conoscenza della versione:

• Riproducibilità: se la versione non viene registrata, nessuno potrà in seguito ricostruire quale sistema ha prodotto l'output approvato.
• Responsabilità: la persona che presenta l'analisi, non il fornitore, risponde dei suoi contenuti. Quella responsabilità si basa su uno stato specifico del sistema.
• Rilevamento della deriva: il comportamento del modello cambia tra le versioni. Le indicazioni di IBM sulla deriva del modello identificano il rilevamento della deriva come un componente centrale di una solida governance dell'IA, e parte dall'identificazione della versione di riferimento.^[4]

Tre elementi su una sola riga in copertina sono sufficienti per rendere un'analisi assistita dall'IA ricostruibile. Il formato esatto è meno importante della disciplina: ogni documento assistito dall'IA che raggiunge il consiglio riporta quella riga.

1. Il nome della piattaforma o dello strumento, così che il documento possa essere attribuito a un sistema specifico.
2. La versione del modello o il range di versione, così che lo stato esatto del sistema sia identificabile.
3. La data di generazione, collegata alla cronologia dei rilasci del fornitore.

Una riga praticabile: «Analisi generata su [Piattaforma], versione del modello [X], in data [data].» Questo fornisce al consiglio, alla funzione di revisione e a qualsiasi esaminatore futuro le tre coordinate necessarie per localizzare l'analisi nella cronologia delle versioni del fornitore.

La stessa disciplina dovrebbe estendersi a qualsiasi aggiornamento significativo. Se un'analisi viene aggiornata in una data successiva, la copertina riporta la riga di divulgazione della versione aggiornata – e se la versione del modello è cambiata tra l'originale e l'aggiornamento, tale modifica viene annotata.

Se la piattaforma aggiorna il suo modello sottostante dopo che il consiglio ha approvato l'analisi, il documento approvato rimane invariato purché la versione su cui è stato generato sia bloccata, registrata e recuperabile. L'approvazione si collega al documento, non al rilascio corrente del fornitore.

La modifica diventa rilevante quando l'analisi verrà rieseguita, aggiornata o utilizzata per una decisione attiva. I fornitori deprecano spesso le versioni precedenti secondo i propri calendari, e gli aggiornamenti ai modelli sottostanti possono modificare silenziosamente il comportamento.^[5]

Tre domande da porre quando un fornitore annuncia una modifica del modello:

• Questa analisi verrà rieseguita o aggiornata sulla nuova versione? In caso affermativo, gli output potrebbero differire e il comitato dovrebbe vedere entrambe le versioni affiancate.
• Una decisione attiva continuerà a basarsi su di essa? L'utilizzo attivo significa che è lo stato corrente del modello a fare il lavoro, non il documento bloccato.
• Il fornitore ha dato un preavviso adeguato? Il preavviso determina se il team ha avuto il tempo di testare la nuova versione prima di affidarsi a essa.

Regola pratica: informare il consiglio quando una riesecuzione sulla nuova versione potrebbe plausibilmente modificare una conclusione rilevante. Non informare il consiglio ogni volta che cambia un numero di versione.

Tre domande trasformano la preoccupazione sulle versioni del modello in impegni applicabili al momento della firma del contratto, anziché dopo che l'analisi è già nel pacchetto per il consiglio.

1. La versione del modello viene registrata nella traccia di revisione per ogni output generato e può essere esportata come parte di un pacchetto di riproducibilità insieme alle fonti e ai prompt?
2. Cosa dice il contratto di servizio riguardo alle modifiche del modello, alle deprecazioni e ai periodi di preavviso?
3. Un ordine enterprise può rafforzare le condizioni di preavviso e di blocco della versione al momento della firma?

I periodi di preavviso dei fornitori variano considerevolmente. Un'analisi delle condizioni contrattuali vigenti indica che OpenAI si impegna a 14 giorni di preavviso per le modifiche del modello, Anthropic e Google a 30 giorni, e alcuni fornitori non si impegnano ad alcun preavviso.^[6] Queste clausole predefinite sono spesso un floor, non un ceiling; le finestre di preavviso e gli impegni di blocco della versione sono genuinamente negoziabili al momento della firma per i clienti enterprise.

Il consiglio ha bisogno di quasi nessun dettaglio tecnico. Tre proprietà che un amministratore non tecnico può verificare sono tutto ciò che conta:

1. La versione del modello è registrata per ogni analisi assistita dall'IA che ci viene presentata?
2. Quella registrazione viene conservata in una forma che potremmo recuperare tra un anno, se una decisione venisse contestata?
3. La versione alla base di un determinato documento è bloccata, così che una riesecuzione oggi verrebbe eseguita su uno stato del sistema noto e denominato?

I dettagli tecnici – architettura transformer, numero di parametri, punteggi di benchmark – appartengono a un livello inferiore, al segretario societario o alla funzione di revisione. I consigli già si affidano a modelli di valutazione, assunzioni attuariali e metodi di campionamento statistico i cui meccanismi interni la maggior parte degli amministratori non può ricostruire. La versione del modello è lo stesso tipo di input: uno stato del sistema denominato e datato a cui si può fare riferimento in seguito, non un meccanismo che il consiglio deve capire.

Il compito del segretario societario o della funzione di revisione è confermare, una volta all'anno, che la disciplina del registro delle versioni viene applicata e che almeno un'analisi significativa dell'anno precedente può essere riprodotta sulla versione su cui è stata generata.

Questo esempio è illustrativo. Un comitato investimenti di una società di private equity approva un'analisi di deal assistita dall'IA nel primo trimestre. La copertina riporta la riga di divulgazione: nome della piattaforma, versione del modello e data di generazione. Un pacchetto di riproducibilità viene archiviato nel fascicolo del deal.

Nel secondo trimestre la piattaforma aggiorna il suo modello sottostante. La revisione di governance esegue tre verifiche:

1. L'analisi approvata del primo trimestre è ancora riproducibile sulla versione bloccata? Se il fornitore l'ha già deprecata, il pacchetto di riproducibilità diventa l'unica registrazione di quanto è stato approvato.
2. Una riesecuzione nel secondo trimestre sul nuovo modello modifica una conclusione rilevante? In caso affermativo, il punto viene segnalato per una nuova approvazione con i vecchi e i nuovi output affiancati.
3. Le condizioni di preavviso del fornitore hanno dato al team il tempo sufficiente per testare la nuova versione prima di qualsiasi affidamento su di essa? In caso negativo, le condizioni contrattuali dovrebbero essere riviste al rinnovo.

Il risultato è una di due brevi note al comitato: o l'analisi approvata non è interessata e il documento del primo trimestre è archivato, o il punto viene segnalato per una nuova approvazione. Nessuna delle due richiede al comitato di comprendere i dettagli tecnici della modifica del modello.

Piattaforme costruite per il lavoro strategico a livello di consiglio, come Decisity, trattano la tracciabilità delle fonti e la verificabilità come requisiti fondamentali di progettazione, così che l'allegazione della versione e il pacchetto di riproducibilità siano prodotti come parte del flusso di lavoro standard anziché come un compito documentale retrospettivo.

Letture correlate:

• Chi risponde quando una strategia redatta dall'IA si rivela sbagliata?
• Clausole di riservatezza da richiedere al fornitore di piattaforma IA
• Documenti riservati e strumenti di IA: cosa verificare
• Presentare un'analisi strategica assistita dall'IA a un consiglio scettico

• ISS-Corporate via Harvard Law School Forum on Corporate Governance: AI Governance Appears on Corporate Radar (April 2024)
• Regolamento IA europeo: articolo 50, Obblighi di trasparenza
• GPR-bench: Regression testing per sistemi di IA generativa
• IBM: Cos'è la deriva del modello?
• The Neural Base: Come gli aggiornamenti del modello modificano il comportamento dell'IA
• Digital Applied: Prezzi IA e impegni deboli negli acquisti