Futura AI
en
Tutti gli articoli
  • Produzione
  • Metodo

Il costo che nessuno mette a budget: la manutenzione di un sistema di AI

Il primo rilascio è la parte meno costosa. Modelli, documenti e processi cambiano continuamente: che cosa mettere a budget e a contratto per non farsi sorprendere dal degrado silenzioso di un sistema di AI.

di Daniele Grotti5 min di letturaAggiornato il
Futura AI — Il costo che nessuno mette a budget: la manutenzione di un sistema di AI

In un sistema di AI il primo rilascio è la parte meno costosa. I modelli cambiano, i documenti cambiano, i processi cambiano.

Questa asimmetria è nota in ogni ambito del software, ma nei sistemi basati su modelli linguistici è più marcata. Un applicativo tradizionale, se nessuno lo tocca e l’ambiente resta stabile, continua a comportarsi allo stesso modo. Un sistema di AI ancorato a documenti e a modelli forniti da terzi si degrada anche restando fermo.

Il degrado è graduale e non produce errori evidenti. È per questo che viene riconosciuto tardi.

Le tre voci ricorrenti

L’aggiornamento dei modelli. I fornitori rilasciano nuove versioni e dismettono le precedenti, con preavvisi che raramente coincidono con i tempi dell’organizzazione. Un cambio di modello non è una sostituzione trasparente: il comportamento varia, e istruzioni calibrate su una versione possono produrre risultati diversi su un’altra.

Ogni cambio richiede una nuova esecuzione dei test di valutazione e, in genere, una taratura delle istruzioni. Su un sistema in produzione in un contesto regolato, richiede anche l’aggiornamento della documentazione tecnica e la registrazione della versione attiva.

Chi opera con modelli open weight su infrastruttura propria ha maggiore controllo sui tempi, ma assume l’onere dell’aggiornamento e del dimensionamento.

L’aggiornamento della base documentale. Circolari che cambiano, procedure riviste, manuali con nuove revisioni, atti che entrano in archivio ogni giorno.

Se l’indicizzazione non è automatica e continua, la base si disallinea. Il sintomo è caratteristico: il sistema risponde correttamente su ciò che era vero sei mesi fa. Nessuno se ne accorge finché non arriva una contestazione su un caso specifico.

A questo si aggiunge il governo delle versioni, che è un’attività organizzativa: qualcuno deve stabilire e mantenere quale documento è vigente.

L’evoluzione dei processi. Cambia una norma, si riorganizza un ufficio, si introduce una nuova tipologia di pratica. Il sistema è stato progettato sul processo precedente.

È la voce più difficile da prevedere e quella che genera le richieste di intervento più corpose. Un sistema che non segue l’evoluzione del processo viene progressivamente aggirato dagli operatori, che tornano alle modalità precedenti per i casi nuovi.

Perché un sistema non presidiato peggiora

Il peggioramento non è metaforico. Ha tre cause misurabili.

La base documentale si disallinea rispetto alla realtà, e l’accuratezza cala su tutto ciò che è cambiato dopo l’ultima indicizzazione.

Le eccezioni si accumulano. Ogni caso non previsto che il sistema gestisce male genera una scorciatoia informale. Dopo alcuni mesi, la quota di lavoro che passa dal sistema si è ridotta senza che nessuno lo abbia deciso.

I permessi si disallineano. Le persone cambiano ruolo, gli uffici si riorganizzano. Se i diritti non seguono automaticamente le fonti, si creano sia accessi indebiti sia impossibilità di accedere a documenti necessari.

C’è poi un fenomeno meno tecnico. Se nessuno raccoglie e analizza gli output corretti dagli operatori, l’informazione più preziosa sul funzionamento del sistema viene prodotta ogni giorno e dispersa.

Come dimensionare il presidio interno

Il presidio non richiede necessariamente una struttura dedicata, ma richiede tempo attribuito e riconosciuto.

Le attività ricorrenti sono cinque: verifica periodica dell’accuratezza sull’insieme di prova, raccolta e analisi degli scarti, aggiornamento dell’indice quando la base cambia, gestione delle segnalazioni degli utilizzatori, rapporto con il fornitore per le evoluzioni.

Le prime tre sono in larga parte automatizzabili nell’esecuzione; l’analisi dei risultati no.

Il dimensionamento dipende dal numero di sistemi, dal volume documentale e dalla criticità. Nella nostra esperienza, per un singolo sistema in produzione su un processo definito, si tratta di una frazione stabile di una persona, con picchi in occasione dei cambi di modello o di normativa. Il dato va però stimato caso per caso in fase di progetto, non assunto.

Due errori ricorrenti nel dimensionamento. Attribuire il presidio a una persona già satura, con il risultato che le verifiche vengono rinviate. E attribuirlo a chi non conosce il processo: la valutazione di un output errato richiede competenza di dominio, non solo tecnica.

Che cosa mettere a contratto con il fornitore

Sette elementi, da definire prima della firma.

La gestione dei cambi di modello: chi li rileva, con quale preavviso, chi esegue la nuova valutazione e a quali condizioni economiche.

La frequenza e la modalità dell’aggiornamento documentale, distinguendo ciò che è automatico da ciò che richiede intervento.

I livelli di servizio sull’accuratezza, con la metrica, l’insieme di prova di riferimento e la cadenza di verifica. Un livello di servizio espresso solo in termini di disponibilità del servizio non dice nulla sulla qualità delle risposte.

Il perimetro della manutenzione correttiva rispetto a quella evolutiva, con una definizione operativa che eviti la controversia ricorrente su dove finisca un difetto e inizi una nuova esigenza.

La titolarità di dati, indici, configurazioni e istruzioni, e il formato in cui vengono restituiti alla scadenza.

Le condizioni di uscita: preavviso, supporto alla migrazione, durata del periodo di affiancamento.

La documentazione da mantenere aggiornata e chi ne è responsabile.

Che cosa la manutenzione non risolve

Non compensa un’architettura inadeguata. Un sistema progettato male richiede più manutenzione e resta fragile.

Non sostituisce il governo documentale. Se l’organizzazione non stabilisce quale versione è vigente, nessuna frequenza di aggiornamento risolve.

E non giustifica un progetto marginale. Se il beneficio atteso è modesto, il costo ricorrente di presidio può azzerarlo. È un motivo legittimo per non fare un progetto, e va valutato prima.

In chiusura

La manutenzione va stimata insieme allo sviluppo e messa a budget dall’inizio, con un orizzonte di almeno tre anni. Non è una voce di dettaglio: in molti progetti supera il costo iniziale nell’arco del ciclo di vita.

Nella valutazione di un progetto, la domanda da porre accanto a “quanto costa realizzarlo” è “quanto costa tenerlo in funzione e chi lo farà”.

Se state valutando un progetto o avete un sistema già in esercizio, siamo disponibili a un confronto sul dimensionamento del presidio e su che cosa conviene definire a contratto.

Se questo tema riguarda un processo reale della tua organizzazione, parliamone con un Assessment AI mirato.

Richiedi un Assessment AI