Voice AI e TTS sovrani per il settore pubblico europeo

Nota sull'ambito. “Sovrano” non è una certificazione giuridica. I requisiti di sicurezza, accessibilità, appalti, conservazione documentale e protezione dei dati dipendono dall'amministrazione, dallo Stato membro, dal caso d'uso e dalla classificazione delle informazioni.

Punti chiave

• Valutate il servizio completo: telefonia, riconoscimento vocale, orchestrazione, fonti di conoscenza, TTS, log, supporto, aggiornamenti e uscita. Un fornitore UE o un container TTS self-hosted non rendono conforme o sovrana quella catena.
• Documentate una base giuridica e una finalità per ogni trattamento. Le amministrazioni pubbliche si basano di norma su un obbligo legale o su un compito di interesse pubblico fondato nel diritto dell'Unione o dello Stato membro, non sul consenso per impostazione predefinita.
• Non registrate le chiamate solo perché la piattaforma lo consente. Distinguete il trattamento audio transitorio dalla registrazione, dichiarate la finalità, verificate la normativa nazionale sulle comunicazioni e assegnate una regola di conservazione a ogni classe di dati.
• Gli obblighi di trasparenza dell'articolo 50 dell'AI Act si applicano dal 2 agosto 2026. Un servizio vocale completo può inoltre essere ad alto rischio per ciò che fa, ma il TTS non è ad alto rischio per il solo fatto che lo usi un'amministrazione pubblica.
• Testate l'accessibilità come percorso end-to-end del cittadino. Il trasferimento a un operatore e un canale alternativo non vocale equivalente richiedono orari, limiti di attesa e responsabilità definiti.
• Scrivete i bandi come risultati misurabili con evidenze, rimedi e una prova di uscita. Evitate marchi, nazionalità e slogan sul “cloud europeo” come sostituti dei requisiti tecnici.

Ultimo aggiornamento: 10 agosto 2026. Questa guida è una checklist di appalto e progettazione, non consulenza legale né un accreditamento di sicurezza.

Che cosa richiede una voice AI sovrana per il settore pubblico?

Partite dagli obiettivi di controllo, non da un'etichetta di hosting. Un'amministrazione deve sapere chi può accedere a ciascun componente, quali entità giuridiche e giurisdizioni sono coinvolte, che cosa esce dalla rete approvata, come arrivano gli aggiornamenti e come il servizio prosegue o si conclude quando un fornitore non è disponibile.

Mappate almeno telefonia, speech-to-text, modello linguistico o motore di regole, fonti di retrieval, identità, TTS, osservabilità, registrazioni, backup, supporto remoto, distribuzione del software, verifiche di licenza e strumenti di gestione degli incidenti. Per ogni collegamento, registrate le classi di dati, la finalità, chi lo opera, l'ubicazione, la cifratura e il titolare delle chiavi, la conservazione e le connessioni in uscita consentite.

Classificate i percorsi separatamente. Leggere gli orari di apertura non equivale a discutere la domanda di prestazione sociale di una persona identificata. Per ogni percorso, approvate le informazioni ammesse, il livello di autenticazione, le azioni, la registrazione di audit richiesta, l'obiettivo di disponibilità, il fallback e se sia consentito un trattamento esterno.

Quali decisioni GDPR vanno messe agli atti di progetto?

Il GDPR si applica quando il servizio tratta dati personali; input parlato, trascrizioni, identificativi dei chiamanti e log possono rientrarvi tutti. La maggior parte delle pubbliche amministrazioni tratta dati in forza di un obbligo legale o di un compito di interesse pubblico o connesso all'esercizio di pubblici poteri, e quella base deve essere fondata nel diritto dell'Unione o dello Stato membro. Il legittimo interesse di cui all'articolo 6(1)(f) non si applica ai trattamenti effettuati dalle autorità pubbliche nell'esecuzione dei loro compiti.

Prima dell'appalto, il titolare del trattamento dovrebbe documentare:

• la finalità e la base dell'articolo 6 per ciascun percorso, oltre a una condizione dell'articolo 9 per le categorie particolari di dati, ove pertinente;
• i ruoli di titolare, responsabile ed eventuale contitolare per ogni fornitore;
• i campi di input minimi e se il livello TTS abbia effettivamente bisogno di nomi, identificativi o dell'intero contesto della pratica;
• le condizioni per il responsabile ai sensi dell'articolo 28, le modifiche dei subresponsabili, i controlli di accesso, la sicurezza, l'assistenza in caso di incidente, la cancellazione, le evidenze di audit e i trasferimenti internazionali;
• informative sulla privacy che funzionino in audio e in una forma scritta accessibile;
• se il trattamento possa presentare un rischio elevato e richieda quindi una valutazione d'impatto ai sensi dell'articolo 35;
• se il servizio completo assuma decisioni unicamente automatizzate con effetti giuridici o similmente significativi, il che richiede una specifica analisi ai sensi dell'articolo 22.

Il TTS di norma pronuncia testo selezionato da un altro componente; non ha bisogno di ricevere il fascicolo né di decidere il diritto a una prestazione. Inviate al sintetizzatore l'enunciato approvato più breve possibile e mantenete la logica decisionale nel sistema che possiede le regole, la revisione e il percorso di ricorso pertinenti. I trattamenti a fini di contrasto possono rientrare nella Direttiva sulla protezione dei dati in ambito penale e nella normativa nazionale di attuazione anziché nel GDPR, quindi richiedono una valutazione separata.

Quando può un'amministrazione registrare e conservare una chiamata?

Il trattamento in tempo reale non equivale a conservare una registrazione. Un servizio può bufferizzare l'audio quanto basta a trasmetterlo o sintetizzarlo senza creare una registrazione riutilizzabile della chiamata. Se l'amministrazione vuole registrazioni a fini probatori, di controllo qualità, antifrode o di miglioramento dei modelli, trattate ciascuna come una finalità distinta e stabilite se la registrazione sia consentita prima di attivarla.

La Direttiva ePrivacy impone agli Stati membri di tutelare la riservatezza delle comunicazioni e riconosce alcune registrazioni legalmente autorizzate nell'ambito di prassi commerciali lecite. Non crea un permesso generalizzato per i numeri verdi pubblici. Verificate l'attuazione nazionale, le regole di settore, le norme sul controllo dei lavoratori e i limiti di diritto penale. Un avviso vocale favorisce la trasparenza ma non fornisce di per sé una base giuridica.

Usate una matrice di conservazione invece di un'unica impostazione per i “dati di chiamata”:

Gli obblighi di pubblicità e archiviazione possono imporre la conservazione della decisione o della comunicazione finale. Non giustificano automaticamente la conservazione di ogni prompt, trascrizione intermedia, buffer audio o log di debug. Fate approvare la matrice da chi gestisce gli archivi, dal DPO, dalla sicurezza e dal responsabile del servizio.

Che cosa richiede l'AI Act europeo a un servizio vocale pubblico?

Classificate il sistema completo in base alla finalità prevista secondo l'AI Act europeo. Un componente TTS che converte in audio un testo approvato non è automaticamente ad alto rischio. Un sistema più ampio può rientrare in una categoria dell'allegato III, per esempio perché valuta l'accesso a prestazioni pubbliche essenziali oppure perché è usato in determinati contesti di contrasto, migrazione, giustizia o processi democratici. L'obbligo di alfabetizzazione all'IA dell'articolo 4 si applica dal 2 febbraio 2025, quindi definite la formazione necessaria per operatori, revisori, personale di servizio e team di gestione degli incidenti.

Gli orientamenti sulla trasparenza dell'articolo 50 si applicano dal 2 agosto 2026. I fornitori di sistemi destinati a interagire direttamente con le persone devono progettarli in modo che le persone siano informate di interagire con un'IA, a meno che ciò non sia evidente. Gli orientamenti della Commissione indicano che l'informativa deve essere chiara, distinguibile, accessibile e fornita fin dall'inizio della prima interazione. L'amministrazione dovrebbe rendere quell'informativa parte di un test di accettazione e assicurarsi che la configurazione non possa rimuoverla in silenzio.

L'articolo 50 disciplina anche la marcatura leggibile a macchina dell'audio sintetico. È un obbligo del fornitore, e i sistemi immessi sul mercato prima del 2 agosto 2026 beneficiano di una transizione limitata per questo obbligo fino al 2 dicembre 2026 ai sensi del Regolamento (UE) 2026/1744. Non confondete la marcatura leggibile a macchina con l'obbligo di informativa visibile o udibile che grava sul deployer in caso di deepfake: una narrazione sintetica ordinaria non è necessariamente un deepfake, mentre può esserlo un audio realizzato per assomigliare a una persona o a un evento reali.

La stessa modifica del 2026 ha spostato al 2 dicembre 2027 l'applicazione dei principali obblighi del capo III per i sistemi ad alto rischio dell'allegato III. Quando quelle regole si applicheranno, un'amministrazione che utilizza il sistema potrà avere obblighi di registrazione, logging, sorveglianza umana, informazione delle persone interessate e valutazione d'impatto sui diritti fondamentali. L'appalto dovrebbe procurarsi fin d'ora le evidenze necessarie a quegli obblighi, ma non dovrebbe etichettare per default ogni voice bot come “ad alto rischio”.

Quali regole e test di accessibilità sono rilevanti?

La Direttiva sull'accessibilità del web riguarda i siti web e le applicazioni mobili del settore pubblico. Richiede dichiarazioni di accessibilità e meccanismi di feedback e di applicazione; la Commissione individua nella EN 301 549 la norma armonizzata a supporto della conformità. Una linea telefonica a sé stante non è automaticamente un sito web o un'app mobile, ma i controlli web o app del servizio vocale restano nel perimetro.

La direttiva europea sull'accessibilità si applica a prodotti e servizi specificati dal 28 giugno 2025, fatte salve le sue regole transitorie. Comprende le comunicazioni elettroniche e alcuni servizi bancari al consumo, di trasporto e di e-commerce, ma non rende ogni flusso telefonico di un'amministrazione un servizio soggetto alla direttiva. Determinate il perimetro in base alla normativa nazionale di attuazione e alle altre regole applicabili su disabilità, parità e servizi pubblici.

Indipendentemente dalla fonte dell'obbligo, testate il percorso reale con persone che hanno esigenze diverse di accesso uditivo, verbale, cognitivo, motorio e visivo:

• comunicate l'uso dell'IA, la registrazione e le informazioni sulla privacy a un ritmo comprensibile, con un'opzione di ripetizione e un equivalente scritto accessibile;
• supportate “ripeti”, “indietro”, la correzione, la conferma prima delle azioni con conseguenze e timeout adeguati;
• offrite un'alternativa come DTMF, testo in tempo reale, web, servizio di relay o un canale con operatore, quando serve, senza costringere il chiamante a ricominciare;
• definite gli orari del trasferimento a un operatore, l'attesa massima, il contesto trasmesso all'operatore e che cosa succede fuori orario;
• testate nomi, date, importi, indirizzi, numeri di riferimento, abbreviazioni e termini ufficiali con madrelingua per ogni lingua supportata;
• misurate i tassi di completamento del compito e di errore grave per lingua ed esigenza di accesso, non solo la naturalezza su un campione registrato in studio.

La pronuncia regionale può migliorare la comprensione, ma una voce dialettale non è di per sé un presidio di accessibilità. Non deducete mai identità, diritto a una prestazione, competenza o rischio di frode dall'accento, dal dialetto, da un disturbo del linguaggio o dalla qualità del riconoscimento.

Che cosa deve chiedere un bando pubblico?

Ai sensi dell'articolo 42 della Direttiva sugli appalti pubblici, le specifiche tecniche devono consentire pari accesso ed evitare ostacoli ingiustificati; i riferimenti a una marca, a una fonte o a un'origine richiedono di norma una motivazione e la formula “o equivalente”. Indicate risultati funzionali ed evidenze invece di imporre un fornitore specifico o un indefinito “cloud sovrano europeo”.

Richiedete almeno:

• un diagramma dei componenti e dei flussi di dati che mostri ubicazioni, entità giuridiche, subresponsabili, amministratori, supporto remoto, telemetria, percorsi di aggiornamento e licenza, backup e ogni connessione in uscita;
• architettura di sicurezza, software bill of materials, firma e provenienza delle immagini, gestione delle vulnerabilità, obiettivi di patching e rollback, revisione degli accessi, notifica degli incidenti, test di ripristino e assurance indipendente adeguata alla classificazione dell'amministrazione;
• ruoli privacy, istruzioni di trattamento, meccanismo di trasferimento ove necessario, assistenza agli interessati, controlli di conservazione ed evidenze di cancellazione;
• test del percorso accessibile, la norma applicabile e le regole nazionali, scadenze di rimedio esplicite e un fallback umano e non vocale già provato;
• un set di test di proprietà dell'amministrazione che copra le lingue approvate, numeri, date, acronimi, indirizzi e terminologia giuridica, con soglie di superamento e output grezzi conservati come evidenza di gara;
• test di carico, failover, funzionamento degradato e ripristino sulla topologia prevista, oltre a conseguenze chiare per i criteri di accettazione non superati;
• provenienza e diritti sulla voce, approvazione per i dati di voci personalizzate, controlli di accesso, risposta agli abusi e un processo di revoca;
• formati di esportazione, documentazione delle interfacce, titolarità di configurazioni e dizionari, supporto alla transizione, scadenze di cancellazione e diritti post-contrattuali su immagini, licenze e aggiornamenti di sicurezza necessari.

Quando un appalto fissa requisiti vincolanti che incidono sull'interoperabilità transfrontaliera di un servizio pubblico digitale transeuropeo, verificate se il Regolamento Europa interoperabile imponga una valutazione di interoperabilità. Anche quando non la impone, preferite API documentate, formati di esportazione aperti, dizionari e prompt portabili, identificativi stabili e schemi di evento che l'amministrazione possa trasferire a un altro fornitore.

Che cosa rende credibile un piano di uscita?

Provatelo davvero. Durante il pilota, esportate una configurazione e un dizionario di pronuncia di esempio, instradate un percorso di test verso un endpoint sostitutivo, ripristinate i documenti richiesti, revocate gli accessi del fornitore e verificate la cancellazione dei contenuti di prova. Registrate il tempo impiegato, i passaggi manuali, gli artefatti mancanti e le licenze residue.

Il contratto deve indicare chi possiede numeri di telefono, registrazioni e diritti delle voci personalizzate, dizionari, prompt, log e dati di valutazione. Deve inoltre definire il supporto alla transizione, il formato di restituzione dei dati, le evidenze di cancellazione e se l'amministrazione possa continuare a usare l'ultima immagine approvata durante la migrazione. “API standard” e “portabilità dei dati” non sono criteri di accettazione finché il trasferimento non riesce davvero.

Dove si colloca KugelAudio in uno stack vocale sovrano?

KugelAudio fornisce TTS, non telefonia, riconoscimento vocale, gestione delle pratiche o la policy che determina l'esito per il cittadino. La sua documentazione offre un endpoint diretto nell'UE e un deployment self-hosted distribuito per Kubernetes tramite un Helm chart. Sono opzioni di deployment, non la prova che il servizio completo sia conforme o privo di dipendenze esterne.

Per un bando reale, verificate la regione di hosting esatta e le condizioni contrattuali e sui subresponsabili in vigore. Per il self-hosting, esaminate chart e immagini forniti, i requisiti di rete in uscita, il comportamento delle licenze, la telemetria, gli accessi del supporto, il processo di aggiornamento, la titolarità dei backup e il funzionamento senza il fornitore. Interrogate i modelli e le voci disponibili sull'endpoint che verrà effettivamente distribuito, invece di affidarvi a un numero riportato nel materiale di marketing.

Quando l'on-premise non è la scelta sovrana?

Il self-hosting sposta le responsabilità. Se l'amministrazione o il suo operatore approvato non è in grado di applicare patch ai nodi GPU, monitorare la capacità, ruotare le credenziali, rispondere agli incidenti e ripristinare il servizio, un ambiente gestito dedicato con controlli esigibili può offrire un controllo pratico migliore. Confrontate entrambe le architetture con gli stessi test di classificazione, ripristino, supporto, accessibilità e uscita.

Quali sono i limiti di questa guida?

Questo articolo non determina una classificazione ai sensi dell'AI Act, una base giuridica, una procedura di gara, l'ambito di applicazione delle regole di accessibilità o un'approvazione di sicurezza. Non fornisce punteggi dialettali di KugelAudio, report di conformità all'accessibilità, prove di cancellazione o accreditamenti per il settore pubblico. Procuratevi quegli artefatti per la versione, l'endpoint, le lingue e la topologia di deployment previsti.

FAQ

Che cos'è una voice AI sovrana?

È un sistema le cui dipendenze tecniche, giuridiche e operative soddisfano gli obiettivi di controllo documentati dall'amministrazione. L'hosting nell'UE può contribuire a quegli obiettivi, ma la sola ubicazione non stabilisce sovranità né conformità.

Il TTS per il settore pubblico può girare on-premise?

Sì. KugelAudio documenta un deployment su Kubernetes concordato con il team commerciale e basato su un Helm chart. L'amministrazione deve comunque approvare la catena di fornitura delle immagini, i percorsi di licenza e aggiornamento, le connessioni in uscita, il modello operativo e il resto dello stack vocale.

Il TTS on-premise significa che i dati dei cittadini non vengono mai conservati?

No. Permette all'operatore di controllare l'ambiente TTS, ma log, registrazioni, cache, backup, telemetria e altri componenti possono comunque conservare dati. Verificate l'intero percorso dei dati e il comportamento di cancellazione con un record di prova.

KugelAudio è un fornitore TTS tedesco?

Il sito di KugelAudio indica una società tedesca. La sede è solo uno degli elementi di due diligence: confermate l'entità contraente, l'assetto proprietario, i subresponsabili, le sedi del supporto, la legge applicabile e i flussi tecnici dei dati nei documenti contrattuali in vigore.

L'AI Act europeo impone a un voice bot pubblico di dichiararsi tale?

L'articolo 50 si applica dal 2 agosto 2026. Per i sistemi di IA destinati a interagire direttamente con le persone, il fornitore deve progettare il sistema in modo che le persone siano informate, a meno che l'interazione non sia evidente; gli orientamenti della Commissione richiedono un'informativa chiara e accessibile fin dall'inizio della prima interazione.

Ogni voice bot del settore pubblico è un sistema di IA ad alto rischio?

No. La classificazione dipende dalla finalità prevista e dal sistema completo, non dalla natura pubblica del cliente né dall'uso del TTS. I sistemi impiegati per determinate funzioni relative a prestazioni essenziali, contrasto, migrazione, giustizia o processi democratici richiedono una specifica valutazione ai sensi dell'allegato III.

L'hosting nell'UE basta per un appalto pubblico?

No. Un bando può richiedere requisiti misurabili di sicurezza, privacy, accessibilità, interoperabilità, continuità, supporto, conservazione e uscita. L'ubicazione nell'UE va tradotta in controlli precisi su flussi di dati e giurisdizione e testata come ogni altro requisito.