Over the past two years, artificial intelligence has evolved from a buzzword into a key business asset. It has become a de facto prerequisite for funding, serves as a marketing argument (AI washing), and is a reason for the retrofitted "AI-ification" of applications that would have worked just as well without it. What gets lost in the process are the significant cybersecurity risks associated with AI models and the reporting obligations under the Cyber Resilience Act (CRA), which will apply from 11 September 2026.
Integrating AI into a product has never been easier. This can be done either through a provider's commercial API or using a publicly available open-source model. Both have advantages and disadvantages, but the choice has little impact on the legal implications. Any business that integrates an AI model into its own product and places that product on the market under its own name is considered a manufacturer under the CRA. If an existing product on the market is substantially modified, for which fine-tuning serves as a strong indicator, this is treated as equivalent to being a manufacturer. In both scenarios, the same set of obligations applies.
The risk scenario is no longer theoretical
On one of the largest repositories for open AI models, security researchers found around 100 models that automatically execute malicious code when loaded, thereby allowing attackers remote access to the affected system. The scanning partner engaged by the platform itself reported around 350,000 unsafe or suspicious findings across all models examined. And the platform’s scanners can be bypassed: With the "nullifAI" technique, a deviating compression format is enough to avoid being flagged as suspicious. Anyone who integrates such a model without checking it is importing the vulnerability into their own product.
Commercial providers shift this risk; they do not eliminate it. There, the vulnerability typically does not arise within the model, but rather in its integration. Anyone who uses a model to process documents, emails or web content exposes it to indirect prompt injection – manipulated content is read as an instruction and triggers data exfiltration or unwanted tool calls. Added to this are factors beyond one’s control: model version, behaviour and availability. A provider update can alter product's security assumptions overnight, and the provider itself is a rewarding target for attack.
Mandatory obligations under the CRA
The CRA will be fully applicable as of11. December 2027: risk assessment, secure-by-design requirements, vulnerability management throughout the entire support period, technical documentation, SBOM (in practice presumably an ML-BOM as well) and CE marking. For third-party components, particularly open-source, a due diligence obligation of its own applies as the manufacturer is liable for them as for its own software.
However, the reporting obligations for actively exploited vulnerabilities and severe security incidents will take effect as early as September 11, 2026. This means an early warning within 24 hours, a detailed notification within 72 hours, and a final report within 14 days. As soon as you become aware of something, the clock is running.
Non-compliance may result in penalties of up to EUR 15 million or 2.5% of global annual turnover.
Three questions businesses should ask themselves
- Which AI models are running in your products – from what source, and in what version?
- Have you modified any of them or integrated them into an existing product?
- Who reports at 3:00 a.m. on a Sunday – to whom, and with what content?
The deadline for the reporting obligations under the CRA is imminent, which is why an early review will help identify risks and implement necessary adjustments in a timely manner.In a compact CRA check, our team is happy to work with you on what needs to be done now.
For inquiries, please contact our CMS team.
