AI Act: i 5 obblighi chiave per SaaS italiani
Timeline, sanzioni e passi operativi. Cosa fare se utilizzi API di OpenAI o modelli proprietari — e perché la classificazione del rischio è la decisione che non puoi rimandare.
Leggi l'analisi →
Legal DevOps · Tech Compliance
we regulate
your complexity.
Compliance Intelligence
Aree di Competenza
Supporto legale specializzato per ogni fase del tuo prodotto digitale. Tre discipline, un solo principio: la conformità normativa come requisito funzionale.
Data
Costruiamo insieme l'architettura legale del tuo trattamento dati. Data Schema review, Data Retention policy e gestione dei consensi integrati nel ciclo di sviluppo prima che la complessità del dato diventi compliance debt.
Scopri di più →
ROBOTS
Ti accompagno all'intersezione tra AI Act, Regolamento Macchine e Cyber Resilience Act: dalla classificazione del rischio AI alla marcatura CE, fino alla FRIA e alla tutela della proprietà intellettuale dei tuoi modelli.
Scopri di più →
Cybersecurity Law
Compliance NIS2, gestione degli incidenti e responsabilità personale del management. Costruiamo un framework di sicurezza che il tuo Board comprende e il tuo team implementa. Senza rallentare il delivery.
Scopri di più →
Approccio
Compliance By Design
La conformità normativa non è un ostacolo: è un elemento di qualità del prodotto, da integrare fin dalla progettazione.
Integrata nel prodotto
La compliance entra nel processo di sviluppo come requisito funzionale con acceptance criteria verificabili.
Scalabile con il business (proporzionata al rischio reale)
Un framework normativo costruito sul profilo di rischio effettivo della tua azienda, non su checklist generiche. Dalla startup seed alla scale-up con 50 sub-processor e audit ISO 27001: la struttura si adatta senza riscritture complete.
Collaborativa e misurabile (con gli strumenti del tuo team)
Lavoro con GitHub, Linear, Notion, Slack. I requisiti normativi sono Issues, non relazioni PDF. La compliance diventa qualcosa che il team monitora e migliora, non qualcosa che gestisce solo l'area legal.
Essere conformi agli standard europei significa essere pronti per qualsiasi cliente, in qualsiasi mercato.
Knowledge Base
Insights & Analisi
NIS2: Responsabilità diretta del CTO
Le nuove responsabilità personali degli amministratori per la gestione del rischio cyber. Come costruire un framework di governance che protegge l'azienda — e il management.
Leggi l'analisi →USA Data Transfer: Guida 2025
Data Privacy Framework e Transfer Impact Assessment. Come gestire legalmente AWS, Google Cloud e Stripe senza bloccare l'operatività.
Leggi l'analisi →
Focus: Data Economy Europea
Data Economy.
Prenota la call →
Data Economy.
Quattro regole.
Un ecosistema.
GDPR, Data Act, Data Governance Act, ePrivacy: il tuo prodotto opera all'intersezione di tutte e quattro. Non sono adempimenti separati da spuntare su una checklist, sono un sistema normativo unico che governa ogni flusso di dati europeo, personali e non. Conoscerne uno senza gli altri è il modo più rapido per essere conformi sulla carta ed esposti nella realtà.
Il sistema normativo che governa ogni dato europeo
Il tuo prodotto produce dati. Li raccoglie, li elabora, li trasferisce, li condivide con sub-processor, li analizza per migliorare le feature, li manda ad AWS, Stripe, Segment, OpenAI. Ogni passaggio è regolato, e il perimetro si è espanso radicalmente negli ultimi anni.
Il GDPR è la base. Ma dal 2023 in poi il legislatore europeo ha costruito intorno a lui un ecosistema di nuove norme che estendono la governance ai dati non personali, ai dati industriali, alle comunicazioni elettroniche. Ignorare il Data Act perché "non trattiamo dati personali IoT" o il DGA perché "non siamo un data marketplace" è un errore che si paga durante la due diligence enterprise o il primo contratto con un cliente bancario.
Il nostro approccio considera la data governance come un layer architetturale del prodotto: i requisiti normativi entrano nel data model, nella pipeline di integrazione e nei contratti con i fornitori, non come vincoli aggiunti a posteriori, ma come specifiche funzionali dalla prima user story.
Il sistema in quattro regolamenti
GDPR Reg. UE 2016/679
La base dell'ecosistema. Governa ogni trattamento di dati personali: raccolta, conservazione, elaborazione, trasferimento. Diritti degli interessati (accesso, cancellazione, portabilità, opposizione), accountability del titolare con registro dei trattamenti, base giuridica per ogni trattamento, obblighi di notifica in caso di data breach entro 72h.
La protezione dei dati deve essere integrata nel sistema fin dalla progettazione e le impostazioni predefinite devono essere le più rispettose della privacy: non sono raccomandazioni — sono obblighi con impatto diretto sull'architettura del prodotto. Questo significa che la retention policy si decide quando si progetta il DB schema, non quando arriva il Garante.
Attenzione al confine della pseudonimizzazione: i dati pseudonimizzati nel tuo sistema di analytics o ML non sono automaticamente fuori dal GDPR. Se il tuo sistema può ricondurli a un individuo specifico (anche indirettamente) restano dati personali. Prima di escluderli dalla compliance, serve una valutazione tecnica specifica.
Per le startup SaaS: il GDPR non è solo privacy policy e banner cookie, è l'architettura del consenso, la retention policy nel DB schema, i DPA con ogni sub-processor, il Data Breach Response Plan testato prima che serva.
Data Act Reg. UE 2023/2854 (in vigore dal settembre 2025)
Il Data Act cambia le regole del gioco per chi produce hardware connesso: i tuoi clienti hanno ora il diritto di prendere i dati generati dall'uso del loro dispositivo e darli a un concorrente diretto. Non è una eventualità teorica, è un diritto esercitabile dal settembre 2025. Come lo gestisci contrattualmente? Come impatta l'architettura del tuo servizio di valore aggiunto sui dati?
Per chi elabora o commercializza dati IoT di terze parti: le nuove norme sull'accesso e la condivisione cambiano la tua posizione contrattuale rispetto ai produttori di quel hardware. Verifica prima della prossima rinegoziazione.
Per i cloud provider: il Data Act introduce obblighi di portabilità e switching. Per i clienti enterprise che usano il tuo SaaS su un singolo cloud: le clausole di lock-in che hai oggi potrebbero non reggere al confronto con i nuovi standard di portabilità.
Per i SaaS nel settore sanitario: l'European Health Data Space introduce obblighi specifici di portabilità secondaria e accesso per finalità di ricerca. Se gestisci dati di salute, il perimetro si è già allargato.
DGA Data Governance Act — Reg. UE 2022/868 (in vigore dal settembre 2023)
Se il tuo prodotto aggrega dataset da più fonti, facilita la condivisione di dati tra aziende o funziona come marketplace di dati, il DGA ti classifica come "data intermediation service provider" con obblighi di registrazione, separazione delle attività e requisiti di neutralità. Non è una categoria intuitiva, molte startup che la rientrano non lo sanno ancora.
Il DGA e il Data Act non si sovrappongono: il DGA regola chi facilita la condivisione (gli intermediari), il Data Act regola i diritti su categorie specifiche di dati (quelli generati da prodotti connessi). Un'azienda che costruisce un servizio B2B sui dati IoT deve comprendere entrambi, perché i rischi di non-conformità vengono da direzioni diverse.
ePrivacy Dir. 2002/58/CE e proposta di Regolamento (in revisione)
Il framework che il Garante applica nelle sue ispezioni sui cookie e sul behavioral tracking. La proposta di Regolamento ePrivacy è in stallo dal 2017, ma il Garante non aspetta: ha già emesso sanzioni significative su cookie wall, dark pattern e configurazioni non conformi delle CMP. Non aspettare il regolamento finale per mettere a posto il tuo banner.
La data governance diventa un requisito funzionale del software. Lavoro direttamente con il tuo team tecnico, non a valle del loro lavoro, ma dalla prima user story. I requisiti normativi entrano nel DB schema prima della prima migrazione, nei DPA prima dell'integrazione del sub-processor, nella CMP prima del go-live.
Il risultato è un prodotto che non accumula compliance debt: ogni nuova feature nasce già valutata rispetto al suo impatto normativo, ogni nuovo fornitore viene qualificato prima dell'integrazione, ogni trasferimento extra-UE ha la sua base legale documentata.
Servizi
DPO as a Service
Nomina formale come Data Protection Officer esterno ai sensi dell'art. 37 GDPR. Punto di contatto ufficiale con il Garante Privacy, monitoraggio continuativo della conformità, gestione delle richieste degli interessati (DSAR: accesso, cancellazione, portabilità, opposizione), formazione del team, reportistica con metriche di compliance. Modello scalabile: retainer calibrato sulla fase della tua azienda, ampliabile senza vincoli di assunzione. Non un DPO generalista, un DPO con competenza diretta su architetture SaaS, API economy e cloud provider.
Privacy Architecture Review
Analisi tecnico-giuridica dell'architettura del prodotto rispetto ai requisiti GDPR e Data Act: mappatura di tutti i flussi dati (dall'input utente al bucket S3, passando per ogni microservizio e ogni chiamata API di terze parti), identificazione delle basi giuridiche per ogni trattamento, analisi delle retention policy implementate nel DB schema, verifica della minimizzazione dei dati raccolti. Include la verifica del confine tra dati personali e pseudonimizzati per i sistemi di analytics e ML: un dato che non identifica direttamente l'utente non è automaticamente fuori dal GDPR.
Technical DPIA
Data Protection Impact Assessment per trattamenti ad alto rischio: profilazione comportamentale su larga scala, monitoraggio sistematico, trattamento di categorie particolari (dati sanitari, biometrici, giudiziari). La DPIA è costruita sull'architettura reale del sistema, con threat model dei rischi per i diritti degli interessati, analisi delle misure tecniche di mitigazione implementate (cifratura, pseudonimizzazione, access control) e valutazione della proporzionalità del trattamento. Documento difendibile in caso di ispezione o contestazione.
Data Breach Response
Procedura strutturata di risposta agli incidenti: valutazione del livello di rischio per i diritti degli interessati, notifica al Garante entro 72h con documentazione completa dell'incidente, comunicazione agli interessati quando il rischio è elevato, remediation plan e post-incident review. Il servizio include canale di emergenza con SLA di risposta nelle prime ore, perché la qualità della notifica e l'esito dell'indagine si decidono nelle prime 24h dall'identificazione dell'incidente.
Vendor Risk & Transfer Impact Assessment
Mappatura e qualificazione di tutti i sub-processor: AWS, GCP, Stripe, HubSpot, Intercom, Mixpanel, Segment, Sentry, OpenAI, Anthropic e ogni altro fornitore che tratta dati per tuo conto. Negoziazione e redazione dei Data Processing Agreement. Standard Contractual Clauses per i trasferimenti extra-UE. Transfer Impact Assessment per i flussi verso USA, UK e paesi terzi. Il registro dei trattamenti viene costruito e mantenuto come documento vivo, aggiornato ad ogni nuova integrazione.
Consent & Cookie Compliance
Implementazione della strategia di consenso conforme alle linee guida Garante 2021: configurazione della Consent Management Platform, verifica dei default privacy-safe, audit del banner cookie e del cookie wall, analisi dei tag di terze parti (Google Tag Manager, Meta Pixel, LinkedIn Insight Tag, Hotjar). Per ogni script di terze parti: base giuridica, categoria di cookie, implicazioni per il consenso. Il consenso raccolto deve essere documentato, granulare e revocabile con la stessa facilità con cui è stato dato.
FAQ
Il Data Act si applica a noi? Costruiamo software, non hardware.
Se costruisci solo software SaaS senza hardware, non sei il target diretto. Il problema è a monte: i tuoi clienti che producono device connessi hanno nuovi obblighi di data sharing che cambieranno le loro architetture di integrazione, e di conseguenza i contratti con te. Se il tuo SaaS è parte di un ecosistema IoT enterprise, inizia ora a capire come i nuovi diritti di accesso ai dati ridisegnano i flussi e i rapporti contrattuali tra i soggetti coinvolti.
Abbiamo già una privacy policy. Siamo a posto?
La privacy policy è solo la superficie visibile della compliance GDPR. Quello che il Garante verifica in un'ispezione è il livello sottostante: il registro dei trattamenti effettivamente compilato, la base giuridica documentata per ogni trattamento, i DPA firmati con tutti i sub-processor, le procedure reali di gestione delle DSAR e del data breach. Una privacy policy ben scritta senza architettura sottostante è uno scudo di carta.
Quando scatta l'obbligo di nominare un DPO?
L'obbligo scatta in tre casi: autorità pubblica, monitoraggio sistematico su larga scala degli interessati come attività principale, trattamento su larga scala di categorie particolari. Per le startup SaaS l'obbligo scatta tipicamente quando il core business è la profilazione comportamentale, l'analytics predittivo o il trattamento di dati sanitari. Ma anche senza obbligo formale, la nomina volontaria è consigliata: viene valutata positivamente dal Garante e segnala maturità organizzativa agli investitori.
Usiamo dati sintetici per l'addestramento dei modelli. Siamo fuori dal GDPR?
Non automaticamente. I dati sintetici escono dal perimetro GDPR solo se garantiscono l'impossibilità pratica di re-identificazione rispetto ai dati originali — e questa soglia va dimostrata tecnicamente, non solo affermata. Se usi dati sintetici derivati da dataset di dati personali, una valutazione specifica è necessaria prima di usarli come alternativa al consenso.
Cosa cambia per noi con il Data Act in vigore da settembre 2025?
Dipende da chi sono i tuoi clienti. Se producono o usano hardware connesso, le loro architetture di data sharing cambiano, e cambieranno i contratti con te. Se sei un cloud provider o gestisci servizi di hosting, i nuovi obblighi di portabilità e switching impattano le tue clausole contrattuali. Se sei un SaaS nel settore sanitario, l'ecosistema dell'European Health Data Space ha già allargato il perimetro dei tuoi obblighi. Verifica prima della prossima rinegoziazione contrattuale.
Dove sei rispetto alla Data Economy europea?
Una call di 30 minuti per mappare i tuoi flussi dati rispetto a GDPR, Data Act e DGA: quali regolamenti si applicano al tuo prodotto, quali sono le esposizioni reali e quali passi concreti fare nei prossimi 90 giorni. Senza impegno.
Focus: AI Act · Regolamento Macchine · Cyber Resilience Act
AI Act & Macchine.
Richiedi la classificazione →
AI Act & Macchine.
Il futuro è già
regolato.
Se costruisci robot, sistemi autonomi o macchine con AI integrata, stai operando all'intersezione di tre normative europee che si sovrappongono: l'AI Act, il Regolamento Macchine e — dal 2027 — il Cyber Resilience Act. Non basta conoscerne una sola. E quasi nessuno conosce tutte e tre.
Tre normative, un solo prodotto
Fino al 2024 i costruttori di macchine industriali avevano un unico framework di riferimento: la Direttiva Macchine con la sua marcatura CE. Oggi quel framework non è più sufficiente. Se la macchina integra AI, serve un secondo layer di conformità, l'AI Act. Se ha componenti software aggiornabili, dal dicembre 2027 servirà anche il Cyber Resilience Act.
Il risultato pratico è un regime multiplo di conformità: la macchina deve essere sicura come hardware (Regolamento Macchine, marcatura CE), conforme come sistema AI (classificazione del rischio, documentazione tecnica, supervisione umana, FRIA) e (dal 2027) cyber-resiliente come prodotto con elementi digitali (security by design, vulnerability disclosure, patch support per tutta la vita commerciale).
Chi non costruisce la documentazione tecnica in modo integrato dalla prima release si trova a fare una riscrittura completa prima del lancio enterprise. Il costo non è lineare: è molto più alto se affrontato a posteriori.
Aggiunge un ulteriore layer di rischio la nuova Direttiva sulla Responsabilità per i Prodotti: un bug nel modello ML che causa un incidente non è più solo una questione tecnica, ma una potenziale responsabilità civile del produttore. La due diligence legale sul software e sull'AI non è opzionale, è parte del prodotto.
I framework al loro punto di intersezione
AI Act Reg. UE 2024/1689
Quattro categorie di rischio. Per le macchine industriali il punto critico è l'Allegato III: i sistemi AI usati come componenti di sicurezza sono classificati ad alto rischio, con obblighi di documentazione tecnica, registrazione nel database EU, testing di robustezza, supervisione umana obbligatoria e FRIA. La classificazione errata verso il basso è il tipo di non-conformità più sanzionato.
Se integri un modello AI general purpose (un LLM, per esempio) nella tua macchina per interfacce vocali o decision support: verifica che il modello rispetti gli obblighi di trasparenza sui dati di training previsti per questi modelli. Se non è conforme, la responsabilità può ricadere su di te come deployer.
Intersezione Il doppio regime per robot con AI
Una macchina con componente AI ad alto rischio deve soddisfare contemporaneamente: i requisiti essenziali di sicurezza del Regolamento Macchine, inclusi quelli per macchine con funzioni di apprendimento automatico (Allegato I, sezione 1.1.9); e i requisiti AI Act: documentazione tecnica Allegato IV, log automatici verificabili, misure di supervisione umana, post-market monitoring. Le due conformità condividono alcune evidenze documentali ma richiedono strutture distinte — costruirle separatamente duplica il lavoro senza aggiungere valore.
Reg. Macchine Reg. UE 2023/1230 (applicabile dal gennaio 2027)
Sostituisce la Direttiva Macchine con un framework aggiornato che include le macchine con capacità di apprendimento automatico. I nuovi requisiti essenziali di sicurezza per macchine "self-evolving" richiedono che i comportamenti di sicurezza rimangano prevedibili e verificabili anche dopo le fasi di training e aggiornamento del modello. Ogni progetto che inizia oggi dovrebbe tenerne conto: è molto meno costoso che fare una revisione completa tra 18 mesi.
CRA Cyber Resilience Act — Reg. UE 2024/2847 (applicabile dal dicembre 2027)
Dal dicembre 2027 tutti i prodotti con elementi digitali (inclusi robot e sistemi autonomi con componenti software) devono soddisfare requisiti di cybersecurity by design: la sicurezza deve essere incorporata nel prodotto fin dalla progettazione, non aggiunta dopo. Obblighi concreti: gestione strutturata delle vulnerabilità, supporto di patch di sicurezza per tutta la vita commerciale del prodotto, notifica all'ENISA entro 24h delle vulnerabilità attivamente sfruttate. Per chi costruisce robot con firmware aggiornabile in remoto: ogni componente software rientra nel perimetro CRA. Costruire oggi la documentazione tecnica in modo integrato con il Regolamento Macchine e l'AI Act (invece di tre processi separati) è la scelta più efficiente.
Scadenze operative
| Data | Evento |
|---|---|
| Feb 2025 | AI Act: divieti assoluti in vigore (identificazione biometrica real-time, manipolazione subliminale, social scoring). |
| Ago 2026 | AI Act: piena applicazione per sistemi ad alto rischio (Allegato III). FRIA, documentazione tecnica, registrazione EU. Sanzioni: fino a 15M€ o 3% del fatturato. |
| Gen 2027 | Reg. Macchine 2023/1230 sostituisce la Direttiva Macchine 2006/42/CE. |
| Dic 2027 | Cyber Resilience Act: applicazione piena. Security by design, vulnerability disclosure, patch support obbligatorio. |
Servizi
AI Risk Classification Report
Analisi del sistema AI rispetto alle quattro categorie del regolamento, con focus sull'Allegato III per i componenti di sicurezza nelle macchine. Mappatura dell'intended purpose dichiarato e del ragionevole foreseeable misuse, perché l'AI Act valuta il rischio sul caso d'uso reale, non solo su quello dichiarato. Verifica dell'interazione tra la classificazione AI Act e quella sotto il Regolamento Macchine. Analisi del regime applicabile ai modelli general purpose eventualmente integrati nel sistema.
Output: classification memo con posizione difendibile davanti al market surveillance authority, mappa degli obblighi applicabili e roadmap di compliance prioritizzata per i prossimi 18 mesi.
Marcatura CE & Documentazione Tecnica Integrata
Gestione della documentazione tecnica per sistemi a regime multiplo, Regolamento Macchine, AI Act, Cyber Resilience Act. Costruzione della documentazione integrata che soddisfa tutti i framework senza duplicazioni: stessa evidenza documentale, strutture distinte dove richiesto. Definizione del percorso di conformità: auto-dichiarazione vs. coinvolgimento di un Notified Body per le categorie ad alto rischio.
Un punto critico nella costruzione della documentazione tecnica è la frattura tra obbligo di controllo e potere di controllo: l'AI Act impone obblighi di supervisione umana (Art. 14), ma un sistema AI può essere progettato in modo tale da rendere questo controllo difficile o impossibile da esercitare concretamente. Una macchina che elabora centinaia di segnali al secondo in ambienti industriali non può essere "supervisionata" da un operatore umano nel senso tradizionale del termine. La documentazione tecnica deve affrontare questo punto esplicitamente: definire quale tipo di supervisione è tecnicamente esercitabile su quel sistema specifico, in quali condizioni operative, con quale frequenza. Non documentare questa analisi espone al rischio di non soddisfare il requisito normativo.
FRIA — Fundamental Rights Impact Assessment
Valutazione d'impatto sui diritti fondamentali obbligatoria per i sistemi AI ad alto rischio. Per le macchine industriali: analisi dei diritti delle persone che interagiscono con la macchina o ne sono influenzate (operatori, lavoratori, terzi nell'ambiente operativo). Analisi dei bias sistematici nei dati di training per le funzioni safety-critical. Documento costruito per essere aggiornato ad ogni modifica significativa del sistema.
Product Liability & Responsabilità Civile AI
Strategia di documentazione per dimostrare due diligence nella progettazione e nel monitoring del sistema AI. Struttura contrattuale lungo la supply chain: clausole di indemnity tra costruttore della macchina, fornitore del componente AI e distributore. Analisi della copertura assicurativa rispetto al nuovo regime di responsabilità per prodotti con componenti software e AI.
Due dinamiche strutturali rendono la responsabilità civile nei sistemi AI più complessa di quella per i prodotti tradizionali. La prima è il many hands problem: la catena di sviluppo coinvolge decine di soggetti — nessuno ha il controllo completo, nessuno ha visibilità su ogni componente. In caso di incidente, questa frammentazione crea un vuoto di responsabilità che la struttura contrattuale deve affrontare esplicitamente. La seconda è il rischio del moral crumple zone: in un sistema dove un operatore è nominalmente responsabile della supervisione ma nella pratica non può esercitare un controllo reale sull'output del sistema AI, è questo operatore ad assorbire il peso legale in caso di incidente. La documentazione tecnica deve definire con precisione il perimetro effettivo del controllo umano esercitabile nel contesto operativo reale.
Training Data & IP dei Modelli
Analisi della composizione del dataset di training: provenienza, licenze, presenza di dati protetti da copyright o segreto industriale. Review delle licenze open source per i modelli base e delle restrizioni d'uso per applicazioni commerciali e ad alto rischio. Protezione della proprietà intellettuale del modello proprietario: trade secret, IP assignment nei contratti con dipendenti e contractor. Compliance con gli obblighi di trasparenza sui dati di training per i modelli general purpose.
CRA Readiness Assessment
Analisi del prodotto rispetto ai requisiti del Cyber Resilience Act in preparazione alla scadenza del dicembre 2027: mappatura della superficie di attacco, verifica dell'architettura di security by design, analisi della policy di vulnerability disclosure, verifica della procedura di patch release. Per i costruttori di robot: il CRA si sovrappone agli obblighi di post-market surveillance del Regolamento Macchine e al monitoring richiesto dall'AI Act, un sistema integrato è più efficiente di tre processi separati.
Post-Market Monitoring & Incident Reporting
Progettazione del sistema di monitoraggio in produzione richiesto dall'AI Act: KPI di performance, soglie di alert per performance degradation, procedura di aggiornamento del modello senza trigger di una nuova conformity assessment. Incident reporting: gravi malfunzionamenti devono essere notificati al market surveillance authority nazionale. Integrazione con gli obblighi di post-market surveillance del Regolamento Macchine e con la vulnerability disclosure del CRA.
Per chi è pensato
Costruttori di robot industriali e cobot — Robot collaborativi con funzioni adattive, sistemi di pick-and-place con computer vision, bracci robotici con trajectory planning ML-based. Il componente AI è quasi certamente un safety component ai sensi dell'AI Act: alto rischio, Allegato III.
Produttori di sistemi autonomi e AMR — Autonomous Mobile Robot e AGV con navigazione ML-based per ambienti industriali o logistici. L'autonomia di movimento in ambienti condivisi con persone attiva requisiti specifici sia sotto il Regolamento Macchine che sotto l'AI Act.
Startup robotics e deep tech — Team che sviluppano piattaforme robotiche per agricoltura, edilizia, healthcare, difesa o spazio. Il regime normativo multiplo impatta il design del sistema dall'inizio: è molto più costoso adeguare un'architettura a posteriori che costruirla conforme dalla prima release.
Integratori di sistemi AI in macchine esistenti — Chi aggiunge un layer AI (computer vision, anomaly detection, predictive maintenance) a macchine già certificate. L'integrazione di un componente AI ad alto rischio può richiedere una nuova valutazione di conformità dell'intera macchina, e dal 2027 una revisione della documentazione CRA se il prodotto ha componenti software aggiornabili in remoto.
FAQ
Ho già la marcatura CE per la mia macchina. Devo fare qualcosa per l'AI Act?
La marcatura CE non copre la compliance AI Act. Se il sistema AI rientra nell'alto rischio — tipicamente perché è un componente di sicurezza della macchina — servono documentazione tecnica aggiuntiva, registrazione nel database EU, sistema di logging e monitoring, FRIA. La marcatura CE resta valida per la sicurezza meccanica, ma la conformità AI Act è un obbligo separato. Dal 2027 verifica anche i requisiti CRA per i componenti software aggiornabili.
Il mio modello migliora nel tempo (online learning). Ogni aggiornamento richiede una nuova conformity assessment?
Non necessariamente, ma dipende dall'entità della modifica. L'AI Act distingue tra modifiche "sostanziali" e aggiornamenti minori. La documentazione tecnica iniziale deve descrivere i limiti entro cui il modello può aggiornarsi senza richiedere una nuova valutazione — progettare questa soglia in anticipo è molto più efficiente che valutarla caso per caso. Il CRA dal 2027 aggiunge requisiti specifici: ogni patch di sicurezza va documentata secondo la procedura di vulnerability disclosure.
Siamo una startup. Possiamo permetterci il regime normativo multiplo?
Il costo della conformità è inversamente proporzionale a quanto presto la integri. Un'architettura che parte già con la documentazione tecnica corretta, il sistema di logging e le procedure di monitoring costa marginalmente di più nella fase di sviluppo, e risparmia la riscrittura completa prima del lancio enterprise. Il mercato enterprise e i fondi di investimento richiedono sempre più evidenza di AI Act e CRA readiness come condizione per la firma.
Il Regolamento Macchine sostituisce la Direttiva dal 2027. Cosa devo fare adesso?
Ogni nuovo progetto che inizia oggi dovrebbe essere progettato tenendo conto dei nuovi requisiti: è molto meno costoso che fare una revisione completa tra 18 mesi. Considera già il CRA (dicembre 2027): i requisiti di cybersecurity by design si sommano ai nuovi requisiti del Regolamento Macchine. Affrontarli separatamente è meno efficiente che costruire una documentazione tecnica integrata fin dall'inizio.
Il tuo robot o sistema AI è classificato correttamente sotto tutti i framework applicabili?
Una sessione di classificazione per analizzare il tuo prodotto rispetto ad AI Act, Regolamento Macchine e Cyber Resilience Act: categoria di rischio, obblighi applicabili, interazione tra i tre regimi e roadmap operativa. 60 minuti, posizione difendibile come output.
Focus: NIS2 · DORA · Cyber Resilience Act
NIS2 & Cyber Law.
Richiedi la Gap Analysis →
NIS2 & Cyber Law.
Prepariamoci insieme.
NIS2 non è solo un problema IT. È un obbligo legale con responsabilità personale diretta per gli amministratori. La delega al team tecnico non è sufficiente, e ignorarlo espone il management a sanzioni personali indipendentemente da chi gestisce la sicurezza operativa.
Responsabilità personale degli amministratori
Dal recepimento della NIS2 in Italia (D.Lgs. 138/2024), gli organi di gestione approvano le misure di sicurezza e ne monitorano l'attuazione. La mancata conformità può comportare responsabilità personale dei dirigenti — inclusa la sospensione temporanea dalla carica per i soggetti essenziali.
Il cambio strutturale che NIS2 introduce
Il perimetro si è triplicato. NIS1 copriva 7 settori. NIS2 ne copre 18, includendo per la prima volta i managed service provider, i cloud provider, i software vendor e i fornitori ICT in generale. Se il tuo cliente principale è una banca, un ospedale, una utility o una PA, potresti trovarti soggetto agli obblighi NIS2 della supply chain anche senza rientrare direttamente nel perimetro, perché i soggetti essenziali sono obbligati a gestire il rischio dei loro fornitori ICT.
La responsabilità è diventata personale. Gli organi di gestione approvano le misure di sicurezza e ne monitorano l'attuazione. La mancata conformità può comportare responsabilità personale dei dirigenti, inclusa la sospensione temporanea dalla carica per i soggetti essenziali. Non è più una questione solo tecnica: è una responsabilità del Board.
Le notifiche sono più rapide e strutturate. Pre-alert all'ACN entro 24h dall'identificazione dell'incidente, notifica dettagliata entro 72h, rapporto finale entro 1 mese. Ogni fase ha requisiti di contenuto specifici. Arrivare a un incidente senza procedure documentate e testate significa gestire contemporaneamente la crisi tecnica e la redazione di documenti normativi sotto pressione.
NIS2 valuta la sicurezza a 360 gradi. Non solo la cybersecurity tecnica: anche i controlli fisici sui sistemi (accesso non autorizzato ai server) e la resilienza rispetto a interruzioni elettriche o eventi ambientali. Un framework che copre solo il software è incompleto, e lo è anche davanti all'ACN.
Sei una fintech, una banca o un'assicurazione?
Il tuo framework di riferimento non è NIS2 ma il DORA (in vigore da gennaio 2025): requisiti specifici di ICT risk management, testing di resilienza operativa, gestione formalizzata dei fornitori ICT critici. Dove DORA e NIS2 si sovrappongono, prevale DORA. Ma se eroghi servizi ICT a terzi, potresti essere soggetto a entrambi, e gestirli come due silos separati è più costoso che costruire un framework integrato.
Sviluppi software venduto come prodotto?
Dal dicembre 2027 il Cyber Resilience Act impone requisiti di cybersecurity by design: sicurezza incorporata nel prodotto fin dalla progettazione, gestione strutturata delle vulnerabilità, supporto di patch per tutta la vita commerciale. Per le startup che vendono software come licenza o prodotto embedded: il CRA introduce un regime di conformità simile alla marcatura CE.
Finestre temporali obbligatorie — Incident Notification NIS2
24h
Pre-alert
Notifica iniziale all'ACN: informazioni minime sull'incidente, impatto stimato, indicazione se si sospetta un attacco deliberato.
72h
Notifica completa
Analisi iniziale della causa, misure adottate, indicatori di compromissione. In parallelo, notifica al Garante Privacy se coinvolti dati personali.
1 mese
Report finale
Analisi completa della causa radice, misure di remediation, impatto effettivo quantificato, lezioni apprese.
Servizi
NIS2 Gap Analysis
Verifica dell'assoggettamento al D.Lgs. 138/2024: analisi del settore operativo, delle dimensioni (soglia 50 dipendenti o 10M€ fatturato) e della tipologia di soggetto (essenziale o importante). Mappatura degli obblighi tecnici e organizzativi applicabili: misure di sicurezza tecniche, fisiche e organizzative, sicurezza della supply chain ICT, gestione degli incidenti, business continuity, crittografia, autenticazione multi-fattore. L'analisi valuta la conformità rispetto agli standard internazionali di riferimento (ISO/IEC 27001, ISO/IEC 27005) la cui adozione è la strada più difendibile in caso di ispezione ACN.
Output: verifica di assoggettamento documentata, mappa degli obblighi con priorità operative, roadmap con milestone concrete.
Incident Response Plan
Piano di risposta agli incidenti conforme agli obblighi NIS2: definizione operativa di "incidente significativo", procedure di rilevamento e escalation interna, catena di notifica all'ACN (24h pre-alert → 72h notifica dettagliata → 1 mese rapporto finale), template di documentazione per ogni fase. Include il monitoraggio preventivo delle vulnerabilità note nei sistemi in uso, perché un incidente spesso nasce da una vulnerabilità già nota e non patchata. Coordinamento con le procedure GDPR per gli incidenti che comportano anche data breach: le due notifiche hanno scadenze analoghe ma contenuti diversi e devono essere gestite in parallelo. Il piano viene testato con scenari simulati: un piano non testato non funziona quando serve.
Supply Chain Security Contracts
Assessment dei fornitori ICT critici e redazione delle clausole contrattuali di sicurezza: obblighi tecnici minimi (patching policy, incident notification, audit rights), SLA di sicurezza con metriche misurabili, diritti di audit e penetration testing, obblighi di notifica degli incidenti verso il cliente. La supply chain è il vettore di attacco più comune, e NIS2 la rende una responsabilità contrattuale esplicita.
DORA Compliance (settore finanziario)
Per banche, fintech, assicurazioni e gestori di investimenti: analisi del profilo di conformità rispetto al DORA. Revisione del framework di ICT risk governance. Assessment dei fornitori ICT critici secondo le linee guida delle autorità di supervisione europee. Strutturazione delle procedure di incident reporting DORA e coordinamento con gli obblighi NIS2. Per le fintech: verifica dell'assoggettamento diretto e dell'impatto sui contratti con i clienti soggetti DORA.
Board & Management Training (4h)
Sessione formativa per CTO, CEO e membri del CDA: quadro degli obblighi e responsabilità personale del management, perimetro completo della sicurezza richiesta (tecnica, fisica, organizzativa), cosa deve approvare il Board e come documentarlo, scenari pratici di incidente con simulazione del processo decisionale nelle prime 24h. Formazione documentata e certificata, prova dell'adempimento dell'obbligo formativo in caso di ispezione.
Cyber Risk Legal Assessment
Analisi del profilo di rischio legale: mappatura delle potenziali sanzioni rispetto al livello di non-conformità attuale, valutazione dell'esposizione della responsabilità personale del management, analisi dei contratti con clienti enterprise che contengono clausole di security compliance. Per le startup che forniscono servizi ICT a soggetti NIS2: valutazione dell'impatto degli obblighi di supply chain security. Include una prima analisi del perimetro CRA per chi sviluppa e vende software come prodotto.
CSIRT Notification Management
Supporto legale nella gestione delle notifiche obbligatorie all'ACN durante e dopo un incidente: redazione del pre-alert nelle prime 24h, gestione della notifica dettagliata nelle 72h, predisposizione del rapporto finale entro 1 mese. Gestione coordinata con il Garante Privacy quando l'incidente coinvolge anche dati personali. Supporto nelle eventuali fasi di indagine successiva.
NIS2: sei soggetto?
Settore — Allegato I (soggetti essenziali): energia, trasporti, banche, infrastrutture mercati finanziari, sanità, acqua potabile, acque reflue, infrastrutture digitali, gestione servizi ICT B2B, PA centrale, spazio. Allegato II (soggetti importanti): servizi postali e corrieri, gestione rifiuti, produzione chimica, produzione alimentare, produzione dispositivi medici/elettronici/macchinari/veicoli, fornitori digitali (marketplace, motori di ricerca, social network).
Dimensioni — 50+ dipendenti oppure fatturato annuo > 10M€. Le condizioni sono alternative: basta una delle due.
Supply chain — Anche se non rientri direttamente nel perimetro, i tuoi clienti soggetti NIS2 hanno l'obbligo di gestire il rischio dei fornitori ICT critici. Se fornisci software, infrastruttura o servizi gestiti a banche, ospedali, utility o PA, aspettati clausole contrattuali NIS2-aligned nei prossimi contratti.
Sanzioni
| Tipologia | Sanzione massima | Responsabilità management |
|---|---|---|
| Soggetti Essenziali | €10M o 2% fatturato mondiale | Sospensione temporanea dalla carica |
| Soggetti Importanti | €7M o 1,4% fatturato mondiale | Notifica pubblica dell'incidente |
| DORA (soggetti finanziari) | Fino a 1% del fatturato medio giornaliero per ogni giorno di violazione | Responsabilità personale dei vertici |
FAQ
Entro quando devo essere conforme?
Il D.Lgs. 138/2024 è in vigore. Le aziende soggette devono registrarsi sulla piattaforma ACN e implementare le misure di sicurezza richieste. L'ACN ha avviato le attività di registrazione e le prime verifiche. Il momento giusto per strutturare la compliance è prima del primo incidente notificabile, non dopo.
Come funziona la cascata di notifica NIS2?
Tre fasi: (1) pre-alert entro 24h — informazioni minime sull'incidente, impatto stimato, indicazione se si sospetta un attacco deliberato; (2) notifica dettagliata entro 72h — analisi iniziale della causa, misure adottate, indicatori di compromissione; (3) rapporto finale entro 1 mese — analisi completa della causa radice, misure di remediation, impatto effettivo quantificato. Per gli incidenti che coinvolgono dati personali, la notifica al Garante Privacy (stessa finestra di 72h) va gestita in parallelo con la NIS2.
NIS2 si applica alle startup?
Le micro e piccole imprese sono generalmente escluse dal perimetro diretto. Ma se i tuoi clienti enterprise sono soggetti NIS2, inizieranno a richiedere garanzie contrattuali di sicurezza nei prossimi 12 mesi, indipendentemente dalle tue dimensioni.
Siamo una fintech. NIS2 o DORA?
DORA per gli obblighi di resilienza operativa ICT: è la norma specifica per il settore finanziario e prevale su NIS2 dove si sovrappongono. Ma se eroghi servizi ICT a terzi al di fuori del perimetro finanziario, NIS2 potrebbe applicarsi in parallelo. Gestire i due regimi come un framework unico (invece di due compliance separate) è più efficiente e meno costoso.
Dobbiamo certificarci ISO 27001 per essere conformi NIS2?
No, non è un obbligo. Ma adottare standard internazionali riconosciuti (ISO/IEC 27001 per la gestione della sicurezza, ISO/IEC 27005 per il risk assessment) è la strada più difendibile in caso di ispezione: dimostra che le misure di sicurezza sono proporzionate, strutturate e verificabili. Non un audit da fare per la norma, ma un framework che rende la compliance sostenibile nel tempo.
La NIS2 riguarda la tua azienda?
Un'ora di assessment per verificare l'assoggettamento, mappare gli obblighi applicabili e definire da dove iniziare in modo concreto. Output: verifica di assoggettamento documentata e priorità operative.
Studio Legale Pompilio
Our Vision.
Crediamo che la conformità normativa non sia un freno all'innovazione, sia il suo fondamento più solido. Il diritto è il codice dell'ecosistema digitale.
“Non si tratta di inseguire la conformità ma di anticiparla. Disegnare i processi misurando, sin dall'inizio, l'esatta esposizione al rischio è il primo passo verso l'obiettivo.”
— Avv. Matteo PompilioI tre principi
Privacy come standard architetturale
Le decisioni sulla protezione dei dati sono decisioni di architettura. Appartengono alla fase di progettazione del sistema, non a quella di revisione finale. Quando la retention policy entra nel DB schema dalla prima migrazione, quando il consenso viene disegnato nel flusso UX prima del go-live, quando i DPA vengono negoziati prima dell'integrazione di un sub-processor: la compliance smette di essere un layer aggiunto e diventa parte della struttura. Un prodotto costruito con questa impostazione è più solido, più verificabile e più facile da evolvere nel tempo.
Diritto e tecnologia: una sola competenza
Il diritto digitale non può essere applicato a distanza dalla tecnologia che regola. Una clausola contrattuale scritta senza conoscere l'architettura del sistema che descrive è strutturalmente debole. Un'analisi di rischio condotta senza leggere il codice (o almeno la documentazione tecnica) non è affidabile. Il metodo dello studio prevede che il lavoro legale e quello tecnico si svolgano in parallelo, con gli stessi strumenti e nella stessa conversazione: non a valle di decisioni già prese, ma nel momento in cui vengono prese.
La conformità è un processo, non un adempimento
La conformità normativa non ha un punto di arrivo. I prodotti evolvono, le architetture cambiano, le normative si aggiornano, i mercati si espandono. Un framework costruito come adempimento periodico (da verificare una volta l'anno, o prima di un audit) non regge a questa dinamica. Il metodo dello studio tratta la conformità come un processo continuo integrato nel ciclo di vita dell'organizzazione: ogni nuova feature viene valutata rispetto al suo impatto normativo, ogni nuovo fornitore viene qualificato prima dell'integrazione, ogni incidente viene gestito con procedure già testate. La conformità che si accumula nel tempo è quella che non si rompe nel momento peggiore.
Il metodo
Integrazione nel ciclo di sviluppo
I requisiti normativi entrano nel processo come acceptance criteria, non come revisioni finali. Ogni sprint ha la sua componente di compliance review, proporzionata al rischio delle feature sviluppate.
Collaborazione diretta con il team tecnico
Non consegno documenti: lavoro con il team. Partecipo alle conversazioni tecniche, capisco l'architettura del sistema, conosco lo stack prima di scrivere una riga di documentazione legale.
Scalabile con il business
Il framework normativo cresce con l'azienda. Costruiamo la struttura giusta per la fase attuale, con la flessibilità per adattarla al prossimo round, al primo cliente enterprise, all'espansione in un nuovo mercato geografico.
Trasparenza totale
Niente linguaggio legale inaccessibile. I rischi sono comunicati in modo chiaro, con impatto sul business quantificato. Le priorità sono condivise, le scadenze sono reali, il lavoro è misurabile.
Costruiamo qualcosa di conforme — e duraturo.
La prima conversazione è gratuita e senza impegno. Analizziamo insieme la regulatory surface del tuo prodotto e definiamo i passi concreti per le prossime settimane.
Iniziamo →Privacy & Cookie Policy
Ultimo aggiornamento: 31 Gennaio 2025
La tua privacy è importante. Questa policy spiega in modo chiaro come gestiamo i tuoi dati quando visiti questo sito. Click sulle sezioni per espanderle.
📋 Privacy Policy
Chi gestisce i tuoi dati?
Sono io, Avv. Matteo Pompilio, il responsabile (tecnicamente "Titolare del Trattamento") dei dati che raccolgo attraverso questo sito.
📍 Studio: Via Superga 195 - 76125, Trani (BT)
Quali dati raccolgo?
🌐 Quando navighi il sito
Il sito raccoglie automaticamente alcune informazioni tecniche:
- • Indirizzo IP (per sicurezza e funzionamento)
- • Browser e dispositivo che usi (per ottimizzare l'esperienza)
- • Pagine visitate e quando (per migliorare il sito)
Versione 2.0 - Ultimo aggiornamento: 31 Gennaio 2025
✉️ Quando mi contatti
Se mi scrivi via email o form di contatto, raccolgo quello che mi dai volontariamente:
- • Nome e cognome
- • Messaggio e richiesta che mi fai
Perché lo faccio? Per rispondere alla tua richiesta di informazioni o consulenza.
Base legale: Esecuzione misure precontrattuali (Art. 6.1.b GDPR)
Quanto li conservo? 24 mesi dalla richiesta, o fino a quando mi chiedi di cancellarli.
Con chi condivido i tuoi dati?
I tuoi dati NON vengono venduti o condivisi per scopi commerciali.
Possono essere comunicati solo a:
- • Fornitori tecnici che mi aiutano a far funzionare il sito (Netlify per hosting, Google Fonts per i caratteri). Questi servizi hanno le loro policy privacy conformi GDPR.
- • Autorità se richiesto per legge (es. Garante Privacy, forze dell'ordine con mandato).
⚠️ Trasferimenti Extra-UE
Alcuni servizi (Netlify, Google) hanno server anche negli USA. I trasferimenti avvengono nel rispetto di EU-US Data Privacy Framework e Clausole Contrattuali Standard approvate UE.
Quali sono i miei diritti?
Il GDPR ti dà controllo totale sui tuoi dati. Puoi:
🔍 Accedere
Chiedermi una copia di tutti i dati che ho su di te
✏️ Rettificare
Correggere dati sbagliati o incompleti
🗑️ Cancellare
Farmi cancellare i tuoi dati ("diritto all'oblio")
⏸️ Limitare
Bloccare temporaneamente l'uso dei tuoi dati
📦 Portare via
Ricevere i dati in formato leggibile da altre piattaforme
🚫 Opporti
Dire "no" al trattamento per motivi legittimi
Come esercitare i tuoi diritti?
Scrivimi semplicemente a: matteopompilio@studiolegalepompilio.it
Ti risponderò entro 30 giorni (max previsto da GDPR).
💡 Puoi anche presentare reclamo al Garante Privacy se ritieni che i tuoi diritti siano stati violati.
🍪 Cookie Policy
📅 Modifiche a questa policy
Questa policy può essere aggiornata nel tempo per riflettere cambiamenti normativi o nelle pratiche del sito. Troverai sempre la versione più recente qui, con data di aggiornamento in alto.
Storico versioni
v2.0 - 31 Gen 2025
Policy completa GDPR. Accordion interattivo, linguaggio chiaro, dettaglio cookie tecnici.
v1.0 - 01 Gen 2025
Informativa iniziale minima.