---
title: "Vibecoding in produzione: perimetro normativo, rischi reali e i controlli prima del deploy"
url: https://zerofive.ai/blog/compliance/vibecoding-produzione-cra-ai-act-controlli
canonical: https://zerofive.ai/blog/compliance/vibecoding-produzione-cra-ai-act-controlli
language: it
published: 2026-09-07
updated: 2026-09-18
author: "ZeroFive.AI"
tags: vibecoding, Cyber Resilience Act, AI Act, SBOM, sicurezza applicativa
abstract: "Perimetro CRA e AI Act per le app generate con AI, problemi strutturali del metodo e le otto verifiche da fare prima di andare in produzione."
---

# Vibecoding in produzione: perimetro normativo, rischi reali e i controlli prima del deploy

Un giovane imprenditore ci ha mostrato a giugno la sua applicazione, costruita in undici giorni con un generatore di codice e già usata da quattro clienti paganti. Funzionava bene. Alla domanda su quali pacchetti npm ci fossero dentro ha risposto che non lo sapeva, perché li aveva scelti il modello. Alla domanda su chi potesse leggere la tabella degli utenti ha aperto la console del database e ha scoperto una policy permissiva su tutte le righe, scritta dal generatore al secondo giorno e mai più guardata da nessuno.

Il vibecoding ha spostato il collo di bottiglia dello sviluppo software dalla scrittura del codice alla sua verifica, e il salto tra prototipo e produzione, che prima richiedeva settimane di lavoro visibile, adesso avviene senza che nessuno se ne accorga. Questo articolo ricostruisce dove cadono davvero gli applicativi generati con questi strumenti dentro il perimetro normativo europeo, quali problemi strutturali il metodo introduce a prescindere dalla normativa, e quali controlli concreti vanno fatti sui fornitori e sul team prima di mettere qualcosa davanti a un utente reale. In coda trovate un vocabolario dei termini usati.

![Vibecoding Production Gate: triage di perimetro Cyber Resilience Act e le otto verifiche prima del rilascio in produzione](/vibecoding-production-gate-it.png)

## Il perimetro del Cyber Resilience Act

L'assunzione diffusa è che il Cyber Resilience Act colpisca qualunque software. Sul punto che riguarda la maggior parte delle applicazioni generate con questi strumenti, la guidance della Commissione dice esattamente il contrario.

Il 27 luglio 2026 la Commissione ha approvato la guidance applicativa richiesta dall'articolo 26 del regolamento, documento con riferimento C(2026) 5252, con l'obiettivo dichiarato di rendere la conformità più praticabile per le piccole e medie imprese. La parte più estesa riguarda proprio l'ambito di applicazione.

Il criterio è dove il software viene eseguito. Il software che gira sul dispositivo dell'utente, quindi un'app scaricata, un'estensione del browser, un client installato localmente, è un prodotto con elementi digitali. Il software semplicemente raggiunto da remoto attraverso un browser non lo è su questa sola base, e le web app usate soltanto tramite browser insieme ai siti che si limitano a presentare informazioni non sono in genere prodotti con elementi digitali. Rientrano soltanto quando si qualificano come elaborazione dati a distanza che supporta la funzione di un prodotto.

La bozza di guidance del 3 marzo 2026 aveva già confermato in modo esplicito che il SaaS autonomo resta fuori ambito. Cloud e SaaS rientrano solo dove il componente si qualifica come remote data processing solution, e questo richiede tre condizioni simultanee: che elabori dati a distanza, che il prodotto non riesca a svolgere una funzione essenziale senza di esso, e che sia stato progettato dallo stesso fabbricante del prodotto supportato o sotto la sua responsabilità. Solo i componenti che soddisfano tutte e tre le condizioni rientrano come elaborazione dati a distanza. Anche quando il SaaS resta fuori dal Cyber Resilience Act, erogarlo nell'Unione può far scattare la direttiva NIS2 in capo all'organizzazione.

Un'altra precisazione utile a chi lavora con repository pubblici: la definizione di software del regolamento copre sia il codice macchina sia il codice sorgente, ma la semplice condivisione di codice open source su un repository pubblico non costituisce in genere immissione sul mercato.

Tradotto in una tabella di triage utilizzabile in mezz'ora:

| Cosa avete portato in produzione | Cyber Resilience Act | Cosa si applica comunque |
|---|---|---|
| Web app usata solo da browser | fuori ambito | AI Act, GDPR, NIS2 se siete in perimetro |
| App mobile scaricabile da uno store | dentro, insieme al backend che la fa funzionare | tutto il resto |
| Applicazione desktop, Electron, estensione browser, CLI | dentro | tutto il resto |
| SaaS con agente installabile o SDK distribuito | dentro, e il backend entra col prodotto | tutto il resto |
| Backend che fa funzionare un dispositivo del cliente | dentro come elaborazione dati a distanza | tutto il resto |
| Progressive web app installabile sul dispositivo | zona grigia, va documentata caso per caso | tutto il resto |

Per il portafoglio tipico di chi lavora con questi strumenti la maggior parte delle applicazioni resta fuori dal Cyber Resilience Act, e l'esposizione reale arriva da altre direzioni. Le eccezioni ricorrenti sono le progressive web app installabili, le applicazioni pubblicate sugli store e qualunque estensione del browser, categorie che in questi ambienti si producono con la stessa facilità di una pagina web.

Vale la pena scrivere il risultato del triage e archiviarlo con la motivazione, perché la domanda arriverà da un cliente enterprise molto prima che da un'autorità, e una risposta documentata vale più di una risposta corretta improvvisata.

## Gli obblighi che valgono comunque

Fuori dal Cyber Resilience Act non significa fuori da tutto. Le quattro esposizioni che seguono valgono per un'applicazione generata in tre giorni esattamente come per un prodotto sviluppato in tre anni.

**Trasparenza dell'AI Act, applicabile dal 2 agosto 2026.** Se l'applicazione espone un chatbot, un assistente, un generatore di testo o di immagini, esiste già oggi un obbligo di informare l'utente che sta interagendo con un sistema di intelligenza artificiale, e di marcare i contenuti sintetici in modo leggibile automaticamente. È l'esposizione più probabile e la più economica da sanare, e quasi nessuna applicazione costruita in un fine settimana la copre.

**Alfabetizzazione, applicabile dal 2 febbraio 2025.** L'obbligo riguarda sia chi sviluppa sia chi utilizza sistemi di intelligenza artificiale, e si dimostra con evidenze documentate. Un team che genera codice con un modello senza saper leggere quello che il modello produce è il caso che la norma intende coprire, e la formazione qui non è un adempimento formale ma la condizione per accorgersi di un errore.

**Alto rischio, applicabile dal 2 dicembre 2027.** Un'applicazione costruita in tre giorni può essere ad alto rischio senza che nessuno lo abbia deciso. Screening di candidature, valutazione o assegnazione di compiti ai dipendenti, scoring per l'accesso al credito o a servizi essenziali, valutazione in ambito educativo. Sono tutti casi dell'Allegato III e sono tutti fra i primi che un giovane imprenditore prova a risolvere con un generatore, perché sembrano problemi di interfaccia e di database. Chi rientra dovrà avere sistema di gestione del rischio, governance dei dati, documentazione tecnica, registrazione automatica degli eventi, sorveglianza umana e valutazione di conformità.

**NIS2 e protezione dei dati.** Erogare un servizio nell'Unione può far entrare l'organizzazione nel perimetro NIS2 in base a settore e dimensione, in modo indipendente dal Cyber Resilience Act. La normativa sui dati personali si applica sempre, con una particolarità: un database generato da prompt ha quasi sempre una minimizzazione che nessuno ha progettato, perché il modello aggiunge colonne quando servono e non le toglie mai.

## I punti deboli del metodo

Questi valgono a prescindere dal perimetro normativo, perché sono problemi di ingegneria prima che di conformità. Li elenco nell'ordine in cui li abbiamo incontrati sul campo.

**Nessuno sa cosa c'è dentro.** La distinta base del software presuppone che qualcuno abbia scelto le dipendenze. Nel vibecoding le sceglie il modello, spesso pescando pacchetti per nome plausibile, e la catena transitiva resta invisibile a chi ha scritto soltanto prompt. Il rischio di pacchetti abbandonati o di nomi costruiti per assomigliare a librerie note non è teorico, ed è aggravato dal fatto che il generatore non ha alcun modo di sapere se un pacchetto è stato compromesso la settimana scorsa. Anche restando fuori dal Cyber Resilience Act, l'elenco dei componenti è la prima cosa che un ufficio acquisti strutturato chiede in fase di qualifica fornitore.

**Il default di sicurezza del generatore.** La classe di errore più frequente riguarda le regole di autorizzazione sulle righe dei database gestiti, le chiavi di servizio finite dentro il bundle consegnato al browser e le funzioni serverless esposte senza autenticazione. Il generatore produce codice che funziona, e funzionare non coincide con essere protetto. Chi non sa che cosa sia una policy di sicurezza a livello di riga non può verificarne una scritta da un modello, e il modello la scrive permissiva perché così l'applicazione parte al primo tentativo.

**Il confine tra prototipo e produzione evapora.** Questo è il punto centrale. In questi ambienti il prototipo è deployato su un dominio pubblico dal primo minuto, quindi manca il momento in cui qualcuno decide consapevolmente di andare in produzione. La decisione avviene per accumulo, quando il primo utente reale entra e nessuno se ne accorge. Ogni presidio successivo dipende dal ripristino di quel momento decisionale.

**Non c'è tracciabilità delle modifiche.** Senza revisione del codice e senza registro delle modifiche nessuno può rispondere alla domanda su quando sia stata introdotta una modifica sostanziale, che è il test capace di riaprire la valutazione di conformità nel Cyber Resilience Act e la documentazione tecnica nell'AI Act. Nessuno può nemmeno ricostruire quale versione fosse in esecuzione nel momento in cui si è verificato un incidente, che è la prima domanda di qualunque analisi post-evento.

**Registrazione degli eventi e conservazione.** Per i sistemi ad alto rischio l'AI Act richiede registrazione automatica e conservazione per un periodo definito. Le applicazioni generate hanno quasi sempre una registrazione da ambiente di sviluppo, verbosa dove non serve e assente dove servirebbe, con dati personali che finiscono nei log senza che nessuno lo abbia deciso.

**Regressioni senza rete di protezione.** Un singolo prompt può riscrivere una funzione che nessuno stava guardando. In assenza di test automatici la verifica è visiva, e la verifica visiva non copre autorizzazioni, casi limite e condizioni di errore. La velocità di modifica che rende attraente il metodo è la stessa che rende probabile la regressione silenziosa.

**Il periodo di supporto.** Chi rientra nel Cyber Resilience Act deve dichiarare per quanto tempo manterrà il prodotto, con un orizzonte che in linea di principio non scende sotto i cinque anni. Un'applicazione generata da un singolo startupper, su una piattaforma che potrebbe cambiare modello sottostante due volte l'anno, ha un problema di sostenibilità della promessa prima ancora che di conformità.

**Chi è il fabbricante.** Se mettete sul mercato con il vostro marchio, il fornitore ai sensi dell'AI Act e il fabbricante ai sensi del Cyber Resilience Act siete voi. La piattaforma su cui avete generato il codice non compare da nessuna parte in quella catena di responsabilità. Vale anche in direzione opposta, e riguarda direttamente chi fa consulenza: se un'unità di prototipazione consegna un prototipo e il committente lo porta in produzione così com'è, il confine di responsabilità va scritto nel contratto prima della consegna.

## La dipendenza da tre fornitori

Un'applicazione vibecoded tipica poggia contemporaneamente su tre fornitori: la piattaforma di generazione e hosting, il database gestito, il fornitore del modello. Ciascuno con la propria giurisdizione di controllo societario, il proprio calendario di deprecazione e la propria politica sugli incidenti.

La domanda di due diligence che si pone oggi su questi tre fornitori riguarda quasi sempre il prezzo e la velocità. Le domande che il quadro europeo rende rilevanti sono di natura diversa, e il pacchetto cyber presentato dalla Commissione il 20 gennaio 2026 le rende attuali anche per progetti molto piccoli, perché introduce la possibilità di designare fornitori come ad alto rischio con obblighi di dismissione progressiva.

Il costo di uscita da queste tre dipendenze cresce più rapidamente di quanto uno startupper stimi, perché al contratto si sommano progressivamente lo schema del database, le funzioni serverless scritte per quella piattaforma, i prompt tarati su quel modello e le abitudini del team. Verificare l'esportabilità reale del codice prima del terzo cliente costa un pomeriggio, verificarla dopo il trentesimo costa un trimestre.

## Le verifiche sui fornitori

Sulla piattaforma di generazione e sull'infrastruttura, otto punti da chiudere per iscritto:

- Esportabilità reale del codice e proprietà del repository, provata con un export effettivo e non con una voce di documentazione
- Trattamento dei prompt e del codice, con conferma esplicita sull'uso o sul non uso a fini di addestramento
- Elenco dei sub-responsabili del trattamento e residenza dei dati, aggiornato e non genericamente dichiarato
- Certificazioni e verifiche indipendenti disponibili, con la data dell'ultima verifica di sicurezza offensiva
- Canale e tempi di divulgazione delle vulnerabilità, verificando la compatibilità con una finestra di ventiquattro ore nel caso in cui l'obbligo di segnalazione ricada su di voi
- Controllo societario e giurisdizione, in ottica di designazione futura della catena di fornitura
- Posizione del fornitore rispetto a NIS2, perché un fornitore già in perimetro ha processi che potete ereditare invece di costruire
- Storico degli incidenti e delle interruzioni, ricostruito in modo indipendente e non chiesto al fornitore

Sul fornitore del modello vanno aggiunte quattro verifiche specifiche: politica di versioning e preavviso di deprecazione, comportamento in caso di aggiornamento del modello sotto lo stesso nome commerciale, luogo di elaborazione dei dati, e clausole contrattuali sull'uso degli input inviati in inferenza.

Su ciascuno di questi punti la risposta accettabile è un documento o una clausola. Una risposta ricevuta a voce in una call di vendita non serve a nulla quando serve davvero.

## Competenze e responsabilità nel team

Le verifiche sul team sono meno numerose e più difficili da superare, perché toccano competenze e responsabilità invece che documenti.

**Titolarità nominata.** Serve una persona con nome e cognome responsabile dell'applicativo, che risponde della segnalazione e della documentazione. In assenza di questo ogni altro presidio resta teoria, perché nel momento dell'incidente la prima cosa che manca è qualcuno che decida.

**Chi può mandare in produzione.** Un secondo paio di occhi sul rilascio, anche in un team di due persone. Il vibecoding rende il rilascio così economico che la barriera va reintrodotta a mano.

**Competenza di lettura.** Almeno una persona in grado di leggere il codice generato su tre dimensioni: autorizzazioni, gestione dei segreti, validazione degli input. Se questa competenza non esiste internamente va acquistata a ore, e costa meno di un incidente su dati di clienti.

**Alfabetizzazione documentata.** L'obbligo dell'AI Act si dimostra con registri di formazione e contenuti, non con la percezione che il team sia bravo. Serve una traccia con date, contenuti e partecipanti.

**Presidio dell'orologio.** Chi riceve la segnalazione di sicurezza il venerdì sera, attraverso quale canale, con quale procedura di escalation e con quale sostituto in ferie. Ventiquattro ore non consentono di costruire il processo mentre l'incidente è in corso.

**Conoscenza del perimetro.** Il team deve sapere se l'applicazione che sta costruendo ricade nell'Allegato III, e questa domanda va posta prima del primo prompt. Scoprirlo a prodotto avviato significa rifare l'architettura dei dati e della sorveglianza umana.

## Il gate pre-produzione

Otto verifiche, tutte rispondibili in mezza giornata, nessuna delle quali richiede un consulente per essere impostata la prima volta.

1. **Triage di perimetro scritto e archiviato.** Cyber Resilience Act sì o no, AI Act sì o no, Allegato III sì o no, ciascuna risposta con la sua motivazione e la data.
2. **Distinta base generata e archiviata**, con scansione delle vulnerabilità note sui componenti e una data di riscansione programmata.
3. **Revisione manuale delle regole di autorizzazione** sul database, tabella per tabella, con un test negativo che dimostra che un utente non autorizzato riceve un rifiuto.
4. **Nessun segreto nel bundle client**, verificato con una ricerca testuale sul pacchetto di produzione e non sul codice sorgente.
5. **Trasparenza implementata** ovunque esista un componente generativo esposto all'utente, con marcatura dei contenuti sintetici.
6. **Registrazione strutturata degli eventi** con periodo di conservazione definito, informativa allineata e verifica che i log non contengano dati che non dovrebbero contenere.
7. **Contatto di sicurezza pubblicato** e procedura di segnalazione scritta, con i tempi interni definiti a ritroso dalle ventiquattro ore.
8. **Titolare nominato** e confine di responsabilità con il committente messo per iscritto, incluso il caso della consegna di un prototipo.

Chi non passa questi otto punti ha un prototipo. La distinzione tra prototipo e prodotto è una decisione che qualcuno deve prendere consapevolmente, e in questi ambienti va reintrodotta come artefatto formale perché la tecnologia l'ha rimossa.

## La checklist

Il gate, il triage di perimetro e le domande da porre a fornitori e team sono raccolti in un documento di tre pagine costruito per essere compilato invece che letto.

**A cosa serve.** A trasformare una decisione implicita in una decisione registrata, con una data e un nome accanto. Oggi il passaggio in produzione avviene per accumulo e nessuno lo scrive da nessuna parte, quindi quando arriva la domanda, da un cliente in fase di qualifica fornitore o da chi indaga un incidente, non esiste nulla da mostrare. La checklist produce quella traccia in mezza giornata, ed è la stessa traccia che serve a voi sei mesi dopo, quando nessuno ricorda più perché una scelta era stata fatta in quel modo.

**Come si usa.** La prima pagina si compila una volta per applicativo e si rivede a ogni modifica sostanziale: il triage di perimetro stabilisce quali regimi si applicano e perché. La seconda pagina si usa in fase di selezione o di rinnovo dei fornitori, e le sue righe funzionano bene anche come allegato a una richiesta di offerta. Il gate a otto punti si ripercorre a ogni rilascio, e dopo la prima volta richiede un'ora.

**Chi la compila.** Il titolare nominato dell'applicativo per le parti di perimetro e di titolarità, chi esegue il rilascio per il gate, chi si occupa di acquisti per le verifiche sui fornitori. In un team di due persone le tre figure coincidono, e va bene lo stesso, purché il nome scritto sia quello di una persona e non quello di un reparto.

**Che cosa non è.** Non è un'attestazione di conformità, non sostituisce un parere legale e non certifica nulla, perché nessun documento compilato da chi costruisce può fare quel lavoro. È uno strumento di decisione, e serve a sapere dove siete prima di aprire un cantiere e di spendere un budget.

**Licenza e crediti.** Il documento è rilasciato con licenza Creative Commons Attribuzione e Non commerciale 4.0. Potete usarlo, stamparlo, compilarlo e adattarlo dentro la vostra organizzazione, anche se siete un'impresa, e condividerlo con colleghi, fornitori e clienti. Non potete rivenderlo né includerlo in servizi di consulenza, audit o formazione a pagamento erogati a terzi. Ogni riproduzione o citazione deve riportare la fonte, ZeroFive.AI, con collegamento a zerofive.ai quando il formato lo consente. Per usi commerciali scrivete a hello@zerofive.ai.

[**Scarica la checklist in PDF, tre pagine**](/checklist-vibecoding-produzione-zerofive.pdf) e tenetela accanto al repository, perché il momento in cui serve è quello del rilascio e non quello della lettura.

## L'esecuzione dei controlli

Le verifiche del gate diventano gestibili quando si traducono in operazioni concrete. Quelle che seguono sono eseguibili da chiunque abbia accesso al repository e alla console dell'infrastruttura.

**Distinta base.** Generatela dal gestore di pacchetti in formato standard, archiviatela con la data e il commit di riferimento, e passatela a uno strumento di scansione delle vulnerabilità note. Il primo passaggio produce quasi sempre un elenco lungo, e la parte utile è distinguere le segnalazioni che riguardano codice effettivamente eseguito da quelle su dipendenze di sviluppo. Fissate le versioni invece di lasciare intervalli aperti, perché un intervallo aperto significa che il prodotto in produzione cambia senza che nessuno lo rilasci.

**Autorizzazioni sul database.** Elencate le tabelle, verificate che la sicurezza a livello di riga sia attiva su ciascuna, e leggete la condizione di ogni policy. Qualunque condizione sempre vera va riscritta. Il controllo che conta arriva dopo: aprite una sessione con un utente qualsiasi e provate a leggere una riga che appartiene a un altro utente. Finché non avete visto un rifiuto con i vostri occhi, la policy è un'ipotesi.

**Segreti.** Cercate le stringhe delle vostre chiavi dentro il pacchetto di produzione servito al browser, non dentro il codice sorgente, perché il processo di build può includere variabili che non vi aspettate. Ripetete la ricerca sulla cronologia del repository, dove una chiave rimossa tre settimane fa continua a essere leggibile. Le chiavi trovate vanno ruotate, e la rimozione dal codice non sostituisce la rotazione.

**Superficie esposta.** Elencate le funzioni serverless e gli endpoint pubblicati, e per ciascuno verificate quale controllo di autenticazione applica. Il generatore tende a creare endpoint di supporto durante lo sviluppo e a non rimuoverli, e quelli restano raggiungibili.

**Log applicativi.** Leggete una giornata di registrazioni e cercate quello che non dovrebbe esserci: indirizzi email, contenuti inseriti dagli utenti, token. Definite un periodo di conservazione e applicatelo, perché una conservazione indefinita è una posizione difficile da difendere.

**Regressione.** Prima ancora di una suite di test completa, scrivete i tre test che coprono le operazioni sui dati più sensibili dell'applicazione ed eseguiteli a ogni rilascio. Tre test eseguiti battono trenta test pianificati.

## Il confine contrattuale

La questione della responsabilità merita un trattamento separato, perché è quella che produce i danni più costosi e le conversazioni più imbarazzanti.

Chi immette sul mercato con il proprio marchio è il fabbricante per il Cyber Resilience Act e il fornitore per l'AI Act, indipendentemente da chi abbia materialmente prodotto il codice. Una piattaforma di generazione non entra in quella catena, e non ci entra nemmeno il consulente che ha costruito il prototipo, salvo che il contratto dica altro.

Quando un prototipo passa di mano il contratto dovrebbe dire almeno quattro cose. Che l'artefatto è un prototipo destinato alla validazione e non al servizio di utenti reali. Quali verifiche sono state eseguite e quali sono state esplicitamente escluse, con l'elenco. Che il passaggio in produzione richiede un intervento ulteriore, definito nel perimetro e nel prezzo. Chi assume la titolarità dal momento della consegna e con quale decorrenza.

Questa non è cautela legale fine a se stessa. Un prototipo consegnato senza queste quattro righe finisce in produzione nella maggior parte dei casi, perché funziona e perché costa zero metterlo online, e il primo incidente riapre la discussione su chi avesse detto cosa mesi prima.

## Vocabolario

**Allegato III dell'AI Act.** Elenco dei casi d'uso che qualificano un sistema come ad alto rischio, tra cui selezione del personale, gestione dei lavoratori, accesso a servizi essenziali, biometria e istruzione.

**Bundle client.** Il pacchetto di codice che il browser dell'utente scarica ed esegue. Tutto quello che si trova al suo interno è leggibile da chiunque, comprese le chiavi che non dovrebbero essere lì.

**Catena transitiva delle dipendenze.** L'insieme dei pacchetti che il vostro progetto installa indirettamente, perché richiesti dai pacchetti che avete scelto. In un progetto moderno supera facilmente il migliaio di elementi.

**Distinta base del software, o SBOM.** Elenco strutturato dei componenti software di un prodotto, comprese le dipendenze di terze parti e open source.

**Elaborazione dati a distanza.** Categoria del Cyber Resilience Act che porta in ambito un servizio cloud quando elabora dati a distanza, quando il prodotto non funziona senza di esso e quando è progettato dallo stesso fabbricante del prodotto.

**Fabbricante.** Chi immette un prodotto sul mercato europeo con il proprio nome o marchio assumendone la responsabilità commerciale. Non coincide necessariamente con chi ha scritto il codice, né con la piattaforma che lo ha generato.

**Funzione serverless.** Frammento di codice eseguito su infrastruttura gestita, tipicamente esposto su un indirizzo pubblico. Se non ha controlli di autenticazione, chiunque conosca l'indirizzo può richiamarlo.

**Modifica sostanziale.** Cambiamento a un prodotto già sul mercato tale da riaprire la valutazione di conformità. La guidance della Commissione del luglio 2026 dedica una sezione a definirne i confini.

**Periodo di supporto.** Arco temporale durante il quale il fabbricante si impegna a gestire le vulnerabilità del prodotto, dichiarato all'utente e in linea di principio non inferiore a cinque anni.

**Policy di sicurezza a livello di riga.** Regola che stabilisce quali righe di una tabella un determinato utente può leggere o scrivere. Una policy permissiva rende l'intera tabella accessibile a chiunque riesca a interrogare il database.

**Prodotto con elementi digitali.** Categoria del Cyber Resilience Act che comprende hardware e software con connessione diretta o indiretta a dispositivi o reti, insieme alla relativa elaborazione dati a distanza.

**Progressive web app.** Applicazione web che può essere installata sul dispositivo e funzionare in parte offline. È la zona grigia più frequente nel triage di perimetro.

**Test negativo.** Verifica che accerta che un'operazione vietata venga effettivamente rifiutata. È il test che manca quasi sempre, perché nessuno pensa a provare quello che non deve funzionare.

**Typosquatting.** Pubblicazione di pacchetti con nomi simili a librerie note, allo scopo di essere installati per errore o per suggerimento automatico.

**Vibecoding.** Sviluppo di software condotto descrivendo il risultato desiderato in linguaggio naturale a un modello generativo, con verifica prevalentemente sul comportamento osservato invece che sul codice prodotto.

## In sintesi

La velocità che questi strumenti hanno introdotto è reale e conviene tenersela. Quello che è saltato è il momento in cui qualcuno decideva che una cosa era pronta, e quel momento va ricostruito a mano perché nessuna piattaforma lo restituirà.

Le otto verifiche del gate costano mezza giornata la prima volta e un'ora a ogni rilascio successivo. Un incidente su dati di clienti costa la relazione con quei clienti, e il costo non si recupera con la velocità di sviluppo.

Chi vuole capire dove si trova la propria organizzazione su questi presidi prima di aprire un cantiere di conformità può scrivere a hello@zerofive.ai oppure prenotare un confronto su calendly.com/fabiolalli/zerofive.

**Fonti.** Commissione europea, guidance sull'applicazione del Regolamento (UE) 2024/2847 approvata il 27 luglio 2026, documento C(2026) 5252, e bozza di guidance interpretativa del 3 marzo 2026. Testi normativi citati: Cyber Resilience Act, Regolamento (UE) 2024/2847; AI Act, Regolamento (UE) 2024/1689 come modificato dal Regolamento (UE) 2026/1744; direttiva NIS2, Direttiva (UE) 2022/2555. Commissione europea, pacchetto cyber del 20 gennaio 2026, proposte COM(2026) 11 e COM(2026) 13.