Il momento in cui lo screenshot cambia mestiere

Per anni abbiamo chiesto agli utenti di allegare uno screenshot e poi abbiamo trattato quell’immagine come una fotografia da aprire manualmente. Il 10 settembre 2026 ServiceNow ha documentato una novità significativa per il proprio AI Specialist: la capacità di aprire e comprendere file allegati alla richiesta, inclusi screenshot, PDF e log, utilizzandoli nella risposta. È un passaggio piccolo da descrivere e grande da governare.

Lo screenshot smette di essere soltanto un allegato. Diventa un input operativo: contiene un codice di errore, la versione dell’applicazione, il nome del tenant, l’orario, forse un dato personale o un’informazione che l’utente non sapeva di avere condiviso. L’agente può ricavarne contesto prima di formulare un’altra domanda e, nei casi più semplici, evitare il ping-pong che rallenta dipendente e operatore.

Non significa che ogni immagine venga interpretata correttamente o che la funzione sia disponibile in ogni configurazione. La novità documentata è un segnale di direzione: il Service Desk entra in una fase multimodale, nella quale testo, immagini e documenti concorrono alla diagnosi. Il valore non sarà nel leggere più file, ma nel trasformarli in evidenze controllate.

RiferimentiServiceNow — Now Assist Suite release notes, 10 settembre 2026 ↗

Meno domande, se il contesto è davvero utilizzabile

Un allegato ben interpretato può accorciare il percorso. Se l’immagine mostra “accesso negato”, l’agente può distinguere un problema di credenziali da un’autorizzazione mancante. Se il PDF contiene una ricevuta di installazione, può evitare di chiedere quale pacchetto sia stato distribuito. Se il log riporta una correlazione temporale, può collegarla a un evento noto. La conversazione diventa più naturale perché la persona non deve tradurre in parole tutto ciò che vede.

Ma una riduzione delle domande non deve diventare un aumento delle supposizioni. Un codice letto male, una schermata ritagliata o un log riferito a un’altra sessione possono portare a una diagnosi credibile e sbagliata. L’agente dovrebbe separare ciò che ha osservato da ciò che ha dedotto: “vedo il codice X” è diverso da “la causa è Y”. Quando la decisione produce un’azione, la prova deve essere sufficiente e verificabile.

Per questo aggiungerei alle metriche tradizionali tre indicatori: percentuale di richieste in cui l’allegato evita almeno un follow-up; accuratezza dell’estrazione su un campione controllato; quota di azioni bloccate perché l’evidenza era ambigua. L’obiettivo non è premiare l’agente che parla meno, ma quello che usa meglio il contesto senza aumentare riaperture ed errori.

L’allegato è anche una superficie d’attacco

Il file caricato da un utente non è automaticamente attendibile. Può avere un’estensione ingannevole, un Content-Type contraffatto, contenuto attivo o dimensioni progettate per saturare risorse. La guida OWASP sul file upload raccomanda difese stratificate: consentire solo estensioni necessarie, validare tipo e firma, rinominare i file, imporre limiti, conservare fuori dal webroot e usare antivirus, sandbox o Content Disarm and Reconstruction quando appropriato.

Con l’AI compare un rischio ulteriore. Dentro un PDF o un’immagine può esserci testo che tenta di influenzare l’agente: istruzioni, dati falsi o contenuti non pertinenti presentati come autorevoli. Un parser sicuro protegge il sistema dal file; non basta però a proteggere la decisione dal significato del file. Il contenuto dell’allegato deve restare dato non fidato, mai comando privilegiato.

Il modello operativo dovrebbe quindi prevedere una zona di quarantena, estrazione in ambiente isolato, etichetta di provenienza, controllo antivirus e una policy sugli strumenti che l’agente può invocare dopo la lettura. Una schermata può suggerire una soluzione; non deve da sola autorizzare un reset, una modifica dei permessi o l’esecuzione di codice.

RiferimentiOWASP — File Upload Cheat Sheet ↗

Privacy: leggere di più non autorizza a vedere tutto

Uno screenshot di assistenza può mostrare email, chat, cartelle, numeri di pratica o dati HR. Un log può contenere identificativi, token o percorsi personali. Quando l’AI amplia la capacità di lettura, deve restringersi il perimetro di accesso. Le stesse note ServiceNow richiamano protezioni specifiche per informazioni provenienti dai casi HR, visibili soltanto agli amministratori autorizzati.

Il principio manageriale è la minimizzazione. Prima dell’analisi si può oscurare ciò che non serve, estrarre soltanto i campi necessari e applicare una retention coerente con il caso. L’identità dell’agente, il servizio, la finalità e gli strumenti utilizzati devono essere registrati. Chi verifica l’operato deve poter ricostruire quale allegato ha influenzato quale conclusione, senza distribuire copie incontrollate.

Il NIST AI Risk Management Framework insiste su governance, misurazione e gestione continua del rischio. Applicato al ticket multimodale, significa inventariare tipi di dati e possibili danni, testare il comportamento su casi rappresentativi, monitorare errori e definire chi può sospendere l’elaborazione. Il consenso dell’utente a caricare un file non equivale a un consenso illimitato al suo riuso.

RiferimentiNIST — AI Risk Management Framework e Playbook ↗

Dall’allegato alla catena di evidenza

Per rendere affidabile il processo serve una catena di evidenza semplice. Il file originale riceve un identificatore e resta immutabile; l’estrazione conserva pagina, area o riga di provenienza; l’agente registra osservazione, confidenza e decisione; l’azione finale produce una verifica. Se un operatore corregge l’interpretazione, quella correzione alimenta il miglioramento senza alterare retroattivamente la storia del caso.

Non occorre mostrare tutto questo al dipendente. A lui basta sapere che l’allegato è stato ricevuto, quali informazioni utili sono state riconosciute e se deve confermare qualcosa. L’operatore, invece, deve vedere il collegamento tra evidenza e proposta, non una sintesi opaca. Il service owner ha bisogno di una vista aggregata: tipi di file, errori di estrazione, dati sensibili rilevati, tempo risparmiato e incidenti evitati.

Partirei con tre intenti ad alto volume e basso rischio, per esempio errori applicativi noti, installazioni software e problemi di connessione. Creerei un set di allegati anonimizzati, includendo immagini sfocate, PDF lunghi e log rumorosi. Prima del rilascio misurerei estrazione, diagnosi, sicurezza e qualità del passaggio umano. Solo dopo allargherei il perimetro.

La scelta manageriale: automazione o prova verificabile?

Un progetto multimodale può essere venduto come acceleratore della risoluzione. La domanda più utile è diversa: quali decisioni diventano più verificabili grazie agli allegati? Se la risposta è soltanto “l’agente chiude più ticket”, manca la parte importante. Occorre sapere quali domande vengono eliminate, quali dati vengono protetti, quando l’agente si ferma e come una persona può contestare la lettura.

Nei prossimi trenta giorni farei una baseline su cento ticket con allegati. Conterei follow-up, tempo di analisi manuale, dati sensibili visibili e percentuale di allegati realmente utili. Poi sperimenterei l’AI su un campione controllato, senza azioni autonome, confrontando le osservazioni con quelle degli operatori. Il primo risultato atteso non è il full automation: è una triage più ricca, rapida e trasparente.

Il futuro del Service Desk non è chiedere all’utente di descrivere meglio lo schermo. È imparare a leggere ciò che condivide, senza dimenticare che ogni immagine è contemporaneamente un aiuto, un dato e una responsabilità.

Fonti e approfondimenti

Analisi e interpretazioni sono personali e non rappresentano le posizioni delle organizzazioni citate o del mio datore di lavoro.

Ti è stato utile?Lascia un segno, basta un clic.0 persone hanno apprezzato