AI detector su testo: perplexity, humanizer e il rischio di accusa per falsi positivi
ZeroGPT ha flaggato pezzi della Costituzione USA, Frankenstein capitolo 5 e sezioni Wikipedia come AI-generated. Originality.ai e Pangram, che rivendicano 99,98% accuratezza, cedono entrambi dopo una singola passata negli humanizer commerciali. Tante aziende italiane stanno introducendo questi strumenti in HR ed editoriale, esponendosi a falsi positivi che diventano accuse reali. Approfondimento su perplexity, burstiness, come i detector falliscono matematicamente, perimetro di rischio legale. Continua a leggere
Ultima modifica:
Il miglior detector commerciale deepfake del 2026 raggiunge 78% di accuratezza su 44 ore di video, esperti forensi arrivano al 90% dichiarato. Dato il limite strutturale, la strategia difensiva passa dalla provenance: Content Credentials (firma C2PA) e SynthID (tracce nei metadata Google Veo). Tutorial pratico per configurare entrambi su un workflow aziendale, con analisi dei casi aggirabili, interoperabilità limitata, valore residuo legale e reputazionale. 
Il provvedimento Garante Privacy gennaio 2026 contro Grok/ChatGPT/Clothoff ha cristallizzato un pattern emergente: quando la qualità dei deepfake è alta, anche i contenuti autentici vengono considerati fake da pezzi di opinione pubblica. È il liar dividend. Per una PMI italiana con CEO visibile, testimonial o portavoce, è un rischio reputazionale nuovo. Checklist operativa in dodici punti per protezione del brand: monitoring, procedure di verifica, policy interna, contrattualistica. 
I computer quantistici non sono ancora una minaccia operativa, ma i dati cifrati oggi con RSA saranno decifrabili tra 10-15 anni. Per applicazioni che gestiscono dati con vita utile lunga, la migrazione verso algoritmi post-quantistici va pianificata ora. Vi racconto lo stato degli standard NIST e le implicazioni pratiche per PHP. 
Ho accompagnato una software house torinese con 20 sviluppatori nel percorso di adeguamento NIS2 come soggetto essenziale. Il processo ha richiesto 6 mesi: gap analysis iniziale, introduzione di vulnerability disclosure policy, incident response plan, log retention e controllo degli accessi. Vi racconto ogni fase con tempi e costi reali. 
La sicurezza come fase finale prima del rilascio è un fallimento annunciato. Ho aiutato un'azienda software con 12 sviluppatori a integrare sicurezza nel ciclo di sviluppo: security gate automatici in CI, revisione delle dipendenze ad ogni PR, threat modeling trimestrale. La velocità di sviluppo non è calata. 
Ho trovato una vulnerabilità critica in un gestionale PHP usato da 300 PMI italiane. Non era un mio cliente. La gestione della disclosure è stata complicata: il vendor non aveva un canale dedicato, i tempi di fix erano incerti, e le PMI erano a rischio. Vi racconto come ho gestito ogni fase. 
Alle 2 di notte, un cliente mi chiama: il suo VPS ha comportamenti anomali. Nei successivi 30 minuti, ho fatto un elenco di azioni in ordine preciso. Quell'ordine è importante: sbagliarlo significa perdere prove forensi o dare tempo all'attaccante. Vi scrivo il runbook che tengo sempre pronto. 
L'investimento in firewall e antivirus non serve a nulla se il dipendente clicca sul link di phishing. Ho aiutato un'azienda con 45 dipendenti a costruire una cultura della sicurezza partendo dalla formazione pratica, dalle simulazioni di phishing e da procedure semplici che la gente segue davvero. 
Una finanziaria di medie dimensioni mi ha chiesto di revisionare la sicurezza di un'applicazione di prestiti ancora in sviluppo. In due ore di threat modeling con STRIDE abbiamo identificato 14 rischi significativi - cinque dei quali avrebbero richiesto settimane di refactoring se scoperti dopo il lancio.