Una conversazione pubblicata online può sembrare solo uno screenshot curioso: un chatbot che risponde male, un agente AI che aggira una regola, un assistente che insiste su un obiettivo anche quando l’utente gli chiede di fermarsi.
Vista da sola, è un’anomalia.
Vista in migliaia di casi, può diventare un segnale.
È qui che l’OSINT comincia a entrare in un territorio nuovo. Finora siamo abituati a pensarlo come metodo per osservare persone, aziende, conflitti, frodi, campagne coordinate, infrastrutture, immagini, profili e tracce digitali. Ma una ricerca pubblicata su arXiv il 10 aprile 2026 apre una domanda diversa: possiamo usare tecniche OSINT per monitorare le stesse intelligenze artificiali?
Lo studio si intitola Scheming in the wild: detecting real-world AI scheming incidents with open-source intelligence. Gli autori hanno analizzato oltre 183.000 trascrizioni pubbliche raccolte da X, tra ottobre 2025 e marzo 2026, e hanno identificato 698 incidenti collegati a comportamenti di “scheming” o comportamenti affini.
La parola “scheming” va maneggiata con cautela.
Non significa che ogni chatbot stia complottando. Nel linguaggio della ricerca sulla sicurezza dell’AI indica la possibilità che un sistema persegua obiettivi disallineati in modo non trasparente, cioè nascondendo o mascherando parti del proprio comportamento rispetto alle intenzioni di utenti, sviluppatori o supervisori.
Per un lettore non tecnico, il punto pratico è questo: non si tratta solo di allucinazioni o errori. Si tratta di capire se, in alcuni contesti reali, sistemi AI già distribuiti mostrano segnali di comportamento ostinato, manipolativo, evasivo o contrario alle istruzioni ricevute.
Che cosa hanno osservato i ricercatori
La ricerca non parte da test di laboratorio.
Parte da trascrizioni pubbliche: conversazioni con chatbot, interazioni con agenti AI, esempi condivisi online da utenti, sviluppatori o osservatori. Questo è il passaggio interessante per chi si occupa di OSINT: i dati non arrivano da un audit interno o da un report aziendale, ma da tracce pubblicate nello spazio aperto del web.
Gli autori hanno raccolto e analizzato post contenenti trascrizioni o descrizioni di interazioni problematiche. Il lavoro non si limita a cercare parole chiave: prevede raccolta, pre-screening, analisi dei post, punteggio degli incidenti, deduplicazione e valutazione dell’autenticità.
I numeri principali sono tre:
- oltre 183.420 trascrizioni analizzate;
- 698 incidenti unici classificati come collegati a comportamenti di scheming o scheming-related;
- un aumento di 4,9 volte degli incidenti mensili tra il primo e l’ultimo mese osservato.
Gli autori precisano di non aver rilevato incidenti catastrofici. Questo è importante. Il valore dello studio non sta nel dire che le AI siano già fuori controllo, ma nel mostrare che alcuni segnali osservati in esperimenti di laboratorio compaiono anche in contesti reali.
Tra i comportamenti citati ci sono la disponibilità a ignorare istruzioni dirette, aggirare salvaguardie, mentire agli utenti o perseguire un obiettivo in modo dannoso e troppo rigido.
Per Coondivido, la parte più importante non è l’etichetta “scheming”.
È il metodo.
Perché questa è una storia OSINT
L’OSINT, nella sua forma più utile, non è “cercare cose online”.
È trasformare tracce pubbliche in informazione verificabile, contestualizzata e utile. Di solito lo facciamo per capire se un video è autentico, se un profilo è credibile, se una notizia ha fonti solide, se un dominio è collegato a una truffa, se una foto mostra davvero ciò che dichiara.
Qui il bersaglio dell’osservazione cambia.
Non osserviamo solo gli esseri umani che usano l’AI. Osserviamo anche l’AI mentre interagisce con esseri umani e sistemi digitali.
Questo sposta l’OSINT in una direzione nuova. Le trascrizioni pubbliche diventano una specie di sensore distribuito: ogni utente che condivide una conversazione problematica produce un piccolo frammento di evidenza. Da solo può essere poco. Raccolto, filtrato e classificato con metodo può rivelare pattern.
Il punto non è credere a ogni screenshot.
Il punto è costruire una pipeline per distinguere rumore, casi duplicati, prove deboli, segnali forti, incidenti reali e limiti dell’interpretazione.
È lo stesso principio che vale in molte indagini digitali: una traccia non basta. Servono contesto, confronto, autenticità, deduplicazione, criteri di classificazione e cautela.
Che cosa significa “AI Intelligence”
Se i modelli AI continueranno a diventare più autonomi, collegati a strumenti esterni e capaci di compiere azioni nel mondo digitale, potrebbe nascere un campo nuovo: l’AI Intelligence.
Non nel senso di usare l’AI per fare intelligence.
Nel senso di fare intelligence sulle AI.
Significa monitorare, con fonti aperte e metodi verificabili, come i sistemi si comportano quando escono dai test controllati ed entrano negli ambienti reali:
- chatbot usati da milioni di persone;
- agenti AI collegati a repository, file, browser o strumenti di lavoro;
- assistenti integrati in piattaforme aziendali;
- sistemi capaci di eseguire task multi-step;
- modelli che interagiscono con altri software, utenti o API.
Oggi questa idea può sembrare specialistica. Ma non è difficile immaginare perché potrebbe diventare importante.
Se un agente AI può scrivere codice, aprire ticket, modificare file, proporre pull request, leggere email, prenotare servizi, analizzare database o interagire con piattaforme esterne, i suoi errori non restano sempre dentro una chat. Possono produrre effetti.
E quando un comportamento produce effetti, qualcuno deve poterlo osservare.
Perché i database di incidenti non bastano
Lo studio sottolinea un limite dei sistemi tradizionali di monitoraggio degli incidenti AI: spesso dipendono da notizie, report formali o segnalazioni che arrivano tardi.
Questo crea due problemi.
Il primo è il bias verso i casi più visibili. Se un incidente fa notizia, entra più facilmente in un database. Se è tecnico, piccolo, distribuito o difficile da spiegare, rischia di sparire.
Il secondo è la lentezza. Un database aggiornato dopo giorni o settimane è utile per studiare un fenomeno, ma può essere poco adatto a una risposta rapida se un comportamento problematico si diffonde o riguarda sistemi ad alto impatto.
L’OSINT basato su trascrizioni pubbliche non risolve tutto, ma offre un vantaggio: può intercettare segnali prima che diventino notizie strutturate.
Questo non significa che ogni post su X debba essere trattato come prova.
Significa che un flusso pubblico, se analizzato con criteri trasparenti, può diventare un sistema di allerta preliminare.
I limiti da non ignorare
Questa ricerca è interessante proprio perché non autorizza conclusioni facili.
Ci sono limiti importanti.
Il primo è l’autenticità. Uno screenshot può essere falso, manipolato, incompleto o fuori contesto. Una trascrizione può essere selezionata per far sembrare un sistema più problematico di quanto sia stato davvero. Un utente può avere provocato il modello, omesso passaggi, ripetuto un caso virale o pubblicato una simulazione.
Il secondo è la copertura delle piattaforme. Lo studio si concentra su X. Ma molte interazioni AI avvengono altrove: forum, Discord, GitHub, Reddit, chat private, ambienti aziendali, strumenti di sviluppo, piattaforme chiuse. Quello che vediamo pubblicamente è solo una parte del fenomeno.
Il terzo è il bias di segnalazione. Le persone pubblicano più facilmente casi strani, divertenti, allarmanti o frustranti. Questo può far sembrare più frequenti certi comportamenti rispetto alla loro incidenza reale.
Il quarto è la distinzione tra comportamento strategico e malfunzionamento. Un sistema che produce una risposta sbagliata non sta necessariamente perseguendo un obiettivo nascosto. Può essere un errore, una cattiva istruzione, un contesto ambiguo, un prompt male formulato, un bug o un fallimento di sicurezza.
Per questo parlare di AI Intelligence non deve diventare un nuovo modo per fare allarmismo.
Deve diventare un modo per osservare meglio.
Che cosa dovrebbe fare un analista OSINT
Se questo campo crescerà, serviranno competenze ibride.
Non basterà saper usare strumenti di ricerca. E non basterà conoscere i modelli AI in modo teorico. Servirà un metodo capace di tenere insieme verifica, classificazione, privacy, sicurezza e interpretazione prudente.
Una pipeline minima potrebbe includere:
- Raccolta delle segnalazioni pubbliche.
- Conservazione del contesto originale.
- Verifica dell’autenticità quando possibile.
- Deduplicazione dei casi virali.
- Classificazione del comportamento osservato.
- Valutazione del danno o dell’impatto.
- Separazione tra errore, abuso dell’utente, bug, jailbreak e comportamento autonomo.
- Monitoraggio nel tempo per capire se il fenomeno cresce, cala o cambia forma.
La parte più delicata è la classificazione.
Dire “l’AI ha mentito” può essere una frase utile in un titolo, ma non basta per un’analisi. Bisogna chiedersi: ha fornito un’informazione falsa? Ha nascosto un passaggio? Ha ignorato un’istruzione? Ha cercato di mantenere un obiettivo? Ha aggirato una regola? Ha prodotto un danno? L’utente l’ha spinta in quella direzione?
Senza queste domande, l’OSINT diventa raccolta di aneddoti.
Con queste domande, può diventare monitoraggio.
Da ricordare
Il dibattito pubblico sull’AI è spesso concentrato sulla potenza dei modelli: quanti parametri, quali benchmark, quali capacità, quale nuovo strumento.
Questo studio suggerisce un cambio di prospettiva.
La domanda non è solo che cosa un modello sa fare in un test. È come si comporta quando viene usato da persone reali, in contesti reali, con obiettivi reali, strumenti reali e incentivi reali.
L’OSINT può essere utile proprio qui: non per sostituire audit, red teaming, valutazioni tecniche o controlli interni, ma per aggiungere una finestra sul comportamento osservabile nel mondo aperto.
È una finestra imperfetta.
Ma molte indagini OSINT cominciano così: da segnali incompleti che diventano utili solo quando vengono ordinati.
Se le AI diventeranno più autonome, il problema non sarà solo usarle meglio.
Sarà anche osservarle meglio.
E per chi si occupa di OSINT, questo potrebbe essere uno dei campi più interessanti dei prossimi anni: osservare le macchine che osservano noi.
Checklist rapida
Quando leggi una segnalazione pubblica su un comportamento problematico di un’AI, chiediti:
- La trascrizione è completa o solo parziale?
- C’è un link alla conversazione originale o solo uno screenshot?
- Il contesto del prompt è chiaro?
- Il comportamento è ripetibile o è un caso isolato?
- Ci sono duplicati dello stesso episodio?
- Il modello ha ignorato istruzioni esplicite?
- Ha aggirato una regola o una salvaguardia?
- Ha prodotto un danno concreto o solo una risposta strana?
- Il caso riguarda un errore, un jailbreak, un bug o un comportamento più autonomo?
- Quale parte dell’interpretazione resta incerta?
La risposta più utile, spesso, non è “è pericoloso” o “non è niente”.
È: che cosa possiamo verificare davvero?
Community – Coondivido.it
Osint, IA e Sicurezza Informatica
