“Non può farlo semplicemente l'AI?” Ormai sento questa domanda regolarmente. La mia risposta: gran parte del lavoro preparatorio – sì. La decisione finale – no.
Dove l'AI aiuta davvero nel supporto
Lavoro da anni nel supporto di 2° e 3° livello e in parallelo costruisco strumenti di AI miei. Nel lavoro quotidiano tre compiti si sono dimostrati particolarmente utili:
Riassumere log lunghi. Un ticket arriva con diverse migliaia di righe di log. Un modello linguistico può dire in pochi secondi quali errori compaiono per primi e quando, quali si ripetono e quali componenti sono coinvolti. Non sostituisce la lettura del log, ma mostra dove guardare per primo.
Trovare casi simili già visti. Molti problemi si sono già presentati, solo descritti con parole diverse. Una ricerca semantica su articoli della knowledge base e ticket risolti – per esempio con RAG, una ricerca che recupera i documenti pertinenti e li passa al modello come base – li trova anche quando i termini non coincidono.
Preparare una prima bozza di risposta. Struttura, formulazione cortese, i passaggi in un ordine sensato. Il contenuto lo controllo io, ma non parto da una pagina bianca.
Ognuno di questi compiti fa risparmiare solo pochi minuti. Con molti ticket a settimana, si sente.
Dove l'AI arriva al limite
I modelli linguistici sono convincenti anche quando sbagliano. Un comando con un'opzione che non esiste, una chiave di configurazione di un'altra versione, una causa plausibile ma inventata – succede.
Ancora più importante: l'AI non si prende responsabilità. Se basta un workaround o la causa è più profonda, se una modifica a un sistema in produzione è accettabile adesso, se con un cliente è meglio telefonare che scrivere – lo decide ancora una persona che conosce il sistema e la situazione.
Un modello vede solo ciò che gli si dà. Il contesto fuori dal ticket – la manutenzione della settimana scorsa, una particolarità nota di un'installazione, l'umore di un cliente al terzo contatto – non lo conosce.
Le mie regole per l'AI nel supporto
- Fonti, non affermazioni. Le risposte basate su una knowledge base dovrebbero indicare su cosa si fondano. Così si verifica in pochi secondi se sono corrette.
- I comandi si controllano prima di eseguirli. Nessun suggerimento di un modello finisce su un sistema del cliente senza essere letto.
- I dati restano dove devono stare. Log e ticket contengono spesso dati personali. Cosa può vedere un servizio esterno è una questione di protezione dei dati e di regole aziendali, non di comodità. I modelli eseguiti in locale sono un'opzione.
- Il ticket lo chiude una persona. L'AI prepara; della decisione e della risposta al cliente risponde una persona.
Un collega veloce per il lavoro preparatorio
Per me l'AI nel supporto è un collega molto veloce che legge i log, raccoglie appunti e mette sul tavolo una bozza. Instancabile e spesso sorprendentemente bravo. Ma non è lui a chiudere il ticket.
L'analisi della causa lo mostra bene: un modello può individuare anomalie e proporre ipotesi. Se un'ipotesi è giusta si scopre solo quando qualcuno la verifica sul sistema.
Come iniziare
- Scegliere un lavoro preparatorio ricorrente, ad esempio i riassunti dei log.
- Chiarire quali dati si possono elaborare, e dove.
- Per un periodo ricontrollare consapevolmente i risultati.
- Solo dopo affidare altri compiti.
Così la fiducia nello strumento cresce dove è giustificata – insieme a un'idea chiara di dove non lo è.