L’AI invisibile sta superando gli inventari di rete aziendali

KnowBe4 ha rimesso in discussione un vecchio presupposto della sicurezza: un inventario approvato non dimostra più che ogni risorsa attiva sia conosciuta. L’articolo di Google News mette in evidenza servizi AI, dispositivi nascosti e altre risorse che i registri convenzionali possono non rilevare. Questa combinazione trasforma una debolezza amministrativa in un problema di sicurezza attivo.

Il conflitto importante non è tra un fornitore di sicurezza e un altro. È tra registri statici ed evidenze continue. I database di approvvigionamento descrivono ciò che un’organizzazione ritiene di possedere, mentre la telemetria di rete, endpoint, identità e browser rivela ciò che le persone utilizzano davvero.

Questo divario si è ampliato con la diffusione delle funzioni AI attraverso software, estensioni del browser, interfacce di programmazione delle applicazioni e suite di produttività esistenti. Un servizio potrebbe non arrivare mai come prodotto acquistato separatamente. Può comparire tramite un aggiornamento, un account personale, una chiave API o un dispositivo di proprietà del dipendente.

L’argomentazione di KnowBe4 va quindi oltre la gestione ordinaria degli asset. I team di sicurezza devono ora individuare il comportamento del software, il movimento dei dati, le identità e i servizi esterni insieme all’hardware fisico. Devono inoltre farlo senza considerare dannosa ogni connessione insolita.

L’articolo di Google News rivela un più ampio fallimento dell’inventario

Il cambiamento centrale è semplice: gli inventari di sicurezza devono descrivere l’attività osservata, non soltanto la proprietà approvata.

L’articolo di Google News presenta il problema attraverso tre classi di asset. Gli strumenti AI rappresentano servizi esterni e software integrato. I dispositivi nascosti rappresentano hardware che ha aggirato il normale processo di registrazione. Gli asset sconosciuti coprono tutto ciò che resta visibile nella telemetria ma assente dai registri autorevoli.

Queste classi si sovrappongono, ma sollevano domande diverse. Un laptop personale potrebbe accedere a un servizio AI approvato tramite un browser non gestito. Un laptop approvato potrebbe utilizzare un modello non approvato tramite un’API. Una piattaforma di produttività autorizzata potrebbe attivare una nuova funzione AI senza un evento di acquisto separato.

Un inventario tradizionale può registrare il laptop e la suite di produttività, ma non rilevare il comportamento rischioso. Può anche registrare un fornitore AI senza mostrare quali dipendenti lo utilizzano. Nessuno dei due registri spiega quali dati attraversino il confine.

Per questo un semplice elenco di dispositivi non può supportare le moderne decisioni sul rischio. I team di sicurezza hanno bisogno di una mappa delle relazioni che colleghi utenti, endpoint, applicazioni, identità, dati e destinazioni. Ogni osservazione richiede contesto prima di diventare attuabile.

Il problema va inoltre oltre l’AI generativa. Telecamere, stampanti, apparecchiature di laboratorio, sistemi di controllo degli edifici, macchine virtuali, container e risorse cloud temporanee possono tutti sfuggire ai registri manuali. Alcuni non dispongono di agenti di gestione standard. Altri compaiono brevemente e scompaiono prima della successiva revisione programmata.

NIST ha formalizzato questa portata più ampia nel CSF 2.0. I suoi risultati relativi alla gestione degli asset coprono hardware, software, sistemi, servizi, fornitori, dati e flussi di rete. Il framework considera inoltre l’identificazione come gestione continua del rischio, non come un esercizio contabile annuale.

Questa distinzione conta perché sconosciuto non significa ostile. Un dispositivo osservato di recente potrebbe essere una sostituzione autorizzata in attesa di documentazione. Un dominio insolito potrebbe appartenere al sistema di distribuzione dei contenuti di un fornitore approvato. Un endpoint legato all’AI potrebbe supportare una funzione che i dipendenti non hanno mai attivato consapevolmente.

La scoperta dovrebbe quindi creare una coda per la classificazione. Non dovrebbe attivare automaticamente punizioni o isolamento. I team hanno bisogno di evidenze sufficienti per determinare proprietà, finalità, sensibilità e importanza per il business.

Il titolo di KnowBe4 funziona perché riduce questi casi a un’unica domanda scomoda: i difensori possono proteggere asset che non sanno nominare? La risposta dipende meno dall’acquisto di un altro scanner che dalla riconciliazione di diverse visuali incomplete.

Shadow AI mette sotto pressione i team di sicurezza da entrambe le direzioni

I responsabili della sicurezza sono sotto pressione per individuare l’uso non autorizzato dell’AI senza bloccare il lavoro utile né creare una sorveglianza eccessiva dei dipendenti.

Shadow AI indica servizi o funzionalità AI utilizzati al di fuori del processo tecnologico approvato da un’organizzazione. Il termine copre più dei dipendenti che visitano chatbot pubblici. Include anche account API personali, assistenti di programmazione, estensioni del browser, funzioni integrate e modelli eseguiti su hardware locale.

Ogni percorso lascia evidenze diverse. L’accesso via browser può comparire nei log web o dei nomi di dominio. L’attività API potrebbe comparire nei registri cloud, dei repository o di gestione dei segreti. I modelli locali potrebbero non produrre alcuna connessione esterna dopo l’arrivo dei loro file.

Questa frammentazione pone i team di sicurezza tra due esigenze. I dirigenti vogliono un inventario AI affidabile perché informazioni riservate possono entrare in sistemi esterni. I dipendenti vogliono accedere a strumenti che li aiutino a fare ricerche, redigere testi, programmare, analizzare e comunicare.

Un blocco generalizzato offre una policy chiara ma una debole visibilità operativa. Le persone possono passare a dispositivi personali, connessioni mobili o servizi meno familiari. L’organizzazione perde così l’opportunità di osservare l’utilizzo, guidare i comportamenti o fornire un’alternativa più sicura.

L’accesso senza restrizioni crea il problema opposto. I lavoratori possono inviare informazioni sui clienti, contratti, codice sorgente, note di riunioni o strategie interne a servizi con regole di conservazione poco familiari. Anche un fornitore affidabile può essere inadatto a una particolare classe di dati.

Le linee guida di Microsoft sulla scoperta delle app AI illustrano il passaggio verso controlli a livello di comportamento. Descrivono la visibilità su visite, caricamenti, contenuti incollati e altre interazioni rischiose. Si tratta di un compito diverso dal verificare se un’applicazione compare in un elenco di approvvigionamento.

L’identità aggiunge un ulteriore livello. Un account aziendale e un account personale possono raggiungere lo stesso servizio attraverso lo stesso endpoint. Il monitoraggio a livello di dominio può identificare la destinazione, ma non il contratto applicabile, l’impostazione di conservazione o l’autorizzazione dell’utente.

L’AI integrata complica ulteriormente la classificazione. Un’applicazione familiare può aggiungere riepilogo, trascrizione, previsione o generazione di contenuti tramite un aggiornamento ordinario. Il prodotto sottostante rimane approvato, mentre il suo comportamento di trattamento dei dati cambia.

I team di sicurezza sono quindi spinti a mantenere due inventari correlati. Il primo copre asset e servizi tecnici. Il secondo copre casi d’uso approvati, classi di dati, identità, proprietari e requisiti di controllo.

Questo secondo inventario non può appartenere soltanto alla sicurezza. Il procurement conosce i contratti. L’ufficio legale comprende le condizioni d’uso. I team privacy valutano il trattamento dei dati. I responsabili di reparto sanno perché i dipendenti hanno bisogno di uno strumento. I proprietari delle piattaforme comprendono configurazione e registrazione.

La risposta imposta è tanto organizzativa quanto tecnica. La sicurezza deve costruire un processo ripetibile che trasformi le scoperte in decisioni di titolarità. Altrimenti, i sistemi di rilevamento producono avvisi senza creare governance.

I dipendenti hanno anche bisogno di un percorso di segnalazione utilizzabile. Un lavoratore che trova una funzione AI utile dovrebbe poter richiedere una revisione senza aspettarsi un rifiuto automatico. Questo processo rivela la domanda prima che si sposti completamente al di fuori dei canali gestiti.

La pressione persisterà perché l’adozione dell’AI cambia più rapidamente dei cicli di revisione annuali. Un inventario trimestrale può comunque non rilevare un servizio che ha accumulato migliaia di interazioni interne in pochi giorni. La scoperta continua deve alimentare un processo più rapido di approvazione e correzione.

Le evidenze continue stanno sostituendo l’elenco statico degli asset

L’approccio vincente combina diversi segnali imperfetti, quindi misura le discrepanze tra di essi.

Nessun singolo sensore può identificare ogni asset. La scansione attiva analizza sistemi raggiungibili, ma può interrompere apparecchiature operative sensibili. Il monitoraggio passivo osserva il traffico in sicurezza, ma i dispositivi silenziosi possono restare invisibili. Gli agenti endpoint offrono dettagli, ma l’hardware non gestito ne è privo.

Un programma di scoperta affidabile considera ogni fonte come evidenza parziale. I registri di rete mostrano le connessioni. I sistemi di identità mostrano account e autenticazione. Le piattaforme endpoint mostrano applicazioni installate, processi, estensioni e file locali. I piani di controllo cloud mostrano risorse e relazioni tra servizi.

I database di procurement e configurazione restano importanti. Forniscono contesto su proprietà, contratto, ciclo di vita e business. La loro debolezza non è l’inutilità. La loro debolezza è che spesso descrivono l’intenzione anziché il comportamento attuale.

Il primo passo pratico consiste nel definire aspettative autorevoli. I team hanno bisogno di elenchi di dispositivi, servizi, identità, strumenti AI, classi di dati e percorsi di rete approvati. Questi elenchi costituiscono una base di riferimento, ma non dovrebbero mai diventare l’unica versione della realtà.

Il secondo passo consiste nel raccogliere osservazioni continuamente. I registri DHCP e di risoluzione degli indirizzi possono rivelare hardware connesso. I log dei nomi di dominio e dei proxy possono individuare servizi esterni. I log di autenticazione possono collegare l’attività alle identità. I dati endpoint possono identificare i processi che hanno avviato il traffico.

Gli ambienti cloud richiedono percorsi di scoperta propri. Le risorse possono comparire tramite automazione e scomparire dopo il completamento di un carico di lavoro. Container, funzioni serverless, database gestiti e ambienti di sviluppo temporanei potrebbero non assomigliare ai dispositivi tradizionali.

L’utilizzo dell’AI aggiunge evidenze a livello applicativo. I team possono cercare categorie di servizi note, estensioni del browser, concessioni OAuth, chiavi API legate ai modelli e trasferimenti insoliti verso destinazioni esterne. Possono inoltre verificare quali prodotti approvati hanno aggiunto di recente funzioni AI.

Il terzo passo è la riconciliazione. Ogni oggetto osservato dovrebbe essere confrontato con un record previsto. Ogni record previsto dovrebbe disporre di evidenze recenti che dimostrino che esiste ancora. La discrepanza diventa la coda di lavoro.

Questa coda necessita di categorie chiare. Un asset può essere autorizzato e documentato, autorizzato ma non documentato, non autorizzato ma benigno, sospetto o non più presente. Sconosciuto dovrebbe essere una classificazione temporanea, non un’area di stazionamento permanente.

La priorità dovrebbe seguire esposizione e conseguenza. Un gateway sconosciuto esposto a Internet merita una revisione più rapida di un dispositivo di test isolato. Un servizio che riceve dati regolamentati richiede più attenzione di uno che elabora testo di marketing pubblico.

La tecnologia operativa richiede ulteriore cautela. Questi sistemi hanno spesso cicli di vita lunghi, protocolli specializzati e tolleranza limitata alla scansione attiva. Le linee guida multiagenzia sull’inventario OT raccomandano di combinare documentazione, ispezione fisica e informazioni derivate dalla rete.

Le linee guida identificano anche attributi utili, tra cui ruolo del dispositivo, hostname, indirizzo di rete, produttore, modello, sistema operativo, posizione, protocolli, porte, servizi e account utente. Questi attributi aiutano a trasformare un indirizzo osservato in una decisione sul rischio.

Questo meccanismo cambia il modo in cui dovrebbe essere misurato il successo. Un inventario ampio non è automaticamente un buon inventario. Un programma utile misura copertura, aggiornamento, tempo di riconciliazione, titolarità e anzianità degli elementi sconosciuti non risolti.

Dovrebbe inoltre tracciare la frequenza con cui asset conosciuti diventano sconosciuti dopo le modifiche. Questa metrica mette in luce processi difettosi di onboarding, offboarding, approvvigionamento e configurazione. La discovery può quindi migliorare i sistemi che hanno creato il divario.

Il risultato non è una visibilità perfetta. È un processo difendibile che rileva il cambiamento, registra l'incertezza e assegna responsabilità. Questo vale più di un foglio di calcolo ben rifinito di cui nessuno sa dimostrare l'accuratezza.

Gli strumenti AI e i dispositivi nascosti lasciano indizi diversi

Gli asset sconosciuti diventano gestibili quando i team ne analizzano i segnali in base al tipo di asset.

Un dispositivo fisico nascosto lascia solitamente evidenze a livello di rete. Richiede un indirizzo, risolve nomi, annuncia servizi, comunica con altri dispositivi o contatta una destinazione esterna. Talvolta è possibile dedurne il produttore dall'indirizzo hardware, anche se questo indizio non è conclusivo.

Il team può quindi porsi domande concrete. Quale segmento di rete lo ha rilevato? Quando è comparso per la prima volta? Torna secondo una pianificazione? Quali protocolli utilizza? Il suo traffico assomiglia a quello di una stampante, telecamera, telefono, server o controller?

I controlli di accesso alla rete possono richiedere l'autenticazione o collocare dispositivi non familiari in segmenti con restrizioni. Tuttavia, l'isolamento dovrebbe tenere conto dell'impatto operativo. Un dispositivo medico, di produzione o di controllo degli edifici sconosciuto può supportare funzioni essenziali nonostante una documentazione insufficiente.

Un asset cloud sconosciuto presenta un altro schema. Può avere un account, un tag del proprietario, un modello di deployment o un'identità di servizio. Gli investigatori dovrebbero collegare il suo evento di creazione a un utente, una pipeline di automazione, un ticket, un repository o un progetto.

Un servizio AI nascosto può essere più difficile da classificare, perché la destinazione può essere visibile mentre il caso d'uso resta oscuro. Vedere il dominio di un fornitore di modelli non rivela se un utente abbia inviato testo pubblico o codice sorgente riservato.

Il contesto del browser e dell'endpoint aiuta a colmare questa lacuna. Un browser gestito può distinguere visite, caricamenti, contenuti incollati, download e tipi di account. I controlli dell'endpoint possono identificare l'applicazione di origine e applicare regole in base alla sensibilità delle informazioni.

L'utilizzo basato su API richiede evidenze diverse. I team di sicurezza dovrebbero esaminare archivi di segreti, repository del codice sorgente, sistemi di integrazione continua, gateway cloud, registri spese e chiamate ai servizi in uscita. Le chiavi personali possono aggirare account gestiti centralmente e limiti di utilizzo.

Anche le autorizzazioni OAuth meritano attenzione. OAuth consente a un servizio di accedere a un altro per conto di un utente. Un assistente AI con accesso a casella di posta, calendario, drive o repository può diventare una relazione significativa tra asset anche senza un nuovo dispositivo.

I modelli locali ribaltano il problema della visibilità. La loro attività di inferenza può rimanere su un endpoint, mentre i download dei modelli e gli strumenti di supporto generano eventi osservabili. Crescita dello storage, installazione di pacchetti, esecuzione di processi e utilizzo del processore grafico possono fornire un contesto utile.

Le funzionalità integrate richiedono una revisione del fornitore. I team dovrebbero monitorare note di rilascio, impostazioni amministrative, sub-responsabili del trattamento e modifiche contrattuali per le applicazioni approvate. Un fornitore conosciuto può introdurre un nuovo percorso dei dati senza cambiare il nome del prodotto familiare.

Anche i knowledge worker creano una sfida documentale. Possono combinare diversi strumenti durante un'unica attività, spostando contenuti tra un registratore di riunioni, un chatbot, un editor di documenti e una piattaforma di progetto. Ogni strumento può essere approvato, mentre il flusso combinato viola le policy.

Mantenere una chiara base di conoscenza AI può aiutare i team a documentare flussi di lavoro approvati, proprietari, evidenze e confini dei dati. La documentazione dovrebbe supportare l'indagine, non sostituire l'osservazione tecnica.

Il processo di classificazione dovrebbe concludersi con un'azione. Gli asset approvati entrano negli inventari gestiti. I servizi non necessari perdono l'accesso. Gli strumenti configurati in modo errato ricevono impostazioni più sicure. I sistemi sospetti passano alla risposta agli incidenti. I casi poco chiari mantengono un accesso limitato finché non emerge un proprietario.

Questo approccio evita di trattare tutti gli sconosciuti allo stesso modo. Riconosce inoltre che la discovery degli asset non è completa quando uno scanner produce un nome. L'organizzazione deve comprenderne lo scopo, il controllo e l'esposizione dei dati.

Una maggiore visibilità può creare rischi propri per sicurezza e privacy

La discovery continua diventa controproducente quando la raccolta supera una finalità di sicurezza definita.

L'obiezione più forte al monitoraggio esteso riguarda la privacy. I registri di browser, endpoint, identità e rete possono rivelare il comportamento dei dipendenti con notevole dettaglio. Combinare tali registri aumenta il valore investigativo, ma aumenta anche il potenziale di abuso.

Le organizzazioni dovrebbero definire cosa raccolgono, perché lo raccolgono, chi può accedervi e per quanto tempo lo conservano. Un programma di shadow AI dovrebbe concentrarsi su eventi rilevanti per la sicurezza. Non dovrebbe diventare un sistema generale per classificare l'attività dei dipendenti.

I dispositivi personali creano un confine particolarmente difficile. Un'azienda può controllare l'accesso ai dati aziendali senza pretendere visibilità sull'intero dispositivo di un dipendente. Applicazioni gestite, spazi di lavoro protetti e accesso condizionale possono preservare questa separazione.

I falsi positivi creano un altro rischio. Infrastrutture condivise, reti di distribuzione dei contenuti, integrazioni dei fornitori e servizi in background possono far sembrare insolito il traffico ordinario. Il blocco automatico basato su un dominio o un'etichetta può interrompere il lavoro legittimo.

Anche i database di classificazione invecchiano rapidamente. Emergono nuovi servizi AI, i fornitori rinominano i prodotti e le piattaforme esistenti aggiungono funzionalità basate su modelli. Le regole di rilevamento che dipendono da elenchi statici di fornitori non individueranno i nuovi servizi e classificheranno erroneamente quelli esistenti.

La crittografia limita l'ispezione della rete. Un gateway può spesso vedere la destinazione e i metadati della connessione, ma non sempre può determinare cosa abbia inviato un utente. Decrittografare il traffico aumenta la visibilità, creando però problemi di privacy, certificati, prestazioni e operatività.

Il monitoraggio degli endpoint colma alcune lacune, ma introduce problemi di copertura. Appaltatori, sistemi non gestiti, dispositivi mobili e apparecchiature specializzate potrebbero non disporre di agenti. I team di sicurezza dovrebbero segnalare questi punti ciechi anziché presentare una copertura parziale come certezza.

Esiste anche un rischio di governance nell'equiparare la discovery al controllo. Individuare un servizio AI non spiega se il suo uso fosse necessario, approvato informalmente o coperto da un accordo esistente. Le evidenze tecniche necessitano di un responsabile aziendale con accountability.

L'impostazione di KnowBe4 dovrebbe quindi essere considerata un avvertimento sulla visibilità, non la prova che ogni asset non identificato sia pericoloso. La fonte fornita non dimostra una violazione misurata, un tasso di rilevamento universale o un singolo prodotto che risolva il problema.

Il framework di NIST fornisce un importante limite. Chiede alle organizzazioni di prioritizzare gli asset in base a classificazione, criticità, risorse e impatto sulla missione. Ciò scoraggia i team dal dedicare lo stesso impegno a ogni anomalia.

Un programma maturo misura anche i limiti dei sensori. Ogni report dovrebbe indicare quali reti, endpoint, identità, account cloud e utenti remoti erano coperti. Dovrebbe distinguere l'assenza osservata dall'assenza effettiva.

I team di sicurezza possono testare le proprie affermazioni mediante esercitazioni controllate. Possono introdurre dispositivi di test autorizzati, risorse cloud temporanee, estensioni del browser e chiamate API AI. L'obiettivo è misurare quali segnali rilevano ciascun caso e quanto rapidamente gli analisti lo classificano.

Questi test dovrebbero includere condizioni di errore. Cosa accade quando un dispositivo rimane silenzioso? Il traffico API personale può aggirare un gateway gestito? Una funzionalità AI integrata appare come servizio separato? Il team può identificarne il proprietario dei dati?

Le risposte varieranno tra gli ambienti. Proprio questa variazione è il motivo per cui le organizzazioni dovrebbero resistere alle affermazioni di visibilità completa. L'obiettivo difendibile è una copertura misurabile, punti ciechi noti e periodi di incertezza progressivamente più brevi.

Tre segnali mostreranno se la discovery di rete sta recuperando terreno

Il prossimo test sarà verificare se le organizzazioni riescono a trasformare più telemetria in decisioni più rapide e sicure.

Il primo segnale è la velocità di riconciliazione. I team dovrebbero misurare l'intervallo tra la prima osservazione e la classificazione. Un intervallo più breve indica che i processi di discovery, ownership e risposta funzionano insieme.

Questa metrica dovrebbe essere separata per classe di asset. Un dispositivo fisico, una risorsa cloud, un'applicazione SaaS e un'integrazione API AI richiedono evidenze diverse. Riunirli in un'unica media può nascondere ritardi gravi.

Se i tempi di riconciliazione diminuiscono mentre i falsi positivi restano sotto controllo, il modello delle evidenze continue acquisisce credibilità. Se le code crescono più rapidamente di quanto gli analisti riescano a risolverle, i sensori aggiuntivi stanno producendo rumore anziché visibilità utile.

Il secondo segnale è la copertura dell'AI integrata e basata su API. Molti controlli iniziano dalle categorie di siti web perché il traffico del browser è più facile da identificare. Questo lascia fuori chiavi personali, flussi di lavoro degli sviluppatori, modelli locali e funzionalità AI all'interno di piattaforme approvate.

Le organizzazioni dovrebbero confrontare le scoperte nei log di rete con i risultati di endpoint, autorizzazioni di identità, sistemi cloud, repository e revisioni dei fornitori. Grandi discrepanze rivelano dove l'architettura di monitoraggio rimane incompleta.

Una copertura più ampia rafforzerebbe l'avvertimento di fondo di KnowBe4 e la risposta proposta qui. Una dipendenza continua da elenchi di domini web indebolirebbe le affermazioni secondo cui le imprese comprendono la propria esposizione all'AI.

Il terzo segnale è se la governance diventa più rapida senza ricorrere per impostazione predefinita al blocco universale. I team di sicurezza hanno bisogno di evidenze che i servizi utili possano passare da sconosciuti a esaminati e approvati. Hanno inoltre bisogno della prova che gli utilizzi rischiosi possano essere limitati in base a identità, classe di dati o funzionalità.

Un processo di approvazione sano dovrebbe avere proprietari nominati, requisiti di evidenza definiti e tempi decisionali chiari. Dovrebbe produrre alternative più sicure quando un servizio richiesto non può rispettare la policy. Il silenzio o una revisione indefinita incoraggiano i dipendenti ad aggirare i controlli.

Osservate come i fornitori espongono impostazioni amministrative, eventi di audit, destinazioni dei modelli e opzioni di conservazione dei dati. Una migliore telemetria dei prodotti renderà più semplice governare l'AI integrata. Log limitati lasceranno i clienti dipendenti da indizi indiretti della rete.

La lezione più ampia di questa storia di Google News non è che ogni asset invisibile sia dannoso. È che ogni asset non risolto rappresenta una domanda senza risposta su proprietà, accesso, dati e responsabilità.

I responsabili della sicurezza dovrebbero porsi una domanda pratica questo trimestre: per quanto tempo un dispositivo o servizio AI non registrato può operare prima che qualcuno gli assegni un proprietario? Dovrebbero poi testare la risposta con esempi controllati.

Se il risultato si misura in settimane, l'organizzazione ha ancora un problema di inventario statico. Se si misura in ore, con evidenze documentate e controlli proporzionati, la discovery sta diventando una capacità operativa di sicurezza.

La prossima mossa è chiara. Selezionate un segmento di rete, un ambiente cloud e un flusso di lavoro dei dipendenti ad alto utilizzo. Riconciliate i record previsti con l'attività osservata, classificate ogni discrepanza e registrate i punti ciechi. Questo esercizio rivelerà più di un altro foglio di calcolo dell'inventario e mostrerà se l'organizzazione può davvero smascherare ciò che i controlli esistenti non riescono a vedere.