Quando l'IT helpdesk è un'IA

← Tutto

Un caso reale di troubleshooting Windows, condotto passo passo insieme a un assistente IA, come esempio concreto di cosa significa oggi "IA come primo (e secondo, e terzo) livello di supporto tecnico".

C'è un modo per capire davvero il potenziale di un assistente IA in ambito IT: non descriverlo in astratto, ma raccontare un caso vero, con tutti i vicoli ciechi, le correzioni di rotta e i momenti in cui la diagnosi iniziale si è rivelata sbagliata. Questo articolo ripercorre una sessione di supporto reale — durata diversi giorni — in cui un utente con un PC Windows 11 gravemente compromesso ha risolto il problema lavorando in coppia con un assistente IA, senza mai coinvolgere un tecnico umano.

Descrizione del problema

Tutto parte da un sintomo apparentemente circoscritto: alcune app (Blocco Note, un'app di terze parti) smettono di aprirsi. Cliccando l'icona, non succede nulla. Provando a disinstallarle, la procedura resta bloccata per minuti e termina con un errore generico:

Non è possibile disinstallare Blocco note. Operazione non riuscita. Riprova più tardi. Il codice di errore è 0x80073cf8.

A questo si accompagnano sintomi collaterali apparentemente slegati: un processo di sistema (svchost — Servizio Repository Stati) fisso al 25% di CPU, e il Microsoft Store che non riesce più a scaricare aggiornamenti.

Il primo compito dell'assistente non è stato eseguire un comando, ma leggere il quadro clinico nel suo insieme: riconoscere che sintomi in apparenza distinti (app che non partono, disinstallazione bloccata, una pagina di Impostazioni vuota, CPU anomala) erano probabilmente manifestazioni di un'unica causa a monte — in questo caso, un database di sistema (lo State Repository, che traccia i pacchetti app installati) rimasto corrotto dopo un crash improvviso di Windows. Questa capacità di correlare sintomi eterogenei in un'unica ipotesi diagnostica, invece di trattarli come problemi indipendenti, è probabilmente il valore aggiunto più immediato di un assistente IA rispetto a una ricerca manuale sintomo-per-sintomo.

Analisi guidata di log ed eventi

Una diagnosi corretta ha bisogno di prove, non solo di ipotesi plausibili. Buona parte della conversazione è stata dedicata a guidare l'utente — passo dopo passo, con percorsi precisi — dentro il Visualizzatore eventi di Windows, per andare a cercare la conferma tecnica dell'ipotesi formulata:

Apri eventvwr.msc → Log applicazioni e servizi → Microsoft → Windows → AppXDeploymentServer → Operational (se non abilitato: tasto destro → Visualizza → "Mostra log analitici e di debug").

Ogni evento raccolto (un ID 404 con un HRESULT specifico, un evento 327 con l'elenco esatto dei pacchetti coinvolti in una transazione, un evento 1000 con nome del modulo e versione del file in crash) è stato usato per confermare o smentire l'ipotesi corrente, non semplicemente per "avere più informazioni". Un dettaglio si è rivelato decisivo: la versione 0.0.0.0 di un file di sistema (ControlCenter.dll) — indice quasi certo di un file corrotto — trovata incrociando due log diversi (log applicazioni e log Windows Error Reporting) che riportavano lo stesso crash da due prospettive complementari.

Un altro esempio, ancora più tecnico: il codice di errore generico 0x800704C7 restituito dal setup di riparazione di Windows è stato messo a confronto con l'analisi automatica di SetupDiag (lo strumento diagnostico ufficiale Microsoft), il cui output XML è stato letto riga per riga per distinguere un vero blocco da un semplice passaggio di cleanup.

Utilizzo massiccio di comandi da terminale

Gran parte del lavoro pratico è passato da PowerShell e dal Prompt dei comandi, quasi sempre con privilegi di amministratore. La coerenza dei comandi è stata una priorità: una volta stabilita la sintassi corretta per un'operazione, è stata riutilizzata identica nei passaggi successivi, così da ridurre il rischio di errori di battitura o di sintassi in un contesto già delicato.

Alcuni esempi rappresentativi dei comandi usati nel corso della sessione:

# Verifica presenza di un pacchetto AppX per tutti gli utenti
Get-AppxPackage -AllUsers *ScreenSketch*

# Ri-registrazione di pacchetti di sistema (componenti XAML della shell)
Get-ChildItem "C:\Windows\SystemApps\MicrosoftWindows.Client.CBS_*\appxmanifest.xml" |
    ForEach-Object { Add-AppxPackage -Register $_.FullName -DisableDevelopmentMode }

# Presa di possesso di una cartella protetta, con SID universale
# (per evitare i problemi di localizzazione del nome del gruppo "Amministratori")
icacls "C:\ProgramData\Microsoft\Windows\AppRepository" /setowner "*S-1-5-32-544" /t /c
icacls "C:\ProgramData\Microsoft\Windows\AppRepository" /grant "*S-1-5-32-544:F" /t /c

# Reinstallazione mirata di App Installer (winget) e poi dello Store
Add-AppxPackage -Path ".\Microsoft.DesktopAppInstaller_x64.msixbundle"
winget install --id 9NBLGGH4NNS1 -s msstore --accept-package-agreements --accept-source-agreements

Un aspetto interessante, tipico di un contesto italiano: takeown /d y ha restituito un errore, perché il prompt Sì/No di quel comando è localizzato e su un sistema in italiano si aspetta S, non Y. È il genere di attrito pratico che un assistente può aiutare a risolvere rapidamente proprio perché può "ragionare" sulla causa (la localizzazione) invece di limitarsi a ripetere lo stesso comando.

Condivisione dello schermo tramite screenshot

Non essendoci accesso remoto reale al PC, l'intero canale diagnostico è passato attraverso screenshot: finestre di errore, pannelli del Visualizzatore eventi, output grezzo di PowerShell. Questo ha richiesto all'assistente di:

• leggere ed estrarre informazioni precise da interfacce grafiche in italiano (nomi di campi, codici, timestamp);
• incrociare più screenshot inviati nello stesso messaggio per ricostruire una sequenza cronologica di eventi coerente, individuando pattern che si ripetono (lo stesso crash con lo stesso offset, ripetuto ogni 30–40 secondi);
• distinguere immediatamente, tra decine di eventi "Informazioni" innocui, le poche righe realmente rilevanti (nel caso concreto, un crash ricorrente di CrossDeviceResumeApp nascosto in mezzo a eventi di routine di Winlogon e del driver grafico Intel).

Quando anche la copia degli screenshot (via PrtScn) ha smesso di funzionare a causa dello stesso problema di sistema, la diagnosi si è naturalmente estesa a coprire anche quel sintomo — un esempio di come, in un troubleshooting reale, il problema da risolvere può in parte sovrapporsi allo strumento usato per diagnosticarlo.

Errori e rimedi

Il percorso non è stato lineare, ed è giusto raccontarlo così. Alcuni tentativi hanno richiesto una correzione di rotta esplicita:

Ricontrolla la correttezza della procedura di reset del database. Ridescrivimela step by step ed indicami anche la procedura di ripristino qualora, dopo quel tentativo, il pc non dovesse più ripartire.

Questa richiesta dell'utente — legittima e prudente — ha portato a una revisione della procedura originale, con l'aggiunta di passaggi di sicurezza che non erano stati previsti al primo giro (backup della chiave BitLocker, creazione di un punto di ripristino, una procedura di rollback dettagliata). È un promemoria utile: anche una diagnosi tecnicamente corretta guadagna da una richiesta esplicita di "cosa succede se va male", e un buon assistente deve saperla accogliere aggiungendo margine di sicurezza, non solo confermando la procedura originale.

In un altro passaggio, un tentativo di reinstallare il Microsoft Store tramite winget ha restituito un messaggio non chiaramente un errore ("pacchetto già installato, nessun aggiornamento disponibile"), che ha richiesto di distinguere tra un vero fallimento e un semplice "falso allarme" prima di introdurre il flag --force come passo successivo solo se necessario — evitando di agire alla cieca su un messaggio ambiguo.

Verifica di più fonti (ufficiali e non)

Più volte, l'assistente ha sospeso l'improvvisazione per verificare via ricerca web prima di proporre un passo importante: il significato reale di un codice di errore, l'esistenza di un bug noto e documentato da Microsoft (in questo caso, un problema pubblico legato ai componenti XAML della shell di Windows 11, con relativa mitigazione ufficiale), o la procedura corretta per reinstallare manualmente winget in assenza dello Store.

Un episodio degno di nota: quando l'utente ha chiesto esplicitamente "dove sono queste istruzioni ufficiali di Microsoft", l'assistente ha dovuto ammettere una imprecisione — la procedura era tecnicamente corretta e proveniva da fonti Microsoft (il repository ufficiale microsoft/winget-cli su GitHub e una pagina di Microsoft Learn), ma non esisteva una singola pagina che descrivesse esplicitamente quello scenario. Comunicare questa distinzione con onestà, invece di far passare un ragionamento assemblato per una citazione diretta, è un aspetto di affidabilità che vale più di una risposta apparentemente più autorevole ma imprecisa.

Un altro caso ha riguardato la sicurezza pratica: cercando "strumento di cattura" nello Store, i primi risultati mostrati erano tutte app di terze parti con nomi e icone simili all'originale, ma non l'app Microsoft ufficiale. Riconoscere questo tipo di "rumore" nei risultati — piuttosto comune negli store applicativi — ed evitare di far installare un clone all'utente, verificando invece l'ID prodotto ufficiale (9MZ95KL8MR0L) su fonti indipendenti (Wikidata, documentazione Microsoft), è un esempio di come la verifica incrociata delle fonti non riguardi solo la correttezza tecnica, ma anche una forma elementare di igiene di sicurezza.

Altri aspetti rilevanti

Diagnosi a strati, non a scatola chiusa

Il caso non si è risolto con un singolo intervento, ma attraverso una sequenza di ipotesi via via più profonde: prima il database dello State Repository, poi i pacchetti XAML della shell, poi un disallineamento di versione tra i componenti di sistema (24H2 e 25H2 mescolati), infine pacchetti interi mancanti dopo la riparazione. Ogni livello ha richiesto strumenti diversi (reset di un database, ri-registrazione di pacchetti, riparazione in-place da ISO, reinstallazione manuale di componenti), e l'assistente ha dovuto più volte segnalare onestamente quando una soluzione proposta rischiava di essere solo un cerotto temporaneo su un problema più profondo — evitando l'effetto "gioco delle tre carte" in cui si rincorre un sintomo alla volta senza mai attaccare la causa.

Gestione esplicita del rischio prima delle azioni irreversibili

Prima di ogni intervento potenzialmente distruttivo (rinominare un database di sistema, avviare un repair dell'intero sistema operativo), l'assistente ha introdotto backup preventivi, verifiche di spazio su disco e — un dettaglio spesso trascurato — il recupero preventivo della chiave di ripristino BitLocker, indispensabile per qualsiasi intervento da ambiente di ripristino su un sistema con crittografia del disco attiva.

Attenzione alla localizzazione

Diversi intoppi (il nome del servizio in italiano, il prompt Sì/No di takeown, i nomi dei log nel Visualizzatore eventi) sono tipici di chi lavora su un sistema non in lingua inglese: un buon supporto tecnico via IA deve saper "tradurre" al volo tra la documentazione tecnica (quasi sempre in inglese) e quello che l'utente vede effettivamente a schermo.

Conclusione

Quello che emerge da questo caso non è "l'IA che sa tutto", ma un modello di lavoro replicabile: formulare un'ipotesi, cercare la prova nei log, verificarla su fonti esterne quando serve, agire con comandi precisi e ripetibili, prepararsi al fallimento prima di agire, e correggere la rotta pubblicamente quando qualcosa non torna. È un flusso di lavoro molto vicino a quello di un buon tecnico di supporto umano — con il vantaggio di poter tenere insieme, senza fatica, decine di log, comandi e fonti diverse nello stesso filo del ragionamento.