Sicurezza del canale voce: rete, telefonia e dati sensibili

La sicurezza del canale voce si gioca su tre piani che l’esame tende a mescolare.

Il primo è il perimetro di rete. La pagina di best practice del voice channel (documentata sotto Customer Service ma dichiarata valida per Dynamics 365 Contact Center embedded, standalone e Dynamics 365 Customer Service) chiede di aggiungere in allowlist gli URL e gli indirizzi IP necessari alla comunicazione con i server Omnichannel e di allineare la configurazione del firewall alle linee guida di Azure Communication Services. Nella stessa area geografica la latenza di rete resta di norma sotto i 150 ms, e i telemetry insights servono proprio a capire da dove arrivano i ritardi.

Il secondo è la telefonia. Portare il proprio SIP trunk via direct routing di Azure Communication Services o di Teams preserva il contesto SIP (caller ID, intent, token di autenticazione); usare numeri Microsoft calling plan semplifica provisioning e compliance ma quel contesto può essere rimosso dai vettori PSTN fuori dalla rete Microsoft. È una scelta di architettura, non un dettaglio: se il flusso dipende dagli header SIP, la seconda opzione non va bene.

Il terzo è il dato sensibile. In Copilot Studio si marca una variabile con il toggle Sensitive data nelle Variable properties. A runtime l’AI agent segnala nella trascrizione “Entered a confidential section of the conversation”, sospende registrazione, trascrizione e logging, e per non alterare la durata del file inserisce silenzio nella registrazione; poi segnala l’uscita dalla sezione confidenziale e la ripresa. Se la conversazione viene escalata a un representative, trascrizione e registrazione non contengono quelle informazioni. Servono i ruoli System administrator e Bot author.

Qui sta la confusione tipica da evitare: il flag non è una rete universale. Non c’è redazione quando si scrive esplicitamente in Dataverse, quando il valore passa in un nodo di transfer, quando finisce all’AI generativa, o in un log custom di Application Insights. E l’impostazione Log sensitive properties (Settings, Advanced, Application Insights) va lasciata spenta, altrimenti le variabili sensibili finiscono nella telemetria.

Compliant call recording: due interruttori indipendenti

Registrazione e trascrizione si configurano nel Copilot Service admin center: si apre il workstream, si va su Phone number, Edit, scheda Behaviors, sezione Transcription and recording. Il menu Transcript and recording offre Transcription oppure Transcription and recording; Start setting vale Automatic o Manual; poi ci sono Allow customer service representatives to pause and resume e Allow automatic pause and resume when agent hold and un-hold the customer. Esiste anche un toggle di audio recording a livello tenant: se è spento, non si registra nulla, qualunque cosa dica il workstream.

Il consent-based recording è un’altra cosa e si costruisce in Copilot Studio: si usa il topic User Consent (fornito come esempio, da adattare ai propri requisiti) e lo si richiama dal system topic Conversation Start con un nodo Go to another topic. Nell’admin center si attiva poi Request for User Consent sotto Transcription and recording. Vincolo importante: è supportato solo per workstream voce inbound a cui è associato un voice-enabled agent, non per le chiamate outbound.

Che cosa verifica l’esame su questo punto: che i due interruttori siano indipendenti. Attivare Request for User Consent non fa da solo comparire la richiesta; se il topic non è configurato, tutti i clienti risultano “opted in” e la chiamata viene comunque registrata. Anche il silenzio del chiamante vale come consenso implicito. Trasferimenti e consult ereditano la scelta iniziale, mentre verso una parte non Microsoft fuori da Dynamics 365 Contact Center Microsoft non registra né trascrive. Il prompt di consenso e la risposta vengono conservati in storage gestito da Microsoft, non accessibile al cliente, ed eliminati automaticamente entro due ore.

SIP X-header: contesto in ingresso e in uscita

Gli X-header SIP trasportano metadati fra la piattaforma telefonica esterna e il voice agent, e richiedono Direct Routing.

In ingresso serve un nodo Parse value (Variable management, Parse value) applicato alla variabile di sistema Conversation.SipXHeader, con Data type impostato su From sample data e lo schema definito da Get schema from sample JSON; il risultato va salvato in una variabile di scope Global per essere leggibile da più topic. Limiti: massimo cinque header per chiamata, nome fino a 64 caratteri, valore fino a 256; gli header assenti valgono stringa vuota.

In uscita si usa il nodo Transfer conversation con Transfer type impostato su External phone number transfer — è l’unico tipo di trasferimento supportato — aggiungendo coppie chiave-valore, ancora al massimo cinque.

La confusione tipica: la regola sul maiuscolo non è simmetrica. In ingresso la piattaforma normalizza sempre il prefisso in x- minuscolo, quindi lo schema JSON deve usare il minuscolo anche se il sistema esterno invia X-. In uscita il nome viene spedito esattamente come lo si scrive, quindi si sceglie il case che si aspetta il destinatario.

Real-time e agenti multilingua

Il voice agent real-time (nei sotto-obiettivi chiamato Real-time Speech agent) non è una variante di configurazione del voice agent standard: si sceglie in Settings, Voice, attivando Enable voice e impostando Voice type su Real-time. È una scelta una tantum, non reversibile verso un basic agent. Si seleziona poi il modello — GPT-Realtime, GPT-Realtime-Mini o GPT-5-Chat (Preview), quest’ultimo un modello testuale che sintetizza la risposta con Microsoft Neural TTS, con maggiore latenza ma catalogo voci più ampio e voci custom; le implicazioni regionali dipendono dal deployment type dei modelli in Microsoft Foundry. La sicurezza va su No Authentication.

Le impostazioni vocali sono proprie: le voci (Alloy, Ash, Ballad, Coral, Echo, Sage, Shimmer, Verse, Marin, Cedar) non sono quelle configurate nel Copilot Service admin center, e solo Alloy, Echo, Shimmer e Ash si allineano ai messaggi di sistema di Dynamics. La Speech sensitivity offre VAD server-based (Based on sound (silence), con Threshold, Prefix padding e Silence Duration) o semantica (Based on sentence context, con Eagerness). Attenzione: la Silence detection non è attiva di default e ha timeout predefinito di 7.000 ms. Sul piano dei trigger, On Unknown Intent non è supportato mentre On Error sì, e la best practice è chiuderlo con un’azione esplicita (trasferimento o chiusura), perché un messaggio soltanto lascia il chiamante nel silenzio.

Per il multilingua in Dynamics 365 Contact Center il workstream può avere più canali voce con numeri diversi per lingua, oppure un solo numero che supporta più lingue. L’AI agent deve supportare tutte le lingue del canale: se non c’è corrispondenza ricade sulla propria primary language. Il routing per lingua si fa con il criterio Conversation.CustomerLanguage nel rule set route-to-queues, e le metriche si leggono con il filtro Last Language, che va aggiunto alla dashboard perché non è presente di default. Sugli agenti real-time le stringhe di localizzazione non servono per i flussi generativi, ma i messaggi deterministici dei topic vanno tradotti a mano; e capacità tecnica non significa lingua certificata, quindi le lingue non validate vanno testate prima della produzione.