Managing Software Risks Under EU Product Safety Laws

MAJOR AI LEGAL NEWS. The revised EU Product Liability Directive came into force yesterday, 8 December 2024. It represents a fundamental shift in how liability for AI systems and software is addressed. The Directive could directly impact organisations using and developing AI, and they may wish to consider if they need to reassess their contracts, policies, and operational approaches to liability management. Under the new framework, AI system providers (treated as manufacturers in the legislation) are liable for defects in AI systems and software that cause harm, potentially including defects that emerge after deployment. This potentially includes harm linked to updates, upgrades, or the evolving behaviour of machine-learning systems. Organisations should also consider the liability implications for failing to have sufficient AI literacy among their staff which is a requirement under the AI Act from 2 February. AI training may now be a business imperative for some organisations. The Directive’s approach to defectiveness considers not only when a product is placed on the market but also whether the manufacturer retains control over it post-market, such as through updates or connected services. This means manufacturers may be held liable for defects that arise after deployment if they could reasonably foresee and mitigate risks but fail to act. Organisations, particularly those providing software or AI systems, should look at ongoing compliance and risk management to meet evolving safety expectations. The Directive's coverage of potential liability for post-market defects could have big implications for contracts. Organisations should consider whether their agreements with suppliers, integrators, and distributors include clear terms governing responsibility for defects. The focus is on whether the product provides the safety consumers are entitled to expect. A proactive approach to risk management, extending beyond initial product deployment to encompass ongoing updates and system monitoring may be prudent. Software providers should take note that they potentially could be held liable even if their product operates as a component of a larger system. This liability regime incentivises stronger warranties, indemnities, and cooperation agreements to allocate risk effectively across supply chains. Companies should review existing contracts to confirm they reflect the Directive's requirements and renegotiate where necessary to close gaps in accountability. The Directive also works in tandem with EU regulations like the AI Act. Businesses that fail to meet mandatory product safety requirements under the likes of the AI Act risk facing presumptions of defectiveness under the Product Liability Directive. With the AI Liability Directive in progress, organisations should also prepare for further changes that will make it easier for claimants to bring AI-related liability claims.

🚨 ATTENTION CISOs: The EU's New Product Liability Rules Just Changed Your Security Game Here's what's keeping me up at night about the new EU Product Liability Directive: • Your software is now legally a "product" - yes, including those AI systems and security patches you're pushing • Cybersecurity vulnerabilities = direct liability • The "it's too complex to explain" defense for AI systems? Gone. • 15-year liability period for defects (was 10) The kicker: You're on the hook for security vulnerabilities even AFTER deployment. 💭 Two major implications I'm seeing: 1. Security-by-design isn't just best practice anymore - it's a legal requirement 2. Your incident response playbook needs a major update 👉 Quick Question for my CISO network: How are you preparing your teams for this new reality where every security update could trigger liability? Particularly curious about documentation strategies for AI systems - drop your thoughts below. Note you can read the full law here: https://lnkd.in/eTaPiKmE For more cutting-edge cybersecurity insights, be sure to follow Team8 and me, Ross Young! #CISO #CyberSecurity #ProductLiability #AI #RiskManagement --- *Disclaimer: I am not a lawyer. Always consult your legal team for official guidance.*

⚠️Making AI Risk Management Practical for EU Business Leaders⚠️ Executives are asking a simple question. How do we meet the EU AI Act’s expectations on risk and impacts in a way that holds up to scrutiny? The Act requires a risk-management system for high-risk AI and sets concrete duties on providers and deployers. ➡️Start with governance structure #ISO42001 describes what an AI management system (#AIMS) looks like. It helps you assign accountable roles, set objectives for AI use, define controls, and review them on a cycle. Certification can provide external assurance that these governance processes exist and operate, but it is not a legal shortcut. You must still meet the Act’s requirements. ➡️Use an AI-specific risk process #ISO23894 adapts risk identification, analysis, and treatment to AI specifics like data quality, model behavior, drift, supplier and GPAI dependencies, and lifecycle change. It helps convert broad worries into ranked risks with treatments and owners. It is guidance, not a certification. ➡️Assess impacts through a structured lens #ISO42005 provides guidance for AI system impact assessments focused on people, groups, and society. It helps document foreseeable effects and mitigation across the lifecycle and aligns well with EU expectations to think beyond internal operational risk. It is guidance, not a presumption of conformity. ➡️Where a FRIA is mandatory Under Article 27, a fundamental-rights impact assessment must be completed before first use by deployers that are bodies governed by public law or private entities providing public services. It is also required for deployers using high-risk AI for credit-scoring and for life and health insurance risk and pricing. Results are notified to the market surveillance authority, and the #FRIA complements any #GDPR #DPIA. Application begins 2 August 2026. ➡️Provider and deployer duties to keep in view 🔸Providers of high-risk AI must implement a risk-management system, keep technical documentation, ensure data governance, provide instructions, and maintain a quality management system that supports conformity assessment. 🔸Deployers must use systems as instructed, assign human oversight, ensure input data is relevant, monitor operation, keep logs for at least six months, and inform workers before use. ➡️A practical sequence you can run now 1️⃣ Stand up the governance system so accountability, policies, and review exist and are auditable. ISO42001 is a solid blueprint for this. 2️⃣ Run an AI-specific risk process across the lifecycle using ISO23894 to identify, analyze, and treat risks tied to the intended purpose and context of use. 3️⃣ Perform an impact assessment using ISO42005 to capture stakeholder effects and mitigation. If you are in scope for a FRIA, complete it and notify the authority as required, making sure it complements any GDPR DPIA. A-LIGN Kevin Schawinski Modulos AG #TheBusinessofCompliance #ComplianceAlignedtoYou

I just published a new article on the EU Cyber Resilience Act (CRA) and what test and engineering teams need to start doing now to prepare for the first major deadline in September 2026. Security topics are consuming a significant portion of my time lately. What has impressed me most is how seriously companies across test, measurement, aerospace, automotive, and semiconductor industries are taking software supply chain risk. This is no longer a theoretical discussion. Teams are actively putting processes, tooling, and governance in place. One of the first major CRA milestones requires organizations to report actively exploited vulnerabilities within 24 hours. That requirement alone is changing how engineering organizations think about dependency visibility, vulnerability monitoring, and coordinated response workflows. If you are not yet familiar with the CRA, or you are trying to explain it internally to engineering or test teams, this article is designed to be a practical introduction. It outlines four concrete actions organizations can take now • Generate and maintain Software Bills of Materials (SBOMs) • Monitor vulnerability databases continuously • Establish clear vulnerability reporting channels • Build coordinated internal response workflows Security regulations are evolving quickly, and long lived engineering systems such as automated test platforms and LabVIEW based solutions are increasingly in scope. Organizations that begin preparing now will reduce compliance risk and build more resilient engineering infrastructure for the long term. You can read the full article here 👉 https://lnkd.in/d9xBeHyt I would be very interested to hear how your organization is preparing for CRA readiness. #CyberResilienceAct #SoftwareSecurity #SBOM #TestEngineering #LabVIEW #SupplyChainSecurity #EngineeringLeadership JKI