Shadow IT generato dall’AI: rischi, governance e come regolarizzare le app create dai reparti

Quando i reparti business creano app con l’AI senza passare dall’IT

L’AI ha cambiato il modo in cui nasce lo shadow IT. Prima un reparto acquistava un SaaS senza informare l’IT. Oggi può costruire una piccola app, un workflow, una dashboard o un tool interno in pochi giorni, collegarlo a fogli, CRM, email, ticket, documenti o database, e iniziare a usarlo come se fosse un sistema aziendale ufficiale.

Il problema non è che il business voglia risolvere i propri problemi: è che una soluzione utile può diventare invisibile. Nessun inventario, nessun owner tecnico, accessi non governati, dati caricati fuori perimetro, API key personali, link pubblici, retention assente e nessun piano se qualcosa si rompe.

Per CIO, CISO, IT manager e responsabili business, la domanda concreta è: quali app create con l’AI esistono già, quali dati trattano e quali devono essere regolarizzate prima che diventino critiche?

Perché l’AI accelera la proliferazione dello shadow IT

Gli AI app builder e gli strumenti di vibe coding abbassano la soglia tecnica in modo significativo. Un team marketing può creare un tool per segmentare lead, Finance può automatizzare riconciliazioni, HR può costruire un form con workflow approvativo e Operations può collegare fogli, email e ticket in pochi giorni. Molte di queste iniziative nascono per motivi legittimi: backlog IT lungo, urgenza operativa, budget limitato, bisogno di prototipare rapidamente.

Il punto critico è che appena l’app tratta dati reali, utenti, integrazioni o decisioni operative, non è più solo un esperimento. A differenza dello shadow IT tradizionale, l’app è costruita su misura e non acquistata come prodotto finito: questo la rende più difficile da censire e rende ancora più importante capire come è fatta — codice, configurazioni, storage, workflow, API, credenziali, domini, log e dati inclusi.

Il primo controllo: l’app esiste nell’inventario?

Il primo passo è sapere che l’app esiste. Se l’IT non la vede, non può applicare SSO, backup, logging, vulnerability management, policy dati, incident response o dismissione. Un inventario utile deve includere almeno questi elementi:

• Nome dell’app e reparto owner
• Scopo operativo
• Tool usato per crearla
• Utenti interni o esterni
• Dati trattati
• Integrazioni e API
• URL, domini, preview e ambienti
• Credenziali e account usati
• Criticità per il processo aziendale

Non serve partire con un censimento perfetto. Serve un processo ripetibile: survey ai reparti, discovery su domini e SaaS, revisione delle OAuth app, controllo dei repository, analisi dei costi cloud e un canale semplice per dichiarare le app esistenti senza il timore di un blocco immediato.

Classificare i dati e valutare l’impatto

Non tutte le app shadow IT presentano lo stesso livello di rischio. Un tool che riformatta testi pubblici è molto diverso da una dashboard con dati cliente, fatture, ticket, dati HR o informazioni sanitarie. La classificazione deve rispondere a poche domande essenziali:

• Tratta dati personali o dati cliente?
• Contiene dati riservati, commerciali, finanziari, HR o contrattuali?
• Legge o scrive su sistemi aziendali?
• Invia dati a provider esterni o modelli AI?
• Produce decisioni operative o solo report?
• È usata da più persone, reparti o soggetti esterni?
• Cosa succede se si ferma, perde dati o espone informazioni?

Le risposte determinano il percorso: tollerare con controlli minimi, regolarizzare, testare, migrare su piattaforma approvata o dismettere.

Accessi: link condivisi, account personali e ruoli mancanti

Molte app nate nei reparti business partono con accessi semplici — link condiviso, password comune, account personale, lista email manuale, permessi “editor” a tutti. Finché l’uso è ristretto sembra funzionare, ma quando entra un nuovo team, un consulente o un utente esterno, il modello cede. I controlli minimi da applicare sono:

• Account nominativi
• SSO e MFA dove possibile
• Rimozione degli account condivisi
• Revoca degli accessi quando una persona cambia ruolo o lascia l’azienda
• Ruoli coerenti con lettura, modifica, export e amministrazione
• Log su accessi e azioni critiche

Per le app con dati cliente o multi-reparto, è utile testare anche l’accesso diretto: un utente può cambiare ID, URL, filtro, workspace o parametro e vedere dati che non gli appartengono?

Integrazioni e API key: il rischio nascosto

Per essere utile, un’app shadow IT spesso si collega a qualcosa: Google Workspace, Microsoft 365, CRM, ticketing, email, storage, ERP, database, Slack, webhook o servizi di pagamento. Il collegamento avviene tipicamente con token personali, API key copiate, OAuth app non approvate o service account con permessi eccessivi. Questo è uno dei punti più critici: un’app piccola può avere accesso ampio a dati aziendali e, se viene compromessa, il danno non resta confinato all’app stessa.

I controlli pratici da applicare includono:

• Inventario di token, OAuth app, service account e webhook
• Scope minimi per ogni integrazione
• Credenziali aziendali, non personali
• Rotazione periodica delle chiavi
• Segregazione per ambiente
• Audit log sulle chiamate più sensibili
• Revoca delle integrazioni non più utilizzate

Esposizione pubblica, preview e domini temporanei

Gli app builder rendono facile pubblicare una preview o un dominio temporaneo. Il reparto business può condividerlo con colleghi, partner o clienti senza percepirlo come un’esposizione su internet. Gli elementi da controllare sono:

• URL pubblici e preview ancora attive
• Domini custom e sottodomini temporanei
• Indicizzazione da parte dei motori di ricerca
• Webhook raggiungibili senza autenticazione
• Endpoint admin o debug
• Storage pubblico
• CORS e callback troppo ampie

Quando l’app è raggiungibile online e gestisce login, API, dati reali o ruoli, l’inventario non è sufficiente: serve un test tecnico. In questi casi il Web Application Penetration Testing verifica il comportamento reale dell’applicazione, non solo la configurazione dichiarata.

Log, export, retention e cancellazione

Le app create dal business spesso ruotano attorno a export e fogli: CSV dal CRM, report finanziari, liste clienti, ticket, allegati, file caricati. Il rischio non è solo l’accesso abusivo, ma l’accumulo non governato di dati sensibili. È necessario sapere dove vengono salvati log e output, chi può esportare dati, per quanto tempo restano file e transcript, se esistono backup, come si cancella un dato e cosa succede quando il progetto viene abbandonato.

Un’app non più usata ma ancora connessa a dati aziendali è un rischio silenzioso: continua ad avere credenziali, link e storage attivi, ma non riceve più attenzione operativa.

Regolarizzare senza bloccare il valore

Se l’IT arriva solo per vietare, lo shadow IT si nasconde. Un percorso efficace deve classificare e regolarizzare, producendo una decisione chiara per ogni app: mantenere, correggere, migrare, testare o spegnere. Non basta “metterla a posto prima o poi”.

Classe	Esempio	Azione
Basso rischio	Tool senza dati reali, uso individuale	Registrare owner e scadenza
Medio rischio	Dashboard interna con dati non critici	SSO, accessi, retention, backup
Alto rischio	App con dati cliente, API o workflow operativo	Risk Assessment, review tecnica, test
Critico	App pubblica, multi-utente, dati sensibili	WAPT/VA, remediation prima dell’uso esteso
Non accettabile	Credenziali condivise, dati vietati, vendor non approvato	Dismissione o migrazione

Checklist per le app shadow IT create con AI

• L’app è censita in un inventario IT/security?
• Esiste un owner business e un owner tecnico?
• Quali dati tratta e da quali sistemi provengono?
• Usa dati personali, cliente, HR, finanziari o contrattuali?
• È accessibile da internet, da partner o solo da rete interna?
• Usa SSO/MFA o account condivisi?
• Quali API key, OAuth app, webhook o integrazioni utilizza?
• Quali ruoli esistono e chi può esportare dati?
• Dove finiscono log, file, export, backup e transcript?
• Esistono preview, domini temporanei o vecchie versioni ancora attive?
• È stato eseguito almeno un test di accesso con utenti diversi?
• È chiaro cosa fare se l’app viene compromessa o va dismessa?

Quando coinvolgere ISGroup

Il punto di partenza può essere un assessment leggero: inventario, dati, esposizione, owner, integrazioni e rischio. Il controllo successivo dipende da cosa emerge.

Scenario	Rischio principale	Controllo consigliato
Molte app non censite create dai reparti	Governance debole e ownership assente	Virtual CISO
Bisogna classificare dati, impatti e priorità	Rischio non compreso o non prioritizzato	Risk Assessment
App, host, domini, preview o servizi esposti	Vulnerabilità note e configurazioni aperte	Vulnerability Assessment
Web app o API con login, dati, ruoli o utenti reali	Abuso applicativo dall’esterno	Web Application Penetration Testing

La scelta non è “fare sicurezza su tutto”. È decidere quali app sono tollerabili, quali vanno regolarizzate, quali richiedono un test tecnico e quali vanno spente — prima che diventino un problema operativo o normativo.

Evidenze utili per una verifica

Per avviare una verifica strutturata è utile raccogliere: elenco delle app, owner, URL, tool usato per crearle, dati trattati, utenti, ruoli, integrazioni, API key, OAuth app, provider coinvolti, log, export, backup, domini, preview, ambienti e criticità del processo. Sono utili anche esempi concreti come screenshot, export, workflow, schema dati, configurazione degli accessi, elenco dei connettori, lista utenti e descrizione di cosa succede se l’app non è disponibile.

Domande frequenti

• Lo shadow IT generato dall’AI va sempre bloccato?
• No. Va scoperto e classificato. Alcune app possono restare operative con controlli minimi, altre devono essere regolarizzate, testate, migrate o dismesse in base al rischio che presentano.
• Qual è il primo controllo da fare?
• L’inventario. Senza sapere quali app esistono, quali dati trattano e chi le usa, qualsiasi controllo tecnico arriva in ritardo e senza contesto.
• Quando serve un Web Application Penetration Test?
• Quando l’app è raggiungibile online, espone API, gestisce login, dati reali, ruoli, upload, pagamenti o workflow usati da più utenti.
• Quando è sufficiente un Risk Assessment?
• Quando il problema principale è decidere priorità, owner, dati trattati, impatto sul business e percorso di regolarizzazione prima di avviare test tecnici.
• Chi deve essere responsabile dell’app?
• Serve almeno un owner business per processo e dati, e un owner IT/security per accessi, controlli, integrazioni e percorso di regolarizzazione.

Fonti e riferimenti

• NIST Cybersecurity Framework
• NIST AI Risk Management Framework
• CIS Control 1: Inventory and Control of Enterprise Assets
• OWASP ASVS
• OWASP SAMM