Voice cloning e audio generati con intelligenza artificiale

Introduzione

Il voice cloning consente di produrre un parlato sintetico che riproduce alcune caratteristiche vocali riconoscibili di una persona.

Il risultato può essere utilizzato per scopi leciti:

• accessibilità;
• doppiaggio;
• assistenza vocale;
• localizzazione;
• intrattenimento;
• restauro della voce;
• sintesi personalizzata autorizzata;
• produzione audiovisiva.

La stessa tecnologia può essere impiegata in modo ingannevole per:

• impersonare un dirigente;
• simulare un familiare in pericolo;
• realizzare una falsa telefonata bancaria;
• produrre un messaggio vocale attribuito a un avvocato;
• inserire parole mai pronunciate in una registrazione;
• costruire una falsa ammissione;
• aggirare procedure basate sulla voce;
• diffondere contenuti diffamatori;
• sostenere una richiesta di pagamento fraudolenta.

Il NIST considera le voci sintetiche uno dei possibili strumenti utilizzabili per facilitare operazioni fraudolente e rappresenta la gestione dei contenuti sintetici come una catena che comprende produzione, pubblicazione, distribuzione e fruizione. Nello stesso quadro, rilevazione tecnica e provenienza sono considerate misure complementari, non alternative assolute. NIST AI 100-4 — Reducing Risks Posed by Synthetic Content

Un cliente di Roma può rivolgersi al perito informatico chiedendo:

«È davvero la voce di mio figlio?»

oppure:

«Questa telefonata è stata generata con l’intelligenza artificiale?»

oppure:

«Il direttore ha realmente autorizzato il bonifico?»

oppure:

«Il vocale WhatsApp è autentico o è stato creato clonando la mia voce?»

La domanda deve essere scomposta.

Occorre distinguere almeno:

1. identità apparente della voce;
2. origine naturale o sintetica del segnale;
3. eventuale trasformazione di una voce reale;
4. presenza di montaggi o sostituzioni parziali;
5. ricodifica introdotta dalla piattaforma;
6. riacquisizione da altoparlante;
7. provenienza del file;
8. account e dispositivo utilizzati;
9. veridicità delle parole;
10. attribuzione della produzione a una persona.

Una voce può sembrare molto simile a quella della persona senza essere stata generata artificialmente: potrebbe trattarsi di un imitatore, di un familiare, di una registrazione precedente o di un frammento autentico decontestualizzato.

Un file può essere sintetico senza imitare una persona reale.

Un messaggio può contenere una voce autentica ma essere montato.

Una frase può essere prodotta sostituendo soltanto poche parole all’interno di una registrazione genuina.

Un audio sintetico può essere riprodotto da un altoparlante e registrato nuovamente, cancellando o attenuando parte delle tracce originarie.

La ricerca ASVspoof 5 mostra che il rilevamento automatico deve affrontare attacchi diversi, codec neurali, condizioni di trasmissione e manipolazioni avversarie; le prestazioni possono degradare quando il materiale esaminato differisce dai dati usati per addestrare o validare il detector. La generalizzazione verso attacchi e condizioni mai osservati resta pertanto una criticità centrale. ASVspoof 5 — analisi del dataset e dei sistemi

Sintesi operativa

1. acquisire il file nella forma più vicina possibile alla fonte;
2. preservare la chat, la telefonata, l’email o la piattaforma;
3. documentare chi ha ricevuto il contenuto e attraverso quale canale;
4. calcolare immediatamente l’hash del reperto;
5. acquisire eventuali versioni alternative;
6. identificare contenitore, codec, stream e metadati;
7. verificare C2PA, watermark o altre informazioni di provenienza;
8. acquisire account, sessioni, dispositivi e log disponibili;
9. creare una copia PCM senza filtri o normalizzazioni;
10. analizzare struttura, pacchetti, waveform e spettrogramma;
11. esaminare prosodia, ritmo, pause, articolazione e transizioni;
12. valutare respirazione, rumore, riverbero, fase e canale;
13. considerare codec, telefonia, messaggistica e ri-registrazione;
14. verificare se il contenuto sia integralmente o parzialmente sintetico;
15. acquisire campioni autentici comparabili e autorizzati;
16. mantenere separati rilevamento sintetico e confronto del parlante;
17. utilizzare detector validati soltanto come una delle fonti;
18. registrare modello, pesi, versione, soglia e preprocessing;
19. verificare generalizzazione, lingua, durata e condizioni del canale;
20. non interpretare lo score come probabilità automatica;
21. confrontare gli esiti di più metodi realmente indipendenti;
22. valutare spiegazioni alternative;
23. distinguere voce sintetica, montaggio, imitazione e riuso;
24. costruire una timeline;
25. indicare sempre i limiti dell’attribuzione personale;
26. produrre una relazione tecnica riproducibile.

1. Avvertenza preliminare

Le procedure descritte devono essere utilizzate esclusivamente:

• su file propri;
• su registrazioni consegnate dal legittimo titolare;
• nell’ambito di un incarico professionale;
• per attività difensive, aziendali o peritali;
• con autorizzazione all’acquisizione delle fonti;
• su copie di lavoro;
• nel rispetto della riservatezza;
• con minimizzazione dei dati.

Non è lecito utilizzare il capitolo per:

• clonare la voce di terzi senza consenso;
• costruire false dichiarazioni;
• impersonare familiari, dirigenti o operatori bancari;
• eludere sistemi di autenticazione;
• accedere ad account o dispositivi di terzi;
• ottenere campioni vocali con inganno;
• intercettare telefonate;
• diffondere registrazioni private;
• addestrare modelli con dati ottenuti illecitamente;
• alterare il reperto originario.

Il perito deve inoltre evitare di caricare registrazioni riservate su detector pubblici senza aver valutato:

• condizioni d’uso;
• conservazione del file;
• riutilizzo del contenuto;
• trasferimenti internazionali;
• proprietà dei dati;
• segreti professionali;
• dati biometrici;
• informazioni sanitarie;
• eventuale presenza di minori.

2. Inquadramento normativo essenziale

2.1 Contenuti vocali falsificati mediante AI

La legge 23 settembre 2025, n. 132, entrata in vigore il 10 ottobre 2025, ha introdotto nel codice penale l’articolo 612-quater. La disposizione riguarda, nei relativi presupposti, la diffusione senza consenso di immagini, video o voci falsificati o alterati mediante sistemi di intelligenza artificiale, idonei a ingannare sulla loro genuinità e capaci di cagionare un danno ingiusto. Gazzetta Ufficiale — legge 23 settembre 2025, n. 132

La qualificazione giuridica non compete al perito informatico.

Il tecnico può documentare:

• caratteristiche del file;
• compatibilità con una generazione sintetica;
• provenienza;
• account;
• diffusione;
• integrità;
• trasformazioni;
• limiti.

Non dovrebbe concludere:

«Il file integra certamente il reato previsto dall’articolo 612-quater.»

2.2 Trasparenza prevista dall’AI Act

Alla data di aggiornamento del capitolo, 14 luglio 2026, gli obblighi di trasparenza dell’articolo 50 dell’AI Act diventeranno applicabili dal 2 agosto 2026.

Il quadro prevede, tra gli altri aspetti, misure affinché determinati contenuti generati o manipolati artificialmente siano identificabili in formato leggibile da macchina e obblighi informativi per chi utilizza deepfake audiovisivi. La nozione comprende anche contenuti audio che assomigliano a persone, oggetti, luoghi, entità o eventi esistenti e che potrebbero apparire falsamente autentici. Il codice di buone pratiche collegato alla trasparenza resta uno strumento volontario di supporto all’adempimento. Commissione europea — Code of Practice on AI-generated content

L’assenza di una marcatura dopo il 2 agosto 2026 non consentirà comunque al perito di concludere automaticamente che il file sia naturale.

Occorrerà verificare:

• soggetto obbligato;
• sistema utilizzato;
• data di produzione;
• modalità di distribuzione;
• eccezioni;
• marcatura effettivamente supportata;
• eventuale perdita durante la ricodifica.

2.3 Voce e dati biometrici

La voce è un dato personale quando consente di riferire il contenuto a una persona identificata o identificabile. Quando viene sottoposta a specifico trattamento tecnico per identificare univocamente il soggetto, può assumere natura di dato biometrico e richiedere anche una condizione applicabile alle categorie particolari di dati. Garante ed EDPB richiamano la necessità di trasparenza e di una base giuridica adeguata quando vengono create o utilizzate impronte vocali per identificazione o autenticazione. Garante privacy — voce e riconoscimento biometrico

L’acquisizione di campioni di confronto deve quindi essere:

• necessaria;
• proporzionata;
• autorizzata;
• documentata;
• limitata al caso;
• protetta;
• cancellata o conservata secondo criteri definiti.

3. Terminologia fondamentale

3.1 Parlato sintetico

Audio parlato prodotto mediante un sistema artificiale.

Può utilizzare:

• una voce generica;
• una voce autorizzata;
• una voce clonata;
• una combinazione di voci;
• una voce non riconducibile a una persona reale.

3.2 Text-to-speech

Un testo viene trasformato in parlato.

testo
→ rappresentazione linguistica
→ caratteristiche acustiche
→ vocoder
→ audio

3.3 Voice cloning

Un sistema produce parlato con caratteristiche simili a quelle ricavate da campioni di una persona.

3.4 Voice conversion

Una registrazione pronunciata da un soggetto viene trasformata per assomigliare alla voce di un altro.

voce sorgente
→ contenuto e prosodia
→ trasformazione dell’identità vocale
→ voce destinazione

3.5 Speech-to-speech

Un sistema riceve parlato e genera altro parlato, eventualmente:

• traducendo;
• correggendo;
• cambiando stile;
• cambiando voce;
• mantenendo parte della prosodia;
• sostituendo parole.

3.6 Deepfake audio

Espressione ampia utilizzata per indicare audio sintetici o manipolati che imitano o rappresentano falsamente una persona o un evento.

Non ogni parlato sintetico è un deepfake.

Un lettore vocale che dichiara apertamente la propria natura artificiale non ha necessariamente finalità ingannevoli.

4. Sintesi vocale tradizionale e neurale

I sistemi storici potevano basarsi su:

• concatenazione di unità vocali;
• modelli statistici;
• dizionari fonetici;
• regole linguistiche.

I sistemi moderni possono utilizzare:

• modelli end-to-end;
• transformer;
• modelli auto-regressivi;
• modelli di diffusione;
• vocoder neurali;
• codec neurali;
• rappresentazioni latenti del parlante.

La qualità raggiunta da alcuni sistemi rende meno affidabile una valutazione basata soltanto su:

• voce robotica;
• prosodia piatta;
• errori di pronuncia;
• assenza di respirazione;
• suono metallico.

Questi elementi possono ancora comparire, ma la loro assenza non dimostra che la voce sia naturale.

5. Zero-shot e few-shot voice cloning

5.1 Zero-shot

Il sistema può produrre una voce simile a quella di riferimento senza addestrare un modello dedicato per lungo tempo sul singolo parlante.

5.2 Few-shot

Il sistema utilizza un insieme limitato di campioni.

5.3 Conseguenza forense

Una breve registrazione pubblica può, in alcuni sistemi, contribuire a condizionare la voce sintetica. La letteratura ASVspoof osserva che i sistemi moderni possono generare parlato imitativo partendo da campioni relativamente brevi e che anche gli ascoltatori umani possono essere ingannati in condizioni realistiche. ASVspoof 5 — analisi 2026

Questo non significa che ogni breve campione produca:

• un clone convincente;
• una voce stabile;
• una buona pronuncia in ogni lingua;
• una corretta emozione;
• una perfetta corrispondenza con il parlante.

La qualità dipende da:

• modello;
• rumore;
• durata;
• copertura fonetica;
• lingua;
• prosodia;
• post-produzione;
• canale di diffusione.

6. Speaker embedding

Molti sistemi rappresentano alcune caratteristiche del parlante mediante un vettore numerico denominato, in senso generale, speaker embedding.

L’embedding non è una “impronta vocale infallibile”.

Può riflettere o essere influenzato da:

• identità vocale;
• microfono;
• ambiente;
• codec;
• lingua;
• emozione;
• età;
• stato di salute;
• rumore;
• durata del campione.

Una forte similarità tra embedding non dimostra automaticamente che:

• i file provengano dalla stessa persona;
• uno sia stato clonato dall’altro;
• il contenuto sia autentico;
• il modello abbia identificato correttamente il soggetto.

7. Voice conversion

La voice conversion parte da una registrazione di un parlante sorgente.

Può conservare in misura variabile:

• parole;
• ritmo;
• pause;
• intenzione;
• emozione;
• respirazione;
• prosodia.

Può trasformare:

• timbro;
• formanti;
• altezza percepita;
• identità del parlante;
• stile.

7.1 Conseguenza investigativa

Una voce convertita può mantenere la cadenza del parlante sorgente, anche quando il timbro assomiglia alla persona imitata.

Un’analisi può quindi cercare divergenze tra:

identità vocale apparente
e
comportamento prosodico o linguistico

La divergenza costituisce un indicatore da correlare, non una prova autonoma.

8. Speech-to-speech e traduzione vocale

Un sistema speech-to-speech può:

• trascrivere;
• tradurre;
• sintetizzare;
• correggere;
• cambiare tono;
• mantenere la voce apparente.

Il risultato può conservare parte delle caratteristiche del parlante e produrre frasi mai pronunciate nella lingua di destinazione.

L’analisi deve pertanto distinguere:

• riconoscimento della voce;
• lingua originaria;
• contenuto semantico;
• traduzione;
• sintesi finale;
• provenienza.

9. Audio interamente sintetico

L’intera traccia viene prodotta dal modello.

Possibili caratteristiche:

• ambiente artificiale;
• riverbero aggiunto;
• rumore sintetizzato;
• respirazioni generate;
• parlato molto regolare;
• assenza di microfono reale;
• output diretto del vocoder.

La post-produzione può aggiungere:

• rumore stradale;
• riverbero di una stanza;
• compressione telefonica;
• distorsione;
• musica;
• interferenze.

L’aggiunta di un ambiente realistico può ridurre l’efficacia di detector basati su artefatti puliti.

10. Audio parzialmente sintetico

Un file può essere costituito da:

registrazione reale
+
parola sintetica
+
registrazione reale

oppure:

frase autentica
+
importo sintetico
+
IBAN sintetico

oppure:

telefonata reale
+
ordine di pagamento generato

10.1 Criticità

Un detector che restituisce un singolo punteggio per l’intero file può non individuare un segmento molto breve.

È opportuno utilizzare:

• segmentazione;
• finestre sovrapposte;
• analisi locale;
• confronto temporale;
• verifica di transizioni;
• risultati per intervallo.

11. Montaggio di parole autentiche

Una falsa frase può essere costruita senza generare alcuna voce artificiale.

Il soggetto può utilizzare parole autentiche prelevate da:

• interviste;
• vocali;
• telefonate;
• video;
• podcast;
• riunioni.

Il risultato può essere:

• concatenato;
• ricodificato;
• riacquisito;
• mascherato con rumore.

Un detector di audio sintetico potrebbe classificare correttamente ogni segmento come umano, pur trovandosi davanti a una dichiarazione mai pronunciata in quella sequenza.

Occorre quindi integrare il rilevamento AI con l’analisi dell’autenticità audio.

12. Imitazione umana

Un imitatore può riprodurre:

• timbro;
• ritmo;
• inflessione;
• accento;
• espressioni ricorrenti.

Un detector addestrato per distinguere audio umano e sintetico potrebbe classificare correttamente l’audio come umano.

La somiglianza della voce non dimostra che il contenuto provenga dalla persona imitata.

13. Riutilizzo di una registrazione autentica

Una frase reale può essere:

• estratta dal contesto;
• riprodotta durante una chiamata;
• inviata in una conversazione diversa;
• usata per rispondere a una domanda preparata;
• presentata con una data falsa.

Anche in questo caso il segnale può essere autenticamente umano.

L’accertamento deve esaminare:

• contesto;
• provenienza;
• timeline;
• account;
• dispositivo;
• eventuali versioni precedenti.

14. Replay e ri-registrazione

Un contenuto sintetico può essere riprodotto attraverso un altoparlante e registrato nuovamente mediante un microfono.

La nuova registrazione introduce:

• risposta dell’altoparlante;
• risposta del microfono;
• ambiente;
• rumore;
• riverbero;
• compressione;
• distorsione;
• nuova catena di codec.

Studi recenti mostrano che il replay può ridurre sensibilmente l’efficacia di detector addestrati su audio sintetico digitale diretto, trasformando il problema in una condizione di canale diversa da quella conosciuta dal modello. ReplayDF — replay attacks contro i detector

La presenza di riverbero e rumore reale non dimostra quindi che la voce originaria fosse umana.

15. Registrazione dello schermo

Un falso vocale può essere riprodotto in un’app e acquisito mediante:

• screen recording;
• registratore esterno;
• secondo telefono;
• software di cattura.

Il file disponibile documenta la riproduzione.

Non consente necessariamente di esaminare:

• il file sintetico originario;
• i metadati del generatore;
• l’eventuale watermark;
• la prima codifica;
• la piattaforma usata per crearlo.

16. Telefonia e compressione

Una telefonata può passare attraverso:

• codec narrowband;
• codec wideband;
• VoLTE;
• VoIP;
• centralino;
• rete mobile;
• registratore lato server;
• applicazione;
• trascrizione.

La catena può applicare:

• riduzione della banda;
• packet loss concealment;
• noise suppression;
• automatic gain control;
• echo cancellation;
• comfort noise;
• transcodifica.

Questi trattamenti possono:

• cancellare artefatti del generatore;
• introdurre nuovi artefatti;
• modificare il detector score;
• rendere meno affidabile il confronto vocale.

17. Minacce tipiche

17.1 Falso familiare

Il truffatore simula:

• figlio;
• nipote;
• coniuge;
• genitore.

Richiede:

• denaro;
• ricarica;
• bonifico;
• pagamento urgente;
• segretezza.

17.2 CEO fraud

La voce apparente del dirigente ordina:

• bonifico;
• acquisto di gift card;
• comunicazione di credenziali;
• trasferimento urgente;
• modifica dell’IBAN.

17.3 Falso operatore bancario

Il contenuto può essere combinato con:

• caller ID spoofing;
• SMS;
• sito falso;
• social engineering;
• voce sintetica.

17.4 Falso avvocato o professionista

Un messaggio può simulare:

• autorizzazione;
• rinuncia;
• incarico;
• confessione;
• accordo;
• richiesta economica.

17.5 Diffamazione e reputazione

Una voce sintetica può essere pubblicata per attribuire alla persona:

• insulti;
• minacce;
• opinioni;
• dichiarazioni riservate;
• promesse;
• ammissioni.

17.6 Prova costruita

Un file può essere presentato come:

• telefonata;
• riunione;
• memo vocale;
• ordine aziendale;
• ammissione;
• messaggio privato.

18. Verifica immediata durante una telefonata sospetta

Quando la telefonata è ancora in corso, la priorità non è l’analisi forense del segnale ma la prevenzione del danno.

Procedure prudenti:

1. interrompere la chiamata;
2. richiamare mediante un numero già verificato;
3. usare un secondo canale indipendente;
4. coinvolgere un referente noto;
5. non comunicare OTP o credenziali;
6. non eseguire pagamenti;
7. applicare la procedura aziendale a doppia approvazione;
8. conservare registro chiamate, SMS e notifiche.

Una domanda segreta improvvisata può non essere sufficiente:

• la risposta può essere nota al truffatore;
• il soggetto può aver raccolto informazioni social;
• un complice può rispondere;
• il sistema può essere interattivo.

La verifica organizzativa indipendente è normalmente più robusta della sola impressione vocale.

19. Le domande del cliente

Un cliente di Roma può chiedere:

• la voce è naturale?
• è la voce del dirigente?
• è stata clonata?
• il file è stato creato da un’app AI?
• è un testo letto da un sintetizzatore?
• è una registrazione autentica modificata?
• contiene soltanto una parola sintetica?
• è stato riprodotto da un altoparlante?
• perché il detector indica 92%?
• il file contiene un watermark?
• è presente C2PA?
• è possibile identificare il generatore?
• chi ha creato il falso vocale?
• il messaggio WhatsApp è quello originario?

La risposta può richiedere competenze e accertamenti differenti.

20. Che cosa non deve promettere il perito

Non promettere:

• rilevazione certa dell’AI;
• identificazione del modello;
• attribuzione dell’autore;
• identificazione certa del parlante;
• esclusione assoluta della sintesi;
• recupero del file originario;
• datazione assoluta;
• riconoscimento infallibile della voce;
• validità probatoria garantita;
• esito processuale.

Una formula corretta è:

«L’analisi valuterà la compatibilità del reperto con differenti ipotesi, nei limiti della qualità del file e delle fonti disponibili.»

21. Materiale da richiedere

[ ] file ricevuto;
[ ] file nella chat originale;
[ ] dispositivo del destinatario;
[ ] dispositivo sorgente, se disponibile;
[ ] registrazione della chiamata;
[ ] registro chiamate;
[ ] dati del centralino;
[ ] email;
[ ] SMS;
[ ] profilo o account;
[ ] link;
[ ] versione inoltrata;
[ ] eventuale screen recording;
[ ] file pubblicato online;
[ ] registrazioni autentiche di riferimento;
[ ] dati temporali;
[ ] descrizione del contesto;
[ ] punto contestato.

Per un vocale ricevuto su WhatsApp, Telegram o Signal, acquisire quando possibile:

• database;
• allegato;
• record;
• timestamp;
• ID;
• account;
• dispositivo;
• backup.

22. Gerarchia delle fonti

Una gerarchia orientativa:

1. file originario del sistema di generazione;
2. file pubblicato direttamente dalla piattaforma;
3. allegato conservato nell’app;
4. file scaricato dal messaggio;
5. export della conversazione;
6. file inoltrato;
7. registrazione dello schermo;
8. registrazione da altoparlante;
9. audio incorporato in un altro file;
10. frammento trasmesso oralmente.

La fonte più vicina all’origine consente normalmente una migliore analisi di:

• metadati;
• codec;
• watermark;
• struttura;
• C2PA;
• eventuale modello.

23. Questionario di provenienza

1. Chi ha ricevuto il file?
2. Da quale account?
3. Attraverso quale applicazione?
4. A quale data e ora?
5. È stato inoltrato?
6. È stato scaricato?
7. È stato convertito?
8. È stato registrato dallo schermo?
9. È stato riprodotto da un altoparlante?
10. È disponibile il messaggio originario?
11. È disponibile la telefonata completa?
12. È disponibile il centralino?
13. Il presunto parlante usa normalmente quella lingua?
14. Esistono espressioni insolite?
15. La persona aveva accesso al contenuto dichiarato?
16. Sono stati chiesti pagamenti o credenziali?
17. Esistono altre versioni?
18. Quale detector è già stato utilizzato?
19. Il file è stato caricato su siti esterni?
20. Quale fatto deve essere verificato?

24. Cartella del caso

CASO_RM_2026_025/
├── 00_incarico/
├── 01_verbali/
├── 02_originali/
├── 03_hash/
├── 04_copie_analisi/
├── 05_chat_chiamate/
├── 06_metadata/
├── 07_ffprobe/
├── 08_mediainfo/
├── 09_exiftool/
├── 10_c2pa/
├── 11_watermark/
├── 12_waveform/
├── 13_spectrogram/
├── 14_praat/
├── 15_detector/
├── 16_modelli_pesi/
├── 17_campioni_riferimento/
├── 18_confronto_parlante/
├── 19_analisi_locale/
├── 20_timeline/
├── 21_report/
└── 22_relazione/

25. Registro dei reperti

26. Catena di custodia

Registrare:

- identificativo;
- nome originale;
- fonte;
- account;
- dispositivo;
- data e ora;
- fuso;
- modalità di acquisizione;
- soggetto consegnante;
- dimensione;
- hash;
- posizione;
- copie;
- strumenti;
- accessi.

La procedura generale è descritta nel Capitolo 2 — Catena di custodia, hash e verbale tecnico.

27. Calcolo dell’hash

Windows PowerShell

Get-FileHash -Algorithm SHA256 `
  -LiteralPath ".\vocale-contestato.ogg"

Linux

sha256sum -- vocale-contestato.ogg

macOS

shasum -a 256 -- vocale-contestato.ogg

L’hash deve essere calcolato prima di:

• conversioni;
• filtri;
• detector;
• estrazione PCM;
• modifica dei metadati;
• segmentazione.

28. Identificare il formato reale

file --brief -- vocale-contestato.ogg
file --brief --mime-type -- vocale-contestato.ogg

ffprobe \
  -v error \
  -show_format \
  -show_streams \
  -of json \
  "vocale-contestato.ogg" \
  > ffprobe-full.json

mediainfo \
  --Output=JSON \
  "vocale-contestato.ogg" \
  > mediainfo.json

Verificare:

• contenitore;
• codec;
• sample rate;
• canali;
• durata;
• bitrate;
• encoder;
• metadati;
• errori.

29. Inventario dei pacchetti

ffprobe \
  -v error \
  -select_streams a:0 \
  -show_packets \
  -show_entries \
packet=pts_time,dts_time,duration_time,pos,size,flags \
  -of csv=p=0 \
  "vocale-contestato.ogg" \
  > packets.csv

Può aiutare a individuare:

• gap;
• discontinuità;
• pacchetti anomali;
• concatenazioni;
• errori;
• struttura del codec.

Una variazione nella dimensione dei pacchetti non dimostra automaticamente sintesi o montaggio.

30. Hash dei payload

ffprobe \
  -v error \
  -select_streams a:0 \
  -show_packets \
  -show_data_hash sha256 \
  -of json \
  "vocale-contestato.ogg" \
  > packet-hashes.json

L’output può essere utile per:

• confrontare due copie;
• identificare segmenti invariati;
• verificare estrazioni;
• documentare il payload codificato.

31. Creare la copia PCM

ffmpeg \
  -v warning \
  -i "vocale-contestato.ogg" \
  -map 0:a:0 \
  -c:a pcm_s24le \
  -map_metadata -1 \
  "vocale-analisi.wav"

Regole:

- preservare il sample rate;
- preservare i canali;
- non normalizzare;
- non ridurre il rumore;
- non equalizzare;
- documentare il comando;
- calcolare l’hash dell’output.

32. Metadati

exiftool \
  -G0:1:2 \
  -a \
  -s \
  -u \
  -ee \
  -struct \
  -json \
  "vocale-contestato.ogg" \
  > exiftool.json

Cercare:

• software;
• encoder;
• data;
• commenti;
• modello;
• XMP;
• ID3;
• QuickTime;
• C2PA;
• campi proprietari.

L’assenza del nome di un generatore AI non dimostra che il file sia naturale.

33. Waveform e spettrogramma

Waveform

ffmpeg \
  -i "vocale-analisi.wav" \
  -filter_complex "showwavespic=s=2400x600" \
  -frames:v 1 \
  "waveform.png"

Spettrogramma

ffmpeg \
  -i "vocale-analisi.wav" \
  -lavfi "showspectrumpic=s=2400x1200" \
  "spectrogram.png"

Documentare:

• risoluzione;
• finestra;
• scala;
• canale;
• intervallo;
• zoom;
• range dinamico.

Lo spettrogramma è uno strumento di ispezione, non un detector autonomo di intelligenza artificiale.

34. Praat

Praat consente di analizzare e annotare il parlato, misurando tra gli altri:

• pitch;
• formanti;
• intensità;
• durata;
• jitter;
• shimmer;
• harmonicity;
• voice breaks.

Le misure dipendono dalle impostazioni, dalla qualità e dal tipo di voce; parametri come il pitch floor e il pitch ceiling possono modificare sensibilmente i risultati. Praat — Manuale introduttivo

34.1 Registrare

- versione;
- pitch floor;
- pitch ceiling;
- metodo;
- formant ceiling;
- window length;
- smoothing;
- intervallo;
- canale.

34.2 Esecuzione di uno script validato

praat \
  --run \
  "<SCRIPT_VALIDATO>.praat" \
  "vocale-analisi.wav" \
  "praat-output.csv"

Lo script deve essere conservato e sottoposto a hash.

35. Sonic Visualiser

Sonic Visualiser può supportare:

• waveform;
• spettrogramma;
• annotazioni temporali;
• confronto tra layer;
• visualizzazione della frequenza;
• analisi di più registrazioni.

Le proprietà della visualizzazione, inclusa la risoluzione FFT, devono essere documentate perché modificano ciò che appare nel grafico. Sonic Visualiser — Reference Manual

36. C2PA

C2PA può associare all’audio un manifesto contenente dichiarazioni firmate su:

• creazione;
• strumento;
• azioni;
• ingredienti;
• origine digitale;
• eventuale uso di AI.

La specifica C2PA 2.4 prevede incorporamenti per più formati audio: WAV e BWF tramite chunk RIFF dedicato, MP3 e FLAC mediante oggetti ID3, Ogg mediante stream logico e formati BMFF come AAC o ALAC attraverso la struttura del contenitore. Il tipo trainedAlgorithmicMedia può dichiarare che il contenuto è stato prodotto mediante un modello algoritmico addestrato. C2PA Technical Specification 2.4

36.1 Analisi

c2patool \
  "vocale-contestato.wav" \
  --info \
  > c2pa-info.txt

c2patool \
  "vocale-contestato.wav" \
  -d \
  > c2pa-detailed.json

36.2 Interpretazione

Un manifesto valido può supportare:

• integrità rispetto al manifesto;
• provenienza dichiarata;
• firma;
• azioni registrate.

Non dimostra automaticamente:

• identità del parlante;
• veridicità delle parole;
• completezza della storia;
• assenza di interventi precedenti;
• liceità.

37. Assenza di C2PA

L’assenza può dipendere da:

• sistema non compatibile;
• contenuto precedente;
• generatore privo di marcatura;
• rimozione;
• ricodifica;
• messaggistica;
• registrazione da altoparlante;
• screenshot;
• esportazione.

Conclusione corretta:

«Nel file non è stato rilevato un manifesto C2PA mediante gli strumenti indicati. Tale assenza non consente di determinare l’origine naturale o sintetica del contenuto.»

38. Watermark audio

Alcuni sistemi possono inserire un watermark:

• nel segnale;
• nelle rappresentazioni latenti;
• mediante tecniche robuste a specifiche trasformazioni;
• su tutta la traccia o su segmenti.

AudioSeal e SynthID sono esempi di sistemi di ricerca o produzione dedicati alla marcatura e al successivo riconoscimento di audio generato da specifici ecosistemi. AudioSeal — Localized Watermarking

38.1 Presenza

Un watermark verificato con lo strumento ufficiale può supportare l’origine dal sistema associato, nei limiti del metodo.

38.2 Assenza

Non dimostra che l’audio sia naturale.

Può dipendere da:

• generatore diverso;
• watermark non applicato;
• perdita;
• rimozione;
• ricodifica;
• replay;
• segmento troppo breve;
• detector non compatibile.

Studi comparativi indicano che watermark e detector passivi possono perdere efficacia in presenza di manipolazioni, trasmissioni o condizioni mai considerate durante la progettazione. Watermarking and passive detection under manipulation

39. Catena tecnica di generazione

Una catena semplificata può essere:

testo
   ↓
analisi linguistica
   ↓
speaker embedding
   ↓
modello acustico
   ↓
vocoder o codec neurale
   ↓
audio sintetico
   ↓
post-produzione
   ↓
compressione
   ↓
piattaforma
   ↓
ri-registrazione

Ogni passaggio può:

• introdurre artefatti;
• attenuarli;
• aggiungere rumore;
• modificare il detector score;
• cancellare metadati;
• produrre un nuovo file.

40. Vocoder

Il vocoder converte rappresentazioni acustiche o latenti in forma d’onda.

Possibili tracce:

• armoniche anomale;
• fase;
• transienti attenuati;
• sibilanti;
• rumore artificiale;
• eccessiva regolarità.

I vocoder moderni possono produrre segnali molto realistici.

L’assenza di artefatti classici non esclude la sintesi.

41. Codec neurali

I codec neurali rappresentano il parlato mediante token o codici appresi.

Possono essere utilizzati per:

• compressione;
• generazione;
• modifica;
• trasmissione;
• modelli audio linguistici.

La ricerca ASVspoof 5 segnala che codifica e compressione neurale possono peggiorare la capacità dei detector di generalizzare, anche quando il modello riconosce bene gli attacchi presenti nel proprio dataset. ASVspoof 5 — Analisi 2026

42. Livelli di analisi

Una procedura robusta comprende almeno:

1. provenienza;
2. file e contenitore;
3. codec e pacchetti;
4. segnale acustico;
5. fonetica e prosodia;
6. contesto linguistico;
7. rilevamento automatico;
8. confronto con campioni autentici;
9. account, dispositivi e rete;
10. timeline.

Un risultato forte richiede la convergenza di livelli indipendenti.

43. Prosodia

La prosodia comprende:

• ritmo;
• accento;
• intonazione;
• durata;
• pause;
• enfasi;
• andamento melodico.

Possibili anomalie:

• intonazione troppo regolare;
• pause in posizioni insolite;
• enfasi semanticamente errata;
• ritmo incoerente;
• cambi di stile.

Possibili spiegazioni naturali:

• lettura;
• stress;
• stanchezza;
• lingua non madre;
• registrazione preparata;
• malattia;
• canale telefonico.

44. Frequenza fondamentale

La frequenza fondamentale, spesso indicata come F0, è collegata alla periodicità della voce e alla percezione dell’altezza.

Analizzare:

• intervallo;
• contorno;
• transizioni;
• errori di tracking;
• salti;
• microvariazioni.

Un contorno molto regolare può essere compatibile con sintesi, ma anche con:

• lettura controllata;
• voce professionale;
• filtro;
• algoritmo di pitch tracking errato;
• segmento breve.

45. Formanti

I formanti sono risonanze associate alla configurazione del tratto vocale.

Possono essere utilizzati per valutare:

• vocali;
• transizioni;
• coarticolazione;
• caratteristiche del parlante;
• qualità del canale.

Le misurazioni sono sensibili a:

• sesso e anatomia;
• lingua;
• vocale;
• microfono;
• codec;
• rumore;
• impostazioni del software.

Una discontinuità nei formanti può essere un indicatore locale, non una prova autonoma di sintesi.

46. Coarticolazione

Nel parlato naturale i suoni si influenzano reciprocamente.

Un modello può produrre:

• transizioni eccessivamente nette;
• raccordi non naturali;
• articolazione incoerente;
• variazioni insufficienti.

I sistemi moderni modellano però la coarticolazione in modo sempre più realistico.

La valutazione deve essere affidata a personale competente e confrontata con campioni comparabili.

47. Consonanti e sibilanti

Possono essere esaminati:

• fricative;
• sibilanti;
• plosive;
• affricate;
• attacchi;
• rilascio.

Possibili anomalie sintetiche:

• energia spettrale uniforme;
• transienti smussati;
• sibilanti metalliche;
• esplosive incomplete;
• raccordi artificiali.

Gli stessi fenomeni possono essere introdotti da:

• MP3;
• AAC;
• Opus;
• telefonia;
• noise suppression;
• clip audio degradate.

48. Respirazione

Una registrazione naturale può contenere:

• inspirazioni;
• espirazioni;
• micro-pause;
• rumori della bocca;
• deglutizione.

Possibili anomalie:

• assenza sistematica;
• respirazione collocata male;
• rumore ripetuto;
• intensità incoerente;
• respiro non compatibile con la frase.

Non ogni parlato privo di respirazioni è sintetico:

• il microfono può non rilevarle;
• la riduzione del rumore può eliminarle;
• il messaggio può essere breve;
• l’editor può aver applicato un gate;
• il parlante può respirare lontano dal microfono.

49. Disfluenze

Il parlato naturale può includere:

• esitazioni;
• ripetizioni;
• correzioni;
• pause riempite;
• false partenze.

Un sistema sintetico può produrre disfluenze intenzionalmente.

La presenza di “eh”, “mm”, pause o respiri non prova quindi l’origine umana.

50. Microvariazioni vocali

Possibili misure:

• jitter;
• shimmer;
• harmonic-to-noise ratio;
• voice breaks;
• spectral tilt.

Questi parametri dipendono da:

• salute;
• emozione;
• età;
• microfono;
• codec;
• rumore;
• algoritmo;
• segmento;
• pitch tracking.

Non devono essere utilizzati singolarmente per classificare un file come sintetico.

51. Riverbero e ambiente

Un audio sintetico digitale può inizialmente essere privo di un ambiente reale.

La post-produzione può aggiungere:

• riverbero;
• rumore;
• eco;
• traffico;
• vento;
• folla;
• televisione.

L’analisi deve verificare:

• coerenza temporale;
• decadimento;
• relazione tra voce e ambiente;
• cambi locali;
• duplicazioni;
• risposta del canale.

Un replay da altoparlante produce invece un ambiente reale, pur partendo da voce artificiale.

52. Rumore di fondo

Esaminare:

• continuità;
• spettro;
• periodicità;
• ripetizioni;
• correlazione tra segmenti;
• rapporto con il parlato.

Un rumore esattamente replicato può essere compatibile con:

• loop;
• copia e incolla;
• ambiente sintetico.

Un rumore continuo non dimostra origine naturale.

53. Fase e canali

Nei file stereo analizzare:

• fase;
• coerenza intercanale;
• ritardo;
• livello;
• rumore;
• posizione apparente.

Un audio sintetico mono può essere trasformato in falso stereo mediante:

• ritardo;
• riverbero;
• duplicazione;
• decorrelazione.

Il falso stereo non prova, da solo, l’origine artificiale del parlato.

54. Coerenza linguistica

Un contenuto sospetto può presentare:

• lessico insolito;
• formalità atipica;
• costruzioni non usate dal parlante;
• errori sul contesto;
• pronuncia di nomi errata;
• date o ruoli incoerenti;
• formule tradotte.

Questi elementi sono contestuali.

Non sono un detector tecnico.

La persona potrebbe:

• leggere un testo;
• essere sotto stress;
• usare una lingua diversa;
• ripetere parole suggerite;
• cambiare stile.

55. Dialetto, accento e lingua

La voce clonata può riprodurre bene il timbro ma meno bene:

• accento romano;
• inflessioni regionali;
• pronuncia di nomi;
• alternanza linguistica;
• consonanti geminate;
• ritmo dialettale.

La qualità dipende dai dati e dal modello.

Un accento incoerente è un elemento orientativo, non conclusivo.

56. Contenuto e conoscenza personale

Un falso vocale può essere smentito dal fatto che il parlante apparente:

• non conosce un dettaglio;
• usa un nome errato;
• confonde ruoli;
• richiede una procedura insolita;
• evita risposte;
• ripete frasi generiche.

Questi elementi sono utili per il contesto e il social engineering, ma non dimostrano tecnicamente l’uso dell’AI.

57. Durata del campione

Un file molto breve presenta:

• minore copertura fonetica;
• meno pause;
• meno respirazioni;
• meno variazioni prosodiche;
• pochi dati per il detector;
• poche informazioni per il confronto vocale.

Un detector può comunque restituire uno score.

Lo score non diventa affidabile soltanto perché il software produce un numero.

58. File molto lungo

Un file lungo può contenere:

• parti naturali;
• parti sintetiche;
• musica;
• silenzi;
• più parlanti;
• più canali;
• segmenti ri-registrati.

È opportuno:

• segmentare;
• identificare i parlanti;
• analizzare finestre;
• confrontare i risultati;
• cercare cambi di canale.

59. Audio parzialmente falso

59.1 Analisi a finestre

Esempio:

finestra: 4 secondi
passo: 1 secondo

Per ogni finestra registrare:

• inizio;
• fine;
• detector score;
• qualità;
• voce;
• rumore;
• codec;
• note.

59.2 Sovrapposizione

L’overlap riduce il rischio che un segmento sintetico cada esattamente tra due finestre.

59.3 Limite

Le finestre adiacenti non sono statisticamente indipendenti.

Non si devono sommare gli score come prove separate.

60. Confronto del parlante

Il confronto vocale risponde a una domanda diversa:

«Il parlante nel reperto è compatibile con la persona di riferimento?»

Non risponde direttamente:

«Il reperto è stato generato con AI?»

Una voce clonata potrebbe risultare simile alla persona.

Una voce autentica degradata potrebbe risultare meno simile.

La comparazione forense del parlante richiede campioni adeguati, metodologia validata e valutazione delle condizioni; ENFSI mantiene linee guida specifiche distinte da quelle sull’autenticità audio. ENFSI — Best Practice Manuals

61. Campioni di riferimento

I campioni dovrebbero essere:

• autentici;
• autorizzati;
• sufficientemente lunghi;
• contemporanei, quando possibile;
• nella stessa lingua;
• nello stesso stile;
• con qualità comparabile;
• senza musica;
• con parlante noto.

61.1 Campioni non comparabili

Esempio:

reperto:
telefonata 8 kHz con rumore;

riferimento:
intervista in studio 48 kHz.

La differenza del canale può dominare le misurazioni.

61.2 Campioni pubblici

Video social e podcast possono essere:

• montati;
• filtrati;
• compressi;
• sintetici;
• doppiati;
• non attribuibili con certezza.

62. Acquisizione dei campioni vocali

Registrare:

- consenso o autorizzazione;
- dispositivo;
- microfono;
- ambiente;
- sample rate;
- formato;
- testo;
- stile;
- data;
- identità;
- catena di custodia.

Non addestrare un modello di clonazione per “verificare quanto è facile” senza:

• autorizzazione specifica;
• valutazione privacy;
• ambiente controllato;
• necessità;
• misure di sicurezza.

La creazione di una copia sintetica della voce genera un nuovo rischio e normalmente non è indispensabile per l’accertamento.

63. Detector automatici

Un detector riceve il segnale e produce, a seconda del sistema:

• etichetta;
• score;
• probabilità calibrata;
• logit;
• classe;
• stima per segmento;
• attribuzione a una famiglia.

Il risultato dipende da:

• training set;
• architettura;
• preprocessing;
• sample rate;
• durata;
• codec;
• lingua;
• soglia;
• versione;
• canale.

64. Famiglie di detector

64.1 Feature tradizionali

Possono utilizzare:

• LFCC;
• CQCC;
• MFCC;
• spectral features;
• phase features;
• prosodic features.

64.2 Raw waveform

Il modello riceve direttamente la forma d’onda.

64.3 Self-supervised speech representations

Utilizzano rappresentazioni apprese da grandi quantità di audio.

Esempi di famiglie di ricerca:

• wav2vec 2.0;
• WavLM;
• HuBERT;
• modelli affini.

64.4 Ensemble

Combina più modelli o feature.

64.5 Detector localizzati

Restituiscono un esito temporale, utile per deepfake parziali.

65. Modelli di ricerca

Architetture come AASIST, RawNet2 e sistemi basati su rappresentazioni self-supervised sono state impiegate nei benchmark e nella ricerca sullo spoofing vocale.

Non sono automaticamente:

• strumenti certificati;
• adatti a ogni lingua;
• calibrati per il caso;
• idonei a una conclusione probatoria isolata.

Gli studi ASVspoof 5 mostrano differenze importanti tra condizioni in-domain, cross-domain, codec e attacchi avversari. ASVspoof 5 — Analisi 2026

66. Score e probabilità

Uno score grezzo non è necessariamente:

• percentuale;
• probabilità;
• grado di certezza;
• rischio processuale.

Esempio:

score = 0,92

potrebbe significare soltanto che il valore supera una soglia interna.

Per interpretarlo servono:

• definizione del modello;
• segno dello score;
• soglia;
• calibrazione;
• classe positiva;
• distribuzione sui dati di validazione;
• condizioni del file.

67. Soglia decisionale

Una soglia separa, in modo semplificato:

audio classificato come umano
audio classificato come sintetico

La soglia può essere scelta per:

• minimizzare errori complessivi;
• ridurre falsi negativi;
• ridurre falsi positivi;
• una specifica applicazione.

La soglia ottimale del benchmark non è automaticamente quella appropriata per una perizia.

68. Equal Error Rate

L’Equal Error Rate è il punto in cui, nel protocollo di valutazione, il tasso di falsi accettati e falsi rifiutati coincide.

È una metrica comparativa.

Non significa:

«Il detector sbaglia esattamente quella percentuale in ogni caso reale.»

Il valore dipende da:

• dataset;
• attacchi;
• proporzioni;
• condizioni;
• protocollo;
• soglia.

ASVspoof utilizza metriche come EER e funzioni di costo per confrontare sistemi in scenari definiti. ASVspoof 5

69. minDCF

La minimum Detection Cost Function considera:

• costi degli errori;
• priorità delle classi;
• soglia.

È utile per benchmark e applicazioni definite.

Non costituisce automaticamente una misura di attendibilità del singolo reperto.

70. Calibrazione

Un detector calibrato cerca di rendere lo score interpretabile rispetto a una distribuzione nota.

La calibrazione può deteriorarsi quando cambiano:

• lingua;
• codec;
• modello generativo;
• ambiente;
• sample rate;
• replay;
• rumore;
• piattaforma.

Una probabilità prodotta fuori dal dominio di calibrazione può essere fuorviante.

71. Domain shift

Il domain shift si verifica quando il caso differisce dai dati usati per sviluppare il detector.

Esempi:

training:
inglese pulito, WAV, 16 kHz;

caso:
italiano, WhatsApp, Opus, rumore stradale.

oppure:

training:
audio sintetico digitale;

caso:
sintetico riprodotto da altoparlante e registrato.

La ricerca ASVspoof rileva che modelli molto efficaci sul proprio dataset possono peggiorare sensibilmente su corpora, codec o attacchi differenti, mostrando possibile apprendimento di caratteristiche specifiche del benchmark. ASVspoof 5 — Generalizzazione cross-domain

72. Lingua italiana e accento romano

Un detector addestrato prevalentemente su inglese può reagire in modo differente a:

• italiano;
• dialetto;
• codice misto;
• nomi propri;
• parlato emotivo;
• accento romano;
• inflessioni regionali.

La lingua deve essere inclusa tra i limiti della relazione.

73. Codec e piattaforma

Un file può essere ricodificato da:

• WhatsApp;
• Telegram;
• social;
• PBX;
• centralino;
• videoconferenza;
• registratore.

È opportuno verificare, se possibile, il detector su:

- file originale;
- copia ricodificata;
- registrazioni autentiche attraverso lo stesso canale;
- campioni sintetici autorizzati già disponibili, senza crearne di nuovi.

74. Rumore e condizioni avverse

Rumore, musica e più parlanti possono:

• ridurre il detector score;
• produrre falsi positivi;
• mascherare artefatti;
• introdurre feature estranee.

Non applicare automaticamente una riduzione del rumore prima del detector.

Il preprocessing deve corrispondere a quello validato dal modello.

75. Replay attack contro i detector

La riproduzione e ri-registrazione può modificare le caratteristiche utilizzate dal detector.

La ricerca ReplayDF ha mostrato un calo rilevante delle prestazioni di modelli open source quando l’audio sintetico veniva riprodotto e acquisito nuovamente attraverso una catena acustica. ReplayDF

La conclusione deve pertanto distinguere:

audio digitale diretto
e
audio sintetico ri-registrato

76. Trasformazioni avversarie

Un soggetto può applicare:

• rumore;
• equalizzazione;
• riverbero;
• compressione;
• resampling;
• cambio codec;
• pitch shift;
• time stretching;
• filtri;
• replay.

Lo scopo può essere:

• rendere il contenuto realistico;
• ridurre l’efficacia del detector;
• simulare una telefonata;
• cancellare metadati.

Un detector robusto su una trasformazione non è necessariamente robusto su tutte.

77. Ensemble di detector

Utilizzare più detector può essere utile.

Occorre però verificare la reale indipendenza.

Due modelli possono condividere:

• dataset;
• frontend;
• architettura;
• pesi pre-addestrati;
• vulnerabilità;
• preprocessing.

Tre score concordi non rappresentano necessariamente tre prove indipendenti.

78. Detector online

Un sito può mostrare:

“AI generated: 87%”

Prima di usare il risultato verificare:

• produttore;
• modello;
• versione;
• informativa;
• soglia;
• lingue;
• codec;
• retention;
• dataset;
• output;
• possibilità di download del report.

Uno screenshot del risultato non è sufficiente.

Conservare:

• file caricato;
• hash;
• data;
• schermata;
• termini;
• report;
• URL;
• eventuali modifiche del servizio.

79. Detector locale

È preferibile quando:

• il file è riservato;
• occorre riproducibilità;
• il modello è disponibile;
• i pesi sono acquisibili;
• l’ambiente può essere conservato.

79.1 Registrare

- repository;
- commit;
- modello;
- checkpoint;
- hash dei pesi;
- dipendenze;
- sistema;
- GPU/CPU;
- sample rate;
- segment length;
- soglia;
- output.

79.2 Ambiente

python --version \
  > python-version.txt

pip freeze \
  > environment.txt

sha256sum \
  model-checkpoint.bin \
  > model-checkpoint.sha256.txt

79.3 Esecuzione concettuale

python \
  "<SCRIPT_VALIDATO>.py" \
  --checkpoint "<PESI_VALIDATI>" \
  --input "vocale-analisi.wav" \
  --output "detector-result.json"

Il comando effettivo deve essere quello previsto dall’implementazione validata.

80. Scheda del detector

81. Output per segmenti

Non presentare una lunga tabella come se ogni riga fosse una prova indipendente.

82. Detector e classificazione del generatore

Alcuni modelli tentano di attribuire l’audio a:

• TTS;
• voice conversion;
• famiglia;
• generatore;
• codec.

La classificazione del generatore è più difficile della semplice distinzione sintetico/umano.

Un modello sconosciuto può essere assegnato alla famiglia più simile anche quando la previsione è errata.

Formula prudente:

«Il classificatore ha associato il reperto alla classe indicata; l’esito non consente di identificare con certezza il software utilizzato.»

83. Rilevamento umano

L’ascoltatore può notare:

• pronuncia anomala;
• emozione incoerente;
• ritmo;
• artefatti;
• respirazione;
• rumore.

L’ascolto resta utile per orientare l’analisi.

Non è sufficiente perché:

• le persone possono essere ingannate;
• la familiarità con la voce crea aspettative;
• il contenuto emotivo influenza il giudizio;
• la telefonia riduce i dettagli;
• alcuni sistemi sono molto realistici. ASVspoof 5

84. Convergenza delle fonti

Una conclusione robusta può derivare da:

C2PA o watermark
+
metadati del generatore
+
artefatti acustici
+
detector validati
+
account della piattaforma
+
assenza del contenuto sul dispositivo dichiarato
+
timeline coerente

Ogni elemento deve essere valutato per:

• affidabilità;
• indipendenza;
• provenienza;
• possibilità di alterazione;
• spiegazioni alternative.

Il NIST considera le tecniche di provenienza e rilevamento complementari proprio perché nessuna copre da sola l’intera catena dei contenuti sintetici. NIST AI 100-4

85. Acquisizione di una chiamata VoIP

Richiedere, quando disponibile:

[ ] registrazione completa;
[ ] file originale PBX;
[ ] call detail record;
[ ] SIP Call-ID;
[ ] numero chiamante;
[ ] numero chiamato;
[ ] timestamp;
[ ] codec;
[ ] RTP;
[ ] indirizzi IP;
[ ] gateway;
[ ] registratore;
[ ] log del centralino.

Il numero visualizzato non identifica necessariamente l’origine reale.

Vedere il capitolo su truffe online e financial cybercrime.

86. Registrazione stereo o multicanale

Un centralino può registrare:

• cliente su un canale;
• operatore sull’altro;
• mix finale;
• tracce separate.

Preservare tutti i canali.

Un falso audio inserito successivamente può risultare:

• soltanto nel mix;
• su un singolo canale;
• con riverbero diverso;
• con diversa dinamica.

87. Caller ID spoofing

La visualizzazione del numero di una persona non dimostra che la voce provenga dal suo telefono.

Acquisire:

• registro chiamate;
• screenshot;
• CDR;
• provider;
• messaggi precedenti;
• eventuale richiamata;
• numero ufficiale.

La voce sintetica e lo spoofing possono essere utilizzati insieme.

88. Messaggio WhatsApp

Per un falso vocale WhatsApp acquisire:

- file Ogg/Opus;
- database;
- record;
- mittente apparente;
- ID messaggio;
- timestamp;
- inoltro;
- backup;
- dispositivo.

Un account compromesso può inviare un vocale sintetico.

La somiglianza della voce e la provenienza dall’account della persona sono due elementi distinti.

89. Telegram e Signal

Acquisire:

• account;
• chat;
• allegato;
• ID;
• dispositivo;
• cloud o database locale;
• versione;
• messaggi correlati.

Vedere il Capitolo 9 — Telegram, Signal e app di messaggistica forensics.

90. Contenuto pubblicato online

Acquisire:

• URL;
• account;
• pagina;
• video;
• file;
• data;
• commenti;
• copie;
• piattaforma;
• eventuale etichetta AI;
• eventuali Content Credentials.

La procedura è approfondita nel Capitolo 16 — Acquisizione di pagine web, social e contenuti online.

91. Ricerca della fonte precedente

Una registrazione falsa può utilizzare audio preesistente.

Cercare:

• podcast;
• interviste;
• social;
• video;
• conferenze;
• vocali;
• telefonate;
• archivi.

Confrontare:

• parole;
• frasi;
• pause;
• rumore;
• waveform;
• spettro;
• campioni.

Una corrispondenza esatta può indicare:

• riuso;
• copia;
• montaggio;
• stessa fonte.

92. Caso pratico 1 — Falso amministratore delegato

Scenario

Un’azienda con sede all’EUR riceve una telefonata apparentemente effettuata dall’amministratore delegato.

La voce ordina un bonifico urgente.

Materiale

- registrazione PBX;
- CDR;
- account Teams;
- email successiva;
- campioni autentici del dirigente;
- procedura aziendale.

Risultati

• chiamata proveniente da infrastruttura esterna;
• numero visualizzato compatibile con spoofing;
• audio narrowband;
• detector discordanti;
• prosodia atipica;
• alcune pronunce errate;
• nessuna attività dell’account del dirigente;
• richiesta contraria alla procedura.

Conclusione prudente

«La telefonata non risulta tecnicamente originata dai sistemi aziendali attribuiti al dirigente. Il segnale presenta elementi compatibili con produzione o trasformazione sintetica, ma la qualità telefonica non consente una conclusione fondata sul solo audio. La ricostruzione complessiva risulta incompatibile con una normale autorizzazione aziendale.»

93. Caso pratico 2 — Falso figlio in emergenza

Scenario

Una cliente di Roma riceve un messaggio di otto secondi con la voce apparente del figlio.

Risultati

- file molto breve;
- rumore stradale;
- audio ri-registrato;
- nessun file sorgente;
- numero sconosciuto;
- richiesta di denaro successiva;
- detector non concordi.

Conclusione

«La durata, la riacquisizione acustica e il rumore limitano significativamente l’analisi. Il file non consente di confermare né escludere in modo affidabile un’origine sintetica. Il contesto e il numero utilizzato risultano tuttavia incompatibili con una comunicazione verificata del familiare.»

94. Caso pratico 3 — Vocale WhatsApp attribuito a un avvocato

Scenario

Un cliente romano produce un vocale nel quale un avvocato sembrerebbe ammettere una condotta professionale.

Risultati

• account mittente compromesso;
• messaggio inviato durante la compromissione;
• voce simile;
• file Ogg/Opus;
• detector locale compatibile con sintesi;
• segmento iniziale uguale a un video pubblico;
• parte finale generata o trasformata.

Conclusione

«Il messaggio è stato inviato dall’account compromesso e contiene un segmento proveniente da materiale pubblico, seguito da audio con caratteristiche compatibili con produzione sintetica. L’account mittente non dimostra che l’avvocato abbia creato o pronunciato il contenuto.»

95. Caso pratico 4 — Replay da altoparlante

Scenario

Un’azienda romana consegna la registrazione di una telefonata effettuata con un secondo smartphone.

Risultati

• riverbero reale;
• risposta di altoparlante;
• rumore della stanza;
• detector classifica umano;
• confronto con il file digitale, successivamente rinvenuto, evidenzia origine TTS.

Conclusione

«Il file disponibile inizialmente era una riacquisizione acustica del contenuto sintetico. La catena altoparlante-microfono ha modificato le caratteristiche utilizzate dal detector, producendo una classificazione non affidabile.»

96. Caso pratico 5 — Falso positivo dopo ricodifica

Scenario

Un professionista di Roma registra un messaggio autentico, successivamente inoltrato più volte.

Risultati

- originale disponibile;
- tre ricodifiche;
- detector pubblico segnala alta probabilità AI;
- originale classificato come umano;
- contenuto decodificato coerente;
- artefatti introdotti dalla piattaforma.

Conclusione

«Il risultato del detector sul file ricodificato costituisce un falso positivo rispetto alla provenienza documentata dell’originale. L’esito dimostra la sensibilità del modello alle condizioni del codec e non può essere utilizzato isolatamente.»

97. Caso pratico 6 — Audio con C2PA

Scenario

Uno studio legale di Roma riceve un file WAV con Content Credentials.

Risultati

• manifesto presente;
• hard binding valido;
• firma valida;
• sorgente dichiarata trainedAlgorithmicMedia;
• generatore indicato;
• nessuna identità del soggetto che ha digitato il testo.

Conclusione

«Il manifesto C2PA validamente associato al file dichiara una produzione mediante modello algoritmico addestrato. L’esito documenta la provenienza dichiarata e l’integrità del file rispetto al manifesto; non identifica la persona che ha creato il contenuto né valuta la veridicità delle parole.»

98. Caso pratico 7 — Sostituzione sintetica di una cifra

Scenario

In una registrazione aziendale autentica viene contestato un importo.

Risultati

- file prevalentemente naturale;
- finestra di 700 millisecondi anomala;
- transizioni non coerenti;
- diverso rumore;
- detector globale classificato umano;
- detector locale e analisi acustica compatibili con sostituzione.

Conclusione

«Il file è prevalentemente costituito da parlato naturale, ma il segmento contenente l’importo presenta caratteristiche non coerenti con le aree adiacenti e compatibili con una sostituzione locale.»

99. Caso pratico 8 — Campioni di riferimento inadeguati

Scenario

Un cliente consegna una telefonata di bassa qualità e un’intervista televisiva come riferimento.

Risultati

• codec differenti;
• lingua e stile differenti;
• rumore;
• distanza microfonica;
• durata limitata;
• score di similarità intermedio.

Conclusione

«Le condizioni dei campioni non sono sufficientemente comparabili per sostenere una conclusione affidabile sull’identità del parlante.»

100. Caso pratico 9 — Falso operatore bancario

Scenario

Un cliente di Roma riceve una chiamata con voce apparentemente naturale che cita dati reali del conto.

Risultati

• dati provenienti da precedente phishing;
• voce sintetica interattiva possibile;
• registrazione telefonica degradata;
• numero falsificato;
• ordine di trasferire denaro;
• nessun contatto proveniente dai sistemi della banca.

Conclusione

«Il contenuto e la provenienza della chiamata risultano incompatibili con una comunicazione verificata della banca. La qualità del segnale non consente di stabilire con certezza la tecnologia vocale utilizzata, ma tale limite non modifica la natura ingannevole della comunicazione documentata.»

101. Caso pratico 10 — Imitatore umano

Scenario

Un audio diffuso in un gruppo Telegram viene attribuito a un imprenditore romano.

Risultati

• detector classifica umano;
• parlante simile ma non coincidente;
• articolazione e accento differenti;
• account anonimo;
• nessuna provenienza dal dispositivo dell’imprenditore.

Conclusione

«Il segnale risulta compatibile con parlato umano. La valutazione non conferma l’attribuzione all’imprenditore e resta compatibile con un’imitazione o con un altro parlante.»

102. Caso pratico 11 — Modello generativo non conosciuto dal detector

Scenario

Un file viene prodotto con un sistema recente e sottoposto a un detector sviluppato su generatori precedenti.

Risultati

- score classificato come umano;
- watermark proprietario presente;
- provenienza della piattaforma;
- modello non rappresentato nel training del detector.

Conclusione

«La classificazione negativa del detector non è significativa rispetto al generatore non rappresentato nei dati di sviluppo. Il watermark e la provenienza documentata supportano invece l’origine sintetica.»

103. Caso pratico 12 — Audio autentico con stile insolito

Scenario

Una dirigente romana legge lentamente un testo preparato.

Risultati

• prosodia regolare;
• poche disfluenze;
• assenza di respirazioni evidenti;
• file originale sul telefono;
• video contestuale;
• metadati coerenti;
• account e dispositivo verificati.

Conclusione

«Le caratteristiche stilistiche inizialmente considerate anomale sono spiegate dalla lettura controllata del testo e dalla catena di acquisizione documentata.»

104. Errori da evitare

Errore 1 — Fidarsi dell’impressione personale

La familiarità con la voce può ingannare.

Errore 2 — Utilizzare un solo detector

Un modello può non generalizzare.

Errore 3 — Interpretare lo score come probabilità

Può essere un valore non calibrato.

Errore 4 — Non conoscere la classe positiva

Uno score alto può indicare umano o sintetico secondo il modello.

Errore 5 — Non registrare la soglia

La decisione non è riproducibile.

Errore 6 — Non conservare i pesi

Il modello può cambiare.

Errore 7 — Non calcolare l’hash del checkpoint

Non si identifica la versione esatta.

Errore 8 — Usare un detector inglese senza dichiararlo

La lingua italiana può essere fuori dominio.

Errore 9 — Ignorare il codec

WhatsApp, PBX e social modificano il segnale.

Errore 10 — Ridurre il rumore prima del detector

Il preprocessing può alterare le feature.

Errore 11 — Ricampionare senza documentarlo

Si modificano i dati.

Errore 12 — Convertire in mono indiscriminatamente

Si perdono caratteristiche dei canali.

Errore 13 — Analizzare soltanto il file derivato

Si perdono metadati e watermark.

Errore 14 — Ignorare la chat

Il contesto può essere decisivo.

Errore 15 — Ignorare l’account compromesso

Un vocale falso può provenire dall’account reale.

Errore 16 — Attribuire il file dal numero telefonico

Il numero può essere falsificato.

Errore 17 — Attribuire il file dall’account

Le credenziali possono essere sottratte.

Errore 18 — Considerare C2PA garanzia di verità

Documenta provenienza dichiarata e integrità.

Errore 19 — Considerare assenza di C2PA prova di naturalità

La marcatura non è universale.

Errore 20 — Considerare presenza di watermark prova completa

Il watermark copre il sistema associato.

Errore 21 — Considerare assenza di watermark prova di voce umana

Può non essere stato applicato.

Errore 22 — Confondere voce sintetica e montaggio

Sono problemi differenti.

Errore 23 — Confondere imitazione umana e voice cloning

Un imitatore resta umano.

Errore 24 — Confondere riuso e sintesi

Una registrazione autentica può essere decontestualizzata.

Errore 25 — Analizzare soltanto l’intero file

Un segmento breve può essere sintetico.

Errore 26 — Usare finestre senza overlap

Si può perdere la giunzione.

Errore 27 — Considerare finestre sovrapposte indipendenti

Condividono parte del segnale.

Errore 28 — Non verificare il replay

La ri-registrazione altera i detector.

Errore 29 — Considerare rumore reale prova di parlato umano

Può essere aggiunto o acquisito durante il replay.

Errore 30 — Considerare respirazione prova di naturalità

Può essere generata o aggiunta.

Errore 31 — Considerare assenza di respirazione prova di sintesi

Può essere rimossa dal canale.

Errore 32 — Considerare prosodia regolare prova di AI

Una persona può leggere.

Errore 33 — Considerare pronuncia errata prova di AI

Può dipendere da lingua o parlante.

Errore 34 — Usare jitter e shimmer isolatamente

Dipendono da molte condizioni.

Errore 35 — Usare i formanti senza campioni comparabili

Canale e lingua influenzano la misura.

Errore 36 — Ignorare il sistema telefonico

Il codec può cancellare caratteristiche.

Errore 37 — Non acquisire il file PBX originale

Una registrazione secondaria è più debole.

Errore 38 — Caricare contenuti riservati su servizi pubblici

Si espongono dati personali e segreti.

Errore 39 — Non conservare i termini del servizio online

Il detector può riutilizzare il file.

Errore 40 — Non registrare la data del detector

Il modello online può essere aggiornato.

Errore 41 — Presentare uno screenshot come report

Mancano parametri e riproducibilità.

Errore 42 — Sommare score differenti

Le scale possono non essere comparabili.

Errore 43 — Considerare il consenso di più modelli prova certa

I modelli possono condividere i medesimi limiti.

Errore 44 — Confondere speaker similarity e autenticità

Una voce clonata può essere molto simile.

Errore 45 — Considerare bassa similarità prova di sintetico

Il canale può degradare la voce autentica.

Errore 46 — Usare campioni pubblici senza verificarli

Potrebbero essere montati o sintetici.

Errore 47 — Acquisire campioni biometrici senza necessità

Si amplia il trattamento.

Errore 48 — Creare un clone di prova senza autorizzazione

Si produce un nuovo rischio.

Errore 49 — Non proteggere i campioni vocali

Possono essere riutilizzati abusivamente.

Errore 50 — Confondere assenza di anomalie e autenticità assoluta

Una sintesi avanzata può non lasciare tracce rilevabili.

Errore 51 — Concludere che il detector è sbagliato perché non concorda con l’ascolto

Entrambi possono essere fallibili.

Errore 52 — Ignorare il contesto linguistico

Può rivelare incompatibilità.

Errore 53 — Confondere testo falso e voce falsa

Le parole possono essere false anche con voce autentica.

Errore 54 — Non acquisire le versioni precedenti

Il file può essere stato ricodificato.

Errore 55 — Non verificare la pubblicazione originaria

Le copie possono alterare il contenuto.

Errore 56 — Non documentare i limiti del dataset

Il benchmark può non rappresentare il caso.

Errore 57 — Dichiarare il modello generatore con certezza

La source attribution può essere errata.

Errore 58 — Considerare l’AI Act una prova tecnica del singolo file

Gli obblighi normativi non sostituiscono l’analisi.

Errore 59 — Formulare conclusioni giuridiche

Il perito deve restare nell’ambito tecnico.

Errore 60 — Scrivere “voce falsa al 100%”

Le conclusioni devono essere proporzionate alle evidenze.

105. Procedura operativa completa

Fase 1 — Autorizzazione

[ ] incarico;
[ ] titolare;
[ ] liceità;
[ ] quesito;
[ ] periodo;
[ ] dati biometrici;
[ ] privacy;
[ ] limiti.

Fase 2 — Acquisizione

[ ] file;
[ ] chat;
[ ] telefonata;
[ ] account;
[ ] dispositivo;
[ ] cloud;
[ ] versioni;
[ ] verbale.

Fase 3 — Conservazione

[ ] originale;
[ ] SHA-256;
[ ] copie;
[ ] accessi;
[ ] cifratura;
[ ] registro.

Fase 4 — Identificazione

[ ] estensione;
[ ] contenitore;
[ ] codec;
[ ] stream;
[ ] sample rate;
[ ] canali;
[ ] durata;
[ ] errori.

Fase 5 — Provenienza

[ ] metadati;
[ ] C2PA;
[ ] watermark;
[ ] piattaforma;
[ ] account;
[ ] sessione;
[ ] pubblicazione.

Fase 6 — Copia PCM

[ ] nessun filtro;
[ ] sample rate preservato;
[ ] canali preservati;
[ ] comando;
[ ] hash.

Fase 7 — Analisi globale

[ ] waveform;
[ ] spettrogramma;
[ ] codec;
[ ] rumore;
[ ] riverbero;
[ ] fase;
[ ] livello.

Fase 8 — Analisi locale

[ ] segmenti;
[ ] transizioni;
[ ] parole;
[ ] pause;
[ ] respirazione;
[ ] formanti;
[ ] sibilanti;
[ ] giunzioni.

Fase 9 — Detector

[ ] modello;
[ ] commit;
[ ] pesi;
[ ] hash;
[ ] dataset;
[ ] lingua;
[ ] preprocessing;
[ ] soglia;
[ ] score;
[ ] output locale.

Fase 10 — Campioni

[ ] autenticità;
[ ] autorizzazione;
[ ] lingua;
[ ] canale;
[ ] durata;
[ ] contemporaneità;
[ ] comparabilità.

Fase 11 — Confronto

[ ] parlante;
[ ] prosodia;
[ ] fonetica;
[ ] contesto;
[ ] ambiente;
[ ] canale;
[ ] alternative.

Fase 12 — Correlazione esterna

[ ] PBX;
[ ] registro chiamate;
[ ] chat;
[ ] email;
[ ] account;
[ ] IP;
[ ] dispositivo;
[ ] timeline.

Fase 13 — Interpretazione

[ ] osservazioni;
[ ] ipotesi naturale;
[ ] ipotesi sintetica;
[ ] montaggio;
[ ] replay;
[ ] imitazione;
[ ] riuso;
[ ] limiti.

Fase 14 — Relazione

[ ] materiale;
[ ] metodo;
[ ] strumenti;
[ ] risultati;
[ ] detector;
[ ] provenienza;
[ ] conclusioni;
[ ] allegati;
[ ] hash.

106. Checklist finale

Provenienza

[ ] fonte originaria;
[ ] account;
[ ] dispositivo;
[ ] chat o chiamata;
[ ] file più vicino all’origine;
[ ] versioni;
[ ] timeline.

Integrità

[ ] SHA-256;
[ ] originali protetti;
[ ] copie di lavoro;
[ ] manifesto;
[ ] catena di custodia.

File

[ ] contenitore;
[ ] codec;
[ ] sample rate;
[ ] canali;
[ ] bitrate;
[ ] pacchetti;
[ ] metadati;
[ ] errori.

Provenienza sintetica

[ ] C2PA;
[ ] watermark;
[ ] generatore dichiarato;
[ ] account piattaforma;
[ ] marcatura;
[ ] perdita durante l’export.

Segnale

[ ] waveform;
[ ] spettrogramma;
[ ] pitch;
[ ] formanti;
[ ] prosodia;
[ ] respirazione;
[ ] rumore;
[ ] riverbero;
[ ] fase.

Detector

[ ] versione;
[ ] pesi;
[ ] hash;
[ ] dataset;
[ ] lingua;
[ ] codec;
[ ] soglia;
[ ] segmentazione;
[ ] score;
[ ] limiti.

Confronto

[ ] campioni autorizzati;
[ ] qualità comparabile;
[ ] stile comparabile;
[ ] durata;
[ ] canale;
[ ] periodo;
[ ] alternative.

Relazione

[ ] fatti separati dalle deduzioni;
[ ] nessuno score presentato come certezza;
[ ] limiti dichiarati;
[ ] attribuzione prudente;
[ ] dati protetti;
[ ] allegati verificabili.

107. Output minimo dell’accertamento

1. incarico;
2. verbale di ricezione;
3. registro dei reperti;
4. file originale;
5. hash SHA-256;
6. copia PCM;
7. ffprobe JSON;
8. MediaInfo JSON;
9. ExifTool JSON;
10. inventario pacchetti;
11. packet hash;
12. waveform;
13. spettrogramma globale;
14. spettrogrammi locali;
15. output Praat;
16. annotazioni;
17. analisi del rumore;
18. analisi del riverbero;
19. analisi dei canali;
20. analisi della fase;
21. report C2PA;
22. report watermark;
23. file dei modelli;
24. hash dei pesi;
25. ambiente software;
26. parametri detector;
27. output detector globale;
28. output detector per segmenti;
29. campioni di riferimento;
30. tabella comparabilità;
31. confronto del parlante, se richiesto;
32. dati PBX o chiamata;
33. acquisizione chat;
34. timeline;
35. matrice delle ipotesi;
36. tabella dei limiti;
37. relazione tecnica;
38. allegati;
39. manifesto hash.

108. Struttura della relazione tecnica

108.1 Incarico

• committente;
• quesito;
• autorizzazione;
• periodo;
• limiti.

108.2 Materiale

• file;
• fonte;
• account;
• dispositivo;
• versioni;
• hash.

108.3 Provenienza

• chat;
• chiamata;
• piattaforma;
• C2PA;
• watermark;
• metadati.

108.4 Metodo

• strumenti;
• versioni;
• parametri;
• preprocessing;
• copie;
• ambiente.

108.5 Analisi del file

• contenitore;
• codec;
• pacchetti;
• durata;
• canali;
• errori.

108.6 Analisi acustica

• waveform;
• spettrogramma;
• prosodia;
• formanti;
• rumore;
• riverbero;
• fase.

108.7 Detector

• modello;
• dataset;
• pesi;
• soglia;
• score;
• segmenti;
• limiti.

108.8 Campioni di riferimento

• autenticità;
• comparabilità;
• qualità;
• periodo;
• lingua.

108.9 Correlazione

• account;
• dispositivo;
• rete;
• PBX;
• timeline;
• contesto.

108.10 Ipotesi

• voce naturale;
• sintesi;
• voice conversion;
• montaggio;
• imitazione;
• replay;
• riuso.

108.11 Conclusioni

Risposte tecniche proporzionate al quesito.

109. Modelli di frasi tecniche

109.1 Compatibilità con audio sintetico

“Il reperto presenta caratteristiche compatibili con un processo di generazione o trasformazione sintetica, da valutare congiuntamente alla provenienza e alle limitazioni del canale.”

109.2 Nessuna anomalia conclusiva

“Non sono stati rilevati indicatori sufficienti per sostenere l’ipotesi di generazione sintetica. Tale risultato non consente di escluderla in termini assoluti.”

109.3 Detector positivo

“Il modello ha prodotto uno score superiore alla soglia dichiarata per la classe sintetica; l’esito è riferito alle condizioni e ai limiti del detector indicato.”

109.4 Detector negativo

“Il modello ha classificato il segmento come umano. Il risultato non esclude generatori, codec o trasformazioni non rappresentati nei dati di sviluppo.”

109.5 Score

“Lo score non è stato interpretato come probabilità di autenticità del singolo reperto.”

109.6 Detector discordanti

“I detector applicati hanno restituito risultati discordanti, compatibili con una limitata generalizzazione rispetto al caso.”

109.7 Domain shift

“Lingua, codec e condizioni del canale differiscono da quelle dichiarate per lo sviluppo del modello.”

109.8 Replay

“Le caratteristiche del file risultano compatibili con una riacquisizione acustica, condizione che può attenuare gli indicatori della sintesi originaria.”

109.9 Audio parziale

“Il risultato globale non esclude la presenza di segmenti sintetici brevi; l’analisi locale ha evidenziato gli intervalli descritti.”

109.10 Voice conversion

“Le osservazioni risultano compatibili con una trasformazione dell’identità vocale applicata a parlato sorgente.”

109.11 Imitazione

“Il segnale appare di origine umana, ma tale risultato non consente di attribuire la voce alla persona rappresentata.”

109.12 Riuso

“Il segmento coincide con materiale autentico precedentemente pubblicato e risulta riutilizzato nel nuovo contesto.”

109.13 Campione breve

“La durata e la limitata copertura fonetica riducono l’affidabilità delle analisi automatiche e comparative.”

109.14 Campioni non comparabili

“Le differenze di canale, lingua e stile non consentono un confronto vocale sufficientemente robusto.”

109.15 C2PA valido

“Il manifesto C2PA dichiara un’origine algoritmica e risulta validamente associato al file esaminato.”

109.16 Assenza di C2PA

“L’assenza di Content Credentials non consente di determinare se l’audio sia naturale o sintetico.”

109.17 Watermark

“Il detector ufficiale ha rilevato il watermark associato al sistema indicato, nei limiti della relativa implementazione.”

109.18 Assenza di watermark

“La mancata rilevazione del watermark non esclude l’origine sintetica né l’utilizzo di un generatore differente.”

109.19 Account

“Il contenuto è stato inviato dall’account indicato, ma tale dato non dimostra chi ne controllasse le credenziali.”

109.20 Numero telefonico

“Il numero visualizzato non consente autonomamente di verificare l’origine della chiamata.”

109.21 Identità del parlante

“L’accertamento di origine sintetica è distinto dall’identificazione forense del parlante.”

109.22 Verità delle parole

“L’analisi tecnica non determina la veridicità delle dichiarazioni rappresentate.”

109.23 Attribuzione del generatore

“Gli indicatori non consentono di identificare con certezza il modello o la piattaforma utilizzati.”

109.24 Attribuzione personale

“La produzione del file non può essere attribuita a una persona fisica sulla base del solo segnale audio.”

109.25 Conclusione prudente

“Nei limiti del materiale disponibile, la convergenza degli elementi sostiene maggiormente l’ipotesi indicata, senza escludere le alternative tecnicamente plausibili descritte.”

110. Immagini e figure suggerite

111. Riferimenti tecnici e normativi esterni

1. NIST AI 100-4 — Reducing Risks Posed by Synthetic Content, produzione, provenienza e rilevamento dei contenuti sintetici.
2. ASVspoof 5 Evaluation Plan, benchmark per deepfake detection e speaker verification robusta allo spoofing.
3. ASVspoof 5 Dataset e analisi 2026, generalizzazione, codec neurali, attacchi avversari e limiti cross-domain.
4. ReplayDF, studio sugli effetti della riproduzione e ri-registrazione contro i detector audio.
5. C2PA Technical Specification 2.4, incorporamento nei formati audio e trainedAlgorithmicMedia.
6. C2PA Guidance for AI/ML, dichiarazioni su modelli, ingredienti e contenuti algoritmici.
7. AudioSeal, ricerca sulla marcatura localizzata del parlato generato.
8. SynthID, marcatura e rilevamento di contenuti generati, inclusi gli audio.
9. Commissione europea — Articolo 50 AI Act, trasparenza dei contenuti sintetici e applicazione dal 2 agosto 2026.
10. Legge 23 settembre 2025, n. 132, introduzione della disciplina italiana sui contenuti vocali falsificati con AI.
11. Garante per la protezione dei dati personali — Voce e riconoscimento biometrico.
12. EDPB — Virtual Voice Assistants, trattamento della voce e identificazione biometrica.
13. ENFSI — Forensic Speech and Audio Analysis, manuali per confronto del parlante e autenticità audio.
14. Praat, analisi del parlato, pitch, formanti, jitter, shimmer e harmonicity.
15. Sonic Visualiser, visualizzazione e annotazione di forma d’onda e spettrogramma.
16. FFmpeg e FFprobe, analisi di stream, pacchetti, codec e filtri audio.

112. Collegamenti interni consigliati

Capitolo precedente

• Autenticità audio: tagli, montaggi e ricodifiche

Capitolo successivo

• Autenticità video: frame, codec, tagli e montaggi

Capitoli correlati

• Triage iniziale della prova digitale a Roma
• Catena di custodia, hash e verbale tecnico
• Copia forense di hard disk, SSD, pendrive e NAS
• Analisi forense di computer Windows
• Analisi forense di macOS e Linux
• Acquisizione forense di smartphone Android
• Acquisizione forense di iPhone e iPad iOS
• Perizia WhatsApp: messaggi, vocali e allegati
• Telegram, Signal e app di messaggistica forensics
• Recupero dati cancellati per fini probatori
• Analisi forense di email e header
• PEC, ricevute, allegati e prova digitale
• Metadati, EXIF, XMP, C2PA e provenienza dei file
• Verifica forense di screenshot e schermate
• Acquisizione di pagine web, social e contenuti online
• Diffamazione online, cyberbullismo, stalking digitale e revenge porn
• Accessi abusivi ad account email, social e cloud
• Truffe online, bonifici fraudolenti e financial cybercrime
• Analisi di log aziendali, firewall, VPN e sistemi cloud
• Cloud forensics: Google, Microsoft, Dropbox e backup
• Analisi video deepfake e face swapping
• Immagini, fotografie manipolate e contenuti generati con AI
• Timeline forense e ricostruzione cronologica degli eventi
• Relazione tecnica, CTP informatico e contestazione delle prove digitali

113. Pagine servizio consigliate

/servizi/perizia-informatica-forense-roma/
/servizi/analisi-smartphone-computer/
/servizi/analisi-email-pec-documenti-digitali/
/servizi/acquisizione-pagine-web-social/
/servizi/consulente-tecnico-parte-informatico-roma/
/contatti/

Anchor text consigliati

perizia su voice cloning a Roma
analisi forense di un deepfake audio
verifica di una voce clonata
analisi di un falso messaggio vocale
detector di audio generato con AI
perizia su chiamata con voce sintetica
analisi di vishing con intelligenza artificiale
verifica C2PA di un file audio
confronto tra voce sospetta e campioni autentici
analisi di un vocale WhatsApp sintetico
perizia su audio parzialmente generato
consulente informatico forense per deepfake audio a Roma

114. Box commerciale finale

Hai ricevuto una chiamata o un vocale sospettato di voice cloning a Roma?

Lo Studio Quaranta Digital Forensics può supportare privati, aziende, professionisti, avvocati e studi legali nell’analisi tecnica di:

[ ] messaggi vocali sintetici;
[ ] telefonate fraudolente;
[ ] voice cloning;
[ ] text-to-speech;
[ ] voice conversion;
[ ] vocali WhatsApp;
[ ] audio Telegram e Signal;
[ ] falsi ordini aziendali;
[ ] chiamate bancarie sospette;
[ ] audio diffamatori;
[ ] contenuti parzialmente sintetici;
[ ] registrazioni riacquisite da altoparlante;
[ ] Content Credentials C2PA;
[ ] watermark audio;
[ ] output di detector automatici.

L’attività può comprendere:

• acquisizione del file e della conversazione;
• calcolo hash;
• analisi di contenitore e codec;
• analisi acustica;
• verifica di provenienza;
• controllo C2PA e watermark;
• detector locali documentati;
• confronto con campioni autentici;
• acquisizione di smartphone e computer;
• analisi di PBX, account e log;
• timeline;
• relazione tecnica;
• supporto al legale e al CTP.

CTA principale: Richiedi una valutazione preliminare
CTA secondaria: Descrivi il file, la piattaforma e il punto contestato

Evita di convertire, filtrare, inoltrare o caricare il file su detector pubblici prima di una valutazione tecnica. Conserva la chat, il registro chiamate e il dispositivo sul quale è stato ricevuto.

Lo Studio non garantisce:

• individuazione certa dell’AI;
• identificazione del generatore;
• riconoscimento certo del parlante;
• attribuzione dell’autore;
• recupero del file originario;
• esito processuale.

115. Conclusione del capitolo

Il voice cloning non può essere accertato mediante un semplice confronto d’ascolto o attraverso una percentuale mostrata da un sito.

Una corretta analisi deve considerare l’intera catena:

campione vocale
→ modello
→ sintesi o conversione
→ vocoder
→ post-produzione
→ codec
→ piattaforma
→ replay
→ acquisizione forense
→ analisi

Ogni passaggio può aggiungere, cancellare o trasformare le tracce.

Il detector può riconoscere caratteristiche statistiche.

La fonetica può evidenziare transizioni o prosodie anomale.

C2PA può documentare una provenienza dichiarata.

Un watermark può collegare il file a uno specifico ecosistema.

L’account può documentare il canale di invio.

Il dispositivo può conservare il file originario.

Nessuno di questi elementi, isolatamente, risolve ogni domanda.

L’origine sintetica di una voce deve essere valutata attraverso la convergenza tra provenienza, struttura, segnale, modelli di rilevamento, campioni comparabili e contesto; uno score automatico non rappresenta una prova certa e l’identità apparente della voce non coincide con l’identità dell’autore del file.

Una relazione tecnicamente corretta deve indicare:

- quale file è stato acquisito;
- quale generazione rappresenta;
- quale piattaforma lo ha trasmesso;
- quali trasformazioni può aver subito;
- quali detector sono stati utilizzati;
- con quali pesi e soglie;
- quali campioni sono stati confrontati;
- quali risultati sono convergenti;
- quali sono discordanti;
- quali spiegazioni alternative restano possibili;
- quali limiti impediscono conclusioni più forti.

Un file classificato come umano può essere:

• una voce autentica;
• un imitatore;
• un montaggio di parole reali;
• un deepfake non riconosciuto;
• un audio sintetico ri-registrato.

Un file classificato come sintetico può essere:

• realmente artificiale;
• naturale ma degradato;
• ricodificato;
• fuori dal dominio del modello;
• influenzato da rumore o telefonia.

Il compito dell’informatica forense non è trasformare il dubbio in una certezza artificiale.

È costruire una valutazione:

• documentata;
• riproducibile;
• prudente;
• tecnicamente motivata;
• utile al legale e al decisore.

116. Anticipazione del capitolo successivo

Capitolo 26 — Autenticità video: frame, codec, tagli e montaggi

Il prossimo capitolo tratterà:

• acquisizione del file video originale;
• contenitori MP4, MOV, AVI, MKV e 3GP;
• codec H.264, H.265, AV1, VP9 e ProRes;
• frame rate costante e variabile;
• GOP;
• keyframe;
• PTS e DTS;
• timebase;
• frame mancanti;
• frame duplicati;
• tagli;
• concatenazioni;
• transcodifica;
• ricompressione;
• audio e video fuori sincronizzazione;
• edit list;
• metadati;
• registrazioni da smartphone;
• videosorveglianza;
• video social;
• screen recording;
• analisi con FFmpeg, FFprobe e MediaInfo;
• estrazione dei frame;
• hash;
• confronto tra versioni;
• limiti delle analisi visive;
• casi pratici ambientati a Roma;
• formule prudenti per la relazione tecnica.

Continua con il Capitolo 26 — Autenticità video: frame, codec, tagli e montaggi →