“Sta scendendo acqua dal soffitto. Posso aspettare domani?”
Per un’automazione generica sembra una normale richiesta di servizio: nome, indirizzo, telefono e appuntamento. Per un idraulico, un elettricista, un tecnico HVAC o una ditta di manutenzione, la domanda decisiva è diversa: l’assistente ha davvero abbastanza informazioni per continuare senza prendere una decisione tecnica che non gli compete?
È qui che una Voice AI ha bisogno di un confine d’emergenza.
Il framework NIST considera il rischio anche in funzione della gravità delle possibili conseguenze. Tradotto in pratica per una PMI: quando un errore può avere un impatto molto più serio, l’autonomia dovrebbe diminuire. Non è una norma svizzera specifica per l’artigianato; è un principio prudente di progettazione.
Il confine viene prima della diagnosi
Molti pilot partono da un prompt troppo aperto: “aiuta il cliente nel miglior modo possibile”. L’assistente ha accesso alle FAQ, al calendario e magari a una lista del servizio di picchetto. In demo sembra capace di gestire qualsiasi conversazione.
Il problema nasce quando da poche frasi prova a dedurre la causa tecnica.
Un ruolo più sicuro è più limitato: raccogliere, classificare, escalare.
L’IA può registrare ciò che il cliente osserva: acqua vicino al soffitto, interruttore che scatta, riscaldamento fermo, odore insolito, rumore. Può chiedere indirizzo, numero di richiamata, accesso all’immobile e quando è iniziato il problema.
Non dovrebbe invece inventare una diagnosi remota, rassicurare che “può aspettare fino a domani” o proporre istruzioni tecniche non approvate dall’azienda.
NIST AI RMF e il profilo per la Generative AI propongono metodi strutturati per identificare e gestire i rischi dell’IA. Anche la Convenzione quadro del Consiglio d’Europa mette al centro affidabilità e responsabilità.
Raccomandazione dell’autore: quando una possibile situazione critica rimane incerta, l’incertezza stessa può essere un trigger di escalation. È una scelta operativa conservativa, non un obbligo legale universale.
Quattro stati sono sufficienti per partire bene
Non serve un albero decisionale enorme. Per un primo pilot bastano quattro stati definiti internamente.
| Stato | Esempio | Comportamento dell’assistente |
|---|---|---|
| Routine | preventivo, manutenzione, appuntamento | raccoglie dati e continua il flusso normale |
| Urgente | impianto fuori servizio, attività bloccata | priorità e regola di picchetto |
| Possibile emergenza | acqua, elettricità, gas o trigger approvato | niente diagnosi libera; passa al percorso d’emergenza |
| Non chiaro | descrizione non classificabile con sicurezza | handover invece di una risposta troppo sicura |
I trigger devono essere definiti dall’azienda. Un elettricista avrà criteri diversi da un installatore sanitario o da una ditta di refrigerazione. Il responsabile tecnico o operativo deve decidere quali segnali fanno uscire la chiamata dal percorso automatizzato.
Il modello può riconoscere modi diversi di esprimere lo stesso problema. Non dovrebbe inventare la policy.
L’handover deve funzionare anche alle 23:40
“Le passo un collega” non serve a nulla se nessuno risponde.
Durante il picchetto può essere previsto un trasferimento live. Altrove può funzionare meglio un callback prioritario, un alert al tecnico di turno o una coda urgente realmente monitorata.
La persona che prende in carico il caso deve ricevere il contesto: nome, numero confermato, indirizzo, sintomo osservato, momento in cui è iniziato, risposte già raccolte e motivo dell’escalation.
Anche la promessa al cliente deve essere precisa. “Il tecnico arriva tra venti minuti” è accettabile solo se quella disponibilità è stata davvero confermata. In caso contrario l’assistente dice ciò che sa: la richiesta è stata classificata come urgente e inoltrata al servizio competente.
Una voce naturale rende credibile anche una frase sbagliata. Per questo la precisione sullo stato del caso è parte della sicurezza.
I casi reali sono vaghi, rumorosi e spesso multilingue
“C’è un odore strano.” “La scatola fa rumore.” “Lampeggia una luce.” Il cliente può essere stressato e non conoscere il nome dell’impianto.
Un sistema debole prova a compensare con dieci domande tecniche. Un sistema migliore fa poche domande semplici e riconosce quando non sta riducendo abbastanza l’incertezza.
In Svizzera si aggiungono dialetti e cambi di lingua. Una chiamata può iniziare in tedesco standard, passare allo svizzero tedesco e contenere un toponimo francese. La qualità audio può essere scarsa. Un singolo confidence score della trascrizione non dovrebbe quindi decidere se un caso è sicuro.
Conviene combinare più segnali: contenuto della segnalazione, presenza di trigger, contraddizioni, tentativi di chiarimento falliti e conseguenza potenziale.
C’è poi un’eccezione importante: anche un tecnico umano non sempre può capire tutto a distanza. Il workflow deve poter mantenere lo stato “non chiaro” senza forzare una conclusione comoda per il CRM.
Pilot minimo: automatizzare l’intake, non la competenza tecnica
Il primo progetto non dovrebbe essere “l’IA gestisce il pronto intervento”. Dovrebbe verificare se l’IA raccoglie bene i fatti e passa i casi sensibili alla persona giusta.
- Raccogliere 30–50 esempi anonimizzati di chiamate di routine, urgenti e ambigue.
- Far definire categorie e wording a una persona tecnicamente responsabile.
- Limitare l’IA a fatti osservabili, contatti, indirizzo e poche domande approvate.
- Eliminare diagnosi libere e istruzioni tecniche non validate.
- Testare dialetto, rumore, interruzioni, risposte contraddittorie e descrizioni vaghe.
- Verificare davvero il percorso di handover fuori orario.
Le metriche utili sono casi critici di test correttamente escalati, falsi negativi, escalation inutili, tempo fino alla presa in carico umana, completezza del contesto passato e numero di affermazioni tecniche non autorizzate generate dall’IA.
Non ottimizzate per avere pochissimi handover. Un sistema che non passa mai la chiamata a una persona potrebbe semplicemente trattenere casi che non dovrebbe gestire.
La conclusione pratica: per un’azienda artigiana, la Voice AI migliore non è quella che trova sempre una risposta. È quella che gestisce bene la routine, riconosce la propria zona di incertezza e restituisce la responsabilità a un professionista quando il rischio lo richiede.
Testate esempi chiari e ambigui, accenti e rumore. Nel dubbio meglio trasferire che rassicurare. Il passaggio umano include il segnale rilevato.
Fonti
- NIST — AI Risk Management Framework 1.0
- NIST — Generative AI Profile
- Council of Europe — Framework Convention on AI
- OpenAI — Introducing GPT-Live
Per gli interventi una casella libera non basta. La guida alla pianificazione con trasferte e capacità aggiunge viaggio, competenze, materiali e margine prima della conferma.
FAQ
Chi decide cosa è un’emergenza?
L’azienda, con un responsabile competente per i propri servizi. Una lista generica generata da IA non sostituisce la validazione tecnica.
L’IA può dare istruzioni immediate?
Solo se quel wording è stato verificato e approvato per quello specifico scenario. La diagnosi aperta non dovrebbe essere il default.
Cosa succede se di notte non c’è nessuno?
Serve un fallback reale: picchetto, callback prioritario o comunicazione trasparente che non è possibile promettere un intervento immediato.
Ogni caso poco chiaro va escalato?
No. Ma se una condizione potenzialmente seria non può essere esclusa con il flusso approvato, un’escalation prudente è ragionevole.
Chi deve approvare il confine d’emergenza?
Una persona tecnicamente responsabile dell’azienda. Per aspetti legali o di responsabilità, va coinvolta la consulenza professionale appropriata.