On December 9, 2026, EU Product Liability Directive (2024/2853) takes effect, officially classifying software and AI systems as products under European law and introducing strict liability for defects. There are important aspects you (as a partner or as a software developer) you need to know.
What is happening on December 9, 2026?
On December 9, 2026, new European rules about software come into effect. These rules say that software is now legally treated the same as any other product (like a toaster, a car, or a phone).
If your software causes damage or harm, you (the person or company who made it) can now be held responsible. This is a big change.
What kinds of software are affected?
ALL kinds. It doesn’t matter how users get your software:
• Installed on a computer;
• Downloaded from an app store;
• Used as a service (SaaS);
• Delivered through the cloud;
• Embedded in a device or machine;
• Artificial intelligence (AI) systems;
If it’s software, these new rules apply to it.
What does “defective software” mean?
Defective means the software doesn’t work as safely as people have a right to expect. This includes:
• Data loss or corruption (files disappearing or being damaged);
• Security breaches (hackers getting in because of security holes);
• Known security problems that haven’t been fixed;
• Missing or outdated security patches;
• Lack of proper security protection;
For example, if your software has a known security hole and you haven’t released a fix for it, that software is considered defective under these new rules.
Am I responsible even if I didn’t do anything wrong?
Yes. This is called “strict liability.” It means:
If your software causes damage, you are responsible, even if you didn’t intentionally cause it and even if you did your best to prevent it.
You can’t protect yourself by writing in your Terms of Service that you’re not responsible. Those warnings don’t matter legally anymore.
So what do I need to prove?
You don’t need to have perfect software. But you DO need to prove that you built and maintained your software professionally and carefully. This means showing evidence of:
1. Testing: You have proper testing processes. You check that new changes don’t break existing features.
2. Security updates: You find security problems quickly and release fixes fast.
3. Vulnerability management: You track security risks. You manage them properly.
4. Technical documentation: You document what your software does, how it works, and what its limitations are.
5. Records of decisions: You keep records showing what was tested, why changes were made, what problems were known.
Think of it this way: you need to show you built your software “reasonably securely” and that you maintained it properly over time.
What counts as damage?
Under these new rules, damage includes:
• Physical harm to people (injury, illness);
• Loss of money or property;
• Destroyed or corrupted data;
• Psychological harm (genuine emotional distress recognized by doctors);
Some real-world examples could be:
• Hospital software crashes and patient records are lost;
• Factory control software malfunctions and injures a worker;
• Banking software loses transaction records, causing business losses;
• Access management software fails and customer identity information is stolen;
Are there any exceptions?
Yes. Free and open-source software is exempt, BUT only if:
• It’s developed by volunteers (not paid);
• It’s distributed for free (not sold);
• It’s not part of a commercial activity;
If you offer support for the software, sell it as part of a package, or receive payment for it in any way, this exception doesn’t apply.
What should I do right now?
1. Look at your current software: which products might be affected by these rules?
2. Review your practices: do you have good testing? Do you manage security updates? Do you keep records?
3. Make a plan: figure out what you need to do to be ready by December 2026.
4. Document everything: write down your testing process, your security process, your update process.
5. Think about insurance: you may need product liability insurance for software.
The bottom line
These new European rules treat software like any other product. If your software causes harm, you are responsible. The good news: you don’t need perfect software. You just need to show that you developed it and maintained it professionally.
For companies that already have good practices for testing, security updates, and documentation, these rules just formalize what you’re already doing. For others, December 9, 2026 is your deadline to change.
Please note that this new regulatory (directive 2024/2853, full text here) applies to products placed on the market or put into service on or after 9 December 2026. Older products remain governed by the legacy 1985 directive (85/374/EEC).
Il 9 Dicembre 2026 entrerà in vigore la Direttiva UE sulla responsabilità per danno da prodotti difettosi (2024/2853), che classifica ufficialmente il software e i sistemi di IA come prodotti ai sensi del diritto europeo e introduce un regime di responsabilità oggettiva per i difetti. Vi sono aspetti importanti che è necessario conoscere (in qualità di partner o di sviluppatore di software).
Cosa succede il 9 Dicembre 2026?
Il 9 Dicembre 2026 entrano in vigore nuove regole europee sul software. Queste regole dicono che il software è ora legalmente trattato come qualsiasi altro prodotto (come un tostapane, un’auto o un telefono).
Se il tuo software causa danno o danno, tu (la persona o l’azienda che l’ha creato) puoi essere ritenuto responsabile. È un grande cambiamento.
Quali tipi di software sono interessati?
TUTTI. Non importa come gli utenti ottengono il tuo software:
• Installato su un computer;
• Scaricato da un app store;
• Utilizzato come servizio web (come Gmail o Microsoft 365);
• Fornito tramite il cloud;
• Incorporato in un dispositivo o una macchina;
• Sistemi di Intelligenza Artificiale (AI);
Se è software, queste nuove regole si applicano.
Cosa significa “software difettoso”?
Difettoso significa che il software non funziona con la sicurezza che le persone hanno il diritto di aspettarsi. Questo include:
• Perdita o corruzione dei dati (file che scompaiono o vengono danneggiati);
• Violazioni della sicurezza (hacker che entrano a causa di buchi di sicurezza);
• Problemi di sicurezza noti che non sono stati risolti;
• Patch di sicurezza mancanti o obsolete;
• Mancanza di protezione di sicurezza adeguata;
Ad esempio, se il tuo software ha un buco di sicurezza noto e non hai rilasciato una correzione, quel software è considerato difettoso secondo queste nuove regole.
Sono responsabile anche se non ho fatto nulla di sbagliato?
Sì. Questo si chiama “responsabilità oggettiva”. Significa:
Se il tuo software causa danno, sei responsabile, anche se non l’hai fatto intenzionalmente e anche se hai fatto del tuo meglio per prevenirlo.
Non puoi proteggerti scrivendo nei tuoi termini di servizio che non sei responsabile. Questi avvertimenti non contano più legalmente.
Allora cosa devo provare?
Non hai bisogno di software perfetto. Ma HAI bisogno di provare che hai costruito e mantenuto il tuo software in modo professionale e attento. Questo significa mostrare prove di:
1. Test: hai processi di test adeguati. Controlli che i nuovi cambiamenti non rompano le funzionalità esistenti.
2. Aggiornamenti di sicurezza: trovi i problemi di sicurezza velocemente e rilasci correzioni rapidamente.
3. Gestione delle vulnerabilità: tieni traccia dei rischi di sicurezza. Li gestisci correttamente.
4. Documentazione tecnica: documenti cosa fa il tuo software, come funziona e quali sono i suoi limiti.
5. Registri delle decisioni: mantieni registri che mostrano cosa è stato testato, perché i cambiamenti sono stati fatti, quali problemi erano noti.
Pensa a questo: devi mostrare di aver costruito il tuo software “ragionevolmente in modo sicuro” e di averlo mantenuto correttamente nel tempo.
Cosa conta come danno?
Secondo queste nuove regole, il danno include:
• Danno fisico alle persone (lesione, malattia);
• Perdita di denaro o proprietà;
• Dati distrutti o corrotti;
• Danno psicologico (angoscia emotiva genuina riconosciuta dai dottori);
Esempi reali possono essere:
• Il software ospedaliero si arresta e i cartelle cliniche dei pazienti vengono persi;
• Il software di controllo della fabbrica malfunziona e ferisce un lavoratore;
• Il software bancario perde i registri delle transazioni, causando perdite commerciali;
• Il software di gestione dell’accesso si guasta e le informazioni di identità del cliente vengono rubate;
Ci sono eccezioni?
Sì. Il software libero e open-source è esente, MA solo se:
• È sviluppato da volontari (non pagati);
• È distribuito gratuitamente (non venduto);
• Non fa parte di un’attività commerciale;
Se offri supporto per il software, lo vendi come parte di un pacchetto, o ricevi pagamento per esso in qualsiasi modo, questa eccezione non si applica.
Cosa devo fare adesso?
1. Guarda il tuo software attuale: quali prodotti potrebbero essere interessati da queste regole?
2. Rivedi le tue pratiche: hai buoni test? Gestisci gli aggiornamenti di sicurezza? Mantieni registri?
3. Fai un piano: capire cosa devi fare per essere pronto entro dicembre 2026.
4. Documenta tutto: scrivi il tuo processo di test, il tuo processo di sicurezza, il tuo processo di aggiornamento.
5. Pensa all’assicurazione: potresti aver bisogno dell’assicurazione sulla responsabilità del prodotto per il software.
Il punto importante
Queste nuove regole europee trattano il software come qualsiasi altro prodotto. Se il tuo software causa danno, sei responsabile. La buona notizia: non hai bisogno di software perfetto. Hai solo bisogno di mostrare che l’hai sviluppato e mantenuto in modo professionale.
Per le aziende che hanno già buone pratiche per i test, gli aggiornamenti di sicurezza e la documentazione, queste regole formalizzano solo quello che stai già facendo. Per gli altri, il 9 dicembre 2026 è la tua scadenza per cambiare.
P.S. questa nuova normativa (direttiva 2024/2853, testo completo qui) si applica ai prodotti immessi sul mercato o messi in servizio a partire dal 9 dicembre 2026. I prodotti precedenti rimangono disciplinati dalla direttiva del 1985 (85/374/CEE).
Stefano Demiliani 