La checklist per portare in produzione un sito vibe-coded (senza finire nei guai)

Costruire un sito o un'app con l'AI oggi è questione di ore, non di settimane. Il problema non è mai stato quello. Il problema è che "funziona in demo" e "pronto per la produzione" sono due cose completamente diverse, e la distanza tra le due si misura in vulnerabilità di sicurezza, violazioni normative e — in Italia ed Europa — sanzioni concrete.

Un'analisi di Escape.tech su 5.600 app generate con l'AI ha trovato che il 91,5% conteneva almeno una vulnerabilità critica. Non parliamo di edge case: parliamo di lanci mainstream, incluso il caso della vulnerabilità RLS di Lovable che nel 2025 ha esposto oltre 170 app in produzione. Veracode, in uno studio indipendente, ha stimato che il 45% del codice generato da AI introduce almeno una vulnerabilità nota.

Questa è la checklist che uso prima di dichiarare pronto per il pubblico un progetto costruito con l'aiuto dell'AI — tecnica, ma anche normativa, perché in Italia e in Europa un sito non a norma è un rischio tanto quanto un database esposto.

1. Sicurezza tecnica: i quattro punti che bloccano il lancio

Se non superi questi quattro, non pubblicare, a prescindere da tutto il resto.

• Nessun secret nel frontend. Chiavi API, credenziali di servizio, token privati non devono mai comparire nel codice lato client. Solo chiavi pubbliche nel frontend, tutto il resto passa da funzioni server-side o da un backend che controlli tu.
• Row-Level Security attiva su ogni tabella del database. Se usi Supabase, Postgres o simili, ogni tabella deve avere policy RLS per ogni ruolo (anon, authenticated, service_role). Un database "protetto" solo a livello di applicazione, senza RLS, è protetto solo finché nessuno prova a interrogarlo direttamente.
• Autorizzazione verificata lato server, mai fidandosi del frontend. Un controllo di autorizzazione scritto solo in JavaScript nel browser non è un controllo, è un suggerimento. Ogni route protetta deve validare token e permessi sul server.
• Nessun pannello admin esposto pubblicamente. Le route di amministrazione vanno protette con autenticazione forte e, se possibile, non devono essere raggiungibili da un URL prevedibile.

2. Igiene del deploy

• Repository sotto il tuo controllo (non solo dentro l'account del tool che hai usato per generarlo), con storia pulita e nessun file generato abbandonato
• Nessuna credenziale committata, nemmeno nella cronologia Git — un secret rimosso ma ancora nella storia del repo resta esposto
• Branch principale protetto, review obbligatoria prima di ogni merge in produzione: il codice generato dall'AI va trattato come qualunque altro codice, non bypassa la review
• Variabili d'ambiente separate tra sviluppo, staging e produzione
• Backup del database configurati e testati — non basta che esistano, deve funzionare anche il ripristino
• HTTPS forzato ovunque, certificato valido e rinnovo automatico
• Header di sicurezza configurati (CSP, X-Frame-Options, Strict-Transport-Security)
• Rate limiting sulle API pubbliche, specialmente su login e form di contatto
• Logging e alerting minimi attivi prima del lancio, non aggiunti dopo il primo incidente

3. Privacy e cookie: cosa richiede il Garante in Italia

Se il sito ha utenti in Italia, questa parte non è opzionale, indipendentemente da quanto sia piccolo il progetto.

• Informativa privacy presente e raggiungibile dal footer di ogni pagina, non solo dalla home
• Cookie banner conforme alle linee guida del Garante: pulsanti "Accetta" e "Rifiuta" con pari evidenza visiva, oppure una "X" di chiusura che equivalga al rifiuto — lo scroll della pagina non è mai considerato consenso valido
• Nessuna casella pre-spuntata per i cookie non tecnici: il consenso deve essere un'azione positiva ed esplicita dell'utente
• Nessun cookie wall che blocchi l'accesso ai contenuti se l'utente rifiuta la profilazione, salvo rare eccezioni con alternativa equivalente
• Cookie tecnici caricati liberamente, cookie di profilazione e di terze parti (analytics non anonimizzati, pixel di tracciamento, embed social) solo dopo consenso esplicito
• Il banner non va riproposto a ogni accesso a chi ha già scelto, salvo cambi sostanziali del trattamento o dopo almeno sei mesi
• Se raccogli dati tramite form (contatti, newsletter, iscrizioni), serve una base giuridica chiara e un modo semplice per l'utente di esercitare i suoi diritti GDPR (accesso, cancellazione, portabilità)

4. Accessibilità: obbligo reale, non solo buona pratica

Qui c'è una novità che molti sottovalutano: dal 28 giugno 2025 il D.Lgs. 82/2022, che recepisce l'European Accessibility Act, ha esteso gli obblighi di accessibilità anche a soggetti privati — non più solo pubblica amministrazione. Il riferimento tecnico resta lo standard WCAG 2.1 livello AA, insieme alla norma europea EN 301 549. Nel maggio 2026 AgID ha pubblicato anche un nuovo regolamento di vigilanza, con una piattaforma dove cittadini e consumatori possono segnalare barriere digitali.

Chi è effettivamente obbligato dipende dalle dimensioni dell'attività (in generale, aziende sopra i 2 milioni di euro di fatturato o con almeno 10 dipendenti per i servizi di e-commerce ai consumatori), ma trattarla come "buona pratica da fare quando c'è tempo" è la lettura più rischiosa possibile, soprattutto se il progetto è destinato a crescere.

Checklist minima, valida a prescindere dagli obblighi di legge:

• Contrasto colore testo/sfondo conforme al livello AA
• Ogni immagine informativa ha un testo alternativo
• Il sito è completamente navigabile da tastiera, senza dipendere dal mouse
• I form hanno label associate correttamente ai campi, non solo placeholder
• La struttura HTML usa heading semantici in ordine logico (h1, h2, h3...), non solo per lo stile
• Focus visibile su ogni elemento interattivo
• Nessuna informazione comunicata solo tramite colore

5. Cosa controllare dopo, non solo prima del lancio

• Uno scan di sicurezza sull'URL live dopo il deploy, non solo sul codice prima di pubblicare — un'app può risultare sicura in locale e esporre qualcosa in produzione per via della configurazione dell'hosting
• Monitoraggio attivo dei primi giorni post-lancio, quando il traffico reale rivela edge case che l'AI non aveva previsto
• Un piano minimo di incident response: cosa fai se il database va giù, cosa fai se scopri un secret esposto, chi avvisi
• Rilettura della cookie policy e dell'informativa privacy ogni volta che aggiungi un nuovo servizio esterno (nuovo tool di analytics, nuovo embed, nuova integrazione)

Il punto

Scarica la guida.md

Vibe coding non significa "senza responsabilità". L'AI scrive codice che funziona, non codice che è automaticamente sicuro o conforme — questi restano compiti tuoi, e in un contesto italiano ed europeo hanno anche un peso legale concreto, non solo tecnico. La velocità che guadagni generando il codice va reinvestita qui, in questa checklist, prima del primo utente reale — non recuperata a incidente già avvenuto.