Creare un gestionale con l’IA: fin dove si arriva da soli e cosa controllare
Creare un gestionale con l’IA si può: descrivendo a parole quello che serve, un assistente o un costruttore di app restituisce un prototipo che si apre, salva e mostra i dati. Resta il lavoro su chi può vedere che cosa, sui casi fuori dal percorso previsto e sulle copie di sicurezza. Qui trovi quattro passaggi per partire e i controlli da fare prima di inserire i dati veri dei clienti.
In questo articolo
Il prototipo si ottiene: il lavoro che resta riguarda dati e permessi
Gli strumenti sono di due famiglie. L’assistente che scrive codice produce i file del programma: pubblicarli, collegarli a un database e tenerli aggiornati resta di norma compito di chi li ha chiesti. Il costruttore di app genera l’applicazione e la ospita sui propri server, con database e indirizzo già pronti. In entrambi i casi si lavora in linguaggio naturale: lo chiamano vibe coding.
Il prototipo che ne esce fa quello che si vede: schermate, moduli, elenchi, un accesso con email e password. Il resto dipende da domande che nessuno gli ha posto: chi può leggere quali righe, che cosa succede se due persone salvano insieme, come si recupera un archivio cancellato per errore.
La differenza la fa chi rivede regole di accesso e casi limite, e per rivederli bisogna sapere che cosa cercare. Una parte di quelle verifiche si fa senza leggere codice: con due account, due finestre del browser e qualche domanda allo strumento.
Come creare un gestionale con AI: da dove partire in quattro passaggi
I quattro passaggi si fanno senza scrivere codice. Chiedono di decidere, prima di aprire lo strumento, che cosa il programma deve ricordare e a chi lo deve mostrare.
Passo 1: Scrivere dati e regole prima del primo prompt
Su un foglio va l’elenco delle cose da ricordare: clienti, appuntamenti, ordini, pagamenti. Accanto a ognuna, chi la può vedere e chi la può modificare. Una frase come «ogni collaboratore vede solo i propri clienti, il titolare vede tutto» è la regola che lo strumento non può indovinare.
Passo 2: Scegliere fra assistente e costruttore di app
Conta chi terrà acceso il programma: con l’assistente tocca a te, con il costruttore di app programma e dati stanno sui suoi server. Prima di scegliere conviene leggere dove stanno i dati e che cosa cambia fra piano gratuito e piani a pagamento.
Passo 3: Costruire un solo flusso dall’inizio alla fine
Nel primo prompt si copiano l’elenco e le regole del foglio, poi si chiede un solo percorso completo: per esempio dalla richiesta del cliente all’appuntamento chiuso. Chiedere tutto insieme lascia molte schermate e nessuna provata fino in fondo. Un flusso solo mostra subito se il modello dei dati, cioè quell’elenco, sta in piedi.
Passo 4: Provarlo con dati finti e con due utenti diversi
Nomi inventati, mai l’archivio vero. Si creano due account, si inserisce un dato con il primo e si prova a leggerlo, modificarlo e cancellarlo con il secondo. Poi si fa quello che fa un utente distratto: due tocchi su Salva, un campo vuoto, la pagina chiusa a metà.
Dove un gestionale generato regge: strumenti interni e prototipi
In alcuni usi il risultato si può adoperare così com’è. Hanno una cosa in comune: un errore sui dati costa poco.
Uno strumento interno per una sola persona
Il registro dei preventivi che usi solo tu, il calcolo dei turni, l’elenco delle scadenze. Con un utente solo la domanda su chi vede che cosa quasi non si pone. Resta da sapere dove sono salvati i dati e come se ne tiene una copia.
Dati che non riguardano persone
Listini, inventario, misure di un cantiere, codici di magazzino. Appena entrano nomi, telefoni, indirizzi o note sui clienti la categoria cambia: sono dati personali, con obblighi verso le persone a cui appartengono.
Un prototipo da portare a uno sviluppatore invece di un documento
Costruire una prima versione obbliga a decidere cose che in una riunione restano vaghe: quali campi servono, in che ordine si lavora. Chi poi deve stimare il lavoro vede il flusso e trova prima le regole che mancano. Da che cosa dipenda il prezzo lo spieghiamo nell’articolo su quanto costa un gestionale personalizzato.
Il primo controllo: ogni utente arriva solo ai dati che gli spettano
Prendiamo uno studio con tre collaboratori, ognuno con i suoi clienti. Nel prototipo ciascuno entra con la propria password e vede il proprio elenco. Sembra fatto. Resta da capire dove avviene il controllo. Se è la schermata a scegliere quali righe mostrare, il database le consegna tutte a chiunque sappia chiederle. Quando a rifiutare è il database, la schermata può anche sbagliare. Per questo, anche quando la prova con due account va bene, va chiesto allo strumento dove sono scritte le regole di accesso.
Un esempio di regole scritte nel database viene da DietApp, la nostra app per i piani alimentari, su Google Play dal 26 settembre 2025 e solo per Android. Profilo, piano, diario e misurazioni del peso stanno su Cloud Firestore, un database di Firebase, con regole per utente. La documentazione di Firebase sulle regole di sicurezza (si apre in una nuova scheda) descrive lo schema: lettura, modifica e cancellazione passano solo se chi chiede ha fatto l’accesso e il suo identificativo coincide con quello del dato.
La stessa documentazione, in pagine diverse, segnala due trappole. La prima: una regola che verifica soltanto l’accesso apre tutti i dati a chiunque sia registrato, come nel caso dei tre collaboratori. La seconda: le librerie per il codice che gira su un server scavalcano tutte le regole. Lì i permessi deve applicarli il codice.
Quando il gestionale serve più attività, la separazione vale anche fra l’una e l’altra. In BarbierItalia, la nostra piattaforma per barbieri e parrucchieri, appena lanciata, il principio è che un salone non vede i dati di un altro. L’isolamento va progettato dal primo giorno, come spieghiamo nell’articolo sui gestionali pensati per un solo settore: aggiungerlo dopo obbliga a ripassare ogni interrogazione già scritta.
Un caso documentato sta in un registro pubblico. La scheda CVE-2025-48757 nel National Vulnerability Database (si apre in una nuova scheda) è stata pubblicata a fine maggio 2025 e riguarda un costruttore di app, nelle versioni fino al 15 aprile 2025. Descrive regole insufficienti di accesso alle righe del database: un estraneo, senza fare l’accesso, poteva leggere o scrivere tabelle dei siti generati. Riporta anche la contestazione del fornitore, secondo cui ogni cliente accetta la responsabilità di proteggere i dati della propria applicazione.
Tre precisazioni aiutano a pesare la scheda. La prima: si ferma a quella data, e oggi la documentazione del costruttore descrive una scansione a ogni pubblicazione che cerca anche le tabelle senza controllo di accesso. La seconda: il registro non ha svolto una propria analisi. La terza: chi ha segnalato dichiara di lavorare per una piattaforma concorrente. Resta un esempio del tipo di errore, senza una misura di quanto sia diffuso.
Pagamenti, stati di un abbonamento e scritture contemporanee: cosa provare
Su tre punti un prototipo può comportarsi bene nella prova semplice e male in quella vera. Vanno provati, senza darli per rotti.
Il primo sono i pagamenti. Il gestionale sa che un cliente ha pagato perché il fornitore di pagamenti gli manda una notifica. La documentazione di uno di questi fornitori avverte che la stessa notifica può arrivare più di una volta e che l’ordine di consegna non è garantito. Aggiunge che senza una verifica della provenienza, a partire dalla firma, un estraneo può inviarne di false.
In nessuno dei tre casi deve nascere un ordine in più o un accesso mai pagato. Allo strumento va chiesto che cosa fa il programma con una notifica ripetuta, con una arrivata fuori ordine e con una senza firma valida.
Il secondo sono gli stati di un abbonamento. Chi vende ne ha in mente due, attivo e non attivo. La documentazione di due fornitori ne elenca di più, e ognuno li chiama a modo suo: in prova, attivo, primo pagamento non concluso, rinnovo fallito, sospeso, disdetto. Per ciascuno va deciso che cosa vede il cliente e che cosa può ancora fare.
Il terzo sono le scritture contemporanee: due persone che salvano insieme lo stesso dato. Prendiamo Beachfy, la piattaforma per stabilimenti balneari che sviluppiamo, in pre-lancio e senza lidi attivi. Lì la disponibilità di una postazione si ricava ogni volta dalle prenotazioni, senza essere salvata a parte. Con un calcolo di questo tipo due richieste arrivate insieme per lo stesso ombrellone possono trovarlo entrambe libero: a chi va la postazione deve deciderlo il codice.
In BarbierItalia la disponibilità viene ricalcolata anche alla conferma, che fallisce se lo spazio si è chiuso: lo raccontiamo nell’articolo su gestionale e sito del salone. Sul proprio prototipo la prova la può fare chiunque: due finestre del browser, due account, lo stesso orario e il pulsante Conferma premuto quasi insieme. Uno dei due deve ricevere un rifiuto chiaro. Se passano entrambi, il gestionale ha venduto due volte la stessa cosa.
Cosa controllare prima di inserire dati veri in un gestionale generato
Otto voci, ognuna con la prova da fare. Le prime due riguardano il controllo degli accessi, che quando è difettoso occupa il primo posto fra i rischi delle applicazioni web nella classifica OWASP Top 10 del 2025 (si apre in una nuova scheda).
| Voce | Come si verifica | Perché serve |
|---|---|---|
| Autenticazione e ruoli | Con un account per ruolo, tentare le azioni degli altri. | Un collaboratore non deve arrivare a ciò che spetta al titolare. |
| Regole di accesso lato server | Con il secondo account cercare i dati del primo, poi chiedere dove stanno le regole. | Il rifiuto deve venire dal database: una schermata che nasconde le righe si aggira. |
| Backup e ripristino | Trovare dove sono le copie e ripristinarne una per prova. | Nella documentazione di due servizi di database le copie automatiche vanno attivate o dipendono dal piano. |
| Registro delle modifiche | Modificare un dato e cercare chi lo ha cambiato e quando. | Senza registro un errore o un accesso indebito non si ricostruisce. |
| Aggiornamento delle dipendenze | Chiedere l’elenco delle librerie usate e chi le aggiorna. | Il codice poggia su librerie di terzi che ricevono correzioni di sicurezza. |
| Ambiente di prova separato | Verificare che esista una copia con dati finti. | Una modifica sbagliata deve rompere la copia e lasciare intatto l’archivio. |
| Gestione degli errori | Togliere la rete durante un salvataggio, lasciare campi vuoti, premere due volte Salva. | Un errore gestito male lascia dati a metà o doppi. |
| Esportazione dei dati | Scaricare tutto in un formato apribile altrove e vedere che cosa manca. | Dice se si può cambiare strumento, e con che cosa in mano. |
Di chi sono il codice e i dati quando usi un costruttore di app
Con un costruttore di app le regole le scrivono i termini di servizio, diversi per fornitore e per piano. In quelli letti il 10 ottobre 2026 abbiamo cercato tre cose, le stesse da cercare prima di cominciare.
La prima è la proprietà del codice. I termini di due costruttori la riconoscono al cliente: uno fa salvi i diritti di terzi, l’altro la riconosce nei limiti in cui un diritto sul codice esiste per legge. In Italia il riferimento è la legge sul diritto d’autore, modificata dalla legge 132/2025. Tutela le opere dell’ingegno umano di carattere creativo anche se create con l’ausilio di strumenti di intelligenza artificiale, purché risultato del lavoro intellettuale dell’autore.
La seconda è l’uscita: come si porta via il lavoro. Nella documentazione di un costruttore l’archivio con il codice completo si scarica dai piani a pagamento, e il progetto si può sincronizzare con un repository tuo, cioè un deposito esterno del codice. L’esportazione dei dati contiene l’intero database ma lascia fuori i file caricati, il codice delle funzioni e le chiavi segrete. La regione in cui stanno i dati si sceglie all’attivazione e poi resta quella.
La terza è l’uso di quello che scrivi. I termini di due costruttori prevedono che i dati del cliente possano servire ad addestrare i modelli, e uno dei due ammette la richiesta contraria, valida per il futuro. Per gli assistenti conta il piano. In quelli per privati, nei due casi letti, l’addestramento dipende da un’impostazione dell’account, con eccezioni dichiarate dai fornitori. Nei prodotti per aziende è escluso: un fornitore lo scrive nei termini, l’altro lo applica come impostazione predefinita.
Con nomi e telefoni dei clienti si applica il Regolamento (UE) 2016/679 (si apre in una nuova scheda), il GDPR. L’articolo 28 prevede che chi fa trattare dati per proprio conto ricorra solo a responsabili con garanzie sufficienti, e che il rapporto sia disciplinato da un contratto o da altro atto giuridico. L’articolo 32 chiede misure adeguate al rischio, fra cui la capacità di ripristinare l’accesso ai dati dopo un incidente.
Da qui la domanda da fare al fornitore: in quale piano offre l’accordo sul trattamento dei dati. Un costruttore lo dichiara incluso nei piani Business ed Enterprise. Per valutare il caso specifico serve un professionista: un consulente per la protezione dei dati o un legale.
Dal prototipo allo strumento affidabile: cosa cambia con una revisione
A consigliare una revisione è lo stesso costruttore citato nel registro. La panoramica sulla sicurezza nella sua documentazione (si apre in una nuova scheda) avverte che le scansioni integrate non sostituiscono una revisione approfondita e che con dati sensibili ne va considerata una professionale.
Chi rivede legge le regole di accesso una per una, cerca il codice che gira sul server e le scavalca, controlla dove sono finite chiavi e password dei servizi collegati. Il risultato utile è un elenco scritto, che separa ciò che regge da ciò che va corretto o rifatto.
Per i nostri lavori alcune voci della tabella sono scritte sul sito. Dopo la consegna di siti e piattaforme il rapporto continuativo, concordato prima di iniziare, comprende aggiornamenti tecnici di librerie e dipendenze, backup e ripristino, monitoraggio con registrazione degli errori. CivitApp è la nostra app per i Comuni, in pre-lancio commerciale e senza Comuni aderenti. I suoi test riguardano il codice che gira sul server, le regole di accesso a database e file e l’intero percorso d’uso, provato su Comuni fittizi. Le altre righe restano criteri: non le attribuiamo a ogni prodotto.
Rivedere conviene quando il modello dei dati è giusto e i difetti stanno in permessi ed eccezioni. Riscrivere conviene quando è sbagliato il modello, cioè quando le cose che il programma ricorda non corrispondono al modo in cui l’attività lavora, o quando il programma non si può portare fuori dalla piattaforma. Sui siti esistenti accettiamo piccoli interventi quando sono definibili: se la revisione di un prototipo rientri fra questi si capisce solo guardandolo.
Domande frequenti su come creare un gestionale con AI
Si può creare un gestionale con l’intelligenza artificiale?
Sì. Descrivendo a parole dati, schermate e regole, un assistente che scrive codice o un costruttore di app produce un prototipo funzionante. Restano da verificare le parti che non si vedono: i permessi di ogni utente, i salvataggi contemporanei, le copie dei dati. Per uno strumento interno usato da una sola persona il prototipo può bastare.
Posso creare un gestionale con ChatGPT o Claude?
Sì, fino al prototipo. Al 10 ottobre 2026 OpenAI indica che Codex, l’agente che scrive codice, è incluso nei piani ChatGPT con limiti d’uso diversi secondo il piano. Il centro assistenza di Claude descrive gli artifact, i contenuti che Claude crea accanto alla conversazione, fra cui piccoli strumenti interattivi: nei piani a pagamento possono salvare dati di solo testo entro un limite di spazio. Permessi, copie e dati dei clienti restano decisioni di chi usa lo strumento.
Un gestionale con AI è sicuro per i dati dei clienti?
Dipende da controlli che lo strumento da solo non garantisce. Il primo riguarda la separazione dei dati: con un secondo account si prova a leggere i dati del primo, e deve essere il database a rifiutare. Con dati personali si applica il GDPR, che agli articoli 28 e 32 chiede un contratto, o un altro atto giuridico, con chi li tratta per tuo conto e misure adeguate al rischio.
Di chi è il codice generato da un costruttore di app?
Dipende dai termini del fornitore, da leggere prima di cominciare. In quelli di due costruttori, letti il 10 ottobre 2026, la proprietà del codice generato è riconosciuta al cliente. Uno fa salvi i diritti di terzi, l’altro la riconosce nei limiti in cui la legge prevede un diritto sul codice. Conviene verificarlo in pratica: scaricare il codice completo ed esportare i dati, controllando da quale piano è possibile.
Quando conviene far rivedere il prototipo da uno sviluppatore?
Prima di inserire i dati veri dei clienti, soprattutto quando il gestionale ha più utenti con permessi diversi, incassa pagamenti o gestisce prenotazioni. Se il modello dei dati è giusto, una revisione corregge permessi, eccezioni e copie senza buttare il lavoro. Se il modello è sbagliato, conviene riscrivere usando il prototipo come descrizione del bisogno.
