---
title: "App fatta con l'AI in produzione: controlli, rischi e costi · Volcanic Minds"
description: "Che cosa manca fra una demo fatta con Lovable, Claude Code o Replit e un'app per clienti veri: i controlli, il GDPR, sistemare o rifare, quanto costa."
url: "https://volcanicminds.com/guides/ai-prototype-to-production"
lang: "it"
type: "second_level_page"
updated: "2026-10-29"
alternate: "https://volcanicminds.com/en/guides/ai-prototype-to-production"
summary: "Un'app costruita con Claude Code, Lovable, Replit, Bolt o Cursor si può dare a clienti e colleghi dopo una verifica, non così com'è: una demo che funziona non dice se un cliente può leggere i dati di un altro, se una chiave segreta è finita nel codice che arriva al browser, se i dati hanno un backup che si ripristina. Se sistemarla o rifarla lo decidono il modello dei dati e i permessi, non il fatto che il codice l'abbia scritto un'AI."
---

# 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.

## 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.

**App della vetrina Lovable Launched con dati esposti**

10,3% su 100

170 app su 1.645 analizzate, con 303 endpoint esposti.

Fonte: [Matt Palmer, «Statement on CVE-2025-48757», 29 maggio 2025](https://mattpalmer.io/posts/statement-on-CVE-2025-48757/)

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.

**Compiti in cui il modello ha scelto la soluzione insicura**

45% su 100

80 compiti di programmazione, più di 100 modelli.

Fonte: [Veracode, comunicato del 30 luglio 2025 sul 2025 GenAI Code Security Report](https://www.veracode.com/press-release/ai-generated-code-poses-major-security-risks-in-nearly-half-of-all-development-tasks-veracode-research-reveals/)

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'AI | 10,83 |
| Scritte solo da persone | 6,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](https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report)

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](/frequently-asked-questions#ai-nel-nostro-lavoro): **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](https://vms.srl/booking)

## 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](/frequently-asked-questions#backup-rto-rpo), **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](/insights/low-code-no-code-vs-coding).

## 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](/guides/custom-software-cost#quanto-costa-un-software-su-misura-in-cifre): 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](/frequently-asked-questions#costi-ricorrenti).

## 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](/frequently-asked-questions#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](/guides/custom-software-cost#quanto-costa-dopo-il-rilascio), 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](/guides/custom-software-maintenance). **Il codice resta tuo**, e i dati [si esportano senza passare da noi](/frequently-asked-questions#cambio-fornitore). Se l'app deve diventare un prodotto in abbonamento, con i dati di ogni cliente isolati, è il lavoro che descriviamo in [Sviluppo SaaS](/saas-development).

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](/guides/custom-software-project-risks). Per chi sviluppa, il confronto fra gli strumenti è nell'articolo [Vibe coding](/insights/vibe-coding-tools-for-devs).

## 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](/contacts)

## Articoli sugli stessi temi.

*Continua*

- [Web Bot Auth: visitatori senza occhi](/insights/web-bot-auth-agentic-traffic.md): 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.
- [Generative UI: per umani e macchine](/insights/generative-ui-agents-dual-mode.md): Come la generative UI e la dual-interaction UX semplificano i gestionali B2B, con interfacce progettate insieme per le persone e per gli agenti AI.
- [SaaS multi-tenant: segregare i dati in modo corretto](/insights/multi-tenant-ai-saas-strategy.md): 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.