Assistenti nell'ambiente di lavoro
Codice proposto da assistenti integrati nell'editor, nel repository o nella pipeline di integrazione e rilascio.
Progettare e scrivere software dando istruzioni in linguaggio naturale a un modello generativo è ormai pratica quotidiana. La velocità però non cambia il punto di partenza: davanti alle regole europee risponde chi immette il prodotto sul mercato, non lo strumento che ha prodotto il codice. Ecco che cosa chiedono il Cyber Resilience Act e l'AI Act, quali regole darsi e come portare il tema nella strategia aziendale.
Per vibe coding si intende lo sviluppo di software attraverso istruzioni in linguaggio naturale rivolte a modelli generativi o ad agenti, che producono, modificano, provano o integrano codice, configurazioni, documentazione, infrastruttura e componenti applicative.
Codice proposto da assistenti integrati nell'editor, nel repository o nella pipeline di integrazione e rilascio.
Applicazioni e prototipi generati da piattaforme che costruiscono il software a partire da una descrizione.
Script, query, test e infrastruttura come codice suggeriti o scritti dal modello.
Pacchetti e componenti open source individuati e integrati su indicazione del modello.
Agenti autorizzati a intervenire su repository, ambienti di sviluppo, cloud o rilasci.
Manuali, descrizioni tecniche e note di rilascio scritte in automatico, che vanno comunque verificate.
Conta il prodotto, non lo strumento. Per le regole europee rilevano il prodotto venduto, l'uso a cui è destinato, i rischi che presenta e il soggetto che lo offre con il proprio nome. Il fatto che parte del codice sia nata da un prompt non giustifica vulnerabilità, violazioni di licenza, trattamenti illeciti di dati personali o danni agli utenti.
Di norma è produttore chi sviluppa o fa sviluppare il software e lo immette sul mercato dell'Unione con il proprio nome o marchio. Resta il primo responsabile della conformità anche quando si affida a sviluppatori esterni, piattaforme cloud, componenti open source o modelli di terzi.
Il fornitore che scrive il codice, con o senza IA, non prende il posto del produttore. Il contratto deve però prevedere obblighi su sicurezza, revisione, licenze, supporto e collaborazione nella gestione delle vulnerabilità.
Le condizioni d'uso dello strumento di IA regolano il rapporto con il suo fornitore, non la conformità del vostro prodotto. Restano da valutare l'uso dei dati inviati, la riservatezza del codice e la titolarità di quanto generato.
Anche la responsabilità civile cambia. La nuova direttiva (UE) 2024/2853 sulla responsabilità per danno da prodotti difettosi, da recepire entro il 9 dicembre 2026, considera espressamente il software un prodotto. Una vulnerabilità non corretta o un aggiornamento mancato possono quindi rendere difettoso il prodotto anche dopo la vendita, con un risarcimento che non richiede la prova della colpa.
Il regolamento (UE) 2024/2847 disciplina i prodotti con elementi digitali immessi sul mercato dell'Unione, compresa gran parte del software commerciale, con esclusioni e regole specifiche da valutare caso per caso. Il principio è semplice: la sicurezza si gestisce per tutto il ciclo di vita.
Prima del rilascio e a ogni modifica rilevante, con un documento che resta agli atti.
Configurazioni sicure fin dall'installazione e superfici esposte ridotte al minimo.
Nel codice generato, nelle dipendenze e nelle configurazioni, non solo nel codice scritto a mano.
Patch, aggiornamenti e una politica documentata di divulgazione delle vulnerabilità.
Una documentazione tecnica completa, che contenga le prove dei test e della gestione dei componenti.
Le vulnerabilità sfruttate attivamente e gli incidenti gravi, entro i tempi fissati dal regolamento.
Entra in vigore il regolamento. Gli obblighi diventano applicabili in modo progressivo.
Si applicano le regole sulla notifica degli organismi di valutazione della conformità.
Diventano applicabili gli obblighi di segnalazione previsti dall'art. 14, anche per i prodotti già sul mercato. Si comunica tramite la piattaforma unica di segnalazione di ENISA; per l'Italia il coordinatore è CSIRT Italia, presso l'Agenzia per la cybersicurezza nazionale.
Piena applicazione: requisiti essenziali di sicurezza, valutazione della conformità, documentazione tecnica e marcatura CE per i prodotti immessi sul mercato da quella data.
Le sanzioni sono da grande impresa. Per la violazione dei requisiti essenziali e degli obblighi del produttore, comprese le segnalazioni, il regolamento prevede fino a 15 milioni di euro o, se superiore, il 2,5 per cento del fatturato mondiale annuo. Per gli altri obblighi si arriva a 10 milioni o al 2 per cento.
Usare un assistente per scrivere codice non trasforma da solo il software finale in un sistema di IA disciplinato dal regolamento (UE) 2024/1689. Il quadro cambia quando ciò che vendete contiene un sistema di IA.
Il prodotto resta software tradizionale e risponde soprattutto al CRA. L'azienda però usa sistemi di IA nella propria attività: l'art. 4 dell'AI Act, ricalibrato dal Digital Omnibus, le chiede di promuovere un livello adeguato di alfabetizzazione del personale che li utilizza.
Un assistente conversazionale, un motore che decide o classifica, un agente autonomo, una funzione di profilazione: in questi casi l'AI Act si applica direttamente, accanto al CRA.
Il calendario dopo il Digital Omnibus. Il regolamento (UE) 2026/1744 ha spostato gli obblighi per i sistemi ad alto rischio: dal 2 dicembre 2027 per quelli elencati nell'Allegato III, come selezione del personale, merito creditizio e istruzione, e dal 2 agosto 2028 per quelli integrati nei prodotti dell'Allegato I. Il tempo in più serve a progettare bene, non a rinviare.
Il vibe coding aumenta la produttività, ma sposta il lavoro dalla scrittura al controllo. Ogni rischio ha un presidio che si può misurare.
Gli strumenti di vibe coding si usano dentro un processo. La rapidità del prototipo non sostituisce analisi, revisione, test, autorizzazione al rilascio e gestione successiva.
Nessun codice generato va in produzione senza la revisione di una persona tecnicamente competente e autorizzata.
Niente credenziali, chiavi, dati personali superflui, codice riservato o segreti commerciali, salvo autorizzazione e garanzie adeguate.
Ogni componente proposto dall'IA va controllato: esistenza, provenienza, manutenzione, vulnerabilità e licenza.
Le modifiche passano da repository aziendale, controllo di versione, richiesta di modifica, revisione e pipeline approvata.
Almeno la scansione di codice e dipendenze; per servizi esposti o critici anche test dinamici, penetration test e revisione dell'architettura.
Accessi, cloud, rete, container e infrastruttura come codice generati dall'IA hanno una verifica separata.
Ogni versione ha un proprietario nominato, un'approvazione formale e un piano per tornare indietro.
Per i prodotti soggetti al CRA o che incorporano IA si conservano le evidenze richieste, rilascio dopo rilascio.
La formula da condividere con i team. Usare l'IA per scrivere codice è consentito. Mettere in distribuzione codice che non comprendiamo, non abbiamo verificato o non sappiamo mantenere non lo è. Chi immette il prodotto sul mercato resta responsabile della sua sicurezza, della conformità e della gestione nel tempo.
Per ogni prodotto, o per ogni rilascio rilevante, le evidenze vanno conservate in un repository o in un sistema documentale controllato. Sono la base di qualunque verifica, interna o dell'autorità.
Descrizione, destinatari, impiego previsto e limiti dichiarati, con architettura e flussi di dati principali.
Elenco di componenti e dipendenze, preferibilmente in formato SBOM, con la verifica delle licenze.
Valutazione dei rischi, decisioni di sicurezza e misure di mitigazione adottate.
Esiti di revisioni del codice, analisi statiche e dinamiche, controllo dei componenti e test funzionali.
Vulnerabilità con gravità, decisioni, patch e tempi di correzione, più il canale per riceverne segnalazione.
Strumenti usati, regole applicate e traccia delle istruzioni decisive per capire una scelta, senza conservare dati superflui.
Nelle PMI i ruoli si sommano, non spariscono. In una piccola software house la stessa persona può essere responsabile tecnico e del rilascio. Conta che ogni responsabilità abbia un nome e che chi approva non sia, per quanto possibile, chi ha generato il codice.
Il vibe coding cambia costi, tempi, rischi e valore del software. Per questo non si governa solo nei team di sviluppo: va portato dove si decidono priorità, investimenti e tolleranza al rischio.
L'art. 2086 del Codice civile impone assetti adeguati alla natura e alla dimensione dell'impresa: dove il software è il prodotto, il processo che lo genera ne fa parte. Per i soggetti che rientrano nella NIS2, il Dlgs 138/2024 chiede agli organi di amministrazione di approvare le misure di cybersicurezza, sovrintenderne l'attuazione e formarsi.
I clienti più strutturati chiederanno inventari dei componenti, periodi di supporto dichiarati e prove di sicurezza. Chi le ha pronte vince gare e qualifiche di fornitura, accorcia le due diligence e rende il software un attivo che vale di più, non un rischio nascosto.
Una mappa che incrocia valore e rischio: prototipi, test e strumenti interni da accelerare, prodotti venduti e dati sensibili da presidiare di più.
Strumenti ammessi, dati vietati nei prompt, soglie di escalation e responsabili, approvati dall'organo amministrativo e riesaminati ogni anno.
I rischi entrano nel registro aziendale, nel controllo interno e nel modello 231: reati informatici, violazioni del diritto d'autore sul software e il nuovo art. 25-vicies.
Clausole con i fornitori di IA e con gli sviluppatori esterni su dati, sicurezza e vulnerabilità; verso i clienti, un periodo di supporto chiaro.
Formazione di chi usa gli strumenti, revisori capaci di leggere il codice generato e una cultura che premia chi segnala un problema.
Pochi indicatori, portati con regolarità al consiglio e all'organo di controllo, per decidere sulla base di dati e non di impressioni.
Indicatori a scopo illustrativo: vanno scelti e calibrati sul modello di business e sulle dimensioni dell'impresa.
Inventario degli strumenti di IA davvero in uso, compresi quelli non autorizzati, e dei prodotti venduti nell'Unione. Prima qualificazione rispetto a CRA e AI Act e procedura per le segnalazioni entro 24 e 72 ore.
Policy approvata dal consiglio, controlli automatici nelle pipeline, canale pubblico per le segnalazioni di vulnerabilità, ruoli nominati e prima formazione.
Fascicoli di conformità per prodotto, inventari dei componenti, contratti rinegoziati, aggiornamento del modello 231 e indicatori portati al consiglio.
I prodotti immessi sul mercato rispettano i requisiti essenziali del CRA, con la documentazione tecnica e, dove richiesta, la marcatura CE.
Spuntate ciò che è già fatto e documentato per la prossima versione significativa. Il risultato indica le aree da completare prima di distribuire. Le scelte restano nel browser.
Quando fermarsi e coinvolgere sicurezza e legale. Prima del rilascio serve un'escalation se il prodotto tratta dati personali su larga scala, dati sensibili, di minori, finanziari o sanitari; se è destinato a infrastrutture critiche, sanità, istruzione, lavoro, credito, assicurazioni, pubblica amministrazione o biometria; se prende o influenza decisioni con effetti giuridici sulle persone; se un agente può agire da solo su sistemi o dati di produzione; se il servizio è esposto a Internet, gestisce pagamenti o identità; se compaiono componenti di provenienza incerta, vulnerabilità critiche o segreti esposti.
Il PDF contiene l'articolo e la checklist con le voci spuntate. Non sostituisce una valutazione legale o tecnica sul singolo prodotto.
Revilaw affianca imprese e software house nella mappatura degli strumenti di IA e dei prodotti sul mercato europeo, nella policy da portare in consiglio, nell'aggiornamento degli assetti e del modello 231 e nelle verifiche indipendenti prima del rilascio. Un percorso calibrato sulle dimensioni dell'impresa, che lascia evidenze ordinate.