daRedazione|Gen 3, 2026|Diritto d'Impresa
A partire dal mese di gennaio 2026 diviene operativo, per i soggetti rientranti nella disciplina NIS, l’obbligo di notifica degli incidenti informatici aventi un impatto significativo sulla continuità dei servizi e delle attività svolte. Tale obbligo, previsto daldecreto legislativo 4 settembre 2024, n. 138, trova oggi una declinazione puntuale e operativa nelleLinee Guida NIS – Specifiche di base del processo di gestione degli incidenti di sicurezza informatica, pubblicate il 31 dicembre 2025 dall’Agenzia per la Cybersicurezza Nazionale.
Il documento si inserisce nel più ampio quadro delle misure di attuazione della direttiva NIS e rappresenta un passaggio rilevante nel processo di progressiva definizione delle modalità di gestione e notifica degli incidenti informatici.
Le Linee guida chiariscono che gli incidenti informatici non devono essere considerati quali eventi soltanto tecnici, bensì come accadimenti dotati di una rilevanza giuridica e organizzativa, idonei a incidere sulla responsabilità degli organi di amministrazione, sulla governance del rischio e sulla resilienza complessiva dell’organizzazione.
L’obiettivo del presente contributo è quello di fornire unaguida esplicativadelle Linee guida ACN, illustrando in modo sistematico cosa debbano concretamente fare i soggetti NIS per allinearsi all’obbligo di notifica degli incidenti informatici a partire dal 2026. L’analisi si concentrerà, in particolare, sul rapporto tra misure di sicurezza e procedure di gestione degli incidenti informatici, mettendo in luce come l’adempimento dell’obbligo di notifica non possa essere disgiunto da una preventiva e consapevoleorganizzazione dei processi interni.
Incidenti informatici come rischio giuridico-organizzativo
Nell’assetto delineato dall’Agenzia, gli incidenti informatici assumono una qualificazione che travalica la dimensione meramente tecnica per collocarsi stabilmente nell’ambito dei rischi giuridico-organizzativi dell’impresa e delle pubbliche amministrazioni coinvolte.
Essi sono espressamente considerati eventi potenzialmente idonei a compromettere la continuità delle attività e dei servizi, la protezione delle informazioni e, più in generale, la resilienza complessiva dell’organizzazione. Al riguardo, secondo ACN, la gestione degli incidenti informatici è una capacità essenziale, la cui assenza o inadeguatezza può determinare impatti significativi sotto il profilo operativo, economico e reputazionale.
In questa prospettiva, gli incidenti informatici vengono ricondotti all’interno del sistema dellemisure di gestionedel rischio per la sicurezza informatica, che il decreto NIS pone direttamente in capo agli organi di amministrazione e direttivi.
Sul punto le Linee Guida precisano che la gestione degli incidenti è un processo strutturato che deve essere preventivamente definito, documentato e costantemente aggiornato, in modo coerente con l’evoluzione delle minacce e del contesto operativo. La rilevanza degli incidenti informatici emerge, dunque, anche sotto ilprofilo delle responsabilità, poiché l’inosservanza degli obblighi organizzativi e procedurali può tradursi in violazioni imputabili ai vertici dell’organizzazione.
Le Linee guida chiariscono inoltre che gli incidenti informatici devono essere valutati in relazione ai loro effetti concreti, indipendentemente dalla causa che li ha originati, potendo derivare tanto da condotte dolose quanto da eventi accidentali o da errori umani.
Il processo di gestione degli incidenti informatici nelle Linee Guida ACN
Il fulcro delle Linee guida in esame è rappresentato dalla definizione di unprocesso strutturato di gestionedegli incidenti informatici, concepito come strumento indispensabile per assicurare coerenza, sistematicità ed efficacia alle attività di risposta agli eventi di sicurezza.
Al riguardo le specifiche di ACN prevedono che la gestione degli incidenti informatici sia articolata in un modello unitario, composto da fasi logicamente distinte ma strettamente interconnesse, che consente all’organizzazione di affrontare l’intero ciclo di vita dell’incidente, dalla prevenzione al miglioramento continuo.
La formalizzazione del processo di gestione degli incidenti informatici è il presupposto per l’adempimento degli obblighi di notifica. La capacità di rilevare tempestivamente un incidente, di acquisirne evidenza e di attivare le procedure di risposta dipende, infatti, dalla previa definizione di ruoli, responsabilità, strumenti e flussi informativi.
Al riguardo le specifiche di ACN chiariscono che il processo deve essere descritto e documentato all’interno di un apposito piano per la gestione degli incidenti, approvato dagli organi di amministrazione e direttivi e costantemente riesaminato.
La fase di preparazione: governo, identificazione e protezione
Nelle Linee Guida ACN la fase di preparazione è il momentocoredella gestione degli incidenti informatici, poiché costituisce il presupposto organizzativo e operativo per una risposta efficace agli eventi di sicurezza.
Sul punto le specifiche di ACN prevedono che tale fase ricomprenda, in modo integrato, attività di governo, identificazione e protezione, tutte finalizzate a ridurre la probabilità di accadimento degli incidenti informatici e a mitigarne l’impatto qualora si verifichino. La preparazione non è dunque confinata a un ambito tecnico, ma si estende alla definizione di un assetto decisionale e procedurale coerente con la complessità dell’organizzazione.
Il governo degli incidenti informatici passa, in primo luogo, dall’adozione e dalla formalizzazione di politiche di sicurezza informatica, approvate dagli organi di amministrazione e direttivi, nelle quali devono essere disciplinati il monitoraggio degli eventi, la risposta agli incidenti e le modalità di ripristino.
Tali politiche rappresentano l’impegno formale dell’organizzazione e orientano le decisioni operative, assicurando che la gestione degli incidenti informatici sia coerente con la strategia complessiva di sicurezza e con il profilo di rischio del soggetto NIS.
La fase di identificazione è invece funzionale a garantire una conoscenza puntuale del contesto operativo, attraverso l’inventario dei sistemi informativi e di rete, dei servizi e dei flussi di dati, nonché mediante l’individuazione delle minacce e delle vulnerabilità. Sul punto le specifiche di ACN evidenziano che una mappatura incompleta degli asset compromette la capacità di rilevare e gestire correttamente gli incidenti informatici.
Infine, la fase di protezione si traduce nell’adozione di misure tecniche e organizzative, quali procedure formalizzate, backup, controlli sugli accessi e attività di formazione, che concorrono a rendere la gestione degli incidenti informatici un processo strutturato e verificabile, strettamente connesso agli obblighi di notifica previsti dalla disciplina NIS.
La fase di rilevamento: evidenza degli incidenti informatici e monitoraggio continuo
La fase di rilevamento è fondamentale per assolvere all’obbligo di notifica degli incidenti informatici. Essa permette di individuare tempestivamente il verificarsi di eventi rilevanti per la sicurezza e di valutarne la riconducibilità a un incidente soggetto a notifica.
Al riguardo le specifiche di ACN prevedono che il rilevamento si fondi su attività dimonitoraggio continuodei sistemi informativi e di rete, finalizzate all’individuazione di eventi potenzialmente avversi, sia di natura intenzionale sia accidentale. Sul punto le Linee Guida precisano che non ogni evento di sicurezza integra automaticamente un incidente informatico, rendendosi necessaria una fase di analisi e qualificazione, comunemente definita triage.
Un elemento centrale di questa fase è ilconcetto di “evidenza”dell’incidente informatico, che assume una rilevanza determinante ai fini dell’adempimento dell’obbligo di notifica. Le Linee Guida chiariscono che per evidenza dell’incidente si intende la disponibilità, in capo al soggetto NIS, di elementi oggettivi dai quali si evince il verificarsi di una delle tipologie di incidenti informatici rilevanti.
È da tale momento, e non da quello dell’effettivo verificarsi dell’evento, che decorrono i termini per la trasmissione della pre-notifica e della notifica al CSIRT Italia. Al riguardo le specifiche di ACN sottolineano che l’acquisizione dell’evidenza può avvenire attraverso molteplici canali, interni o esterni all’organizzazione, inclusi i sistemi di monitoraggio automatizzato.
Le Linee Guida pongono inoltre l’accento sull’importanza deglistrumenti tecnici di rilevamento, quali sistemi di monitoraggio dei log, soluzioni per l’analisi del traffico e tecnologie di protezione degli endpoint, che devono essere adeguatamente configurati per ridurre il numero di falsi positivi.
In questa prospettiva, il rilevamento degli incidenti informatici è parte integrante di un processo dinamico che richiede un costante affinamento delle logiche di controllo.
Incidenti informatici e risposta. Procedura di notifica, flussi informativi e ruolo del Referente CSIRT
La fase di risposta rappresenta il momento più delicato e giuridicamente rilevante del processo di gestione degli incidenti informatici, poiché è in questa sede che l’evento di sicurezza assume rilievo ai fini dell’adempimento dell’obbligo di notifica previsto dalla disciplina NIS.
Sul punto le Linee Guida chiariscono che la risposta si attiva nel momento in cui il soggetto NIS acquisisce evidenza dell’incidente informatico, intesa come la disponibilità di elementi oggettivi dai quali risulti il verificarsi di una delle tipologie di incidente significativo previste dalle specifiche di base (v.supra). Tale momento è determinante, in quanto segna l’inizio del decorso dei termini per la comunicazione all’autorità competente.
Al riguardo le specifiche di ACN prevedono una procedura di notifica scandita in più fasi temporali e documentali.
In primo luogo, il soggetto NIS è tenuto a trasmettere al CSIRT Italia, senza ingiustificato ritardo e comunqueentroventiquattro oredall’acquisizione dell’evidenza dell’incidente informatico, una pre-notifica.Tale comunicazione preliminare deve contenere le informazioni disponibili in quel momento e, ove possibile, indicare se l’incidente informatico possa essere ricondotto ad atti illegittimi o malevoli ovvero se sia suscettibile di produrre un impatto transfrontaliero.
Entro le successivesettantadue oredall’evidenza dell’incidente informatico, il soggetto NIS deve trasmettere una notifica completa, nella quale devono essere aggiornate e integrate le informazioni già comunicate, includendo una valutazione iniziale della gravità e dell’impatto dell’incidente, nonché, ove disponibili, gli indicatori di compromissione.
Sul punto le Linee Guida precisano che, ai fini dell’adempimento dell’obbligo di notifica, non è richiesto che sia già stata individuata la causa originaria dell’incidente informatico, rilevando esclusivamente che i suoi effetti siano riconducibili a una delle tipologie di incidente significativo previste.
La procedura di risposta non si esaurisce con la notifica iniziale. Le specifiche di ACN prevedono infatti che, su richiesta del CSIRT Italia, il soggetto NIS debba trasmettererelazioni intermediesugli aggiornamenti della situazione e, in ogni caso, unarelazione finaleentroun mese dalla notifica, contenente una descrizione dettagliata dell’incidente informatico, l’indicazione della probabile causa scatenante, le misure di mitigazione adottate o in corso e l’eventuale impatto transfrontaliero. Qualora l’incidente informatico sia ancora in corso, è altresì previsto l’invio di relazioni mensili di avanzamento fino alla conclusione della gestione.
Un ruolo centrale, nella gestione di tali adempimenti, spetta alla figura delReferente CSIRT(al quale abbiamo dedicato unautonomo approfondimento), quale soggetto deputato alle interlocuzioni con l’autorità e alla trasmissione delle notifiche per conto dell’organizzazione.
ACN ha chiarito che tale designazione costituisce una delega operativa e non una delega di responsabilità, che rimane in capo agli organi di amministrazione e direttivi. Ne discende la necessità di definire procedure interne chiare per l’assunzione delle decisioni rilevanti, soprattutto nei casi in cui l’incidente informatico richieda valutazioni strategiche o comunicazioni verso l’esterno.
| Fase | Presupposto | Termine | Contenuto essenziale |
| Evidenza dell’incidente | Disponibilità di elementi oggettivi che attestano una tipologia di incidente significativo | n/d | Accertamento degli effetti dell’incidente informatico |
| Pre-notifica | Evidenza dell’incidente informatico | Entro 24 ore | Prime informazioni disponibili; possibile natura malevola; eventuale impatto transfrontaliero |
| Notifica | Evidenza dell’incidente informatico | Entro 72 ore | Valutazione iniziale di gravità e impatto; aggiornamento dati; indicatori di compromissione |
| Relazioni intermedie | Richiesta dell’autorità competente (CSIRT Italia) | Su richiesta | Aggiornamenti sullo stato dell’incidente informatico |
| Relazione finale | Conclusione della fase di risposta o gestione in corso | Entro 1 mese | Descrizione dettagliata; cause probabili; misure adottate; impatto (anche transfrontaliero) |
| Relazioni mensili | Incidente informatico ancora in corso | Mensile | Stato di avanzamento della gestione |
Incidenti informatici e modalità di notifica: la comunicazione tramite la piattaforma ACN
Un ulteriore profilo di rilievo riguarda lemodalità operativeattraverso cui i soggetti NIS devono assolvere all’obbligo di notifica degli incidenti informatici.
Le specifiche di ACN prevedono che tutte le comunicazioni relative agli incidenti informatici significativi, incluse la pre-notifica, la notifica e le successive relazioni intermedie, mensili e finali, siano effettuate esclusivamente mediante l’utilizzo della piattaforma digitale messa a disposizione dall’Agenzia per la Cybersicurezza Nazionale. La trasmissione delle notifiche al CSIRT Italia, ivi incluse quelle ai fini dell’obbligo di notifica, è effettuata tramite ilportale ACNpubblicato all’indirizzohttps://segnalazioni.acn.gov.it/
La piattaforma consente di inserire progressivamente le informazioni disponibili, in coerenza con la natura dinamica della gestione dell’incidente informatico, permettendo di adempiere agli obblighi anche quando, nelle fasi iniziali, non siano ancora noti tutti gli elementi tecnici rilevanti.
Incidenti informatici, piano di gestione e fase di ripristino delle operazioni
Le Linee Guida ACN attribuiscono un ruolo centrale al piano per la gestione degli incidenti, quale documento cardine attraverso cui il soggetto NIS traduce in assetto organizzativo stabile gli obblighi previsti dalla normativa.
Le specifiche dell’Agenzia prevedono che il processo di gestione degli incidenti informatici sia formalizzato in un piano organico, approvato dagli organi di amministrazione e direttivi, nel quale devono essere chiaramente individuate le fasi operative, i ruoli e le responsabilità, le modalità di comunicazione interna ed esterna, nonché la reportistica a supporto delle attività di risposta e di notifica.
Si precisa che il piano di gestione degli incidenti informatici deve essere costantemente aggiornato e riesaminato, sia periodicamente sia in occasione del verificarsi di incidenti significativi, al fine di integrare le lezioni apprese e di adeguarsi all’evoluzione delle minacce e del contesto tecnologico.
Tale impostazione rafforza il legame tra gestione degli incidenti informatici e responsabilità degli organi apicali, i quali sono chiamati a garantire che il piano non rimanga un documento statico, ma uno strumento effettivamente calato nei processi aziendali. All’interno di tale cornice si colloca lafase di ripristino, che interviene una volta avviata la risposta all’incidente informatico e mira al recupero del normale funzionamento dei sistemi informativi e di rete compromessi.
Al riguardo le specifiche di ACN prevedono che le attività di ripristino siano disciplinate da procedure formalizzate, coerenti con i piani di continuità operativa e di ripristino in caso di disastro.
Appendice A delle Linee Guida ACN: le specifiche di base e la nozione di incidente significativo
Tutto ciò premesso, un approfondimento autonomo merita l’Appendice A delle Linee Guida emanate dall’Agenzia per la Cybersicurezza Nazionale, nella quale sono illustrate le cosiddette specifiche di base, destinate a orientare in modo concreto l’adempimento degli obblighi previsti dal decreto NIS in materia di incidenti informatici.
Tali allegati tecnici costituiscono il riferimento operativo essenziale sia per l’adozione delle misure di sicurezza sia per l’individuazione degli incidenti informatici soggetti a notifica obbligatoria.
L’Appendice Asi concentra, in particolare, sulla definizione delle tipologie di incidenti informatici significativi di base, distinguendo tra soggetti importanti e soggetti essenziali. Sul punto le Linee Guida precisano che gli incidenti informatici rilevanti ai fini dell’obbligo di notifica sono qualificati attraverso un modello logico fondato su tre elementi: la condizione, rappresentata dall’evidenza dell’incidente; la compromissione, intesa come perdita di riservatezza, integrità o disponibilità, ovvero come accesso non autorizzato o con abuso dei privilegi; e l’oggetto della compromissione, costituito dai dati digitali o dai servizi e dalle attività del soggetto NIS.
Le Linee Guida sottolineano che ciò che rileva, ai fini dell’obbligo di notifica degli incidenti informatici, non è la causa originaria dell’evento, bensì la sussistenza di effetti riconducibili a una delle tipologie previste.
Ne consegue che anche eventi accidentali, malfunzionamenti o errori umani possono integrare un incidente informatico significativo, qualora producano una perdita di riservatezza, integrità o disponibilità verso l’esterno, ovvero una violazione dei livelli di servizio attesi. .
Alla luce delle specifiche di base, letipologie di incidenti informatici significativisoggetti a notifica possono essere così sintetizzate:
IS-1, quando il soggetto NIS ha evidenza della perdita di riservatezza, verso l’esterno, di dati digitali di sua proprietà o sui quali esercita, anche parzialmente, il controllo;
IS-2, quando il soggetto NIS ha evidenza della perdita di integrità, con impatto verso l’esterno, di dati digitali di sua proprietà o sui quali esercita, anche parzialmente, il controllo;
IS-3, quando il soggetto NIS ha evidenza della violazione dei livelli di servizio attesi dei propri servizi o delle proprie attività, sulla base dei livelli di servizio previamente definiti;
IS-4, riservato ai soggetti essenziali, quando vi è evidenza di un accesso non autorizzato o con abuso dei privilegi concessi a dati digitali di proprietà del soggetto o sui quali esso esercita, anche parzialmente, il controllo.
Appendice B delle Linee Guida ACN: misure di sicurezza e gestione operativa
L’Appendice B delle Linee Guida chiarisce il rapporto tra misure di sicurezza e gestione degli incidenti informatici, offrendo una lettura sistematica delle prescrizioni che i soggetti NIS sono tenuti ad attuare lungo l’intero processo di gestione.
Al riguardo le specifiche di ACN prevedono che le misure di sicurezza siano funzionalmente integrate nelle diverse fasi del processo di gestione degli incidenti informatici, dalla preparazione al miglioramento continuo.
Invero, le misure di sicurezza di base sono organizzate in modo coerente con le fasi del processo di gestione degli incidenti informatici: ciascun presidio concorre a garantire la capacità dell’organizzazione di prevenire, rilevare, gestire e superare gli eventi di sicurezza.
In particolare, le misure relative algovernoe all’identificazioneimpongono l’adozione di politiche formalizzate, la chiara attribuzione di ruoli e responsabilità, nonché il mantenimento di inventari aggiornati degli asset e dei servizi, elementi indispensabili per una corretta qualificazione e gestione degli incidenti informatici.
Le misure afferenti allaprotezionee alrilevamentosvolgono una funzione essenziale nel consentire l’acquisizione tempestiva dell’evidenza dell’incidente informatico, presupposto indefettibile dell’obbligo di notifica.
Nelle fasi dirisposta,ripristinoemiglioramentole misure assumono, infine, una valenza dinamica, imponendo la predisposizione di piani documentati, la comunicazione strutturata verso gli stakeholder e il riesame periodico dell’efficacia dei presidi adottati.
In tale ottica, l’Appendice Bconsente di comprendere come la gestione degli incidenti informatici sia il risultato di un sistema integrato di misure organizzative, tecniche e procedurali, la cui coerenza complessiva rappresenta il vero parametro di conformità alla disciplina NIS.
Alla luce delle indicazioni contenute nell’Appendice B, la rilevanza dellemisure di sicurezzaper la gestione degli incidenti informatici può essere ricondotta, in chiave operativa, ai seguenti profili essenziali:
- l’adozione e l’aggiornamento di politiche di sicurezza informatica approvate dagli organi di amministrazione e direttivi, quali presupposto organizzativo della gestione degli incidenti informatici;
- la definizione di ruoli, responsabilità e flussi decisionali chiari, inclusa l’individuazione del Referente CSIRT e dei soggetti coinvolti nelle attività di risposta;
- il mantenimento di inventari aggiornati dei sistemi informativi, dei servizi e dei flussi di rete, funzionali alla corretta individuazione degli asset coinvolti negli incidenti informatici;
- l’implementazione di misure di protezione e di rilevamento, quali backup, sistemi di logging, controlli sugli accessi e monitoraggio continuo, indispensabili per acquisire evidenza dell’incidente informatico;
- la formalizzazione di piani e procedure per la risposta, la notifica, il ripristino e la comunicazione, idonei a garantire tempestività e tracciabilità;
- il riesame periodico delle misure adottate e l’integrazione delle lezioni apprese, al fine di rafforzare la capacità di prevenzione e gestione dei futuri incidenti informatici.
Notifica e gestione degli incidenti informatici. Supporto legale qualificato da avvocati esperti in cybersicurezza
L’impianto delineato dalle Linee Guida ACN rende evidente come la gestione degli incidenti informatici costituisca un ambito nel quale gli adempimenti tecnici si intrecciano in modo indissolubile con profili giuridici e organizzativi di particolare complessità.
Più precisamente, le specifiche di ACN prevedono che l’obbligo di notifica degli incidenti informatici sia inserito all’interno di un sistema strutturato di misure di sicurezza, procedure documentate e responsabilità in capo agli organi di amministrazione e direttivi. La corretta attuazione di tale sistema richiede, pertanto, un’attenta attività di interpretazione normativa e di traduzione delle prescrizioni in processi interni coerenti e verificabili.
L’assistenza e il supporto legale assumono così un ruolo essenziale nel garantire che la gestione degli incidenti informatici sia conforme alle disposizioni del decreto NIS e alle Linee Guida ACN. La redazione del piano di gestione degli incidenti, la definizione delle procedure di notifica, il coordinamento delle comunicazioni con il CSIRT Italia e la corretta integrazione con gli obblighi in materia di protezione dei dati personali richiedono competenze giuridiche specialistiche, che solo un avvocato con esperienza in materia di cybersicurezza è in grado di fornire.
Per la predisposizione del Piano per la cybersicurezza abbiamo sperimentatoScuDoc, una soluzione innovativa grazie alla partnership conJust4CybereTransizione Digitale.
Contattaci qui per un confronto!
Ai sensi dell’art. 70-quater della Legge 633/1941, ai fini della tutela del diritto d’autore, si dichiara che il presente contenuto è riservato, e ne è vietata la riproduzione o l’estrazione di testo, anche mediante sistemi di intelligenza artificiale.
daRedazione|Dic 2, 2025|Diritto d'Impresa
Il referente CSIRT è una figura destinate a divenire il fulcro degli adempimenti operativi relativi alla notifica degli incidenti. L’introduzione di questa nuova figura risponde all’esigenza, sempre più avvertita nella prassi, di assicurare rapidità, competenza e uniformità nella gestione degli incidenti informatici, delineando un canale privilegiato di interlocuzione tra gli operatori essenziali e importanti e il CSIRT Italia.
In tale prospettiva, il referente CSIRT si configura come presidio tecnico-organizzativo, chiamato a interfacciarsi con le strutture nazionali di risposta agli incidenti e a garantire la tempestiva trasmissione delle notifiche obbligatorie e volontarie previste dal D. Lgs. 138/2024.
L’obiettivo di questo articolo è quello di offrire una breve guida sul ruolo del referente CSIRT, illustrando il contenuto delleFAQe dellaDeterminazione ACNin un’ottica di chiarificazione operativa per imprese e pubbliche amministrazioni.
L’analisi si concentrerà sui presupposti normativi della figura, sulle competenze e sui requisiti richiesti, sulle procedure di designazione tramite il Portale ACN e sulle responsabilità operative che ne derivano. Verrà inoltre esaminata la posizione del referente CSIRT nel più ampio modello di gestione degli incidenti informatici, evidenziando il rapporto con il Punto di Contatto e con gli organi apicali del soggetto NIS.
La base normativa del referente CSIRT nella determinazione ACN
La figura del referente CSIRT trova la propria disciplina positiva nellaDeterminazione ACN n. 333017/2025, adottata in attuazione delDecreto Legislativo 4 settembre 2024, n. 138. L’articolato di riferimento, in particolare l’articolo 7 della Determinazione, definisce in termini puntuali la natura, le funzioni e i requisiti della figura, delineando un presidio specificamente dedicato alla gestione delle relazioni operative con il CSIRT Italia.
Laratiodella previsione risiede nella necessità di garantire un flusso informativo standardizzato ed efficiente tra i soggetti NIS e l’autorità nazionale di risposta agli incidenti, assicurando uniformità procedurale e tempestività nell’adempimento degli obblighi di notifica degli incidenti significativi (articolo 25 del Decreto NIS) e delle comunicazioni volontarie (articolo 26).
La Determinazione ACN prevede inoltre che la designazione del referente CSIRT debba avvenire esclusivamente attraverso ilPortale dei Servizi ACN,secondo la procedura telematica resa disponibile a partire dal20 novembre 2025. La stessa disposizione contempla la possibilità di nominare uno o più sostituti, al fine di assicurare la piena continuità operativa nella gestione degli incidenti.
Un profilo di particolare rilievo operativo riguarda la scadenza fissata al31 dicembre 2025, entro la quale ogni soggetto NIS è tenuto a completare la designazione del proprio referente CSIRT attraverso ilPortale dei Servizi ACN. Tale deadline segna il momento entro cui le organizzazioni dovranno adeguare i propri assetti interni, assicurando la piena operatività della funzione e l’allineamento alle prescrizioni dettate dalla Determinazione ACN.
Requisiti professionali e competenze richieste al referente CSIRT
La disciplina elaborata dall’Agenzia per la Cybersicurezza Nazionale attribuisce particolare rilievo ai requisiti di qualificazione del referente CSIRT, nella consapevolezza che l’efficacia del presidio dipenda, in via primaria, dalla competenza tecnica e dalla conoscenza dell’ecosistema digitale del soggetto NIS.
Le FAQ chiariscono che il referente CSIRT deve possedere almenocompetenze di base in materia di sicurezza informaticae di gestione degli incidenti, competenze che costituiscono la soglia minima per interagire con il CSIRT Italia e gestire correttamente il processo di notifica.
Parallelamente, è richiesto un livello di conoscenza approfondita dei sistemi informativi, delle architetture di rete e delle infrastrutture digitali dell’organizzazione, poiché solo una piena consapevolezza delle logiche di funzionamento interne consente di valutare correttamente la portata di un incidente e di fornire informazioni tempestive e coerenti con i requisiti regolatori.
Un ulteriore elemento di flessibilità emerge dalla possibilità, riconosciuta dalle FAQ, di designare un referente CSIRT esterno all’organizzazione, purché tali competenze siano adeguatamente garantite. Questa apertura consente ai soggetti NIS di avvalersi di figure altamente specializzate, quali i responsabili di SOC o CERT esternalizzati, soprattutto quando non sia possibile allocare risorse interne dotate delle competenze richieste.
L’Agenzia, tuttavia, segnala la preferenza per la scelta di unreferente interno, in quanto maggiormente integrato nelle dinamiche operative e decisionali dell’ente. Tale impostazione si inserisce in una logica di rafforzamento dei presidi interni di cybersicurezza, valorizzando la conoscenza diretta dei processi e delle infrastrutture.
Nomina, designazione e ruolo del Punto di Contatto nella procedura ACN
Le FAQ precisano che l’individuazione del referente CSIRT e dei suoi eventuali sostituti deve essere effettuata esclusivamente tramite il Portale ACN, mediante la funzionalità di aggiornamento dati accessibile al Punto di Contatto.
Quest’ultimo, quale figura già istituzionalizzata dal quadro NIS, assume un ruolo centrale nella fase genetica dell’incarico, essendo l’unico soggetto abilitato a inserire i dati identificativi del referente CSIRT, in particolare il codice fiscale e l’indirizzo di posta elettronica. La procedura è congegnata affinché la designazione produca effetti solo a seguito della successiva attività dicensimento da parte dell’interessato, il quale è tenuto ad accedere personalmente al Portale tramite identità digitale (SPID o CIE) e a confermare la propria iscrizione come referente CSIRT. La procedura non richiede alcun caricamento documentale, rendendo il processo snello pur mantenendo un elevato livello di tracciabilità.
Responsabilità operative del referente CSIRT e delega di funzioni
Il ruolo attribuito al referente CSIRT si caratterizza per una marcata dimensione operativa, che si esprime principalmente nella gestione delle notifiche di incidenti significativi ai sensi dell’articolo 25 del Decreto NIS e delle comunicazioni volontarie previste dall’articolo 26.
Le FAQ chiariscono in modo inequivoco che la designazione del referente CSIRT non integra una delega di responsabilità in senso proprio, ma esclusivamente unadelega funzionale e operativa.Le responsabilità giuridiche, anche in caso di omissione o inesattezza nella gestione dell’incidente, sembrerebbero restare in capo agli organi di amministrazione e direzione dell’ente, conformemente all’impianto normativo delineato dall’articolo 23 del D. Lgs. 138/2024.
Il referente CSIRT svolge dunque un ruolo tecnico di raccordo, essenziale per assicurare la tempestività e la qualità delle comunicazioni, ma non subentra nelle responsabilità apicali previste dalla normativa NIS.
Cionondimeno, il referente CSIRT deve essere inserito in un sistema organizzativo che preveda ruoli e procedure chiaramente definite, idonee a garantire la circolazione delle informazioni verso le strutture tecniche, le funzioni aziendali competenti e gli organi apicali chiamati ad assumere le decisioni di maggiore rilievo.
Il ruolo dei sostituti del referente CSIRT e la continuità della funzione
La disciplina delineata dall’Agenzia per la Cybersicurezza Nazionale attribuisce particolare rilievo anche alla figura dei sostituti del referente CSIRT, i quali costituiscono un presidio importante per garantire la continuità operativa nella gestione degli incidenti informatici.
Le FAQ chiariscono che i sostituti partecipano attivamente all’esercizio delle funzioni attribuite al referente, potendo operare in sua vece nei casi di impedimento temporaneo o di necessità connessa alla tempestività della comunicazione verso il CSIRT Italia.
Tale previsione risponde alla logica, sottesa alla normativa NIS, di evitare interruzioni o ritardi nella gestione degli eventi di sicurezza, considerato che la tempestività delle notifiche rappresenta un elemento essenziale per la mitigazione degli impatti e la protezione dell’integrità delle infrastrutture digitali.
I sostituti del referente CSIRT devono essere in possesso degli stessi requisiti richiesti per il referente principale, inclusi la competenza di base in materia di cybersicurezza, la capacità di gestione degli incidenti e la conoscenza approfondita dei sistemi informativi dell’organizzazione.
Questa equiparazione dei requisiti garantisce che il livello di qualità delle interlocuzioni con il CSIRT Italia rimanga invariato, indipendentemente dalla persona fisica che effettua la comunicazione. L’ACN ribadisce inoltre che sia il referente CSIRT sia i suoi sostituti devono completare personalmente il censimento sul Portale dei Servizi ACN, condizione necessaria per l’effettiva abilitazione all’esercizio delle funzioni.
Assistenza legale e supporto operativo nella gestione degli adempimenti NIS 2. Referente CSIRT e piano per la Cybersicurezza.
La disciplina del referente CSIRT, così come delineata dalla Determinazione ACN, introduce un presidio tecnico-organizzativo destinato a incidere in modo significativo sull’assetto interno dei soggetti NIS.
In tale contesto, lo Studio Legale D’Agostino offre supporto specialistico nella configurazione e nell’implementazione degli adempimenti relativi al referente CSIRT, mettendo a disposizione una consolidata expertise in materia di cybersicurezza. Grazie alla collaborazione conTransizione Digitalee all’utilizzo dellapiattaforma ScuDoc,lo Studio assiste imprese e pubbliche amministrazioni nella definizione dei processi, nella predisposizione della documentazione necessaria e nella corretta attuazione degli obblighi previsti dalla normativa NIS.
Ai sensi dell’art. 70-quater della Legge 633/1941, ai fini della tutela del diritto d’autore, si dichiara che il presente contenuto è riservato, e ne è vietata la riproduzione o l’estrazione di testo, anche mediante sistemi di intelligenza artificiale.
daRedazione|Dic 1, 2025|Diritto d'Impresa
Lo sviluppo informatico è divenuto una componente strutturale dell’economia digitale, configurandosi come un’attività sempre più complessa, interdisciplinare e ad elevato contenuto tecnico. Invero, l’elaborazione di un software – sia esso un gestionale aziendale, un’applicazione web, un sistema integrato o unagente di intelligenza artificiale– implica l’analisi esigenze funzionali del committente e la definizione delle logiche di funzionamento che sorreggeranno l’architettura del programma.
Tale complessità rende imprescindibile un’adeguata regolamentazione contrattuale, in grado di disciplinare in modo chiaro i diritti e gli obblighi delle parti, nonché la titolarità del prodotto finale dello sviluppo informatico e dei relativi diritti di proprietà intellettuale.
L’obiettivo del presente contributo è quello di offrire una ricostruzione sistematica delleprincipali clausoleche caratterizzano i contratti di sviluppo informatico, illustrando come la scelta del modello negoziale incida profondamente sulla disponibilità delcodice sorgente,sulle modalità di fruizione del software e sul perimetro di responsabilità dello sviluppatore e del cliente.
In questa prospettiva, saranno analizzati i modelli riconducibili allamera consulenza tecnica e progettuale, in cui lo sviluppatore presta un’attività eminentemente intellettuale senza necessariamente trasferire un prodotto eseguibile; i contratti fondati sulla concessione di unalicenza d’uso,anchein modalità SaaS, nei quali il cliente ottiene un diritto limitato e temporaneo di impiego del software; e, infine, gli schemi negoziali che contemplano lacessione del codice sorgentee dei diritti economici, con conseguente trasferimento della piena disponibilità dell’applicativo.
Verrà inoltre dedicata attenzione aiservizi accessori– quali manutenzione, assistenza tecnica, aggiornamenti e formazione del personale – che, pur collocandosi su un piano distinto rispetto al nucleo centrale dello sviluppo informatico, risultano determinanti per garantire la continuità del servizio e la piena operatività dell’applicativo nel tempo.
L’intento è dunque quello di fornire al lettore una guida alle principali soluzioni contrattuali adottabili, evidenziando le tutele crescenti e le esigenze di bilanciamento che caratterizzano i rapporti tra software house e utilizzatori.
La consulenza tecnica nello sviluppo informatico: analisi dei processi e progettazione preliminare
La fase preliminare dello sviluppo informatico è spesso caratterizzata da un’attività che assume i connotati della consulenza tecnica e della prestazione d’opera intellettuale. In tale configurazione, lo sviluppatore non si obbliga immediatamente alla realizzazione di un programma eseguibile, ma concentra la propria attività sull’analisi deiprocessi aziendali, sulla mappatura delleesigenze funzionali esulla definizione dell’architettura logica del futuro software. Si tratta di un momento essenziale, poiché da esso dipende la corretta progettazione del prodotto digitale e, conseguentemente, la possibilità di realizzare un sistema coerente con le aspettative del cliente.
Un esempio significativo è rappresentato dalle clausole che disciplinano la fase di analisi tecnica, nelle quali si prevede che lo sviluppatore raccolga le informazioni necessarie alla comprensione del contesto organizzativo e definisca “gli obiettivi, le funzioni e i limiti dell’applicativo”, nonché le integrazioni tecniche indispensabili per l’interoperabilità del software. In tali ipotesi, sebbene l’attività non implichi ancora l’assunzione di un’obbligazione di risultato, si configura come una vera e propria consulenza professionale, finalizzata alla predisposizione della documentazione tecnica che costituirà la base per le successive fasi dello sviluppo informatico.
È frequente che, in questa fase, le parti disciplinino la proprietà dei materiali prodotti, precisando che la documentazione progettuale, pur essendo utilizzabile dal cliente per valutare l’opportunità di procedere con le fasi successive, rimane nella titolarità dello sviluppatore, il quale mantiene il controllo sul know-how impiegato e sulle soluzioni tecniche individuate. Tale impostazione riflette la ratio secondo cui, nella fase di consulenza, il contenuto prevalente della prestazione risiede nel sapere professionale e non nel trasferimento di un bene digitale.
L’attività di consulenza rappresenta, in sostanza, un segmento autonomo del rapporto contrattuale, che consente di delimitare l’ambito dello sviluppo informatico, ponendo le basi per una successiva negoziazione sulla realizzazione del software.
Sviluppo informatico e licenza d’uso del software: il modello SaaS e la disponibilità limitata dell’applicativo
Tra le configurazioni più diffuse nei contratti disviluppo informaticovi è quella in cui il prodotto della programmazione non viene trasferito in proprietà al cliente, ma è messo a sua disposizione tramite una licenza d’uso non esclusiva, limitata e revocabile.
Tale schema, frequentemente adottato nelle forniture in modalitàSoftware-as-a-Service, consente allo sviluppatore di mantenere la titolarità del software e delle relative componenti, riservando all’utilizzatore un mero diritto di impiego per la durata contrattualmente stabilita.
La licenza d’uso si caratterizza per una serie di vincoli che circoscrivono l’ambito di disponibilità del software. È tipico, ad esempio, che il contratto precisi come l’applicativo possa essere fruito esclusivamente per i processi aziendali individuati e non possa essere utilizzato “oltre le funzionalità, i canali e i sistemi indicati”, né ceduto o messo a disposizione di soggetti terzi. In tali modelli di sviluppo informatico, l’accesso agli ambienti tecnici e agli account infrastrutturali resta nella disponibilità dello sviluppatore, che ne mantiene la gestione per garantire la stabilità, la sicurezza e il regolare funzionamento del sistema.
Questa impostazione rafforza la distinzione tra proprietà del software e diritto di uso, giacché l’utilizzatore interagisce con un’applicazione ospitata su infrastrutture esterne senza acquisire alcun potere di modifica o controllo sul codice.
Un ulteriore tratto caratteristico della licenza d’uso è il divieto direverse engineering, decompilazione o interventi diretti sul codice sorgente, che permane nella sfera giuridica dello sviluppatore. Tale divieto impedisce che il cliente possa ricostruire l’architettura interna dell’applicativo o replicarlo in altri contesti, preservando così l’integrità del know-how impiegato nello sviluppo informatico.
Il modello della licenza d’uso consente dunque di coniugare l’esigenza del cliente di disporre di uno strumento operativo con l’interesse dello sviluppatore a mantenere il controllo sulla tecnologia fornita, delineando un assetto equilibrato che tutela le prerogative di entrambe le parti.
Sviluppo informatico e cessione del codice sorgente: trasferimento dei diritti e opzioni di riscatto
Accanto ai modelli fondati sulla semplice licenza d’uso, lo sviluppo informatico può assumere forme più incisive quando le parti convengono la cessione del codice sorgente e dei diritti di utilizzazione economica sul software. Tale configurazione è tipica nei progetti in cui il cliente richiede la disponibilità piena e autonoma dell’applicativo, sia per esigenze di integrazione con sistemi proprietari, sia per ragioni di continuità operativa e indipendenza tecnologica rispetto allo sviluppatore.
Lacessione del codicerappresenta un momento delicato, poiché implica il trasferimento di un bene immateriale che costituisce il nucleo essenziale del prodotto digitale e che, in quanto tale, deve essere oggetto di una disciplina puntuale e rigorosa.
Nella prassi contrattuale, la cessione del codice sorgente è spesso subordinata a condizioni precise e predeterminate. È frequente, ad esempio, che il contratto preveda un meccanismo di“opzione di riscatto”, esercitabile dal cliente mediante pagamento di un corrispettivo una tantum o al maturare di un certo numero di canoni. Tale meccanismo consente allo sviluppatore di valorizzare economicamente il proprio lavoro e di tutelare il know-how sottostante, mantenendo al contempo aperta la possibilità di trasferire al cliente la proprietà dell’applicativo quando sussista un interesse concreto.
È altresì comune che la cessione sia limitata alle sole componenti sviluppate su misura, con esclusione delle tecnologie preesistenti, delle librerie proprietarie, dei moduli generici e dei processi interni utilizzati nella fase di sviluppo informatico. Tale distinzione consente di preservare l’integrità dell’ecosistema tecnologico dello sviluppatore, evitando che il trasferimento di una soluzione personalizzata si traduca nella dispersione del patrimonio intellettuale necessario alla realizzazione di altri progetti.
Proprietà intellettuale e know-how nei contratti di sviluppo informatico
La disciplina dellaproprietà intellettuale,nei contratti di sviluppo informatico, definisce l’assetto giuridico dell’applicativo e determina i limiti entro cui il cliente può utilizzare, modificare o integrare il software. Nei contratti che regolano la creazione di programmi per elaboratore è usuale distinguere tra il codice specificamente realizzato su richiesta del committente e l’insieme delle tecnologie, metodologie, librerie e strumenti preesistenti che lo sviluppatore impiega per la realizzazione del progetto. Tale distinzione deriva dalla necessità di preservare il patrimonio di conoscenze tecniche che costituisce il know-how professionale dello sviluppatore, evitando che il singolo incarico possa comportare la perdita del controllo sulle proprie soluzioni tecnologiche.
Clausole come quella secondo cui il fornitore“mantiene la piena ed esclusiva titolarità di tutti i diritti di proprietà intellettuale relativi all’applicativo, incluse le componenti software, le logiche algoritmiche, i flussi operativi, i prompt, le tecniche di sviluppo e ogni perfezionamento”riflettono chiaramente tale impostazione. Il cliente riceve quindi un diritto d’uso circoscritto, il cui ambito deve essere puntualmente definito, mentre lo sviluppatore conserva la disponibilità delle componenti strutturali del software e dei perfezionamenti derivanti dal suo utilizzo.
Si tratta di un principio di grande rilievo, poiché i perfezionamenti generati dall’interazione del sistema con i dati e con i processi aziendali del cliente possono costituire elementi di valore che, pur migliorando l’efficienza dell’applicativo, rimangono inscindibilmente connessi al know-how originario dello sviluppatore.
La distinzione tra proprietà del codice sorgente e titolarità del know-how assume particolare importanza neimodelli di licenza d’uleso,nei quali il cliente non acquisisce alcun diritto di accesso alle logiche interne del programma. Anche nei casi in cui sia prevista la cessione del codice, la proprietà intellettuale sui moduli preesistenti e sugli strumenti generali rimane esclusa dal trasferimento, garantendo allo sviluppatore la possibilità di impiegarli in ulteriori attività di sviluppo informatico. Tale impostazione consente di evitare conflitti sulla riutilizzabilità delle tecnologie e costituisce un fattore essenziale di equilibrio contrattuale.
Sviluppo informatico, libertà professionale dello sviluppatore e informazioni riservate
Nel contesto dei contratti di sviluppo informatico, una questione frequentemente oggetto di confronto e dibattito riguarda l’estensione degli obblighi gravanti sullo sviluppatore dopo la realizzazione dell’applicativo, con particolare riferimento alla possibilità di operare in settori analoghi per conto di altri clienti.
In assenza di una specificapattuizione di non concorrenza,lo sviluppatore o la software house non sono soggetti ad alcun divieto di assumere nuovi incarichi né di realizzare prodotti digitali che presentino caratteristiche funzionali simili a quelle del software sviluppato per il cliente. Tale libertà professionale è coerente con la natura della prestazione e con la logica che governa la proprietà intellettuale del software fornito in modalità SaaS, poiché in questi casi il codice sorgente e le architetture logiche rimangono nella titolarità esclusiva dello sviluppatore e possono essere riutilizzati, adattati o implementati in ulteriori attività di sviluppo informatico.
Ciò non significa, tuttavia, che l’operatività dello sviluppatore sia priva di limiti. La disciplina contrattuale prevede, spesso, obblighi di riservatezza che vincolano entrambe le parti e che impediscono allo sviluppatore di utilizzare o divulgare “informazioni tecniche, operative, organizzative e commerciali” apprese durante l’esecuzione dell’incarico.
Tali obblighi, che si estendono anche ai contenuti dei database, ai flussi aziendali mappati, ai materiali forniti dal cliente e alle configurazioni interne realizzate per l’applicativo, operano come limite fisiologico e necessario alla libertà di iniziativa dello sviluppatore.
Egli resta pienamente libero di progettare software analoghi, ma non può riutilizzare dati, segreti aziendali,informazioni riservateo materiali coperti da diritto d’autore del cliente, né replicare elementi che costituiscano un riflesso diretto dei processi aziendali specificamente appresi nel corso dell’incarico.
In questo equilibrio tra libertà professionale e tutela delle informazioni riservate risiede l’essenza del rapporto contrattuale. Lo sviluppatore non assume un patto di non concorrenza, salvo che ciò sia espressamente previsto e specificamente compensato, ma è rigorosamente tenuto a non alterare, riutilizzare o divulgare elementi riservati acquisiti durante lo sviluppo informatico.
Manutenzione, assistenza e formazione: servizi accessori allo sviluppo informatico
Nell’ambito dei contratti di sviluppo informatico, un ruolo determinante è assunto dai servizi accessori che accompagnano il ciclo di vita del software, i quali, pur non coincidendo con la realizzazione dell’applicativo, ne condizionano in modo decisivo la funzionalità nel tempo.
La manutenzione ordinaria, l’assistenza tecnica e le attività di formazione costituiscono infatti elementi imprescindibili per assicurare la stabilità del sistema, la risoluzione tempestiva delle criticità e l’effettiva capacità del cliente di utilizzare il programma in modo conforme alle sue finalità.
Le clausole contrattuali che disciplinano tali servizi sono spesso molto articolate. È consueto prevedere che lo sviluppatore garantisca un’attività continuativa di monitoraggio, aggiornamento e ottimizzazione dell’applicativo, finalizzata a correggere eventuali vizi tecnici o difformità rispetto alle funzionalità concordate. Simili previsioni riflettono il carattere dinamico dello sviluppo informatico, nel quale il sistema necessita di interventi periodici per adeguarsi all’evoluzione tecnologica, alle modifiche delle piattaforme integrate o alle mutate esigenze operative dell’organizzazione cliente.
Tali attività, tuttavia, non sono mai illimitate. Il contratto stabilisce con precisione quali interventi siano compresi nella manutenzione ordinaria e quali, invece, debbano essere qualificati come servizi aggiuntivi, soggetti a specifica quotazione economica.
Di particolare rilievo è anche la disciplina dell’assistenza tecnica. Il cliente, utilizzatore del software nei propri processi quotidiani, può trovarsi ad affrontare malfunzionamenti o difficoltà di configurazione. Clausole che prevedono la possibilità di richiedere interventi entro determinati tempi di risposta, spesso attraverso canali dedicati, garantiscono prevedibilità e certezza nell’erogazione del servizio. Al tempo stesso, si precisa che l’assistenza non può riguardare attività di sviluppo ulteriori rispetto al contratto, né interventi su piattaforme terze non governate dallo sviluppatore.
Ambito di utilizzo, sicurezza e gestione degli account nello sviluppo informatico
La definizione dell’ambito di utilizzo del software è un momento di centrale importanza per la stesura dei contratti di sviluppo informatico, poiché delimita in modo preciso i confini entro cui il cliente può impiegare l’applicativo e stabilisce le garanzie necessarie a tutela dello sviluppatore.
Nella prassi, tale delimitazione viene attuata attraverso clausole che specificano lefinalitàper le quali il software può essere utilizzato, i processi aziendali cui è destinato e i canali o sistemi tecnici attraverso i quali esso può operare.
Un ulteriore profilo riguarda lagestione degli accounttecnici necessari al funzionamento dell’applicativo. Nei modelli evoluti di sviluppo informatico, soprattutto quando basati su infrastrutture cloud o su componenti distribuite, gli account e gli ambienti informatici restano nella disponibilità dello sviluppatore, il quale ne cura la configurazione e la manutenzione.
Tale impostazione risponde a esigenze di sicurezza e stabilità del sistema, evitando che interventi impropri del cliente compromettano il funzionamento del software o ne mettano a rischio l’integrità. Il cliente, dal canto suo, conserva la responsabilità della custodia delle credenziali fornite ai propri dipendenti o collaboratori e risponde delle attività compiute dagli utenti abilitati.
Corrispettivi, canoni, durata e responsabilità nei contratti di sviluppo informatico
I profili economici e temporali vengono disciplinati, nei contratti di sviluppo informatico, in apposite clausole contenute nelle condizioni generali o nel modulo d’ordine. Esse definiscono, anzitutto, il valore della prestazione, le modalità di remunerazione delle attività svolte e il perimetro entro cui lo sviluppatore può essere ritenuto responsabile per eventuali malfunzionamenti o difformità del software.
Lastruttura dei corrispettiviriflette normalmente la complessità del progetto e si articola in voci distinte che tengono conto dell’analisi preliminare, della realizzazione dell’applicativo, dell’eventuale concessione in licenza e dei servizi accessori di manutenzione e assistenza. Tale ripartizione consente di collegare ciascuna fase dello sviluppo informatico a una specifica prestazione, valorizzando il carattere autonomo delle attività e garantendo trasparenza nelle obbligazioni reciproche.
I contratti prevedono spesso un corrispettivo iniziale per la fase di analisi e progettazione, a cui si aggiungono gli importi dovuti per la realizzazione tecnica dell’applicativo e, nei modelli basati sulla licenza SaaS, un canone periodico che remunera l’accesso continuativo al software e agli ambienti tecnici gestiti dallo sviluppatore.
Ulteriori somme possono essere dovute perservizi aggiuntivi,per interventi straordinari o, nei modelli che contemplano la cessione del codice, per l’esercizio dell’opzione di riscatto. La previsione di un canone ricorrente evidenzia la natura dinamica del rapporto di sviluppo informatico, nel quale la fruizione del software implica attività costanti di monitoraggio, aggiornamento e supervisione della componente tecnologica.
Un tema di particolare delicatezza riguarda laresponsabilità dello sviluppatore. I contratti chiariscono generalmente che l’obbligazione ha natura di mezzi e non di risultato, soprattutto quando il software interagisce con piattaforme terze, servizi cloud o componenti non direttamente controllate dallo sviluppatore.
La durata del rapporto e le condizioni di rinnovo contribuiscono a definire la stabilità dell’accordo. I contratti prevedono spesso un rinnovo automatico della licenza, salvo disdetta, nonché la possibilità di sospendere l’accesso al software in caso di morosità. Queste clausole, tipiche dello sviluppo informatico in modalità SaaS, rafforzano la continuità del servizio e assicurano che il cliente mantenga un comportamento conforme alle proprie obbligazioni.
Assistenza legale qualificata per lo sviluppo informatico. Rivolgiti a noi
La disciplina dei contratti di sviluppo informatico mostra come larealizzazione di un softwarenon possa essere considerata una prestazione unitaria e indistinta, ma debba essere ricondotta a una pluralità di modelli negoziali che riflettono differenti livelli di disponibilità del prodotto digitale e di tutela degli interessi coinvolti.
La distinzione tra attività di consulenza, licenza d’uso e cessione del codice sorgente consente di comprendere come l’assetto contrattuale incida direttamente sulla titolarità dei diritti, sulle modalità di fruizione dell’applicativo e sulla possibilità di garantire continuità operativa nel tempo.
Lo Studio Legale D’Agostino offre supporto qualificato nella redazione, revisione e negoziazione di contratti di sviluppo informatico, mettendo a disposizione una consolidata esperienza nel settore dellestart-upe deibusiness digitali. Tale competenza consente di predisporre accordi chiari, bilanciati e pienamente rispondenti alle esigenze operative delle parti.
Contattaci per un confronto!
Ai sensi dell’art. 70-quater della Legge 633/1941, ai fini della tutela del diritto d’autore, si dichiara che il presente contenuto è riservato, e ne è vietata la riproduzione o l’estrazione di testo, anche mediante sistemi di intelligenza artificiale.
daRedazione|Nov 21, 2025|Diritto d'Impresa
L’approvvigionamento di beni ICT da parte delle pubbliche amministrazioni rappresenta oggi uno degli snodi più delicati delle politiche di sicurezza in ambito pubblicistico. La progressiva digitalizzazione delle funzioni pubbliche, unita alla crescente dipendenza da tecnologie informatiche critiche, ha reso evidente come l’acquisto di infrastrutture, software e servizi digitali non possa più essere considerato una mera operazione commerciale, ma debba essere inquadrato quale attività ad elevata rilevanza strategica.
La selezione di fornitori affidabili, la provenienza dei componenti e la sicurezza delle tecnologie impiegate incidono direttamente sulla tutela degli interessi nazionali e sulla resilienza delle infrastrutture critiche che gestiscono dati, comunicazioni e servizi essenziali per le amministrazioni e per l’intero sistema Paese.
In tale prospettiva, l’articolo che segue intende offrire unaguida esplicativa alla disciplina secondariarecentemente adottata in materia di beni ICT, con particolare riguardo al DPCM 30 aprile 2025 e alle successive Linee guida emanate dall’Agenzia per la Cybersicurezza Nazionale (ACN). Le due fonti, strettamente connesse all’art. 14 dellaLegge n. 90/2024, introducono un sistema di criteri premiali obbligatori nelle gare pubbliche, volto a favorire l’utilizzo di tecnologie provenienti da operatori economici ritenuti sicuri sotto il profilo della cybersicurezza.
L’obiettivo del contributo è illustrare le finalità, la portata applicativa e i principali risvolti operativi della normativa, offrendo alle stazioni appaltanti un quadro chiaro degli obblighi connessi all’acquisizione di beni ICT e delle implicazioni giuridiche derivanti dalle nuove misure di protezione della sicurezza nazionale.
Beni ICT e sicurezza nazionale: il perimetro normativo del DPCM 30 aprile 2025
IlDPCM 30 aprile 2025si inserisce in un percorso normativo volto a consolidare il legame tra l’approvvigionamento di beni ICT e la tutela degli interessi nazionali strategici, riconoscendo che la sicurezza cibernetica non può essere garantita se non a partire dalla catena di fornitura delle tecnologie utilizzate dalle pubbliche amministrazioni.
Il Decreto, pubblicato in attuazione dell’art. 14 dellaLegge n. 90/2024, disciplina l’acquisizione di prodotti e servizi informatici destinati a contesti critici, quali infrastrutture di rete, sistemi di protezione dei dati, piattaforme cloud, tecnologie di autenticazione, videosorveglianza e strumenti di gestione delle comunicazioni. L’ambito materiale riguarda quindi tutte quelle soluzioni tecnologiche che, per caratteristiche e funzioni, risultano idonee ad influenzare l’integrità, la continuità e la riservatezza delle attività istituzionali, nonché il corretto funzionamento delle componenti essenziali dello Stato.
Sotto il profilo soggettivo, il Decreto impone l’applicazione delle sue disposizioni non solo ai soggetti rientranti nell’art. 2, comma 2, delCodice dell’Amministrazione Digitale,ma anche ai soggetti privati ricompresi nelPerimetro di Sicurezza Nazionale Cibernetica, ai quali vengono estese,mutatis mutandis, le medesime prescrizioni in materia di approvvigionamento di beni ICT. In questa prospettiva, la disciplina opera come vero e proprio meccanismo di difesa della sovranità tecnologica dello Stato, orientando le scelte delle stazioni appaltanti verso fornitori in grado di assicurare elevate garanzie di affidabilità, trasparenza e sicurezza lungo l’intero ciclo di vita dei prodotti e dei servizi digitali acquisiti.
Beni ICT e categorie tecnologiche: individuazione delle tecnologie rilevanti
La disciplina introdotta dal DPCM 30 aprile 2025 attribuisce particolare rilievo alla qualificazione dellecategorie tecnologichela cui acquisizione da parte delle amministrazioni pubbliche assume carattere strategico. Tale qualificazione, contenuta nell’Allegato 2 del Decreto, risulta funzionale a delimitare il perimetro applicativo delle misure di cybersicurezza e dei criteri premiali, consentendo di individuare quei beni ICT il cui impiego è idoneo a incidere sulla protezione delle infrastrutture critiche e sulla tutela dei dati e dei processi digitali pubblici.
Tra le categorie ricomprese vi rientrano, a titolo esemplificativo, soluzioni di gestione dell’identità digitale e degli accessi, sistemi antivirus e antimalware, apparecchiature di rete dotate di funzioni di filtraggio e controllo, strumenti per la cifratura e la firma digitale, software dedicati alla gestione dei log e al monitoraggio degli eventi di sicurezza (SIEM), nonché infrastrutture cloud qualificate per l’archiviazione e la protezione dei dati. Accanto a tali tecnologie software, assumono rilevanza anche componenti hardware quali microprocessori con funzioni di sicurezza, dispositivi biometrici, firewall fisici, telecamere di videosorveglianza con capacità di analisi dei flussi, apparati destinati al controllo dell’operatività di reti industriali e sistemi di backup critici.
Attraverso tale classificazione, il Decreto opera unaselezione mirata dei beni ICTche, per natura e funzionalità, devono essere sottoposti a requisiti minimi di cybersicurezza e a verifiche documentali, incidendo direttamente sulle scelte tecniche e contrattuali delle stazioni appaltanti, chiamate a riconoscere e trattare tali prodotti come elementi costitutivi della difesa digitale dello Stato.
Il sistema di premialità previsto dall’art. 14 L. 90/2024
Il DPCM 30 aprile 2025 attua l’art. 14 della Legge n. 90/2024, disposizione che ha introdotto un meccanismo di incentivazione degli operatori economici in grado di offrire beni ICT provenienti da contesti geografici ritenuti affidabili sotto il profilo della sicurezza cibernetica. Tale disciplina mira a orientare le scelte delle amministrazioni verso prodotti e servizi realizzati in Paesi che adottanostandard elevati di protezione delle informazioni,collaborano con l’Unione europea o con l’Alleanza Atlantica e contribuiscono alla sovranità tecnologica nazionale.
Il criterio premiale, lungi dal configurarsi come mera preferenza commerciale, assume la funzione di strumento di tutela dell’interesse pubblico, volto a rafforzare la sicurezza digitale attraverso l’affidabilità dellasupply chain.
In tale logica, la legge conferisce alle stazioni appaltanti la facoltà di incidere sull’esito delle procedure di gara non solo sotto il profilo qualitativo, ma anche mediante la determinazione di untetto massimo al punteggio economico, favorendo così l’attribuzione di punteggi specifici alle offerte che garantiscano origini tecnologiche sicure. La premialità si inserisce, dunque, nel meccanismo dell’offerta economicamente più vantaggiosa, trasformandosi in elemento vincolante per la determinazione del rapporto qualità/prezzo nelle procedure aventi ad oggetto beni ICT, ovvero in requisito minimo laddove si operi con il criterio del minor prezzo.
Ne risulta una disciplina che, pur incidendo sul piano della concorrenza tra operatori, si conforma a un obiettivo superiore: la protezione dell’integrità, della disponibilità e della riservatezza delle infrastrutture pubbliche. Il criterio premiale si configura così come misura di sicurezza nazionale, con effetti diretti sulle modalità di acquisizione dei beni ICT, sul mercato di riferimento e sulla selezione dei fornitori autorizzati a operare nei settori critici della Pubblica Amministrazione.
Beni ICT e criteri premiali nel DPCM: provenienza, Bill of Materials e Paesi “sicuri”
Per la concreta applicazione del sistema premiale, il DPCM 30 aprile 2025 individua un criterio tecnico di verifica della provenienza dei beni ICT attraverso la presentazione, da parte degli operatori economici, della c.d. Bill of Materials (B.O.M.).
Tale documento contiene l’elenco dei componenti e dei servizi utilizzati nella realizzazione del prodotto o nell’erogazione del servizio informatico offerto; contiene una descrizione tecnica del prodotto, con certificazione della sua provenienza geografica, assumendo così la funzione di elemento probatorio ai fini dell’attribuzione del punteggio premiale.
Il Decreto impone che ciascun componente di livello 1 della B.O.M. sia riconducibile a operatori stabiliti in Italia, in Stati membri dell’Unione europea, nei Paesi aderenti all’Alleanza Atlantica (NATO), ovvero nei Paesi terzi elencati nell’Allegato 3 del medesimo DPCM, considerati affidabili in ragione di accordi di cooperazione in materia di cybersicurezza, protezione delle informazioni classificate, ricerca e sviluppo tecnologico. La provenienza deve essere indicata in modo puntuale nella sezione relativa ai campi “Manufacturer” o “Provider”, mediante specificazione dello Stato in cui è localizzato il sito produttivo del componente o il server di erogazione del servizio informatico.
Da tali prescrizioni emerge un modello di selezione dei fornitori che non si fonda su elementi meramente commerciali, ma sulla verifica concreta della filiera produttiva dei beni ICT, nella consapevolezza che la sicurezza cibernetica non può essere efficacemente garantita se uno solo dei componenti critici proviene da contesti considerati insicuri o non allineati agli standard internazionali applicati dallo Stato italiano.
Linee guida ACN e l’obbligo di inserimento dei criteri premiali nelle procedure per beni ICT
LeLinee guida adottate dall’Agenzia per la Cybersicurezza NazionaleconDetermina del Direttore Generale n. 343069 del 24 ottobre 2025assumono una funzione determinante nella concreta applicazione del sistema di premialità previsto dall’art. 14 della Legge n. 90/2024 e attuato dal DPCM 30 aprile 2025.
Esse impongono obblighi specifici alle stazioni appaltanti pubbliche e ai soggetti privati ricompresi nel Perimetro di Sicurezza Nazionale Cibernetica, ai quali è richiesto di conformare le proprie procedure di acquisizione di beni ICT e servizi digitali alle prescrizioni introdotte dal nuovo sistema di sicurezza nazionale.
Sotto ilprofilo soggettivo, le Linee guida chiariscono che il criterio premiale si applica alle amministrazioni e ai soggetti pubblici obbligati dal Codice dell’Amministrazione Digitale, nonché ai soggetti privati che, pur non sottoposti al Codice dei contratti pubblici, siano inclusi nel Perimetro di Sicurezza Nazionale Cibernetica e si procurino beni ICT destinati a infrastrutture o sistemi rilevanti per la sicurezza nazionale.
La disciplina si estende, inoltre, alle centrali di committenza, le quali devono recepire il criterio premiale nella predisposizione degli atti di gara, anche qualora agiscano in supporto ad amministrazioni terze. In tal senso, la normativa non opera in funzione del soggetto aggiudicatore, ma della natura del bene o servizio informatico acquisito, rendendo l’obbligo applicabile indipendentemente dalla qualificazione pubblica o privata dell’ente.
Quanto all’ambito oggettivo, le Linee guida specificano che la premialità deve essere applicata in tutte le procedure di acquisizione di beni ICT destinati a reti, sistemi informativi e servizi digitali che incidano sulla sicurezza nazionale, compresi hardware, software, infrastrutture cloud, sistemi di autenticazione, strumenti di protezione dei dati e componenti destinati a garantire la sicurezza fisica e logica delle infrastrutture critiche.
L’obbligo si estende, inoltre, ai servizi e ai sistemi di telefonia mobile 4G e 5G, sia stand-alone che non stand-alone, nonché alle loro evoluzioni tecnologiche, posta la loro intrinseca connessione con la gestione di reti strategiche e con la trasmissione di dati sensibili. Per tali tecnologie, la disciplina applicativa è integrata dall’Appendice Tecnica TELCO, la quale stabilisce criteri specifici per la predisposizione della documentazione tecnica e per l’attribuzione della premialità.
Sulpiano operativo, le Linee guida stabiliscono le modalità con cui il criterio premiale deve essere tradotto nei documenti di gara. La premialità deve risultare esplicitamente nel bando, nell’avviso o nell’invito, e deve essere disciplinata mediante clausole conformi al modello indicato dall’ACN.
Le stazioni appaltanti sono tenute a richiedere agli operatori economici la presentazione dellaBill of Materials (B.O.M.)in formato CycloneDX 1.6 o formato equivalente autorizzato, completa dell’indicazione della provenienza dei componenti attraverso i campi obbligatori “Manufacturer” e “Provider”. Tale documento deve essere accompagnato da un’autodichiarazione attestante la correttezza e completezza della distinta e la provenienza dei componenti dai Paesi considerati sicuri. La provenienza, ai fini dell’attribuzione del punteggio, deve risultare univoca per tutti i componenti di livello 1, pena la perdita integrale del beneficio premiale.
Le Linee guida precisano, inoltre, che la premialità non può essere suddivisa o graduata in funzione della percentuale di componenti conformi: essa opera secondo un meccanismo binario (“on/off”) che assegna otto punti esclusivamente quando tutti i componenti di livello 1 provengono da Paesi appartenenti all’Unione europea o altri in white list. La presenza anche di un solo componente di livello 1 proveniente da un Paese non considerato affidabile comporta automaticamente la mancata attribuzione dell’intero punteggio.
Da ciò discende l’assoluta obbligatorietà del criterio premiale: la sua omissione nei documenti di gara integra una violazione della disciplina di settore, con possibili conseguenze in caso di controllo da parte dell’ACN.
Le clausole tipo da inserire nei disciplinari per l’applicazione dei criteri di premialità
Le linee guida di ACN precisano che le Stazioni appaltanti, comprese le centrali di committenza, includono nella documentazione di gara una clausolaad hocper l’attribuzione della premialità. A titolo esemplificativo, ACN propone due esempi di clausola tipo:
Ipotesi 1(generale, ad esclusione di approvvigionamenti di sistemi e servizi telefonia mobile 4G e 5G)
«Ai sensi dell’articolo 4, primo periodo, del DPCM del 30 aprile 2025, come modificato dal DPCM 2 ottobre 2025, gli operatori economici producono, in sede di offerta, l’elenco di tutti gli elementi (componenti o servizi) per il livello 1 della BOM (Bill of Materials) conforme ai requisiti di cui alle Linee guida adottate dall’Agenzia per la cybersicurezza nazionale, sentita l’Autorità nazionale anticorruzione, comprensiva almeno dei campi minimi indicati nelle medesime Linee guida;
nonché una autodichiarazione che attesti che la propria offerta contempla, al livello di dettaglio riportato nella BOM, di cui si attesta la correttezza e la completezza, l’uso di tecnologie di cybersicurezza italiane, o di Paesi appartenenti all’Unione europea, o di Paesi aderenti all’Alleanza atlantica (NATO), o di Paesi terzi di cui all’Allegato 3 del citato DPCM.
La BOM dovrà essere fornita, ai sensi dell’Allegato 1, parte II, n. 1), lett. a), del DPCM 30 aprile 2025, in formato CycloneDX versione 1.6 o altro formato equivalente, previa autorizzazione della stazione appaltante».
Ipotesi 2(approvvigionamenti di sistemi e servizi telefonia mobile 4G e 5G)
«Ai sensi dell’articolo 4, secondo e terzo periodo, del DPCM del 30 aprile 2025, come modificato dal DPCM 2 ottobre 2025, gli operatori economici producono, in sede di offerta, l’elenco di tutti i componenti di fabbricazione delle infrastrutture impiegate per erogare i servizi e sistemi di telefonia mobile 4G e 5G, in versione sia stand-alone che non stand-alone, e successive evoluzioni tecnologiche, conforme ai requisiti di cui alle Linee guida adottate dall’Agenzia per la cybersicurezza nazionale, sentita l’Autorità nazionale anticorruzione, comprensiva dei campi del prospetto indicati nelle medesime Linee guida;
nonché una autodichiarazione che attesti che la propria offerta contempla, al livello del prospetto indicato nelle medesime Linee guida, di cui si attesta la correttezza e la completezza, l’uso di tecnologie di cybersicurezza italiane, o di Paesi appartenenti all’Unione europea, o di Paesi aderenti all’Alleanza atlantica (NATO), o di Paesi terzi di cui all’Allegato 3 del citato DPCM.
Il prospetto di tutti i componenti di fabbricazione delle infrastrutture impiegate per erogare i servizi e sistemi di telefonia mobile 4G e 5G, in versione sia stand-alone che non stand-alone, e successive evoluzioni tecnologiche, dovrà essere fornito come previsto nel prospetto di cui all’Appendice tecnica TELCO delle medesime Linee guida».
Verifica successiva dell’ACN e conseguenze sulle procedure di gara relative ai beni ICT
Il sistema dei criteri premiali non si esaurisce nella fase di presentazione dell’offerta. Le Linee guida ACN chiariscono che la Bill of Materials e le autodichiarazioni rese dagli operatori economici in sede di gara sono soggette a verifiche successive, anchedopo l’aggiudicazione, mediante attività di scrutinio tecnico eseguite dall’Agenzia ai sensi dell’art. 1, comma 6, lett. a), deldecreto-legge n. 105/2019.
Tale previsione segna una rilevante discontinuità rispetto alla tradizionale fase dei controlli nelle gare pubbliche, poiché introduce un presidio di sicurezza nazionale destinato a incidere direttamente sull’efficacia del contratto avente ad oggetto beni ICT.
La verifica opera comevalutazione tecnicadell’effettiva corrispondenza tra i componenti impiegati e quanto dichiarato nella B.O.M., assicurando che i prodotti o i servizi utilizzati dalla pubblica amministrazione non presentino elementi estranei ai Paesi considerati affidabili dal DPCM 30 aprile 2025.
Qualora dalla verifica emerga anche una sola difformità rispetto alla distinta dichiarata o siano individuati componenti di livello 1 provenienti da Paesi non affidabili, le Linee guida impongono che la stazione appaltante preveda nei contratti clausole di risoluzione espressa, da applicare in caso di non conformità.
L’eventuale inserimento di componenti non dichiarati o la presenza di elementi provenienti da Paesi non riconosciuti sicuri non comportano una mera penalità economica, ma configurano unaviolazione del principio di fiduciasancito dall’art. 2 del Codice dei contratti pubblici, con conseguenze sul rapporto contrattuale, sulla responsabilità dell’operatore economico e sull’obbligo di segnalazione all’ANAC ai sensi degli artt. 96 e 98 del D.lgs. n. 36/2023.
Di particolare rilievo è il fatto che la verifica dell’ACN non si pone come attività eventuale, ma come controllo strettamente connesso alla tutela degli interessi nazionali strategici. La natura critica dei beni ICT oggetto della disciplina rende necessaria una vigilanza continua sull’interasupply chain tecnologica, la cui integrità non può essere garantita unicamente attraverso le dichiarazioni rese in fase di gara.
Ne deriva un modello di protezione multilivello che vincola gli operatori economici a mantenere per l’intera durata del contratto le stesse condizioni di sicurezza dichiarate nell’offerta, ponendo un obbligo permanente di conformità e trasparenza tecnologica.
Conclusioni: supporto legale qualificato per l’applicazione della normativa
Il quadro delineato dal DPCM 30 aprile 2025 e dalle Linee guida ACN richiede alle stazioni appaltanti un approccio tecnico-giuridico rigoroso, fondato sulla corretta individuazione dei beni ICT, sulla predisposizione delle clausole premiali e sulla gestione delle verifiche della supply chain informatica.
Si tratta di adempimenti che impongono una competenza trasversale tra diritto degli appalti e sicurezza informatica, ambito nel quale il nostro Studio opera stabilmente, affiancando enti pubblici e soggetti privati.
Contattaci per un confronto!
Ai sensi dell’art. 70-quater della Legge 633/1941, ai fini della tutela del diritto d’autore, si dichiara che il presente contenuto è riservato, e ne è vietata la riproduzione o l’estrazione di testo, anche mediante sistemi di intelligenza artificiale.
daRedazione|Ott 21, 2025|Diritto d'Impresa
La disciplina del portale ACN è un continua ed incessante evoluzione. All’esito del lavori del quinto Tavolo NIS, l’Agenzia per la Cybersicurezza Nazionale ha annunciato la pubblicazione dellaDeterminazione n. 250916/2025, con cui viene istituzionalizzata la figura del referente CSIRT, destinata a divenire un nuovo presidio tecnico-organizzativo per la gestione degli incidenti di sicurezza informatica. La designazione di tale figura, prevista tra il 20 novembre e il 31 dicembre 2025, rappresenta una novità di rilievo per assicurare la tempestività delle notifiche allo CSIRT Italia e rafforzare la capacità di risposta degli operatori NIS.
Parallelamente, è stato approvato un nuovo aggiornamento dell’elenco dei soggetti NISattraverso l’integrazione delle registrazioni tardive e delle successive istanze pervenute dopo la scadenza di giugno. Questo processo, destinato a proseguire con ulteriori integrazioni entro la fine dell’anno, mira a mantenere costantemente aggiornato il quadro dei soggetti rilevanti per la protezione delle infrastrutture digitali strategiche.
Ciò premesso, l’obiettivo di questo articolo è fornire una guida chiara e strutturata sul funzionamento del portale ACN, all’esito delle novità apportate dallaDeterminazione del 19 settembre 2025. Ci concentreremo, in particolare, sugli adempimenti che gli operatori NIS devono rispettare nelle fasi di registrazione e aggiornamento.
Il portale ACN e il sistema definitorio della Determinazione
La recente Determinazione n. 250916/2025 conferma il ruolo del portale ACN quale infrastruttura digitale unica per la gestione degli adempimenti previsti per i soggetti NIS.
La Determinazione si apre con un riepilogo dellenozioni cardine: “Servizi NIS”, “censimento”, “associazione”, “registrazione”, “aggiornamento annuale” e “aggiornamento continuo”. I Servizi NIS rappresentano l’insieme di funzioni digitali attraverso le quali avvengono tutte le interlocuzioni ufficiali tra operatori e Autorità, consentendo di effettuare la registrazione, modificare le informazioni, aggiornare periodicamente i dati e ricevere comunicazioni istituzionali.
Il censimento e l’associazione definiscono la fase preliminare di accesso, in cui si autenticano le utenze e si stabilisce formalmente il legame tra l’utente e il soggetto NIS di riferimento. La registrazione costituisce il momento di formalizzazione dei dati anagrafici e strutturali del soggetto, mentre l’aggiornamento annuale e l’aggiornamento continuo scandiscono i successivi obblighi periodici di verifica e modifica delle informazioni.
Le modifiche intervenute non hanno toccato l’essenza la “centralità” del portale ACN quale unico canale autorizzato per la trasmissione e la gestione delle informazioni, garantendo tracciabilità, standardizzazione e integrità dei dati. Esso consente agli operatori NIS di organizzare in modo ordinato i flussi informativi interni, di distribuire responsabilità in maniera trasparente e di assicurare il rispetto delle prescrizioni del Decreto Legislativo 4 settembre 2024, n. 138.
Portale ACN: punti di contatto e responsabilità organizzative
Nella disciplina sul funzionamento del portale ACN, un ruolo di primaria importanza è attribuito alla figura delpunto di contatto, prevista dall’articolo 4 della Determinazione. Si tratta di una persona fisica designata dal soggetto NIS con il compito di curare, per conto dell’organizzazione, l’esecuzione di tutti gli adempimenti previsti dalla normativa NIS, inclusa la registrazione, l’aggiornamento delle informazioni e l’interlocuzione diretta con l’Autorità nazionale competente.
La determinazione ribadisce che tale figura costituisce l’interfaccia formale e sostanziale tra il soggetto e Agenzia per la Cybersicurezza Nazionale, garantendo così la tracciabilità di ogni attività svolta attraverso ilportale ACN.
Il punto di contatto può coincidere con il rappresentante legale del soggetto NIS, con un procuratore generale o con un dipendente formalmente delegato. In presenza di gruppi societari, la funzione può essere esercitata anche da un dipendente di altra impresa del gruppo, purché rientrante nell’ambito applicativo della normativa NIS. Nelle pubbliche amministrazioni, tale funzione può essere affidata anche a personale di altre amministrazioni, previa autorizzazione. In ogni caso, la responsabilità ultima resta in capo agli organi di amministrazione e direttivi, i quali sono tenuti a garantire che le informazioni fornite tramite il portale ACN siano corrette, aggiornate e trasmesse nei tempi stabiliti.
Accanto al punto di contatto è prevista la designazione di unsostituto, anch’egli censito sulla piattaforma, che può operare con le medesime funzioni, salvo la fase di registrazione iniziale. Questa struttura garantisce la continuità operativa e riduce i rischi derivanti da eventuali indisponibilità o impedimenti.
La determinazione precisa inoltre che eventuali avvicendamenti devono essere formalizzati senza ritardo, così da preservare la piena operatività del sistema. L’organizzazione è pertanto chiamata a dotarsi di un assetto interno stabile, chiaro e conforme, nel quale le responsabilità per la gestione del portale ACN siano esattamente individuate e presidiate, a tutela dell’effettività degli obblighi imposti dalDecreto Legislativo 4 settembre 2024, n. 138.
La novità più rilevante: il referente CSIRT
La principale innovazione introdotta dalla Determinazione in esame riguarda l’istituzionalizzazione della figura delreferente CSIRT,destinata a integrare in modo significativo la governance operativa della sicurezza cibernetica. A partire dal 20 novembre ed entro il 31 dicembre 2025, ogni soggetto NIS dovrà designare, per il tramite del punto di contatto, una persona fisica con funzioni specifiche di interlocuzione con CSIRT Italia, al fine di garantire una gestione tempestiva ed efficace delle notifiche di incidente informatico.
La designazione del referente CSIRT, che avviene esclusivamente attraverso il portale ACN, rappresenta un passaggio decisivo nella strutturazione dei presidi di sicurezza all’interno delle organizzazioni soggette alla normativa NIS.
Il referente CSIRT è chiamato ad agire quale snodo tecnico-operativo per la trasmissione delle segnalazioni e delle notifiche previste dagli articoli 25 e 26 delDecreto Legislativo 4 settembre 2024, n. 138. La norma consente inoltre di designare uno o più sostituti, al fine di assicurare la continuità funzionale e di prevenire eventuali ritardi o interruzioni nella gestione delle comunicazioni verso l’Autorità.
Per garantire l’effettività del sistema, il referente e i suoi sostituti devono possedere competenze di base in materia di sicurezza informatica e di gestione degli incidenti, nonché una conoscenza adeguata dei sistemi informativi e delle infrastrutture dell’organizzazione di appartenenza.
Questa nuova previsione rafforza il presidio tecnico a supporto del punto di contatto, creando un canale dedicato di comunicazione e coordinamento operativo con il CSIRT nazionale.
Censimento e associazione delle utenze nel portale ACN
L’accesso al portale ACN – come noto – è subordinato a una rigorosa procedura dicensimento e associazione delle utenze, che rappresenta la base dell’intero sistema di gestione digitale degli adempimenti dal decreto NIS 2. Tale procedura è finalizzata a garantire l’identificazione certa degli utenti e a stabilire un legame formale e tracciabile tra ciascun utente e il soggetto NIS di appartenenza.
L’autenticazione avviene mediante strumenti di identità digitale qualificata, qualiSPID o CIE, assicurando così un elevato livello di garanzia nell’identificazione dell’utente. Una volta autenticato, l’utente è tenuto a completare la propria anagrafica, fornendo informazioni personali e professionali che comprendono, tra le altre, generalità, recapiti, sede di servizio e riferimenti dell’organizzazione di appartenenza. Si tratta di un passaggio essenziale per assicurare la tracciabilità di ogni attività svolta all’interno del portale ACN.
Completata la fase di censimento, il punto di contatto procede all’associazione della propria utenza con il soggetto NIS e, successivamente, può invitare altri utenti a operare sulla piattaforma con ruoli differenziati: sostituto punto di contatto, segreteria e operatori.
Questa articolazione dei profili consente di distribuire le funzioni operative all’interno dell’organizzazione, pur mantenendo la responsabilità ultima in capo al punto di contatto e agli organi di vertice. La procedura telematica di associazione, che si perfeziona attraverso conferme inviate al domicilio digitale del soggetto, costituisce un presidio di affidabilità e integrità del sistema.
Registrazione annuale e dichiarazioni obbligatorie
La registrazione sul portale ACN rappresenta l’antecedente logico fondamentale per la formalizzazione delle informazioni all’interno del portale ACN. L’articolo 11 della Determinazione disciplina in modo puntuale tale procedura, che si svolge annualmente nel periodo compresotra il 1° gennaio e il 28 febbraio.In questa finestra temporale, il punto di contatto è tenuto a compilare e trasmettere la dichiarazione contenente le informazioni necessarie per l’inquadramento giuridico, economico e tecnico del soggetto NIS, secondo quanto previsto dal Decreto Legislativo 4 settembre 2024, n. 138.
La dichiarazione comprende dati relativi alla natura del soggetto, alla sua eventuale appartenenza a un gruppo di imprese e alle imprese collegate rilevanti ai fini dell’articolo 3, comma 10, del decreto NIS, oltre all’indicazione dei codici ATECO che descrivono l’attività esercitata.
Vengono inoltre richiesteinformazioni economiche, come i valori di bilancio, il fatturato e il numero di dipendenti, necessari per individuare la corretta dimensione d’impresa secondo la raccomandazione 2003/361/CE, nonché le normative settoriali e le tipologie di soggetto di riferimento previste dagli allegati I, II, III e IV del decreto. La procedura si conclude con una conferma formale da parte del punto di contatto, resa ai sensi del D.P.R. 28 dicembre 2000, n. 445, che attesta la veridicità delle informazioni trasmesse.
Tutte le comunicazioni relative alla registrazione avvengono esclusivamente tramite il portale ACN e sono notificate al domicilio digitale del soggetto NIS, assicurando così la piena tracciabilità e opponibilità delle dichiarazioni rese. L’Autorità nazionale competente può inoltre procedere a verifiche di coerenza, anche a campione, per accertare l’esattezza delle informazioni fornite.
Aggiornamento annuale e aggiornamento continuo delle informazioni sul portale ACN
La gestione dei dati trasmessi tramite il portale ACN, come noto, non si esaurisce con la registrazione iniziale. In coerenza con il Decreto Legislativo 4 settembre 2024, n. 138, la Determinazione in esame disciplinadue ulteriori fasi procedurali: l’aggiornamento annuale e l’aggiornamento continuo. Si tratta di strumenti fondamentali per assicurare la costante attualità delle informazioni trasmesse, così da consentire all’Autorità nazionale competente di disporre di dati sempre coerenti e tempestivamente aggiornati, in un contesto normativo che richiede elevati standard di affidabilità e reattività.
L’aggiornamento annualesi svolge tra il 15 aprile e il 31 maggio di ogni anno e ha lo scopo di verificare la correttezza e l’adeguatezza dei dati già presenti nel sistema. In questa fase, il punto di contatto è tenuto ad assicurare l’esattezza delle informazioni relative all’organizzazione, ai recapiti ufficiali, ai rappresentanti legali e ai procuratori generali, nonché ai componenti degli organi di amministrazione e direttivi.
Viene inoltre verificata la correttezza dei dati tecnici relativi ai servizi offerti, agli spazi di indirizzamento IP, ai domini utilizzati e agli eventuali accordi di condivisione. Gli aggiornamenti sono confermati tramite il portale ACN e notificati al domicilio digitale del soggetto, a garanzia della piena tracciabilità dell’operazione.
L’aggiornamento continuo,invece, consente ai soggetti NIS di comunicare ogni variazione intervenuta nel corso dell’anno, dal completamento dell’aggiornamento annuale fino al 14 aprile dell’anno successivo.
Questo meccanismo garantisce che eventuali mutamenti significativi, come modifiche societarie, variazioni di contatti o cambiamenti nelle informazioni tecniche, siano immediatamente recepiti e registrati. Anche in questo caso, la conferma delle modifiche avviene per il tramite del punto di contatto, che ne attesta la veridicità ai sensi del D.P.R. 28 dicembre 2000, n. 445.
Verifiche, controlli e formazione dell’elenco dei soggetti NIS
La normativa attuativa del decreto NIS 2 disciplina con particolare attenzione anche i meccanismi di verifica e controllo da parte diAgenzia per la Cybersicurezza Nazionalee delle Autorità di settore. Tali verifiche hanno la finalità di assicurare che i dati trasmessi dai soggetti NIS siano coerenti, completi e conformi agli obblighi previsti dal Decreto Legislativo 4 settembre 2024, n. 138.
Le verifiche di coerenza possono essere svolte a campione e si inseriscono in un procedimento formalizzato che prevede termini stringenti per la conclusione. L’Autorità competente dispone di trenta giorni per comunicare l’esito della verifica, prorogabili una sola volta per ulteriori venti giorni in presenza di approfondimenti complessi. Nel corso dell’istruttoria, l’Autorità può richiedere integrazioni e chiarimenti, ai quali il soggetto NIS è tenuto a rispondere entro dieci giorni.
L’elaborazione dell’elenco dei soggetti NIS si fonda sulle informazioni validate attraverso le verifiche condotte dall’Autorità. Ai soggetti inseriti viene attribuito un codice identificativo univoco, destinato a facilitare le successive interlocuzioni e a consolidare il tracciamento delle comunicazioni.
Disposizioni finali e decorrenza degli obblighi introdotti dalla nuova Determinazione
La parte conclusiva della Determinazione n. 250916/2025 conferma la volontà di assicurare continuità operativa nell’utilizzo del portale ACN. L’articolo 21 stabilisce espressamente che il provvedimento aggiorna e sostituisce la precedente Determinazione n. 283727 del 22 luglio 2025, mantenendo immutata la struttura funzionale della piattaforma e delle procedure già in essere, ma integrandole con le previsioni relative alla figura del referente CSIRT e con un più articolato regime di aggiornamento e verifica delle informazioni trasmesse.
Questa impostazione consente ai soggetti NIS di operare in un contesto regolatorio già conosciuto, evitando interruzioni nei flussi comunicativi e garantendo una transizione ordinata verso le nuove disposizioni.
La nuova disciplina si applicaa decorrere dal 30 settembre 2025, con la sola eccezione dell’articolo relativo all’aggiornamento continuo, la cui efficacia è differita alla pubblicazione del relativo servizio all’interno del portale ACN. Ciò permette di allineare la tempistica applicativa con la piena disponibilità tecnica dello strumento, evitando che obblighi giuridici precedano la funzionalità operativa necessaria per adempiervi.
Affidati a noi per un supporto legale qualificato nelle procedure gestite tramite il portale ACN e nei rapporti con l’Agenzia
La normativa di attuazione del decreto NIS 2 conferma il ruolo strategico del portale ACN come strumento unico e vincolante per la gestione degli adempimenti dei soggetti NIS. L’introduzione della figura del referente CSIRT rafforza ulteriormente la capacità operativa del sistema, affiancando al punto di contatto una funzione dedicata alla gestione degli incidenti informatici e alla comunicazione tempestiva con CSIRT Italia.
In questo quadro normativo e operativo, i soggetti NIS sono chiamati a organizzarsi in modo strutturato e consapevole, adottando procedure interne che consentano di adempiere correttamente e nei termini prescritti a tutti gli obblighi previsti.
Il nostro Studio Legale, grazie a una consolidata expertise dell’Avv. Luca D’Agostino in materia di sicurezza informatica, è a disposizione per assistere operatori pubblici e privati nell’attuazione degli obblighi connessi all’utilizzo del portale ACN.
Rivolgiti a noi per un primo confronto!
Ai sensi dell’art. 70-quater della Legge 633/1941, ai fini della tutela del diritto d’autore, si dichiara che il presente contenuto è riservato, e ne è vietata la riproduzione o l’estrazione di testo, anche mediante sistemi di intelligenza artificiale.
daRedazione|Ott 7, 2025|Diritto d'Impresa
La Legge 132/2025, anche nota come Legge sull’Intelligenza Artificiale, introduce un quadro di regole organico volto a disciplinare l’uso dei sistemi di intelligenza artificiale in diversi settori dell’attività umana, con l’obiettivo di garantire un equilibrio tra innovazione tecnologica e tutela dei diritti fondamentali.
Pubblicata nellaGazzetta Ufficialen. 223 del 25 settembre 2025, la norma rappresenta il primo intervento sistematico del legislatore nazionale in materia, a completamento della disciplina del Regolamento (UE) 2024/1689 (c.d.AI Act), cui si affianca per definire un insieme coerente di norme e principi.
Il presente contributo si propone di offrire una panoramica ragionata delle disposizioni più rilevanti della Legge 132, con esclusione della disciplina concernente il trattamento dei dati sanitari, già oggetto di unaprecedente disamina.
In particolare, saranno esaminati gli articoli relativi all’impiego dell’intelligenza artificiale nelleprofessioniintellettuali, nella pubblica amministrazione e nell’attività giudiziaria, per poi approfondire ledeleghe legislativeconferite al Governo in materia di algoritmi, dati e responsabilità penale. Seguirà un commento alle modifiche apportate alla legge suldiritto d’autoree alledisposizioni penali, con particolare riguardo al nuovo art. 612-quaterdel codice penale e alle aggravanti legate all’uso di sistemi di IA.
Legge 132/2025 e applicazioni dell’intelligenza artificiale nelle professioni, nella Pubblica Amministrazione e nella Giustizia
La Legge 132/2025 dedica una parte significativa del proprio impianto normativo alla regolazione dell’impiego dei sistemi di intelligenza artificiale nei contesti professionali, amministrativi e giudiziari, delineando una cornice di principi ispirata al primato della persona sull’algoritmo. Gli articoli 13, 14 e 15 introducono una disciplina unitaria che mira a garantire l’uso responsabile dell’IA quale strumento di supporto all’attività umana, mai sostitutivo della capacità decisionale e valutativa del professionista o del pubblico funzionario.
Con riferimento alleprofessioni intellettuali, l’art. 13 ribadisce il principio diprevalenza del lavoro umanorispetto agli strumenti automatizzati, chiarendo che l’intelligenza artificiale può essere utilizzata solo per attività strumentali e di ausilio alla prestazione d’opera. Si tratta di un’affermazione di particolare rilievo, poiché riafferma la natura fiduciaria del rapporto tra professionista e cliente, tutelando l’autonomia intellettuale e la responsabilità personale del primo.
Coerentemente, la norma impone al professionista un dovere ditrasparenza informativa, prevedendo che le caratteristiche dei sistemi di IA impiegati siano comunicate al destinatario della prestazione con linguaggio chiaro e comprensibile, così da assicurare piena consapevolezza delle tecnologie utilizzate nel processo di elaborazione e di consulenza.
Per quanto concerne la pubblica amministrazione, l’art. 14 individua l’obiettivo di un impiego dell’intelligenza artificiale funzionale all’efficienza procedimentalee al miglioramento della qualità dei servizi, ma sempre nel rispetto del principio ditracciabilità e conoscibilitàdegli algoritmi. L’IA, in questa prospettiva, assume un ruolo meramente ausiliario rispetto all’attività provvedimentale, mentre la decisione finale rimane prerogativa dell’essere umano, unico titolare della responsabilità giuridica del procedimento. La norma introduce altresì l’obbligo per le amministrazioni di adottare misuretecniche, organizzative e formativevolte a garantire un uso etico, controllato e consapevole delle tecnologie, senza nuovi o maggiori oneri per la finanza pubblica.
Infine, l’art. 15 estende tali principi alsettore della giustizia, specificando che ogni decisione in ordine all’interpretazione della legge, alla valutazione delle prove e all’adozione dei provvedimenti resta esclusivamente riservata al magistrato. Il Ministero della giustizia è chiamato a regolamentare l’impiego dei sistemi di intelligenza artificiale per finalità organizzative e di semplificazione del lavoro giudiziario, nonché a promuovere la formazione digitale dei magistrati e del personale amministrativo.
Le deleghe legislative della Legge 132/2025: dati, algoritmi, vigilanza e responsabilità
Nel cuore della Legge 132/2025 si collocano le deleghe legislative che il Parlamento conferisce al Governo per costruire, entro dodici mesi dall’entrata in vigore, un assetto organico delle regole sull’uso dei dati, degli algoritmi e dei metodi matematici impiegati nell’addestramento dei sistemi di intelligenza artificiale, nonché per adeguare l’ordinamento interno alRegolamento (UE) 2024/1689e tipizzare gli illeciti connessi alla realizzazione o all’impiego abusivo dei medesimi sistemi.
L’art. 16 della Legge 132 delimita con nettezza il perimetro: nel dominio già assoggettato all’AI Act l’intervento nazionale non può introdurre “obblighi ulteriori” rispetto a quelli europei, imponendo al legislatore delegato un delicato esercizio di coordinamento.
In tale cornice, i decreti dovranno innanzitutto individuare le ipotesi in cui si renda necessario disciplinare giuridicamente l’utilizzo di dati, algoritmi e metodi di addestramento, chiarendo diritti e obblighi delle parti che intendano procedervi, e predisponendo strumenti di tutela tanto risarcitori quanto inibitori, affiancati da un apparato sanzionatorio proporzionato.
La scelta di attribuire la cognizione delle relative controversie allesezioni specializzate in materia di impresasegnala la volontà di concentrare la giurisdizione su giudici tecnicamente attrezzati per governare conflitti ad alta intensità tecnologica e informativa.
Sul piano procedurale, gli schemi dei decreti sono proposti dal Presidente del Consiglio dei ministri e dal Ministro della giustizia, trasmessi alle Camere per il parere delle Commissioni competenti e, decorso il termine di sessanta giorni, possono essere emanati anche in mancanza di parere; è prevista una proroga di sessanta giorni quando il termine parlamentare si sovrapponga alla scadenza della delega, a testimonianza dell’esigenza di un confronto istituzionale non meramente formale.
L’art. 24 della Legge 132 reca una delega più ampia, espressamente incardinata sulle procedure di cui all’art. 31 della legge n. 234/2012, che impone al Governo di acquisire i pareri delle Commissioni parlamentari, della Conferenza unificata e del Garante per la protezione dei dati personali, e di adottare uno o più decreti legislativi per l’adeguamento dell’ordinamento interno all’AI Act e per l’ulteriore specificazione della disciplina dei casi di realizzazione e impiego illecito di sistemi di IA.
Il quadro dei criteri direttivi è particolarmente articolato e innerva l’intero ciclo di vita delle tecnologie: alle autorità di cui all’art. 20 dovranno essere attribuiti, nei limiti della rispettiva designazione, i poteri di vigilanza, ispezione e sanzione previsti dal regolamento europeo, incluse le prerogative tipiche dell’autorità di vigilanzadel mercato (richiesta di informazioni, ispezioni in loco e a distanza senza preavviso, controlli sulle prove in condizioni reali e sui sistemi ad alto rischio).
In parallelo, il legislatore delegato è chiamato ad apportare le modifiche necessarie alle normative settoriali – anche in materia diservizi bancari, finanziari, assicurativi e di pagamento– per garantire un adeguamento integrale e coerente, evitando vuoti applicativi o sovrapposizioni.
Di rilievo è poi l’opzione per un uso calibrato della regolazione secondaria da parte delle autorità individuate, nel rispetto delle loro competenze, al fine di tradurre in misure tecniche i principi del regolamento.
Sul terreno repressivo e dienforcement, la Legge 132 indica la strada di un adeguamento del quadro sanzionatorio agli standard dell’art. 99 dell’AI Act, attribuendo alle autorità nazionali il potere diirrogare sanzioni e misure amministrativeentro i limiti edittali europei e secondo procedure compatibili con l’ordinamento interno, con possibilità di deroga ai criteri generali dell’art. 32, comma 1, lett. d), della legge n. 234/2012 e alla legge n. 689/1981, quando necessario a dare piena esecuzione al diritto dell’Unione.
L’art. 24, inoltre, orienta l’intervento del Governo verso la prevenzione del rischio attraverso percorsi di alfabetizzazione e formazione all’uso dell’IA: da un lato, promossi dagli ordini professionali, dalle associazioni di categoria e dalle forme aggregative ex legge n. 4/2013, con la possibile introduzione di un equo compenso modulato in base a responsabilità e rischi connessi all’adozione dell’IA; dall’altro lato, mediante il potenziamento dei curricula scolastici nelle discipline STEM e artistiche, lo sviluppo di attività formative in università, e la valorizzazione della ricerca e del trasferimento tecnologico, anche tramite il coinvolgimento del sistema universitario in spazi di sperimentazione normativa (sandbox) in cooperazione con le autorità nazionali.
Non meno significativo è il mandato a definire una disciplinaad hocper l’uso disistemi di IA nell’attività di polizia, che impone un fine bilanciamento tra esigenze di sicurezza e garanzie dei diritti fondamentali.
Una specifica proiezione penalistica della delega si rinviene tanto nel comma 1 dell’art. 24 quanto nel suo comma 3, con l’espresso incarico al Governo di adeguare e specificare la disciplina dei casi di realizzazione e impiego illecito di sistemi di IA.
I criteri direttivi, elencati al comma 5, disegnano un’architettura completa: misure – anche cautelari – per inibire la diffusione e rimuovere contenuti generati illecitamente con IA;autonome fattispecie di reato,punite a dolo o colpa, centrate sull’omessa adozione o aggiornamento di misure di sicurezza nella produzione, messa in circolazione e uso professionale dei sistemi, quando l’omissione determini un pericolo concreto per la vita o l’incolumità pubblica o individuale o per la sicurezza dello Stato; criteri di imputazione della responsabilità penale delle persone fisiche e dellaresponsabilità amministrativa degli enti, calibrati sul livello effettivo di controllo esercitato sull’algoritmo; strumenti di tutela nella responsabilità civile.
Da ultimo, nella Legge 132, vi è una regolazione dell’uso dell’IA nelle indagini preliminari improntata ai principi di proporzionalità, non discriminazione e trasparenza, nel pieno rispetto del diritto di difesa e della protezione dei dati dei terzi.
A chiudere il cerchio, la delega prevede interventi di coordinamento sostanziale e processuale sull’ordinamento vigente, affinché le innovazioni non rimangano isolate ma si innestino armonicamente nel tessuto normativo.
In sintesi, le deleghe della Legge 132 articolano una strategia in tre movimenti:prevenzione(regole tecniche, formazione, vigilanzaex ante),correzione(poteri ispettivi e misure di esecuzione), erepressione(tipizzazione degli illeciti e sanzioni effettive), con l’intento dichiarato di allineare il diritto interno al paradigma europeo e di fornire ai soggetti pubblici e privati un quadro certo entro cui progettare, addestrare e impiegare sistemi di intelligenza artificiale.
La Legge 132 e la tutela del diritto d’autore nelle opere generate con l’ausilio dell’intelligenza artificiale
La Legge 132 interviene in modo mirato sulla legge sul diritto d’autore, per chiarire il perimetro della protezione autorale nell’ecosistema digitale governato dai modelli di intelligenza artificiale.
La modifica all’art. 1 afferma espressamente che l’oggetto della tutela sono le «opere dell’ingegno umano», includendo quelle realizzate «con l’ausilio di strumenti di intelligenza artificiale» purché costituiscano risultato dellavoro intellettuale dell’autore.
La scelta lessicale restituisce centralità al requisito dell’apporto creativo umano: l’uso dell’IA non è di per sé ostativo alla protezione, ma la tutela sorge solo quando la creazione rechi l’impronta personale dell’autore, riconoscibile in scelte creative autonome (concezione, selezione, organizzazione, direzione del processo generativo) non riducibili a una mera esecuzione automatica. Ne discende che risultati prodotti in via pienamente automatizzata, privi di contributo creativo umano, difettano del presupposto soggettivo della paternità e non accedono al regime di esclusiva.
In parallelo, la Legge 132 innesta un tassello sistemico sull’estrazione di testo e dati (TDM)a fini di addestramento: il nuovo art. 70-septiesconsente riproduzioni ed estrazioni da opere o materiali legittimamente accessibili in rete o in banche dati «attraverso modelli e sistemi di IA, anche generativa», ferma la conformità agli artt. 70-tere 70-quater.
Per i soggetti legittimati (ad es. organismi di ricerca e istituti del patrimonio culturale), l’estrazione ai sensi dell’art. 70-terè ammessa nei limiti dell’accesso lecito:«Sono consentite le riproduzioni compiute da organismi di ricerca e da istituti di tutela del patrimonio culturale, per scopi di ricerca scientifica, ai fini dell’estrazione di testo e di dati da opere o da altri materiali disponibili in reti o banche di dati cui essi hanno lecitamente accesso, nonché la comunicazione al pubblico degli esiti della ricerca ove espressi in nuove opere originali».
Mentre l’estrazione “generale” ex art. 70-quaterresta subordinata all’assenza di opt-out espresso dai titolari:«Fermo restando quanto previsto dall’articolo 70-ter, sono consentite le riproduzioni e le estrazioni da opere o da altri materiali contenuti in reti o in banche di dati cui si ha legittimamente accesso ai fini dell’estrazione di testo e di dati. L’estrazione di testo e di dati è consentita quando l’utilizzo delle opere e degli altri materiali non è stato espressamente riservato dai titolari del diritto d’autore e dei diritti connessi nonché dai titolari delle banche dati».
La Legge 132 assimila così l’addestramento dei sistemi di IA alle ordinarie operazioni di TDM, imponendo a sviluppatori e fornitori un rigoroso governo della filiera dei dati: verifica della liceità dell’accesso, tracciabilità delle fonti, rispetto degli opt-out.
La coerenza dell’impianto è rafforzata sulversante sanzionatorio: l’art. 26 introduce nell’art. 171, comma 1, della legge d’autore la nuova letteraa-ter, che qualifica come illecito penale la riproduzione o estrazione di testo o dati in violazione degli artt. 70-tere 70-quater, anche mediante sistemi di IA.
La combinazione tra regola abilitante e presidio repressivo (171, a-ter) produce un effetto di chiusura del sistema: l’addestramento è lecito se e nella misura in cui rispetta i presupposti dell’accesso e dell’eventuale opt-out; in caso contrario, l’attività esce dall’alveo dell’eccezione ed è suscettibile di sanzione. In prospettiva applicativa, la Legge 132 sollecita prassi dicompliance by designnei contratti di licenza e neidataset governance frameworks, con clausole su fonti,opt-out, audit dei dati e responsabilità lungo la catena dei fornitori, così da assicurare che l’apporto creativo umano resti al centro della protezione e che l’uso massivo dei contenuti a fini di IA si svolga entro confini normativi chiari e verificabili.
Le nuove disposizioni penali della Legge 132/2025: l’articolo 26 e le modifiche al codice penale e alle leggi speciali
Nell’architettura della Legge 132/202, il Capo VI interviene sul versante sanzionatorio, introducendo di una nuova fattispecie incriminatrice, con l’innesto di circostanze aggravanti e aumenti sanzionatori in ambiti di particolare rilevanza.
Lanuova fattispecie di cui all’art. 612-quaterc.p.tipizza l’illecita diffusione di contenuti generati o alterati mediante sistemi di intelligenza artificiale. Si tratta di un reato plurioffensivo che tutela il diritto all’identità personale, all’onore e alla reputazione, la libertà di autodeterminazione comunicativa e, più in generale, l’affidabilità delle relazioni sociali e professionali.
La fattispecie richiede che taluno cagioni un danno ingiusto alla persona offesa diffondendo, senza il suo consenso, immagini, video o voci artificiosamente manipolati tramite IA e idonei a indurre in inganno sulla genuinità; le condotte tipiche sono alternative e comprendono la cessione a soggetti determinati, la pubblicazione in spazi accessibili a una pluralità indeterminata e la diffusione in qualsiasi forma.
La fattispecie è adolo generico, sicché è sufficiente la coscienza e volontà della condotta consapevole della manipolazione e della sua idoneità decettiva; non è richiesto lo specifico fine di nuocere oltre la produzione del danno, che può assumere anche natura non patrimoniale.
Laprocedibilitàè, di regola, a querela della persona offesa; si procede tuttavia d’ufficio quando il fatto è connesso a un delitto perseguibile d’ufficio, ovvero se commesso ai danni di persona incapace, per età o per infermità, o in pregiudizio di una pubblica autorità per ragioni di funzione. La collocazione sistematica accanto all’art. 612-terc.p. evidenzia la funzione di colmare un vuoto di tutela: mentre quest’ultimo presidia la circolazione non consensuale di contenuti sessualmente espliciti, il novello 612-quaterestende la protezione a ogni deepfake o contenuto manipolato idoneo a generare confusione sulla realtà dei fatti, indipendentemente dalla dimensione erotica del materiale.
La Legge 132 prosegue prevedendo una aggravante comune attraverso l’inserimento deln. 11-deciesall’art. 61c.p., destinata ad operare trasversalmente su qualsiasi fattispecie quando il reato sia commesso«mediante l’impiego di sistemi di intelligenza artificiale, quando gli stessi, per la loro natura o per le modalità di utilizzo, abbiano costituito mezzo insidioso, ovvero quando il loro impiego abbia comunque ostacolato la pubblica o la privata difesa, ovvero aggravato le conseguenze del reato».
L’aggravante richiede, dunque, un nesso qualificato tra l’uso dell’IA e l’aumento del disvalore del fatto: non è sufficiente una mera presenza tecnologica di contorno, ma occorre che l’algoritmo incrementi l’offensività (ad es. amplificando la diffusione, occultando l’identità dell’agente, elevando la verosimiglianza del falso). Ne discende un onere probatorio centrato sulla ricostruzione funzionale del ruolo dell’IA nella dinamica delittuosa e sull’accertamento del suo contributo causale alla maggiore pericolosità o all’ostacolo difensivo.
Accanto all’aggravante comune, l’art. 26 delle Legge 132 del 2025 prevede un inasprimento sanzionatorio per altre fattispecie di reato. Per l’art. 294 c.p. (attentati contro i diritti politici del cittadino) è prevista la reclusione da due a sei anni se l’inganno è realizzato con IA: il legislatore tutela così l’integrità del processo democratico, consapevole della capacità dei sistemi generativi di incidere sulla formazione della volontà politica.
Sul versante economico, le Legge 132 del 2025 ha modificato l’art. 2637 c.c. (aggiotaggio) aumentando la pena con reclusione da due a sette anni, quando l’illecito avvenga mediante IA, mentre l’art. 185, comma 1, TUF (manipolazione del mercato) contempla reclusione da due a sette anni e multa da 25.000 a 6.000.000 di euro in caso di uso dell’IA.
In tal modo la novella in esame vuole arginare il rischio di automazione del falso informativo, di scalabilità e di opacità degli strumenti, che amplificano gli effetti distorsivi sui mercati e impongono un trattamento sanzionatorio più severo.
Affidati a una consulenza legale qualificata in ambito AI
La Legge 132 segna una tappa fondamentale nel processo di costruzione di un “diritto dell’intelligenza artificiale” organico e coerente con i principi europei. Ne emerge un quadro di fonti stratificato e in crescenze sofisticazione.
Al cospetto di tali normative, imprese e PA debbono attentamente verificare la conformità dei propri processi decisionali e organizzativi e adotta strategie dicompliancenel breve termine.
In questo contesto, il nostro Studio Legale, attivo nei settori dell’intelligenza artificiale, della cybersicurezza e del diritto delle nuove tecnologie, offre supporto giuridico e strategico aimprese e start-upper l’adeguamento alle normative.
Contattaci per un confronto!
[Ai sensi dell’art. 70-quater della Legge 633/1941, ai fini della tutela del diritto d’autore, si dichiara che il presente contenuto è riservato, e ne è vietata la riproduzione o l’estrazione di testo, anche mediante sistemi di intelligenza artificiale].
