What Article 12 high-risk AI systems require under the CRA
Article 12 high-risk AI systems is the provision that answers a practical question for manufacturers: if a product is both a product with digital elements under the Cyber Resilience Act and a high-risk AI system under the AI Act, can CRA Annex I compliance stand in for the AI Act cybersecurity requirement? Under Article 12(1) of Regulation (EU) 2024/2847, the answer is yes, provided two conditions hold. The product must meet Annex I Parts I and II of the CRA, and the EU declaration of conformity must demonstrate the level of protection that the AI Act's Article 15 cybersecurity requirement calls for. The provision exists so that a manufacturer does not run two parallel cybersecurity programs, each producing its own evidence for the same product. One risk assessment, one set of security properties and one vulnerability handling process can serve both regimes, as long as the evidence maps cleanly to both.
The difficulty lies in the second condition. Meeting Annex I Parts I and II is a test the manufacturer must document, not a label it can claim. Part I covers the product properties that the manufacturer's cybersecurity risk assessment shows are needed, and Part II covers the vulnerability handling process for the whole support period. The manufacturer then has to write the EU declaration so that it explicitly demonstrates the protection level the AI Act asks for. Teams should check early whether their declaration wording, technical documentation and AI risk management records say the same thing about the same controls. Gaps usually appear where the AI Act file describes model-level protections, such as data poisoning or adversarial robustness, that the CRA file does not address in product terms. Confirm with the competent authority or a notified body how they expect those model-level items to be documented.
Article 12(2) and 12(3) then determine which assessment route applies. Article 12(2) applies the AI Act Article 43 procedure, and AI Act notified bodies may also assess CRA Annex I if they assessed compliance with CRA Article 39 during their own notification. Article 12(3) sends important and critical products that are high-risk AI systems under AI Act internal control to the CRA conformity assessment procedures for the essential cybersecurity requirements. Before choosing a route, ask the conformity assessment body in writing which modules it will apply, whether its notification covers CRA Article 39, and what evidence it needs. For supervision, Article 52(14) of the CRA assigns market surveillance of these products to the authorities designated under the AI Act. Manufacturers that want to test their approach before filing can ask about participation in AI regulatory sandboxes under Article 57 of the AI Act, which Article 12(4) allows.
Which products and teams Article 12 high-risk AI systems applies to
Article 12 only applies when a product is both a product with digital elements under the Cyber Resilience Act and a high-risk AI system under the AI Act. Four scoping questions decide which conformity route and which teams carry the work, so answer them in writing before the technical file is started.
Is the product in CRA scope
Start with Article 2 scope. The product must be a product with digital elements made available on the EU market with a direct or indirect data connection, and it must not fall under a sector exclusion. Confirm this for the whole declared product, including firmware, companion apps and the hosted service it depends on, because the CRA treatment of remote data processing decides which of those parts the manufacturer must cover. Record the decision and its reasons in the technical documentation.
Is it a high-risk AI system
Check whether the product is a high-risk AI system under the AI Act, which depends on the intended purpose and the use case listed in that Regulation. Article 12 applies only when both tests are met. Legal and AI or ML engineering should agree the classification, and the file should show the intended purpose statement that supports it, since the same model can be high-risk in one product and out of scope in another.
Important or critical under the CRA
Establish whether the product sits in the default category, an Annex III class I or class II important category, or an Annex IV critical category. Under Article 12(2) and 12(3), important and critical products that are high-risk AI systems follow the CRA conformity assessment procedures for the essential requirements, so the category changes who must assess the product. Confirm the category against the Commission's technical descriptions before choosing a route.
Model, pipeline and cloud boundary
Decide whether the trained model, its training pipeline and the cloud backend that serves inference sit inside the declared product. Anything inside the product must meet Annex I Parts I and II, and the manufacturer carries the vulnerability handling duties for it. Document the boundary with a system diagram and a written rationale, because an assessor will test whether the declared product matches what is actually deployed.
Product security and AI engineering
Product security owns the Annex I risk assessment, secure development, vulnerability handling and the Article 14 reporting path. AI or ML engineering owns the model lineage, training data controls and the robustness evidence that the AI Act cybersecurity requirement relies on. These two teams must share one risk register, because a model weakness such as prompt injection is both a product vulnerability and an AI risk.
Quality, legal and third-party suppliers
Quality and compliance hold the conformity records, the EU declaration of conformity and the notified body relationship where one is required. Legal confirms the classification and contract terms. Third-party components, open-source libraries, model providers and hosting vendors all enter the product, so the team should list each supplier and ask for its security documentation and support period before the product is placed on the market.
Which conformity assessment procedure applies to an Article 12 product
Under Article 12(2), a product that is both a product with digital elements and a high-risk AI system follows the conformity assessment procedure set out in Article 43 of the AI Act. That procedure is the one the AI Act already applies to the AI system, so the CRA does not add a second assessment for the AI function. The cybersecurity part of the AI Act requirement is met through CRA Annex I, which the manufacturer must show through its technical documentation and EU declaration of conformity.
- Who decides the path: The manufacturer determines whether the AI Act Article 43 route applies to its system, based on the AI Act classification and the applicable procedure.
- Documentation scope: The technical file must show how Annex I Parts I and II are met, not only the AI Act Article 15 measures.
- Notified body involvement: Where Article 43 requires a notified body, that body assesses the AI system under the AI Act procedure.
- Declaration content: The EU declaration of conformity must demonstrate the required level of protection for the cybersecurity requirements.
Confirm with your AI Act advisor or notified body which Article 43 variant applies to your system before you map Annex I evidence to it.
Under Article 12(3), a high-risk AI system that is an important or critical product and that is subject to AI Act internal control follows the CRA conformity assessment procedures for the essential cybersecurity requirements. The CRA route therefore depends on the product's class under Annex III or Annex IV, not on the AI Act. Class II important products and critical products always need third-party assessment under the CRA, while class I products may use self-assessment only where harmonized standards are applied in full.
- Class I important products: Self-assessment under module A is possible only when the relevant harmonized standards, common specifications or certification schemes are applied in full.
- Class II important products: A notified body or an EU certificate is required.
- Critical products: The CRA requires third-party conformity assessment, with the applicable module set by the regulation.
- Class determination: The class comes from the product's core functionality, as described in the Commission's technical descriptions.
Check the Annex III or Annex IV category of your product against the current Commission technical description before you select a module.
An AI Act notified body may also assess conformity with CRA Annex I under Article 12(2), but only if its compliance with CRA Article 39 was assessed during its notification. A body that has not been notified under the CRA cannot issue CRA conformity findings on the strength of AI Act notification alone. Manufacturers should therefore ask prospective bodies for written confirmation of their CRA Article 39 status before engaging them.
- Dual scope: Confirm whether the body covers AI Act assessment, CRA Annex I assessment, or both.
- Notification evidence: Ask for the scope of its notification, including the CRA Article 39 assessment.
- Separate fees: Each assessment may be quoted separately, so request one scope covering both.
- Timing: Coordinate both assessments so that one set of technical evidence serves both files.
Ask the body to name the regulation and article under which each finding will be issued before work begins.
The manufacturer chooses and documents the conformity route, and the choice is then checked by the body that performs the assessment. Where the route is internal control, the manufacturer's own process produces the declaration, and where a notified body is required, the body issues findings that the manufacturer files. Neither DeployOpen nor any implementation partner issues a conformity assessment, certificate or declaration. Those are the manufacturer's responsibilities and the independent body's outputs.
- Manufacturer role: Owns the route decision, the technical documentation and the EU declaration of conformity.
- Notified body role: Performs the assessment where required and issues its own findings.
- Implementation partner role: Prepares systems, controls and evidence that support the file.
- Route record: Keep a dated memo showing the product class, AI Act procedure and CRA module chosen.
Record the route decision in the technical file before the first assessment and review it whenever the product or its classification changes.
How an assessor tests Article 12 compliance for a high-risk AI product
This table sets out how an assessor tests each element of the claim that CRA Annex I compliance satisfies the AI Act cybersecurity requirement for a high-risk AI product, the evidence requested and the findings that most often delay conformity. Read it as a checklist for your own file: if an element has no evidence that an assessor can trace to the product as placed on the market, expect a finding.
| Test element | What the assessor checks | Evidence requested and common findings |
|---|---|---|
| Risk assessment basis | Whether the manufacturer's cybersecurity risk assessment covers the AI-specific attack surface, including training data, model artifacts, prompts, tool connections and the serving path, and whether it drives the Annex I controls applied. | Risk assessment document with scope, threat model and traceability to controls. Finding: the assessment covers the application and infrastructure but omits model-level threats such as prompt injection or data poisoning. |
| Annex I Part I properties | Whether each applicable product property is implemented and verified for the whole product, including how the AI component inherits or adds to those properties. | Test records and configuration evidence per property. Finding: evidence covers only the user-facing application, not the model serving path or inference endpoints. |
| Annex I Part II vulnerability handling | Whether the process for identifying, documenting, remediating and disclosing vulnerabilities covers model components and third-party AI libraries across the support period. | Vulnerability handling procedure, component inventory, disclosure policy and records of handled issues. Finding: no process for vulnerabilities in model weights or inference frameworks. |
| EU declaration of conformity content | Whether the declaration identifies the product, the standards or specifications applied and the protection level the manufacturer claims to demonstrate under the AI Act requirement. | Signed declaration referencing the product version. Finding: the declaration does not state the level of protection, so the link to the AI Act requirement cannot be confirmed. |
| Technical documentation | Whether the file lets an independent body reproduce how each Annex I requirement was met for this exact product version, including the AI components. | Architecture diagrams, bill of materials, test reports and version history. Finding: documentation describes a different model or release than the one placed on the market. |
| Model serving and runtime path | Whether the evidence follows the request from the client through the gateway, model server, retrieval and tool layers to logs and updates. | Network and access configuration, logging samples and update records. Finding: the path is untested or excluded from scope, which is the most frequent gap for AI products. |
| Scope and conformity route | Whether the product's classification and the assessment body are consistent with the AI Act procedure that applies. | Written scope statement and notified body documentation where used. Confirm the route with the authority and assessment body before the file is closed. |
How to implement Article 12 compliance step by step
The sequence confirms which legal routes apply, turns the AI Act and CRA cybersecurity expectations into one set of product requirements, and ends with evidence an assessor can test and a conformity route an independent body can sign off where required.
Confirm the dual classification of the product
Establish first whether the product is a product with digital elements under the CRA and whether it is a high-risk AI system under the AI Act. Check the product's intended purpose against the AI Act high-risk categories, and check its core functionality against the CRA Annex III and Annex IV categories, since the class decides which conformity route applies later. The organization owns this decision, and legal counsel should confirm it where the boundary is unclear. The output is a written classification memo listing both determinations, the reasoning and the version of the product it covers.
Map AI Act Article 15 expectations to Annex I
Read the AI Act cybersecurity expectations in Article 15 next to CRA Annex I Part I and Part II, and record where each AI-specific expectation, such as resilience against attempts to manipulate model behavior, is covered by a CRA essential requirement and where a gap remains. Article 12(1) only deems compliance where Annex I Parts I and II are met and the EU declaration of conformity shows the required protection, so the mapping must be complete before any claim is made. The output is a traceability matrix that an assessor can follow from each AI Act requirement to a named CRA requirement and a named piece of evidence.
Run the manufacturer cybersecurity risk assessment
Document the cybersecurity risk assessment that drives the Annex I Part I requirements, covering intended use, reasonably foreseeable misuse, the AI-specific attack surface such as prompt injection, data leakage and model supply chain exposure, and the lifecycle and support period. The manufacturer runs this assessment and signs it off internally, and an implementation partner can facilitate the workshops and test the findings. The output is a versioned risk register with risk ratings, selected controls and documented residual risk that links to the traceability matrix.
Build the security properties and testing evidence
Implement the product properties the risk assessment requires, such as secure defaults, access control, data protection, logging, integrity of updates and resilience against attacks. For AI components, test model and agent behavior with adversarial probes and keep the outputs as evidence. Open-source tools such as garak can produce JSONL reports of probe attempts and a hit log of vulnerabilities found, and Langfuse traces can show runtime operations for logging evidence, but each tool must be confirmed against the specific product and its configuration. The output is a test plan, test results and a remediation record tied to each risk.
Establish the Annex I Part II vulnerability processes
Set up the processes that Annex I Part II requires for the whole support period, including coordinated vulnerability disclosure, component tracking through a software bill of materials, security update distribution and a point of contact for reporting. Assign owners for each process and rehearse the Article 14 reporting path through ENISA's Single Reporting Platform for actively exploited vulnerabilities and severe incidents, which has applied to manufacturers since 11 September 2026. The output is a written vulnerability handling procedure, an SBOM for each release, and a record of at least one tested disclosure workflow.
Prepare technical documentation and the EU declaration
Assemble the technical documentation that both regimes require, combining the AI Act technical file with the CRA material on risk assessment, security properties, vulnerability handling and support periods, so that one set of records serves both assessments. Draft the EU declaration of conformity only after the earlier steps are complete, and check that it covers both the AI Act and CRA obligations that apply to the product. Legal and compliance staff own the declaration and the organization signs it. The output is a single indexed technical file and a signed declaration that cites the exact product version.
Select the conformity route and the authorized body
Confirm the conformity assessment procedure that applies under Article 12(2) and Article 12(3), which depends on whether the product is an important or critical product and whether it uses internal control under the AI Act. Where a notified body is required, confirm that it is notified for the relevant assessment under the CRA and AI Act and listed in the Commission's NANDO system before engaging it. Ask the body for its scope statement and a written plan. The output is a documented route decision, a signed engagement with the body and a list of the evidence it will sample. Only the independent body issues the conformity assessment outcome, and DeployOpen prepares the evidence but does not certify the product.
Evidence that satisfies the Article 12 high-risk AI systems requirement
Article 12 treats a product as meeting the AI Act cybersecurity requirement only when its CRA Annex I compliance is demonstrated through documents and records. The six artifacts below form that body of evidence, and each one must be kept current against the product as placed on the market and as later modified.
Cybersecurity risk assessment
This is the manufacturer's written analysis of the product's threats, intended use and foreseeable misuse, and it drives which Annex I Part I requirements apply and how. For a product that is also a high-risk AI system, the assessment should cover model-specific threats such as data poisoning, prompt injection and model extraction, not only the software stack. Review it whenever the model, its training data source, its connected tools or its deployment environment changes, and record the date and reason for each revision.
Annex I Part I property mapping
This mapping traces each applicable point of Annex I Part I, the general requirement and points (2)(a) to (m), to the design decision, configuration and test result that meets it. Keep one row per requirement with an owner and a link to the evidence file. Re-check the mapping when the risk assessment changes, and mark requirements that do not apply with a written justification so an assessor can follow the reasoning.
Vulnerability handling process records
Annex I Part II sets the process requirements for the whole support period, and the records show that the process runs in practice. Keep the coordinated vulnerability disclosure policy, the vulnerability log with triage and fix dates, SBOM versions per release and the advisories issued to users. Confirm with your notified body or market surveillance authority which records they expect, and confirm how the Article 14 reporting duty fits your existing incident process.
Technical documentation and EU declaration of conformity
The technical documentation describes the product, its design, its development and its operation, and the EU declaration of conformity states that the product meets the applicable requirements. For Article 12 purposes, the file should cross-reference the AI Act technical documentation so one set of facts supports both regimes. Version the file against each release, keep the declaration tied to the product version it covers, and update both when a substantial modification occurs.
AI model and pipeline security test records
These records show that the model and its surrounding pipeline were tested against the threats in the risk assessment. Keep the test plan, the scope covering training data, model artifacts, inference endpoints and tool integrations, and the results of each run. Open-source probes such as garak write a JSONL report of every attempt plus a hit log of successful attacks, which can be archived with the release it tested. Rerun the suite after each model update, retraining or change to system prompts or connected tools.
Operational logs and traces
Logs show that the system behaves as documented after it has been placed on the market, including authentication events, model version identifiers, tool executions and anomalous inputs. Langfuse-style traces capture inputs, outputs, timing and metadata for each request, which supports incident investigation and post-market monitoring. Confirm retention periods with your legal team, protect logs that contain personal data under the GDPR, and make sure each trace records the model version so evidence can be tied to a specific release.
What meeting Article 12 costs in money and effort
This table compares the cost components of meeting Article 12 for a product that is both a CRA product and a high-risk AI system, with who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to structure a quote request, since no price figures are supplied here and each cost depends on the written scope.
| Cost component | One-time or recurring, and who is paid | Main cost drivers and what to ask for in a quote |
|---|---|---|
| Engineering for Annex I Parts I and II | One-time build, then recurring upkeep. Paid to internal engineers or an implementation partner preparing secure-by-design properties and vulnerability handling processes. | Number of product variants and AI components in scope. Ask for a named list of Annex I properties covered and which are already met by the platform. |
| AI-specific security testing | Recurring, with a larger first pass. Paid to a security testing provider for model and agent probing, such as prompt injection and data leakage checks. | Number of AI models, agents and tool integrations. Ask for test scope, attack categories, report formats and retest rules. |
| Tooling and licenses | Mostly recurring. Paid to commercial vendors for scanning, logging or testing products; self-hosted open source can remove most license spend, though support contracts may remain. | Choice between commercial and open-source tools and hosting. Ask whether licenses, support tiers and hosting are itemized separately. |
| Evidence upkeep and logging | Recurring. Internal staff time and infrastructure for keeping technical documentation, test reports and traces current across releases. | Release frequency and retention periods. Ask how evidence is versioned and who maintains it after handover. |
| External testing or review | Recurring at each significant change. Paid to independent testers or reviewers, separate from any certification body. | Attack surface and number of product releases. Ask whether retests after fixes are included in the fixed price. |
| Notified or authorized body fees | One-time per assessment, plus costs for re-assessment after substantial change. Paid to the body that issues the certificate, only where a route requires it. | Whether the product is high-risk AI under the AI Act and which assessment route applies. Confirm the route and the body's fee schedule in writing before scoping. |
| Internal effort for the EU declaration of conformity | One-time for the first declaration, then recurring at each update. Carried by the manufacturer's legal, compliance and product teams. | Number of applicable legal regimes, such as the AI Act and CRA, that must be cross-referenced. Ask the partner which parts of the declaration they draft and which the manufacturer must sign off. |
How open-source tools support the AI-specific evidence
Open-source tools can generate part of the AI-specific evidence that a manufacturer needs when a product is both a product with digital elements and a high-risk AI system, but they produce records, not compliance decisions. The first tool to consider is garak, licensed under Apache-2.0, which probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. It writes a JSONL report covering every attempt and evaluation, plus a hit log listing the attempts that found a vulnerability. Those files can support the testing narrative behind the Article 15 cybersecurity requirement that Article 12(1) refers to, provided you keep the run configuration, model version and date with each report so an assessor can reproduce the result.
The second tool is *Langfuse*, licensed under MIT, which records traces of each request. A trace captures LLM calls, retrieval steps, tool executions and custom logic, along with timing, inputs, outputs, token usage and metadata. For an AI component that calls tools or external data sources, these traces show how the system behaved in operation and can help you detect misuse or anomalous behavior after release. Confirm that your logging design avoids storing personal data or secrets in traces, because the trace store becomes an asset you must protect and document.
Neither tool satisfies Annex I on its own, and neither replaces the EU declaration of conformity or the conformity assessment route that applies under Article 12(2) and 12(3). Before you rely on either tool, confirm its coverage against your own threat model: check which attack classes garak's probes exercise for your model and deployment, and which operational events Langfuse captures for your architecture, including any gaps in tool execution or retrieval logging. Record those decisions in your technical documentation and treat the outputs as inputs to your risk assessment, with an independent assessor deciding whether the evidence is sufficient.
Who does what: your team, an implementation partner and the assessor
Your organization remains the manufacturer or provider in law. Under Article 12, a product that is both a product with digital elements and a high-risk AI system has to meet the Annex I requirements, and the EU declaration of conformity must show the required level of protection. That declaration, the risk assessment and the decision to place the product on the market sit with your team and cannot be delegated.
- Product and risk assessment: Your engineers define the product, its intended use and the cybersecurity risks that follow from them, and record how each Annex I requirement is addressed.
- EU declaration of conformity: Only the manufacturer signs it, and it must be consistent with the technical file that supports it.
- Conformity decision: Your accountable executive decides whether the product meets the requirements and can be placed on the market.
- Ongoing vulnerability handling: Support periods, updates and Article 14 reporting remain your duties after launch.
- Technical documentation: Your team owns the final version of the documentation that the assessor reviews.
Before you engage anyone, confirm internally who holds each of these decisions and who can sign for the organization.
An implementation partner such as DeployOpen works inside your environment to prepare systems, test records and evidence. The partner does the operational groundwork that makes your decisions defensible. It does not decide conformity, sign declarations or issue certificates on your behalf.
- Systems and logging: Partners configure hardening, access controls, update mechanisms and logging so that the evidence your team relies on exists and is retained.
- Security testing: Partners can run application, infrastructure and AI system security testing, including probing language model systems with tools such as garak, and record the results.
- Evidence packs and drafts: Partners assemble test records, logs, configuration baselines and documentation drafts for your review.
- Traceability: Partners map evidence to each Annex I requirement so that your team and the assessor can follow the chain.
- Independence line: The partner never issues the certificate, the attestation or the declaration on the manufacturer's behalf.
Ask any partner to state in writing which deliverables are drafts for your approval and which decisions remain yours.
The conformity assessment outcome comes from a notified body or another independent body that the applicable procedure allows. For high-risk AI systems that are also products with digital elements, the route depends on the classification and the procedure that the AI Act and the CRA set out, and your team should confirm which body applies. The assessor reviews the evidence independently and reaches its own conclusion.
- Independent review: The assessor tests the technical file, the risk assessment and the evidence against the requirements.
- Assessment outcome: The notified or authorized body issues the outcome that the procedure requires, not the implementation partner.
- Notified body scope: Confirm whether the body's notification covers CRA Annex I as well as the AI Act procedure.
- Independence: A body that helped build the system typically cannot also assess it, so keep the assessor separate from implementation work.
- Market surveillance: National authorities designated under the AI Act supervise these products after they reach the market.
Before you select a body, ask it to confirm its notification scope and how it handles conflicts of interest with partners you have engaged.
Outsourcing and in-house work are not the same thing as shared responsibility. Some tasks can be bought in with little risk to the conformity decision. Others must remain with your organization because the law places them there. Clear allocation prevents gaps where each party assumes another has checked a requirement.
- Usually outsourced: Security testing, hardening work, log configuration, evidence collection and drafting of supporting documentation.
- Usually outsourced to the assessor: The independent conformity assessment itself, which only a body independent of your team can provide.
- Must stay in-house: The risk assessment, the EU declaration of conformity, the conformity decision and the accountable signature.
- Shared with review: Technical documentation, where partners draft and your team approves and owns the final text.
- Ongoing: Vulnerability handling and reporting after release, which you may support with a retainer but must be able to run yourself.
Before signing any scope, confirm in writing which of these tasks the partner performs and which your team retains.
Questions buyers ask about Article 12 high-risk AI systems
What does meeting Article 12 require from our own staff?
Your own staff must own the decisions that the regulation places on the manufacturer: the cybersecurity risk assessment, the choice of which Annex I requirements apply, the EU declaration of conformity, and the technical documentation that supports them. Engineering staff must be able to show how the AI system's components, updates and vulnerability handling work in practice, and a named person must be accountable for the process. An implementation partner can prepare systems and evidence, but it cannot take over these decisions or sign the declaration on your behalf.
Can our in-house team handle Article 12 without outside help?
Yes, an in-house team can do the work if it has security engineering capacity, documentation discipline and a clear understanding of both the CRA Annex I requirements and the AI Act Article 15 cybersecurity requirements. The gaps usually appear in evidence collection across the support period, in vulnerability handling procedures, and in demonstrating conformity assessment readiness to a notified body where one is required. Independent assessment is still needed where the route requires it, and only the assessor issues the resulting report or certificate. Ask whether your team has done a comparable conformity exercise before deciding how much outside help to buy.
How long does Article 12 work take, and what drives the timeline?
The timeline depends on the product's current maturity, the number of Annex I requirements that need new engineering work, the size of the AI system's component inventory, and whether a notified body must assess the product. Other drivers include how far the harmonized standards are in force for your product category, how many components depend on third parties, and how quickly your team can produce documentation. The regulation's application dates are set in the researched facts for the CRA, and the timing of harmonized standards should be checked with the Commission before planning. Ask any partner to break its written scope into phases with dependencies, rather than quoting a single overall duration.
Which authority supervises an Article 12 product?
Market surveillance of CRA products that are high-risk AI systems is assigned to the authorities designated under the AI Act, under Article 52(14) of the CRA. The national market surveillance authorities enforce the CRA more generally, but for these products the AI Act designation governs supervision. Member States designate these authorities, so confirm which body is responsible in each market where you place the product. Check the Article 52 text on EUR-Lex for the exact wording before relying on it in your compliance documentation.
Are AI regulatory sandboxes open to manufacturers of these products?
Yes, Article 12(4) allows manufacturers of these products to take part in AI regulatory sandboxes under Article 57 of the AI Act. Participation is a route to test compliance approaches with the supervising authority before market placement, and it does not replace conformity assessment. Confirm with the relevant national authority whether a sandbox is open, what eligibility applies, and what it would require from your staff. Plan for the sandbox as an optional input to your compliance work, not a required step.
What are the Article 64 fine ceilings, and how do they apply?
Article 64 sets maximum administrative fines of EUR 15 million or 2.5% of total worldwide annual turnover for breaches of Annex I and Articles 13 and 14, whichever is higher. Other listed obligations carry a ceiling of EUR 10 million or 2%, and incorrect or misleading information given to authorities carries EUR 5 million or 1%, again whichever is higher. These are maximums set by the regulation, and actual fines depend on the authority's assessment of the breach. Treat them as the reason to fund documentation and vulnerability handling properly rather than as a forecast of exposure.
What should we ask an implementation partner for in a written scope?
Ask the partner to state, in writing, which products and AI system components are in scope, which Annex I Part I and Part II requirements it will prepare evidence for, and which deliverables you will receive. The scope should name what is one-time work, such as the risk assessment and technical documentation, and what recurs, such as vulnerability handling and support-period evidence. Also request the responsibility split between your staff, the partner and the independent assessor, the assumptions about your environment, the acceptance criteria for each deliverable, and the handover format. Confirm how changes to scope are priced and approved before work starts.
How DeployOpen prepares Article 12 evidence for your products
DeployOpen helps organizations prepare the systems, controls and evidence that support Article 12 conformity for products that are both CRA products with digital elements and high-risk AI systems. DeployOpen does not issue declarations or certificates. Your organization owns the declaration, and an independent notified body or assessor issues any certificate that the chosen route requires.
How we scope
- Confirm which of your products are CRA products with digital elements and which are high-risk AI systems under the AI Act.
- Map each product's Annex I Parts I and II requirements to the systems, components and teams that must provide evidence.
- Agree the conformity route with your counsel or notified body before work starts, since class and AI Act procedure decide the path.
- Record the agreed scope, deliverables and timelines in writing before any work begins, as every engagement is fixed-scope.
How we build
- Implement the logging, access, update and vulnerability handling controls your scoped products need inside your own infrastructure.
- Configure open-source tooling for AI red teaming, such as garak, and trace logging, such as Langfuse, where your architecture supports them.
- Test the products against the scoped requirements and record results, gaps and the remediation owner for each finding.
- Keep configuration and build changes under version control so each release can be traced to its security evidence.
How we hand over
- Prepare technical documentation that describes the product, its risk assessment and how each Annex I requirement is met.
- Deliver evidence packs that show test outputs, configuration baselines and logs your assessor can review directly.
- Document the roles your organization keeps, including the declaration of conformity, which only your organization can sign.
- Transfer runbooks and ownership so your staff can produce the same evidence after the engagement ends.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped in writing.
- Review evidence again when a product is substantially modified or a harmonized standard changes your requirements.
- Confirm with your notified body or market surveillance authority which evidence format and retention period they expect.
- Ask for a quote based on the written scope, since DeployOpen does not publish a price list.
