Lo Ha Creato Con Lovable — Chi È Responsabile Se Perde Dati?

Un product manager ha bisogno di una dashboard interna. Invece di aprire un ticket e aspettare un trimestre l'ingegneria, apre Lovable, descrive ciò che vuole in linguaggio naturale, la collega al Google Workspace aziendale e rilascia un'app funzionante nello stesso pomeriggio. Legge da Drive, estrae alcuni fogli di calcolo e invia via email un riepilogo settimanale. Funziona. Tutti sono contenti.

Nessuno si pone la domanda che conta sei mesi dopo, quando un revisore della sicurezza o un'autorità di controllo se la pone: chi è responsabile del modo in cui quell'app gestisce i dati che tratta?

La risposta non è la piattaforma che ha generato il codice. È l'azienda che l'ha distribuita. Questo articolo spiega perché "l'abbiamo costruita con l'AI" non è una giustificazione valida, cosa esattamente va storto con le app create dall'AI, e come ottenere visibilità prima che la domanda venga posta con toni accesi.

Cosa significa davvero "app creata con l'AI"

Una nuova categoria di strumenti — Lovable, Base44, Bolt.new, Cursor e un elenco crescente di altri — consente alle persone di creare e distribuire applicazioni web reali a partire da prompt in linguaggio naturale. Vengono spesso chiamate piattaforme di "vibe coding". L'attrattiva è ovvia: una persona non sviluppatrice può produrre qualcosa che in precedenza richiedeva un team, e può farlo in poche ore.

Queste app non sono giocattoli. Vengono distribuite a utenti reali e si collegano regolarmente a sistemi aziendali reali — Google Workspace, Salesforce, database interni — tramite normali concessioni OAuth. Dal punto di vista dei dati, un'app costruita in un pomeriggio con un prompt e un'app sviluppata in mesi da un team di ingegneria appaiono identiche: entrambe detengono un token di accesso, ed entrambe possono leggere ciò che quel token consente.

Questa simmetria è il cuore del problema. La velocità che rende i builder AI attraenti è la stessa velocità che permette a un'app di raggiungere dati sensibili senza che nessuno esamini cosa ne fa.

Costruire con l'AI non equivale a essere al sicuro

Vale la pena essere precisi ed equi su questo punto: un'app costruita con Lovable o Base44 non è intrinsecamente insicura. Queste piattaforme possono produrre applicazioni perfettamente ragionevoli, e molte lo fanno. Il rischio non è che l'AI scriva codice scadente. Il rischio è la governance, e si manifesta in tre modi prevedibili.

Chi distribuisce l'app raramente legge il codice. L'intera proposta di valore del vibe coding è che non è necessario farlo. Quindi la persona che ha rilasciato l'app spesso non sa dire come vengono archiviati i dati, se vengono registrati campi sensibili, dove vengono inviate le informazioni, o per quanto tempo qualcosa viene conservato. La parte responsabile ha la minor visibilità sulla cosa di cui è responsabile.

L'accesso è ampio e invisibile. I builder AI richiedono gli ambiti (scope) che fanno funzionare la demo, e "farla funzionare" spesso significa un ampio accesso in lettura. Una dashboard interna che doveva solo leggere una cartella potrebbe detenere accesso in lettura a tutto Drive. Poiché la concessione è avvenuta tramite una normale schermata di consenso OAuth, non è mai comparsa sul radar di sicurezza di nessuno — è, per definizione, shadow IT.

Non esiste una politica documentata sulla gestione dei dati. Chieda la politica di conservazione di un sistema di produzione costruito manualmente e di solito otterrà una risposta. Chieda la politica di conservazione di un'app che un collega ha generato lo scorso martedì e non troverà nulla di registrato. Secondo il diritto della protezione dei dati, "non sappiamo per quanto tempo conserva i dati" non è una risposta neutra — è un rilievo.

Perché l'azienda — non la piattaforma — è responsabile

Ecco la parte che sorprende le persone. Quando un'app creata dall'AI gestisce male i dati, la responsabilità legale e normativa ricade sull'organizzazione che l'ha distribuita, non sul builder AI che l'ha generata.

Questo è lo stesso spostamento di responsabilità che sta ora ridefinendo il diritto dell'AI in generale. Secondo il Regolamento Generale sulla Protezione dei Dati (GDPR) dell'UE, l'entità che determina le finalità e i mezzi del trattamento dei dati personali è il titolare del trattamento, e il titolare porta gli obblighi — base giuridica, minimizzazione dei dati, limitazione della conservazione, e il dovere di dimostrare tutto ciò. Quando la sua azienda distribuisce un'app che tratta dati dei clienti, la sua azienda è il titolare del trattamento. La piattaforma builder è, al massimo, uno strumento che ha utilizzato.

Il più ampio panorama giuridico del 2026 indica la stessa direzione. I tribunali hanno iniziato a trattare l'azienda che utilizza un sistema AI come responsabile del suo comportamento — il contenzioso *Mobley v. Workday* negli Stati Uniti è proseguito sulla base di una teoria dell'agenzia (agency theory) e ha successivamente ottenuto la certificazione condizionale di un'azione collettiva a livello nazionale. In Germania, l'OLG Hamm ha affrontato la responsabilità per ciò che un sistema AI comunica ai clienti e ha segnalato che una generica clausola di esclusione "nessuna garanzia" non protegge di per sé l'azienda che lo distribuisce. L'AI Act dell'UE aggiunge ulteriori obblighi specifici per i deployer, con sanzioni significative per gli usi ad alto rischio. Trattiamo questo cambiamento in modo approfondito nella nostra panoramica su chi è responsabile quando un agente AI perde dati.

Il filo conduttore comune: distribuire un'app creata dall'AI è una decisione che la sua organizzazione ha preso, e la legge tratta le decisioni come portatrici di responsabilità. Il fatto che un'AI abbia scritto il codice non cambia nulla riguardo a chi ha scelto di collegarla ai dati aziendali.

Il punto cieco, concretamente

Mettendo insieme i pezzi emerge una modalità di guasto specifica e comune:

• Un dipendente non tecnico crea un'app con un builder AI.
• L'app si collega a Google Workspace tramite OAuth e le vengono concessi ambiti (scope) ampi.
• Raggiunge dati personali di clienti o dipendenti — contatti, contenuti email, file.
• Nessuno ha esaminato la gestione dei dati, e non esiste alcuna politica di conservazione registrata.
• La sicurezza non ha alcuna voce di inventario per l'app, perché non è mai passata attraverso una revisione.

Ogni passaggio è individualmente ragionevole. Insieme producono un'applicazione che tratta dati personali, di cui la sua azienda è legalmente responsabile, e che il suo team di sicurezza non sa che esista. Questo è il divario che un revisore sonda e che una violazione sfrutta.

Come colmare il divario

La soluzione non è vietare i builder AI — quella corsa è già persa, e la produttività è reale. La soluzione è visibilità e prove: sapere quali app create dall'AI sono collegate, sapere cosa ciascuna può raggiungere, ed essere in grado di dimostrare di averle governate.

È esattamente ciò che fa 8200.dev. Scopre le app OAuth collegate al suo Google Workspace, e segnala quelle che provengono da builder AI — Lovable, Base44, Bolt.new, Cursor e simili — a partire dalle firme del nome dell'app e dell'host di reindirizzamento, e dal caratteristico pattern di un'app non verificata, creata di recente, che già detiene ambiti (scope) ampi. Per ciascuna vede la piattaforma builder, gli ambiti esatti concessi, chi l'ha autorizzata e un punteggio di rischio, il tutto presentato in una vista dedicata AI-Built Apps accanto al resto dei suoi agenti AI e app OAuth.

Quando un'app creata dall'AI può raggiungere PII dei clienti, o detiene un ampio accesso senza una politica di conservazione documentata, viene sollevato un rilievo specifico — così il divario diventa un compito con un responsabile assegnato anziché una sorpresa in un audit. E ogni app creata dall'AI può essere registrata nell'AI Agent Registry, così anche quelle che nessun connettore raggiunge compaiono in un unico inventario completo. Può vedere qui l'intero set di funzionalità.

Il punto non è rallentare i suoi team. È assicurarsi che quando arriva la domanda — da un'autorità di controllo, un revisore, o una verifica di sicurezza di un cliente — lei possa rispondere. Non "l'abbiamo costruita con l'AI, quindi è un problema della piattaforma", che non è una giustificazione valida, ma "ecco l'app, ecco esattamente cosa può accedere, ed ecco le prove che l'abbiamo esaminata." Per uno sguardo più approfondito su cosa si aspettano oggi i revisori, consulti cosa richiedono gli auditor per la governance AI nel 2026.

Costruire con l'AI è veloce. Essere responsabili di ciò che si è costruito non è opzionale. Le due cose si conciliano con un'unica cosa: sapere cosa possono effettivamente raggiungere le sue app create dall'AI.

Inizi vedendo cosa è già collegato al suo Workspace. Può mappare le sue app create dall'AI, valutarne l'accesso e generare la sua prima prova sul piano gratuito — consulti i piani e inizi gratuitamente.

*Questo articolo è un'informazione generale, non una consulenza legale. Consulti un legale qualificato per indicazioni specifiche per la sua organizzazione.*