Un prototipo fatto con l'AI, come portarlo in azienda

Che cosa manca fra una demo che funziona e un'app per clienti veri, quali controlli fare, che cosa chiede il GDPR e quando conviene sistemarla invece di rifarla.

Aggiornata il 14 minuti di letturaTemi: AI, Sviluppo

Si può usare in azienda un'app fatta con l'AI?

Sì, dopo una verifica. Strumenti come Lovable, Replit o Claude Code scrivono in pochi giorni un'app che in una demo funziona: si entra, si registrano ordini, si vedono i clienti. Una demo però la usa una persona sola, con dati finti, e non prova quello che conta quando arrivano gli altri: che ognuno veda solo i suoi dati, che nessuno possa cambiare un prezzo dal browser, che i dati sopravvivano a un errore.

Nessuna delle risposte che motori di ricerca e assistenti AI danno a questa domanda dice di usarla così com'è. Lo scrive anche Lovable nella sua documentazione: i suoi strumenti di sicurezza aiutano a trovare i problemi comuni, ma «cannot guarantee complete security», e la responsabilità di dare all'app la sicurezza adatta all'uso che ne fai resta a te.

Che cosa vedi in demo Che cosa serve con utenti veri Che cosa succede se manca
Il login funziona ruoli e permessi: chi vede che cosa, chi modifica un dipendente o un cliente vede quello che non deve
I dati compaiono i dati di ogni cliente separati nel database, non solo nascosti dall'interfaccia un cliente legge gli ordini di un altro cambiando un numero nella richiesta
Le funzioni rispondono chiavi e password solo sul server chi apre il codice della pagina trova la chiave e la usa
Il totale è giusto prezzi e regole calcolati sul server un ordine da 1.000 € passa a 1 € modificando la richiesta
I dati ci sono backup automatici e un ripristino già provato dopo un errore o una cancellazione i dati non tornano
L'app va una copia di prova separata, avvisi quando qualcosa si rompe una modifica rompe la produzione e lo scopri dai clienti
L'hai fatta tu una persona che ne risponde e la aggiorna quando qualcosa si rompe nessuno sa chi deve intervenire

Una demo prova che l'idea funziona; la verifica prova che l'app regge chi la usa davvero. Il resto della guida dice che cosa può andare storto, come controllarlo da solo, che cosa chiede il GDPR, quando conviene sistemare e quando rifare, e quanto costa.

Che cosa può andare storto?

Il rischio più frequente è anche il più grave: un cliente legge i dati di un altro. Succede quando l'interfaccia mostra a ciascuno solo i suoi ordini, ma il database li consegna a chiunque li chieda. Nelle app che poggiano su Supabase, come quelle di Lovable, la protezione si chiama Row Level Security: regole che dicono, riga per riga, chi può leggere e chi può scrivere. La documentazione di Supabase è netta: una tabella esposta senza queste regole si può leggere e modificare, e vanno attivate su ogni tabella esposta.

Il caso più citato è misurato. Il 20 marzo 2025 Matt Palmer, ricercatore indipendente, ha scoperto che molte app pubblicate nella vetrina «Lovable Launched» lasciavano leggere dati sensibili degli utenti, e inserirne di falsi, a chi non ne aveva il diritto: su 1.645 app analizzate, 170 avevano endpoint esposti, 303 in tutto. La causa erano regole di Row Level Security che non corrispondevano a quello che l'interfaccia faceva vedere. Il problema è registrato come CVE-2025-48757, e Lovable lo contesta: secondo la piattaforma, proteggere i dati di ogni app spetta a chi la costruisce. Lo stesso 10,3% circola in rete attribuito a un «audit di HackNope del dicembre 2025» che non si trova: la misura è quella di Palmer.

10,3%0100

App della vetrina Lovable Launched con dati esposti

170 app su 1.645 analizzate, con 303 endpoint esposti.

Fonte: Matt Palmer, «Statement on CVE-2025-48757», 29 maggio 2025

Gli altri rischi sono meno spettacolari e altrettanto comuni. Gli esempi sono illustrativi, ma sono quelli che tornano nelle risposte dei motori e nelle guide di Supabase e Lovable.

Che cosa succede Un esempio Come si controlla
Un cliente legge i dati di un altro cambia l'ordine 1041 in 1042 nella richiesta e vede l'ordine di un'altra azienda due account di prova, ognuno cerca i dati dell'altro
Una chiave segreta arriva al browser la chiave che in Supabase scavalca ogni regola, la service_role, è nel codice della pagina si cerca nel codice pubblicato; se c'è, si sposta sul server e si cambia
Una regola vive solo nell'interfaccia il prezzo o lo sconto si cambiano nella richiesta si manda la richiesta modificata e si guarda se il server la rifiuta
Un accesso resta aperto un dipendente uscito entra ancora elenco degli utenti e dei ruoli, revoca il giorno dell'uscita
Un ordine parte due volte un doppio clic su «Conferma» crea due ordini e due addebiti si ripete la stessa richiesta e si contano gli ordini
Un backup non si ripristina il backup c'è, ma nessuno l'ha mai riportato indietro un ripristino di prova su una copia, misurando il tempo che serve

Il codice scritto dall'AI è meno sicuro?

Più spesso sì, e le misure lo dicono con numeri diversi da quelli che circolano. Veracode ha dato 80 compiti di programmazione a più di 100 modelli: quando c'era da scegliere fra una soluzione sicura e una insicura, i modelli hanno scelto quella insicura il 45% delle volte. Non vuol dire, come si legge spesso, che il 45% del codice generato fallisce in produzione.

45%0100

Compiti in cui il modello ha scelto la soluzione insicura

80 compiti di programmazione, più di 100 modelli.

Fonte: Veracode, comunicato del 30 luglio 2025 sul 2025 GenAI Code Security Report

CodeRabbit ha confrontato 470 pull request, cioè proposte di modifica al codice: 320 scritte con l'aiuto dell'AI e 150 solo da persone. In quelle scritte con l'AI ha trovato in media 10,83 problemi ciascuna contro 6,45, circa 1,7 volte tanto, e problemi di sicurezza fino a 2,74 volte più frequenti.

Problemi trovati in media per pull request

problemi per pull request
Scritte con l'aiuto dell'AI10,83Scritte solo da persone6,45

Su 470 pull request, 320 scritte con l'aiuto dell'AI e 150 solo da persone. Fonte: David Loker, «State of AI vs Human Code Generation», CodeRabbit, 17 dicembre 2025

Il punto quindi non è chi ha scritto il codice, ma chi lo controlla prima che arrivi ai clienti. Anche noi usiamo l'AI ogni giorno, e la regola è scritta nelle nostre FAQ: il codice scritto con l'aiuto dell'AI lo rivede una persona che ne risponde, e un modello non è mai l'ultimo controllo prima della produzione.

Preferisci parlarne a voce?

Prenota una call con chi lavora ogni giorno su questi temi: guardiamo insieme il tuo caso.

Prenota una call

Come capisci se la tua app è pronta?

Rispondi a otto domande: ogni no è un lavoro da fare prima di aprire l'app ad altri. Le prime quattro proteggono i dati dei clienti, e con un no su una di quelle l'app non va in produzione.

Domanda Come lo verifichi Se la risposta è no
Ogni cliente vede solo i suoi dati? con due account di prova, ognuno cerca i dati dell'altro, anche cambiando gli identificativi nelle richieste regole di accesso sul database, tabella per tabella
Chiavi e password stanno solo sul server? cerchi le chiavi segrete nel codice che arriva al browser le sposti sul server e le cambi
Prezzi, sconti e permessi li decide il server? modifichi una richiesta dal browser e guardi se passa sposti la regola sul server
Chi ha lasciato l'azienda non entra più? confronti gli utenti attivi con le persone che lavorano con te ruoli e una procedura di revoca
Hai un backup che hai già ripristinato? lo riporti su una copia e misuri quanto ci vuole backup automatici e una prova di ripristino
Provi le modifiche lontano dai clienti? guardi se esiste una copia di prova separata, con dati finti un ambiente di prova
Sai quando qualcosa si rompe? guardi se gli errori arrivano a qualcuno monitoraggio e avvisi
Qualcuno ne risponde? c'è un nome, non «chi l'ha fatta» una persona interna, o un fornitore con un contratto

Se l'hai fatta con Lovable, la sua scansione di sicurezza è un buon inizio. Quella rapida parte a ogni pubblicazione e controlla le regole di accesso al database, le librerie con vulnerabilità note e i server MCP esposti senza autenticazione; quella approfondita legge tutto il codice, cercando fra l'altro utenti che vedono o cambiano dati non loro, chiavi finite nel codice e prezzi che il cliente può modificare. La documentazione di Lovable dice anche dove si ferma: questi strumenti non sostituiscono una revisione di sicurezza approfondita, e per un'app che tratta dati sensibili consiglia una revisione professionale in più.

Lo strumento che hai usato cambia qualcosa?

Cambia dove stanno codice e dati, e come li porti via; i controlli restano gli stessi.

Strumento Che cosa fa Dove stanno codice e dati
Claude Code legge il tuo codice, modifica i file ed esegue comandi, dal terminale, dall'editor, dall'app o dal browser il codice nel tuo repository, il database che scegli tu
Lovable costruisce l'app da una conversazione il database nel backend incluso, Lovable Cloud, costruito su Supabase, o in un tuo progetto Supabase; il codice si sincronizza con GitHub
Replit il suo agente scrive il codice, prepara l'infrastruttura, configura il database e pubblica l'app su Replit, dove l'agente configura il database e pubblica l'app
Bolt costruisce siti e app, anche strumenti interni e cruscotti il database in Bolt Database, la pubblicazione su Bolt Cloud
Cursor un agente che lavora sul tuo codice: lo spiega, scrive funzioni, corregge errori il codice nel tuo repository, il database che scegli tu

Con Lovable, collega subito il progetto a GitHub: la sincronizzazione va nei due sensi, ti lascia una copia del codice fuori dalla piattaforma, ed è da lì che chi fa la verifica lo legge. Se lo scolleghi, le modifiche successive restano solo dentro Lovable. Se l'app usa Lovable Cloud e un giorno vuoi spostarla su un tuo progetto Supabase, è un lavoro manuale: si esporta il database e si rifanno autenticazione, file, segreti e collegamenti.

Dove stanno i dati, e chi fa i backup?

Prima di tutto, sappi dove sono: in quale servizio, in quale paese, con quale contratto. Se un fornitore tratta i dati dei tuoi clienti per conto tuo, il GDPR ti chiede di sceglierne uno che dia garanzie sufficienti e di regolare il rapporto con un contratto (articolo 28).

Poi i backup. Se l'app usa un tuo progetto Supabase, dipendono dal piano.

Piano Supabase Prezzo Backup automatici
Free gratuito nessuno; il progetto va in pausa dopo una settimana senza attività
Pro da 25 $ al mese giornalieri, conservati 7 giorni
Team da 599 $ al mese giornalieri, conservati 14 giorni

Il ripristino a un istante preciso, invece che al backup della notte, è un'aggiunta da 100 $ al mese ogni 7 giorni di storico. Qualunque sia lo strumento, le domande sono due: dove sono i backup, e chi sa ripristinarli. Il GDPR chiede la capacità di ripristinare tempestivamente i dati dopo un incidente e una procedura per verificare regolarmente che le misure funzionino (articolo 32), cioè un backup provato, non solo acceso. Come diciamo nelle FAQ sui backup, un backup che solo il fornitore sa ripristinare non è un backup, è un'altra dipendenza.

Che cosa chiede il GDPR se i dati escono?

Di notificarlo al Garante entro 72 ore da quando lo sai, salvo che sia improbabile un rischio per le persone, e di avvisare anche le persone coinvolte se il rischio è elevato. Ogni violazione va documentata, anche quella che non notifichi. Se nella tua app ci sono nomi, email o ordini dei clienti, sono dati personali, e il titolare del trattamento sei tu.

Obbligo Che cosa chiede Dove
Sicurezza adeguata al rischio misure tecniche e organizzative, fra cui la capacità di ripristinare i dati e una procedura per verificare regolarmente che le misure funzionino articolo 32
Notifica al Garante senza ingiustificato ritardo e, ove possibile, entro 72 ore da quando lo sai, salvo che il rischio per le persone sia improbabile; dopo le 72 ore, con i motivi del ritardo articolo 33
Documentazione ogni violazione, con le circostanze, le conseguenze e i rimedi, anche se non la notifichi articolo 33, paragrafo 5
Avviso alle persone se il rischio è elevato, senza ingiustificato ritardo e in un linguaggio semplice articolo 34
Contratto con chi tratta i dati per te un fornitore con garanzie sufficienti, e un contratto che regola il rapporto articolo 28

La panoramica AI e la modalità AI di Google citano la sanzione fino al 4% del fatturato. Per gli obblighi di sicurezza e di notifica il tetto è un altro: fino a 10 milioni di euro o al 2% del fatturato mondiale annuo, se superiore (articolo 83, paragrafo 4). Il 4%, o 20 milioni, vale per i principi, fra cui quello che chiede di trattare i dati con una sicurezza adeguata (articolo 5): una violazione grave può ricadere anche lì. Anche il costo medio di una violazione che molte risposte citano, 4,44 milioni di dollari nel 2025 secondo IBM, viene da 600 organizzazioni nel mondo e non dice quanto costerebbe alla tua azienda.

Un contributo tecnico

Le norme sono riassunte dal testo del regolamento pubblicato dal Garante, letto alla data in testa alla pagina. Come le altre guide, questa è un contributo tecnico, non un parere legale.

Conviene sistemarla o rifarla?

Lo decide la verifica, non lo strumento con cui l'hai fatta. Le risposte che si trovano in rete si dividono: la modalità AI di Google dice di rifarla; ChatGPT, Perplexity e la panoramica AI in inglese dicono di sistemarla dopo un controllo. Quelle che spiegano il perché usano lo stesso criterio che usiamo noi, il modello dei dati e i permessi. Se le tabelle sono pensate bene e manca la protezione, si aggiunge; se i dati di tutti i clienti sono mescolati e le regole stanno nell'interfaccia, ogni correzione ne chiede un'altra.

Che cosa trova la verifica Che cosa conviene
dati separati per cliente, regole da aggiungere o da stringere sistemarla
interfaccia buona, database o permessi da ripensare tenere l'interfaccia e rifare la parte che custodisce i dati
regole e calcoli nel browser, dati mescolati, collegamenti a gestionale o pagamenti ancora da fare rifarla, con il prototipo come specifica
un'app che un prodotto pronto fa già, o che non serve più fermarsi

Se sistemarla costa più di 10.000 €, conviene rifarla: è la cifra da cui parte un MVP fatto da noi. In nessuno dei due casi il prototipo si butta, perché è la specifica più chiara che tu possa dare a chi lo rifà: schermate, campi e flussi che hai già provato. Se ti chiedi se ti serva davvero un'app su misura, il confronto con gli strumenti pronti è nell'articolo Low-code, no-code o codice.

Quanto costa portarla in produzione?

Da noi la verifica costa 2.500 € a prezzo fisso e dura una settimana; se poi ci affidi il lavoro, la scaliamo dal preventivo. Sistemarla costa in genere fra 5.000 e 10.000 €, rifarla da 10.000 €, come un MVP: sono stime nostre, e la cifra del tuo caso esce dalla verifica.

Voce Quanto Che cosa ottieni
Verifica 2.500 € a prezzo fisso, in una settimana, scalati dal lavoro se prosegui i problemi in ordine di gravità, la scelta fra sistemare, rifare o fermarsi, il preventivo del lavoro
Sistemarla 5.000-10.000 € in 2-4 settimane, stima i controlli dell'elenco qui sopra messi a posto: permessi, chiavi, backup, ambienti, avvisi
Rifarla da 10.000 €, come un MVP un MVP in produzione, con il prototipo come specifica

Alla stessa domanda, posta lo stesso giorno, i motori danno cifre diverse fra loro, e nessuno dice da dove vengono. La modalità AI di Google, chiesta due volte, ha dato due forchette diverse per rifarla.

Chi risponde Sistemarla Rifarla
Panoramica AI di Google 3.000-7.000 € 12.000-25.000 €
Modalità AI di Google oltre 30.000 € 15.000-25.000 €, alla seconda richiesta 15.000-30.000 €
ChatGPT 3.600-10.700 €, alla seconda richiesta 3.000-8.000 € 12.000-30.000 € e oltre
Perplexity 1.500-4.000 € di verifica e 3.000-10.000 € di messa in produzione, 8.000-20.000 € in tutto non lo stima
Volcanic Minds 2.500 € di verifica, poi 5.000-10.000 €, stima da 10.000 €

Risposte raccolte il 29 ottobre 2026 alla domanda di un'azienda di 25 persone con un'app per ordini e clienti fatta con Lovable. Agli abbonamenti pensa subito: hosting, database e servizi esterni sono costi tuoi, e conviene conoscerli prima.

Chi la mantiene dopo il rilascio?

Una persona con un nome, interna o di un fornitore. Fra le 161 pagine che i motori citano su questa domanda, e che abbiamo letto una per una, una sola se lo chiede. Un'app in produzione va aggiornata, perché le librerie su cui poggia ricevono correzioni di sicurezza; va sorvegliata, e ogni modifica va provata prima di arrivare ai clienti. Con uno strumento di AI una modifica è facile da fare e altrettanto facile da sbagliare.

Da noi, sui progetti a corpo, c'è un mese di garanzia per i bug bloccanti e le attività minori. Dopo, la manutenzione continua solo se la vuoi, con un contratto e SLA dedicati, e la stimiamo sul lavoro che l'app chiede davvero, non come una percentuale del costo iniziale. Per un gestionale semplice, come quello dell'officina della guida sui costi, la manutenzione costa circa 2.500 € l'anno e l'hosting, a parte, da 950 € l'anno; che cosa comprende è nella guida Manutenzione di software su misura e AI. Il codice resta tuo, e i dati si esportano senza passare da noi. Se l'app deve diventare un prodotto in abbonamento, con i dati di ogni cliente isolati, è il lavoro che descriviamo in Sviluppo SaaS.

Se l'hai costruita tu e stai scegliendo a chi affidarla, i rischi di un progetto su misura e che cosa scrivere nel contratto sono nella guida Rischi di un progetto su misura. Per chi sviluppa, il confronto fra gli strumenti è nell'articolo Vibe coding.

Fonti e approfondimenti

In pratica

Domande frequenti

Tutte le domande frequenti
Un'app fatta con Lovable è sicura per i dati dei clienti?

Può esserlo, ma una demo che funziona non lo dimostra. Va controllato che ogni cliente veda solo i suoi dati, con le regole di Row Level Security attive su ogni tabella, che le chiavi segrete non arrivino al browser e che prezzi e permessi li decida il server. Nel 2025 un ricercatore ha trovato dati esposti in 170 delle 1.645 app della vetrina di Lovable che ha analizzato.

La scansione di sicurezza di Lovable basta?

No. È un buon inizio, e la versione approfondita legge tutto il codice, ma la documentazione di Lovable scrive che questi strumenti non sostituiscono una revisione di sicurezza approfondita e consiglia una revisione professionale per le app che trattano dati sensibili. La responsabilità della sicurezza dell'app resta a chi la pubblica.

Quanto costa mettere in produzione un'app fatta con l'AI?

Da noi la verifica costa 2.500 € a prezzo fisso, dura una settimana e si scala dal lavoro se prosegui. Sistemarla costa in genere fra 5.000 e 10.000 €, rifarla da 10.000 €; sono stime, e la cifra del tuo caso esce dalla verifica.

Conviene sistemare l'app o rifarla da zero?

Dipende dal modello dei dati e dai permessi, non dal fatto che il codice l'abbia scritto un'AI. Se i dati sono separati per cliente e mancano solo le protezioni, si sistema; se dati e regole sono mescolati nell'interfaccia, conviene rifarla. Se sistemarla costa più di 10.000 €, conviene rifarla, usando il prototipo come specifica.

Se i dati dei miei clienti escono, che cosa devo fare?

Se c'è un rischio per le persone, notifichi la violazione al Garante entro 72 ore da quando lo sai, e se il rischio è elevato avvisi anche le persone coinvolte (articoli 33 e 34 del GDPR). Ogni violazione va documentata, anche quella che non notifichi.

Chi è responsabile se un'app fatta con l'AI perde dei dati?

Tu, come titolare del trattamento, e non lo strumento con cui l'hai costruita. Lovable lo scrive nella sua documentazione, e Lovable stessa ha contestato la vulnerabilità CVE-2025-48757 sostenendo che proteggere i dati di ogni app spetta a chi la costruisce.

Hai un prototipo fatto con l'AI?

Raccontaci che cosa fa e con che cosa l'hai costruito. In una settimana, a prezzo fisso, ricevi i problemi in ordine di gravità, la scelta fra sistemare e rifare e il preventivo del lavoro.

Parliamo del tuo progetto
  • Non parli con un commerciale
  • NDA prima di entrare nel merito
  • Il codice resta di tua proprietà
Continua

Articoli sugli stessi temi.

Copertina dell'articolo "Web Bot Auth: visitatori senza occhi": composizione tipografica su fondo grafite con il titolo "Web Bot Auth", il sottotitolo "Good bots vs bad ones" e il logo Volcanic Minds in bianco al centro, con quattro barre d'accento a gradiente viola-rosso agli angoli.
AI, Sviluppo

Web Bot Auth: visitatori senza occhi

Gli agenti AI leggono il tuo sito e convertono meglio dell'organico, ma non compaiono negli analytics. Come misurarli e verificarli con Web Bot Auth.

Leggi
Uno studio con schizzi di wireframe su carta e schede di interfacce AI, e sullo sfondo un terminale AS/400 del 1988
AI, Sviluppo

Generative UI: per umani e macchine

Il tuo gestionale serve persone e agenti AI. Con la Generative UI l'interfaccia si compone sul contesto, con un accesso per gli agenti e un fallback manuale.

Leggi
Un edificio di cemento ripreso dal basso, con la scritta «Data segregation» incisa sulla facciata
AI, Sviluppo

SaaS multi-⁠tenant: segregare i dati in modo corretto

Cosa significa multi-tenant e come si sceglie l'isolamento dei dati in un SaaS: database dedicato, schema separato o riga condivisa, e cosa cambia con l'AI.

Leggi