Quando non usare il vibe coding: dati sanitari, pagamenti e account altrui

Dati sanitari, pagamenti e account altrui: un test in tre domande per capire quando il codice generato dall’IA non basta e cosa usare al suo posto.

«Mi fai un gestionale per lo studio con le schede dei pazienti?» «Aggiungi al sito un modulo dove il cliente inserisce la carta.» «Scrivi uno script che entra nell’Instagram del mio cliente e pubblica al posto suo.» Sono tre richieste che un assistente IA può soddisfare in pochi minuti, con codice che sembra funzionare. Nella guida ai rischi del vibe coding spiego perché «funziona» non vuol dire «è sicuro»; qui il punto è più netto. Ci sono progetti in cui un errore non costa una serata di debug ma dati di salute esposti, soldi di altri o un reato: lì il codice generato e rivisto da solo non basta.

Questo non significa che l’IA vada spenta. Significa spostare il suo ruolo: prototipi con dati finti, interfacce, documentazione e codice di contorno sì; la parte che custodisce i dati delicati, incassa o accede ad account altrui va affidata a servizi già certificati o a chi può garantirne la sicurezza.

⚠️ Attenzione — Non è una consulenza legale: riporto le norme principali con il link al testo ufficiale. Se gestisci davvero dati sanitari o pagamenti per un’attività, gli obblighi precisi dipendono dal tuo caso e vanno verificati con un professionista o con il tuo responsabile della protezione dei dati.

Il test in tre domande

Prima di chiedere codice all’IA per un progetto che andrà usato con persone vere, rispondi a queste tre domande.

1. Il programma tratterà dati sanitari o altri dati «particolari» di persone reali?
2. Il programma riceverà, conserverà o inoltrerà dati di pagamento?
3. Il programma accederà ad account, caselle o sistemi di altre persone?

Se rispondi sì anche a una sola domanda, il vibe coding da solo non è la strada giusta per la parte che quella domanda riguarda. Le sezioni sotto spiegano perché e cosa usare al posto suo.

Verifica rapida su un progetto che esiste già

Se il progetto è già avviato, cerca nel codice i campi che tradiscono il problema. Dalla cartella del progetto:

Windows (Prompt dei comandi):

findstr /S /I /N "diagnosi patologia terapia sanitari card_number cardnumber cvv cvc iban password_cliente" *.py *.js *.ts *.html

macOS / Linux (Terminale):

grep -rniE "diagnosi|patologia|terapia|sanitari|card_?number|cvv|cvc|iban|password_cliente" --include="*.py" --include="*.js" --include="*.ts" --include="*.html" .

Le opzioni: /S e -r cercano nelle sottocartelle, /I e -i ignorano le maiuscole, /N e -n mostrano il numero di riga, -E permette di usare | per elencare alternative e card_?number trova sia cardnumber sia card_number. Adatta l’elenco ai nomi che usi tu. Ogni risultato in un modulo, in un modello di database o in un log è un punto da rivedere con le sezioni seguenti. Nessun risultato non significa che il progetto sia a posto: i campi possono avere nomi diversi.

Il test che ho eseguito: carta e password finiscono dove non dovrebbero

Per mostrarti cosa intendo senza usare dati di nessuno, ho scritto un piccolo test: crea in una cartella temporanea un mini progetto nello stile di una bozza fatta in fretta, con due errori che possono comparire nel codice generato e non rivisto. Il primo è una funzione di pagamento che scrive nel log numero di carta, scadenza e CVV; il secondo è la password condivisa del cliente salvata in chiaro nella configurazione. Il test esegue il mini progetto con la carta di prova 4242 4242 4242 4242 (un numero di test pubblico, non una carta vera), poi scansiona la cartella cercando numeri di carta validi secondo l’algoritmo di Luhn, CVV registrati e password scritte nel codice. Usa solo la libreria standard di Python, non apre connessioni di rete e alla fine cancella la cartella temporanea.

Scarica test_dati_sensibili.py (SHA-256 7bb88bb8f5839d07c1a38f8fa29aee20c2ad51993032e7b2ce0765b1f3ec37e7) e lancialo dalla cartella in cui l’hai salvato.

Windows (Prompt dei comandi o PowerShell):

python test_dati_sensibili.py

macOS / Linux (Terminale):

python3 test_dati_sensibili.py

Questo è l’output reale che ho ottenuto il 22 ottobre 2026 su macOS 15.7.7 con Python 3.14.7; su Debian 13 con Python 3.13.5 è identico riga per riga:

1) Eseguo il mini progetto (pagamento finto)...
   risposta dell'app: ok
2) Contenuto di app.log:
   INFO:root:Pagamento: carta=4242424242424242 scad=12/29 cvv=123 importo=49.00
3) Scansione della cartella del progetto:
[!] app.log:1  Numero di carta (Luhn valido): 4242424242424242
[!] app.log:1  CVV registrato: cvv=123
[!] app.py:4  Password in chiaro: password_cliente": "Estate2026!"
[!] app.py:11  Numero di carta (Luhn valido): 4242424242424242
Risultati: 4 problemi trovati

Il punto da notare è la seconda riga: l’app risponde ok, il pagamento «funziona», e intanto il file di log contiene la carta completa e il CVV, che per le regole PCI DSS non va mai conservato dopo l’autorizzazione. Quel log può finire nei backup, in un ticket di assistenza o in un repository. Lo script esce con codice 1 quando trova qualcosa, quindi puoi anche usarlo come controllo automatico. Non l’ho provato su Windows. Su un tuo progetto vero, il modo più semplice per riusare la parte di scansione è copiare la funzione scansiona() e passarle la cartella del progetto; tieni presente che trova solo questi tre schemi, non tutti i dati sensibili possibili.

Dati sanitari e altri dati particolari

Il Regolamento europeo sulla protezione dei dati (GDPR), all’articolo 9, mette in una categoria a parte i dati relativi alla salute, i dati genetici e biometrici, quelli che rivelano origine etnica, opinioni politiche, convinzioni religiose, appartenenza sindacale, vita od orientamento sessuale. Il trattamento è vietato salvo eccezioni precise. Chi li tratta deve inoltre adottare misure di sicurezza adeguate al rischio (articolo 32) e, in caso di violazione, notificarla al Garante entro 72 ore quando ci sono rischi per le persone (articolo 33).

Un gestionale generato in un pomeriggio può avere difetti che con dati comuni sono fastidiosi e con dati sanitari diventano gravi: controlli di accesso deboli, backup in chiaro, log che contengono diagnosi, una cartella esposta sul server. Il problema non è che l’IA scriva sempre codice insicuro; è che tu da solo difficilmente puoi dimostrare che le misure sono adeguate, ed è questo che la norma chiede.

Cosa fare al posto suo:

• Usa un software già pensato per quel settore (gestionali per studi medici, psicologi, fisioterapisti) e valuta il fornitore: dove stanno i dati, chi è responsabile del trattamento, come si esportano.
• Usa l’IA sui contorni: un modulo di prenotazione che raccoglie solo nome e orario, la pagina informativa, un prototipo con dati inventati per mostrare al fornitore cosa ti serve.
• Se il progetto su misura è inevitabile, mettilo in mano a uno sviluppatore che si assuma la responsabilità della sicurezza, con una revisione indipendente prima di usare dati veri.

Pagamenti: non far passare la carta dal tuo codice

Chi riceve, conserva o trasmette numeri di carta deve rispettare lo standard di sicurezza del settore, il PCI DSS. Un modulo HTML scritto dall’IA che raccoglie numero, scadenza e CVV e li manda al tuo server porta tutto il tuo sito dentro quel perimetro: server, database, log, backup.

La soluzione pratica esiste già e non richiede di scrivere la parte delicata. I fornitori di pagamento offrono pagine o campi ospitati da loro. Nella sua guida al PCI DSS, per esempio, Stripe spiega che con Checkout o con i campi Elements i dati della carta vanno direttamente a Stripe e non toccano il tuo server, il che semplifica molto la conformità. Altri fornitori hanno soluzioni equivalenti.

Cosa puoi fare con l’IA, e cosa no:

💡 Consiglio pratico — Il controllo più rapido: apri la pagina di pagamento, premi F12 (Windows e Linux) o Cmd+Option+I (macOS) e guarda la scheda Rete mentre invii un pagamento di prova in modalità test. Se vedi una richiesta verso il tuo dominio che contiene il numero della carta, il progetto è nel caso «No» della tabella.

Account altrui: accesso delegato, non password

La terza richiesta è la più insidiosa perché sembra innocua: il cliente ti dà la password e tu automatizzi. I problemi sono almeno tre.

• Legale: entrare in un sistema informatico altrui senza autorizzazione è un reato in Italia (articolo 615-ter del codice penale, «accesso abusivo a un sistema informatico o telematico»). Il consenso del titolare dell’account cambia il quadro, ma i termini del servizio possono comunque vietare l’accesso automatizzato con le credenziali dell’utente.
• Tecnico: la password finisce nel tuo codice, nel tuo .env, nei log o nella cronologia della chat con l’assistente. Se una di queste copie esce, l’account del cliente è esposto.
• Pratico: l’autenticazione a due fattori, i controlli antifrode e i cambi di interfaccia rompono lo script, e il cliente può trovarsi l’account bloccato.

Cosa usare al posto suo:

1. API ufficiali con accesso delegato (OAuth): il cliente autorizza la tua applicazione dalla pagina del servizio, senza darti la password, e può revocare l’accesso in qualsiasi momento.
2. Ruoli e permessi del servizio: molte piattaforme permettono di aggiungere un collaboratore con il suo account e permessi limitati.
3. Password manager con condivisione, se l’accesso manuale è inevitabile: la credenziale non passa per email o chat e si può revocare.

Lo stesso vale, a maggior ragione, per qualunque script che raccoglie dati da account, profili o caselle di persone che non ti hanno autorizzato: non è un progetto da vibe coding, e non diventa lecito scrivendolo a mano.

Errori tipici

• «Uso dati veri solo per provare» → i dati di test diventano dati in produzione → per le prove genera dati inventati e cancella qualunque copia reale dal progetto.
• «Il server è mio, quindi è sicuro» → la sicurezza dipende da configurazione, aggiornamenti e backup, non dalla proprietà → per dati sanitari preferisci un servizio che se ne assume la responsabilità.
• Chiave segreta del fornitore di pagamento nel codice JavaScript del sito → chiunque la legge dal browser → nel browser va solo la chiave pubblicabile, quella segreta resta sul server.
• Webhook di pagamento accettato senza verificarne la firma → ordini confermati senza pagamento → segui la procedura di verifica della firma indicata nella documentazione del fornitore.
• Password del cliente incollata nella chat con l’assistente → la credenziale esce dal tuo controllo → cambiala subito e passa all’accesso delegato.

Domande Frequenti (FAQ)

Posso usare l’IA per un gestionale con dati dei pazienti se poi lo rivedo?

Puoi usarla per il prototipo con dati inventati e per le parti che non toccano i dati sanitari. Per la versione con dati veri, una revisione fatta da te difficilmente basta a dimostrare misure di sicurezza adeguate, come chiede il GDPR. La strada più prudente è un software di settore o uno sviluppatore che si assuma la responsabilità.

Un e-commerce fatto con il vibe coding è vietato?

No. Puoi costruire vetrina, carrello e pagine con l’IA. Il pagamento deve passare da una pagina o da campi ospitati dal fornitore, così il numero della carta non tocca il tuo codice. Integrazione e webhook vanno rivisti con attenzione.

Se il cliente mi dà la password del suo account, posso automatizzare?

Il suo consenso conta, ma non risolve i termini del servizio né il rischio di conservare la sua password nel tuo progetto. Se il servizio offre API ufficiali con accesso delegato o ruoli per collaboratori, usa quelli. Se non li offre, l’automazione è spesso proprio ciò che il servizio non vuole.

Quali dati sono considerati «particolari» dal GDPR?

L’articolo 9 elenca i dati che rivelano origine razziale o etnica, opinioni politiche, convinzioni religiose o filosofiche, appartenenza sindacale, i dati genetici, biometrici usati per identificare una persona, quelli relativi alla salute, alla vita o all’orientamento sessuale. Per i dati giudiziari c’è una regola separata, all’articolo 10.

L’IA può aiutarmi a capire se il mio progetto rientra in questi casi?

Può aiutarti a elencare i campi e i flussi di dati del progetto, ed è un buon punto di partenza. La valutazione finale, però, va fatta da te sui testi ufficiali e, se il caso è serio, con un professionista: un assistente può sbagliare anche con molta sicurezza nel tono.

Cosa posso fare con il vibe coding in questi settori?

Molto: prototipi con dati finti, pagine informative, moduli che raccolgono solo il minimo indispensabile, strumenti interni che non toccano dati delicati, documentazione e test. L’importante è tenere separata la parte che custodisce i dati o i soldi, e affidarla a servizi certificati.

La linea da tracciare prima del primo prompt

Le tre domande richiedono un minuto e conviene farsele prima di scrivere il prompt di avvio del progetto, non dopo il primo cliente. Se il progetto passa il test, continua con i controlli di sempre, a partire dalla code review umana in 15 minuti e, prima di andare online, da un audit di sicurezza gratuito del sito. Per il quadro completo su perché il codice generato dall’IA può nascondere rischi che non vedi, torna all’articolo madre sul vibe coding e i suoi rischi.