Hai creato un’app con l’AI: cosa verificare prima di usarla in azienda

Prima di usare in azienda un’app creata con AI, verifica che svolga il lavoro previsto con utenti, dati ed errori realistici. Una schermata che funziona durante la demo non basta a valutare permessi, correttezza dei dati o capacità di recuperare da un problema.

L’AI può aiutarti a costruire una prima versione. Il passo successivo è capire cosa hai ottenuto e quali verifiche mancano. Lo stesso criterio vale per il software scritto con altri strumenti: si parte da ciò che l’applicazione deve fare, senza dedurre la qualità dal metodo con cui è nata.

Definisci il primo uso, con confini precisi#

“Il team userà il gestionale” è un obiettivo troppo ampio per un collaudo. Scegli un percorso: per esempio, ricevere una richiesta, assegnarla, lavorarla e registrarne l’esito. Indica gli utenti ammessi, i dati coinvolti e chi può approvare il risultato.

Per questo percorso scrivi cosa deve succedere e cosa non deve essere possibile. Non serve partire da ogni funzione immaginata per il prodotto: serve una prima versione di cui puoi osservare il comportamento.

Prova il percorso completo, comprese le interruzioni#

Non fermarti al salvataggio di un modulo. Riapri il record, cambialo da un altro account, verifica il report che lo usa e controlla l’eventuale invio esterno. Se una funzione comprende più passaggi, annota cosa succede quando ne fallisce uno.

Questa tabella è una base di lavoro, non un collaudo universale. Pagamenti, documenti, dati sensibili e operazioni difficili da annullare richiedono criteri specifici prima di coinvolgere utenti reali.

Login e permessi sono due verifiche diverse#

Il login identifica l’utente; l’autorizzazione stabilisce quali risorse e azioni gli sono consentite. OWASP distingue questi due aspetti e raccomanda controlli dei permessi su ogni richiesta. Nascondere un pulsante nell’interfaccia non dimostra che l’azione sia protetta. Fonte: OWASP, Authorization Cheat Sheet.

Prepara account con ruoli diversi e verifica sia le operazioni ammesse sia quelle vietate. Per un’app con clienti separati, prova che un utente non possa consultare o modificare dati di un’altra azienda. Queste verifiche devono riguardare anche API, esportazioni e file, quando presenti nel perimetro.

Controlla cosa accade ai dati#

Dove vengono salvati? Come sono collegati clienti, attività e documenti? Una modifica aggiorna tutte le viste interessate? Le eliminazioni hanno effetti comprensibili? Sono domande da risolvere prima di introdurre dati operativi.

Per il recupero, distinguerei codice, database e allegati. PostgreSQL, ad esempio, documenta strumenti e passaggi diversi per produrre un dump e ripristinarlo. La proposta per la tua app dovrebbe precisare cosa viene salvato e quale prova di recupero è prevista. Fonte: PostgreSQL, SQL Dump.

Durante i test usa dati dimostrativi quando possibile. Se servono dati reali, concorda ambiente, autorizzazioni e modalità di gestione con chi ne è responsabile.

Dipendenze e credenziali richiedono una revisione#

Le dipendenze sono i componenti esterni usati dall’applicazione. Occorre sapere quali sono, come si aggiornano e quali servizi richiedono credenziali. Per i progetti npm, il comando npm audit segnala vulnerabilità note nelle dipendenze controllate: non è una verifica completa della logica o dei permessi dell’app. Fonte: documentazione npm audit.

Chiedi che i risultati siano valutati nel contesto del progetto. Una segnalazione non si risolve applicando automaticamente ogni aggiornamento: occorre verificare compatibilità e flussi interessati. Per le credenziali, controlla dove sono conservate, chi può usarle e come sostituirle senza interrompere i servizi.

Prepara il rilascio e il ritorno alla situazione precedente#

Prima del primo uso, deve essere chiaro quale versione verrà pubblicata, chi lo farà e come si controllerà l’esito. Un ambiente di prova serve a verificare i passaggi concordati prima di applicarli alla produzione.

La possibilità di tornare indietro non riguarda soltanto il codice. Se un rilascio modifica dati o struttura del database, ripubblicare la vecchia versione potrebbe non bastare. Chiedi quali parti sono ripristinabili, quali dati rischiano di andare persi e chi decide quando interrompere l’uso.

Come decidere se partire, correggere o approfondire#

Un’app può essere utile anche con un perimetro piccolo, purché sia esplicito. La decisione di partire dipende dalle conseguenze degli errori e dai controlli disponibili. Una checklist non equivale a una certificazione di sicurezza né dimostra l’assenza di difetti.

Un’esperienza pertinente di LuCz#

Matteo ha preso in carico un gestionale nato con l’AI, inizialmente parzialmente funzionante, e lo ha portato all’utilizzo operativo in azienda. Oggi è usato da oltre 20 persone; il lavoro comprende sviluppo, integrazioni e rilasci. Il caso è descritto nella pagina di stabilizzazione e manutenzione LuCz. È un’esperienza concreta, che non stabilisce tempi o risultati per un’altra applicazione.

Per capire anche il problema della comprensione e della manutenzione del codice, puoi leggere l’approfondimento sul debito tecnico nell’era AI. Qui il punto è più immediato: quali prove servono per decidere il prossimo utilizzo.

Hai una prima versione, ma non sai quale passo fare prima di farla usare al team?#

Se le verifiche fanno emergere un punto che non riesci a inquadrare, parti da un flusso concreto: chi dovrà usarlo, cosa dovrebbe succedere e dove ti sei fermato. Nel primo confronto con Matteo valutiamo il contesto e la compatibilità del progetto con LuCz, prima di concordare un eventuale incarico.

Nella pagina lasci i recapiti e una breve descrizione, poi scegli giorno e ora. Eventuali analisi tecniche, accessi e interventi successivi vengono concordati separatamente, con perimetro, responsabilità e costo espliciti.

Fonti#

• OWASP Cheat Sheet Series, Authorization Cheat Sheet.
• PostgreSQL 18, SQL Dump.
• npm Docs, npm audit.
• LuCz, Stabilizzazione e manutenzione software esistente.
• LuCz, Debito tecnico nell’era AI.

Fonti consultate il 2 novembre 2026. I casi proposti sono esempi di collaudo, da adattare al sistema e alle conseguenze del suo utilizzo.