Un manuale può spiegare come avviare un processo senza spiegare quando sia sicuro riavviarlo.
Nei sistemi aziendali costruiti e modificati nel corso degli anni, questa differenza può decidere l’esito di un intervento assistito dall’intelligenza artificiale.
Un sistema legacy è, nel contesto di questo articolo, un’applicazione o un insieme di procedure ereditate da precedenti fasi tecnologiche e ancora utilizzate. Può continuare a svolgere funzioni essenziali. Per comprenderlo servono spesso manuali, codice, configurazioni, dati e conoscenza delle persone che lo gestiscono.
Il manuale dice «rilanciare». Il sistema ha già scritto dei dati?
Immaginiamo un caricamento notturno che trasferisce movimenti da un file a un database. Il processo si interrompe e la guida operativa contiene un’indicazione breve: «In caso di errore, rilanciare il job».
Chiediamo all’AI come procedere. Se il modello considera quella frase sufficiente, può proporre una sequenza ordinata e convincente: controllare il file, riavviare, verificare il messaggio finale.
Mancano però informazioni decisive. Il primo tentativo ha registrato alcuni movimenti? Il riavvio riprende dal punto interrotto oppure ricomincia dall’inizio? Esiste una protezione contro i duplicati? Un processo successivo ha già utilizzato i dati parziali?
Chi segue il sistema potrebbe conoscere una condizione mai riportata nella guida: il riavvio è ammesso soltanto dopo la verifica di un registro dei lotti. Anche questa indicazione va riscontrata: una consuetudine operativa può essere superata quanto un documento.
Questo è un esempio didattico costruito per spiegare il problema. Non descrive un incidente specifico, un cliente o una procedura applicabile a un ambiente reale.
La conoscenza operativa è distribuita
La conoscenza necessaria a gestire un sistema può trovarsi in punti diversi. Il codice mostra una condizione, un log registra l’esito di un’esecuzione, una persona ricorda perché è stata introdotta un’eccezione. Presi separatamente, questi elementi possono dare spiegazioni incomplete.
NASA tratta esplicitamente la conservazione della conoscenza critica maturata attraverso l’esperienza come parte della continuità delle proprie attività. È un riferimento utile per comprendere il problema organizzativo, senza equiparare un progetto aziendale a una missione spaziale. [1]
| Fonte | Che cosa può mostrare | Che cosa resta da verificare |
|---|---|---|
| Manuale | Procedura prevista e prerequisiti dichiarati | Versione, ambiente e condizioni ancora valide |
| Codice e configurazione | Logica implementata e parametri presenti | Che siano quelli effettivamente in esecuzione |
| Log e dati di controllo | Eventi ed effetti registrati in un’esecuzione | Copertura, completezza e collegamento con l’incidente |
| Esperienza degli operatori | Eccezioni, dipendenze e motivazioni storiche | Riscontri e validità attuale delle indicazioni |
La tabella propone un metodo di lettura delle fonti. Nessuna riga stabilisce una precedenza automatica: quando le informazioni si contraddicono, occorre ricostruire la differenza.
Conoscere il prodotto non significa conoscere la sua installazione
Un modello può spiegare correttamente le funzioni generali di un programma e non disporre delle informazioni necessarie sul progetto in cui quel programma viene usato.
Il prodotto Oracle Data Integrator (ODI) offre un esempio tecnico concreto.
La documentazione descrive i Knowledge Module come modelli di codice per attività di integrazione e prevede possibilità di adattamento e condivisione tra progetti. La configurazione e gli eventuali adattamenti del modulo diventano quindi elementi da esaminare quando si analizza un’installazione. [2]
La fonte citata riguarda ODI 12.2.1.3: serve a illustrare questo meccanismo, non a fornire istruzioni per qualsiasi versione. Per un intervento reale vanno identificate versione installata, configurazione e procedura applicabile.
Dove l’AI può aiutare e dove può colmare i vuoti
Possiamo usare l’AI per confrontare una guida con uno script, ordinare una cronologia di errori, individuare contraddizioni e preparare domande per gli specialisti. L’utilità di questi impieghi va verificata sul caso concreto.
Il rischio nasce quando una ricostruzione plausibile diventa una conclusione presentata come accertata. Una frase come «il riavvio non genera duplicati» richiede prove sul processo effettivo. La familiarità del modello con procedure simili non dimostra quella proprietà.
Il profilo NIST sull’AI generativa descrive il rischio di contenuti erronei o falsi presentati con sicurezza, comprese spiegazioni che possono indurre fiducia eccessiva. Nel nostro esempio la raccomandazione è quindi chiedere evidenze per ogni conclusione operativa rilevante. [3]
Un metodo pratico per ricostruire prima di intervenire
1. Delimitare il compito. Chiedere inizialmente un’analisi in sola lettura, indicando ambiente, versione e processo interessato. L’analisi non autorizza riavvii o modifiche.
2. Raccogliere le fonti pertinenti. Selezionare guida, codice o configurazioni autorizzate, log dell’esecuzione e dati di controllo necessari. Ridurre o mascherare informazioni personali e riservate prima di utilizzare un servizio AI.
3. Costruire una mappa delle evidenze. Per ogni affermazione annotare fonte, data, ambiente e stato: osservata, ipotizzata o da confermare. «Il log segnala un errore» e «nessun dato è stato scritto» sono conclusioni diverse.
4. Chiedere agli operatori spiegazioni circostanziate. In quali condizioni il processo si può ripetere? Quale controllo precede il riavvio? Quale incidente ha motivato l’eccezione? Cercare poi i riscontri disponibili.
5. Verificare la proposta con criteri espliciti. Nel caso didattico servono criteri su duplicati, completezza dei movimenti, stato dei lotti e processi dipendenti. Eventuali prove che scrivono dati richiedono un ambiente e un’autorizzazione adeguati. Un’esecuzione senza errori non dimostra, da sola, che i dati siano corretti.
Una richiesta da usare come punto di partenza
Analizza in sola lettura la documentazione e i file autorizzati di questo processo. Distingui ciò che è documentato da ciò che è osservabile e dalle tue ipotesi. Per ogni conclusione indica la fonte e il suo ambito. Segnala contraddizioni e informazioni mancanti, soprattutto sugli effetti di un eventuale riavvio. Non proporre come sicura una riesecuzione senza prove. Prepara le domande per chi gestisce il sistema e i controlli necessari a valutare un intervento. Non modificare file o dati e non eseguire riavvii.
Una richiesta dettagliata rende più chiaro il perimetro, ma non garantisce che la risposta lo rispetti. Il controllo umano confronta ciò che è stato chiesto, ciò che l’AI dichiara e le evidenze effettivamente disponibili.
Trasformare la ricostruzione in una procedura mantenibile
Dopo le verifiche, le informazioni confermate devono diventare utilizzabili anche da un altro collega. Un playbook operativo può conservare prerequisiti, sequenza, condizioni di arresto, verifiche e gestione degli errori. Le regole di progetto possono indicare quando richiamarlo; le note di memoria registrano decisioni e punti aperti.
Per ogni procedura conviene distinguere la data di revisione del testo dalla data dell’ultima verifica sul sistema. Correggere una frase oggi non dimostra che oggi siano stati ricontrollati codice, configurazione e comportamento.
L’obiettivo è ottenere una procedura eseguibile e verificabile senza dipendere dalla chat che ha aiutato a ricostruirla. L’AI può contribuire a rendere esplicita la conoscenza disponibile. Le informazioni mancanti restano domande da risolvere, prima di trasformarle in azioni.
Fonti consultate
- NASA, Knowledge Management — APPEL Knowledge Services. Riferimento alla conoscenza critica e alla continuità delle competenze. Consultato il 29 ottobre 2026.
- Oracle, Knowledge Modules, documentazione ODI 12.2.1.3. Fonte tecnica riferita a quella versione, non una procedura per l’ambiente del lettore. Consultata il 29 ottobre 2026.
- NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, luglio 2024, sezione 2.2, Confabulation. Consultato il 29 ottobre 2026.
