What Article 55 requires of providers of systemic-risk AI models
If your general-purpose AI model is classified as having systemic risk, Article 55 adds four duties on top of the documentation, copyright, summary and representative duties in Articles 53 and 54. You must evaluate the model with standardized, state-of-the-art protocols that include documented adversarial testing, and you must assess and mitigate systemic risks at Union level. The baseline duties still apply in full, so Article 55 is an extension of your existing file, not a replacement for it. Each extra duty answers a specific failure mode. Adversarial evaluation catches dangerous capabilities that standard benchmarks miss, such as cyber-offense uplift or misuse under jailbreak pressure. Union-level risk assessment addresses harms that spread across member states and sectors, which a single national deployment would never reveal. Serious incident tracking and reporting to the AI Office addresses slow reaction, since the Act expects you to log incidents and corrective measures and report them without undue delay. The cybersecurity duty covers attacks on the model weights, the training and serving infrastructure, and the physical systems that host them.
The difficulty is that these duties sit across three teams that rarely share tooling. Evaluation belongs to research and safety teams, cybersecurity belongs to security operations, and incident reporting and the file to the AI Office belong to legal and compliance. A practical first step is to name one owner for each duty and agree how a finding from an evaluation run becomes a tracked risk, a mitigation, and, where it qualifies, a report. Confirm with the AI Office and the Commission's published guidance how they expect reports and documentation to be submitted, because the procedure is not something this section can settle for you.
Which models, teams and infrastructure Article 55 reaches
Article 55 applies only after several scoping decisions are settled: whether a model has systemic risk, where the provider is established, how adapted models are treated, and where weights and training runs live. Each card below is a decision or component that changes the evidence an assessor will ask for.
Systemic risk classification
Article 55 duties attach only to a general-purpose AI model classified as having systemic risk, so the first decision is whether the model falls in that class. The classification rules, presumption and designation process are covered on the sibling classification page. Confirm the classification status in writing for each model version you place on the EU market, because the duties follow the classification, not the model name.
EU establishment and market placement
The Act reaches providers placing a model on the EU market wherever they are established, so a non-EU provider cannot avoid Article 55 by hosting outside the Union. Map each model release to a market placement event, including API access offered to EU customers. Where the provider is not established in the EU, the authorised representative duties on the sibling Article 54 page also apply.
Fine-tuned and adapted models
A downstream party that modifies a model can become its provider, which changes who carries the Article 55 duties. Document every fine-tuning, alignment or adaptation step, because Annex XI requires records of model adaptations and their effect on evaluation. Ask each partner and customer whether their change crosses the threshold for becoming a provider, and record the answer in the model file.
Internal teams holding the model
Article 55 evidence comes from several teams: training and research staff who own the weights, evaluation and red team staff who run adversarial tests, security staff who run the cybersecurity controls, and legal or policy staff who file incident reports. Name an accountable owner for each duty and record who can access the weights, checkpoints and training logs. Gaps between these teams are where incident reports and evaluation records most often go missing.
Cloud and data center environments
The weights, checkpoints and training clusters may sit in your own data center, a public cloud account or a colocation facility. Each environment is part of the physical infrastructure that Article 55 requires you to secure, so each must appear in the cybersecurity scope. Confirm which regions, accounts and storage buckets hold copies of the weights, because backups and snapshots are often forgotten.
Third-party hosting and cloud providers
Hosting providers, managed GPU services and model serving platforms run infrastructure that the provider relies on to meet its duties, so they are in scope for assessment. Obtain their security documentation, incident notification terms and access logs, and check that contracts let you produce evidence on request. Confirm in writing which parts of the cybersecurity and incident duties each third party performs and which remain yours.
What state-of-the-art evaluation and adversarial testing must show
For a provider of a model with systemic risk, the evaluation duty in Article 55(1)(a) means running the model against standardized, state-of-the-art evaluation protocols, including documented adversarial testing such as red teaming, and then using those results in a systemic risk assessment at Union level under Article 55(1)(b). The provider owns this duty. An implementation partner can build the test harness, run the probes and keep the records, but the conclusions about whether the model is safe enough to place on the market are the provider's to reach and defend. Start by confirming which protocols your evaluation team treats as the current standard, and record why each was chosen, since an assessor will ask. Annex XI Section 2 sets the documentation baseline. It asks for the evaluation strategy and its results, any internal or external adversarial testing (red teaming included), the model adaptations such as alignment and fine-tuning, and the system architecture. In practice, the test log alone does not satisfy this. A file that shows a passing score but not the threat models, the probe selection, the excluded attack classes and the reasons for those exclusions leaves the reader unable to judge coverage. Documenting the reasoning behind test choices matters as much as the results, because it lets an assessor see whether the testing matched the risks the provider identified for its own model.
The Commission's Safety and Security chapter of the GPAI Code of Practice applies only to providers of models with systemic risk under Article 55, so it is the natural reference for building this evidence. Article 55(2) allows these providers to rely on codes of practice until a harmonised standard is published, or to show alternative adequate means of compliance. Decide early whether you will use the code as your route and, if you choose another route, document how it reaches an equivalent level. Confirm the current status of the code and of any harmonised standard with the AI Office and the official sources before you fix your compliance plan, because both are moving parts of the framework.
How an assessor tests Article 55 compliance
This table compares each Article 55 duty against the test approach an assessor is likely to take, the evidence requested and the findings that appear most often. Read it as a preparation checklist: if a row's evidence does not exist yet, the provider has a gap to close before an assessment. The assessing body is the AI Office for general-purpose AI model rules, or an independent auditor where the provider commissions a voluntary assessment.
| Duty | Assessor test approach and evidence requested | Common findings |
|---|---|---|
| Evaluation with standardized protocols and adversarial testing (Art. 55(1)(a) and (b)) | Document review of evaluation protocols, then a walkthrough of how the evaluation process runs. Sampling of test runs against the documented protocol. Evidence: protocols, adversarial test reports, and records of internal or external red teaming. | Protocols are not standardized across model versions. Adversarial testing is undocumented or cannot be reproduced from the records kept. |
| Union-level systemic risk assessment and mitigation (Art. 55(1)(b)) | Review of the risk assessment method and its outputs, then sampling of mitigation decisions to confirm each identified risk has a documented response. Evidence: risk assessment records, mitigation plans, and sign-off history. | Risk assessments describe risks in general terms with no link to evaluation results. Mitigations are recorded without an owner or a review date. |
| Serious incident tracking and reporting (Art. 55(1)(c)) | Incident drill: the assessor picks a hypothetical serious incident and asks the provider to show detection, classification, internal escalation and the report to the AI Office. Evidence: incident logs, reporting records, timestamps and corrective-action records. | No defined path to the AI Office. Incident definitions are not agreed with downstream providers, so the team cannot tell when a report is due. |
| Corrective measures (Art. 55(1)(c)) | Sampling of closed incidents to confirm each corrective measure was implemented and checked for effect. Evidence: corrective-action tickets, change records and verification results. | Corrective actions are closed without evidence of verification. Links between incidents and model changes are missing. |
| Cybersecurity of the model and its infrastructure (Art. 55(1)(d)) | Security architecture review of model weights storage, training and serving environments, followed by a sample check of access records. Evidence: architecture diagrams, access control lists, authentication logs and vulnerability management records. | Model weights are accessible to more people than the access policy allows. Serving infrastructure is not covered by the same controls as the rest of the environment. |
| Reliance on codes of practice or alternative means (Art. 55(2)) | Review of how the provider chose its route and whether the chosen route covers each Article 55 duty. Evidence: adherence records, gap analysis, and any documented alternative means of compliance. | Provider claims code of practice adherence without mapping each commitment to a duty. Alternative means are asserted without supporting evidence. |
How to implement Article 55 in sequence
The sequence below takes a provider from confirming that a general-purpose AI model carries systemic risk to a documented, testable set of Article 55 controls that the provider can show to the AI Office.
Confirm systemic-risk status and duty owners
Start by establishing whether each model you place on the EU market is a model with systemic risk under Article 55, and whether the Commission has designated it. Record the basis for that conclusion, then name one accountable owner for each Article 55 duty: evaluation, systemic risk assessment, incident reporting and cybersecurity. Output: a classification memo signed by the accountable executive, plus a duty-owner register that lists each owner, backup and reporting line. The step is done when every duty has a named owner and the classification basis can be traced to the model's compute and designation records.
Define the evaluation protocol and adversarial testing program
Write an evaluation protocol that sets out the standardized, state-of-the-art tests you will run before release and after material changes, and state which adversarial testing methods you will use, such as red teaming. Assign who designs, runs and signs off the tests, and whether internal or external testers will be used. Tools such as garak can produce a JSONL record of every probe attempt and a hit log of successful attempts, which helps document results. Output: a versioned evaluation strategy, a test catalogue with pass criteria, and a first set of results. The step is done when a reviewer outside the test team can reproduce the results from the recorded configuration.
Set up the Union-level systemic risk register
Identify the systemic risks your model could pose at Union level, assess how likely and how severe each one is, and record the mitigations you have chosen and why. Keep the register as a living document with an owner, a review trigger and a link to the evaluation results that support each entry. Output: a systemic risk assessment report and a mitigation register that maps each identified risk to its test evidence, its mitigation and its residual risk decision. The step is done when every risk has a documented decision and an owner who has accepted it.
Build incident detection, case handling and AI Office reporting
Define what counts as a serious incident for your model, how staff detect it and how it moves into a tracked case. Route alerts from monitoring sources into cases, record every corrective measure, and keep an audit trail of evidence and decisions. Tracing tools such as Langfuse can record inputs, outputs and tool calls for each request, which supports reconstruction. Output: an incident procedure, a case record template and a reporting checklist for the AI Office, with the time each step is expected to take set internally. The step is done when a tabletop exercise produces a complete case record and a draft report without gaps.
Harden model weights, training pipeline and serving infrastructure
Apply cybersecurity controls to the model artifacts, the training pipeline and the serving stack, covering access to weights, secrets, build systems, logging and network segmentation. Test these controls against the threats you identified in the systemic risk register, including theft of weights and tampering with training data. Output: a security baseline for each asset, a access review record, and a test report from an independent tester. The step is done when every control has an owner, evidence of operation and a recorded test result.
Assemble the technical documentation pack
Gather the evaluation strategies and results, adversarial testing records, model adaptations such as alignment and fine-tuning, and system architecture into one documentation pack that follows the structure of Annex XI Section 2. Cross-check each section against the evidence produced in the earlier steps and record the version of the model each entry describes. Output: a versioned technical documentation pack with an index, a change log and a sign-off record. The step is done when an assessor can trace each claim in the pack to a dated artifact, and the pack is refreshed whenever the model or its tests change.
Evidence that satisfies Article 55 and how to keep it current
Article 55 duties are proven by records, not by a single assessment. Each artifact below has an owner, a refresh trigger and a point where it must be re-read against the current model and its deployment. Tools can generate parts of this evidence, but the provider decides what counts as compliant.
Evaluation protocol and results record
This is the versioned record of the standardized evaluation protocol the provider applies to each model with systemic risk, with the benchmarks used, the thresholds set, the results obtained and the decision taken on each result. Article 55(1)(a) asks for evaluation with state-of-the-art protocols, so the record should show why each protocol was chosen and when it was last reviewed. Re-run the protocol after each material model change, fine-tune or adaptation, and check that results are tied to the exact model version tested. Langfuse (MIT) traces can capture inputs, outputs and timing from evaluation runs, but the provider must confirm the trace fields meet its own protocol.
Adversarial testing reports
Article 55(1)(a) requires documented adversarial testing, including internal or external red teaming. garak (Apache-2.0) probes language models for prompt injection, jailbreaks, data leakage, toxicity and misinformation, and writes a JSONL report of every attempt and evaluation plus a hit log of attempts that found a vulnerability. Keep the reports with the model version, probe set and garak configuration used, and record each hit with a remediation decision or a documented reason for acceptance. A probe run alone does not satisfy the duty, so the provider must confirm that the probe coverage fits the model's risks and that external red teaming is documented where used.
Systemic risk register with mitigation decisions
Article 55(1)(b) requires the provider to assess and mitigate systemic risks at Union level. The register lists each identified risk, its source, the evidence used to assess it, the mitigation chosen, the residual risk and the named owner who accepted it. Review the register when evaluation results change, after a serious incident, and when the model is placed on the market in a new form. Ask the team to show how each risk links to an evaluation result or an incident, because an assessor will check that the register reflects actual test outcomes rather than a generic list.
Serious incident and corrective-action log
Article 55(1)(c) requires the provider to track, document and report serious incidents and corrective measures to the AI Office without undue delay. DFIR-IRIS (LGPL-3.0-or-later) keeps each case as one record of assets, IOCs, tasks and evidence with a full audit trail, and it builds a consolidated timeline from the case data. Its evidence logging with SHA-256 verification and chain of custody supports the record of what was collected and when. Set internal escalation steps so that a case can be classified and reported within the timing the provider has committed to, and confirm the reporting timeline with legal counsel and the AI Office guidance in force.
Cybersecurity architecture and access evidence
Article 55(1)(d) requires adequate cybersecurity for the model and its physical infrastructure, which includes model weights, training and evaluation environments, and the hosts that serve the model. The evidence is a current architecture diagram, an access register for weights and privileged roles, and configuration baselines for the hosts. OpenSearch (Apache-2.0) Security Analytics runs Sigma rule detectors over logs from hosts, network devices and cloud services, records each match as a finding and correlates findings across log types. Test the detectors against known attack paths on a schedule, because a rule that never fires can look like coverage without being coverage.
Annex XI Section 2 documentation set
Annex XI Section 2 adds to the general technical documentation the evaluation strategies and results, any internal or external adversarial testing, model adaptations including alignment and fine-tuning, and the system architecture. Treat this as a document set with one owner per part, each with a version and a date, and cross-reference it to the protocol, test reports, register and incident log. Each adaptation to the model should trigger an update to the adaptation record before the change is released. Confirm with the provider's counsel how the set will be provided to the AI Office on request.
What meeting Article 55 costs in money and effort
This table lists the cost components of Article 55 compliance, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to build a written scope and to ask each bidder the same questions before comparing quotes.
| Cost component | One-time or recurring, and who is paid | What drives it up or down | What to ask for in a quote |
|---|---|---|---|
| Tooling and licenses | Mostly one-time setup, plus recurring hosting and maintenance. garak, Langfuse, DFIR-IRIS and OpenSearch are open source, so license spend can be low, but infrastructure and staff time still apply. | Hosting footprint, number of model versions, log volume and retention. Confirm each tool's license terms (including any commercial or enterprise add-ons) before deployment. | A list of every component, its license and version, who installs it, and what the provider must still buy or run. |
| Engineering time for evaluation harnesses and logging | One-time to build the harness and tracing, then recurring when models change. Paid to the provider's own staff or an implementation partner. | Number of model versions, evaluation protocols in use, and how much logging is already in place. Reusing a standardized test suite lowers effort. | Named deliverables for the evaluation pipeline, traceability from test to model version, and the hours or fixed fee for each. |
| Adversarial testing (internal or external red team) | Recurring for each significant model change, plus any one-time scoping. Paid to internal staff or an external testing firm. | Breadth of attack categories, number of test cycles, and whether testers are independent of the model team. Documentation of results adds effort. | Attack scenarios covered, tester independence, report format matching Annex XI documentation, and retest rules. |
| Systemic risk assessment and mitigation | Recurring, owned by the provider. Usually a mix of internal governance staff and legal or policy advisers. | Model capability, deployment channels and the number of Union-level risks identified. Cross-functional review time grows with scope. | Written risk register, mitigation owners, review cadence, and the assumptions the scope relies on. |
| Incident response readiness and drills | One-time to write playbooks and set up case management, then recurring for drills and updates. Paid to internal teams or a provider. | Staffing across time zones, the number of notification paths, and how fast the case tool can build a timeline. Clear roles reduce cost. | Runbook for reporting to the AI Office, case tool setup, drill schedule, and the people trained for each role. |
| Cybersecurity hardening of model and infrastructure | One-time hardening, then recurring patching, monitoring and access reviews. Paid to internal teams, cloud or data center staff, or an implementation partner. | Size of the infrastructure, number of weights and data stores, and whether the environment is air-gapped or cloud-hosted. | Hardening baseline, monitoring coverage (for example OpenSearch Security Analytics rules), access control design, and patch cadence. |
| Evidence upkeep | Recurring. Paid to the provider's compliance and engineering staff, sometimes with help from a partner. | Frequency of model updates, number of teams contributing, and whether evidence is generated automatically or assembled by hand. | Evidence list mapped to each Article 55 duty, collection frequency, storage location, and who signs off on each record. |
| Independent review or auditor sampling | Recurring or periodic. Paid to an independent auditor or assessor. Preparation by the provider or its partner is billed separately. | Depth of sampling, number of models in scope, and the state of the evidence on the first visit. Clean, traceable records reduce review time. | Who performs the review, sampling approach, what the provider prepares, and what the review does not cover. Confirm that the reviewer issues the report, not the implementation partner. |
Who owns Article 55 duties and who can help
The provider of a model with systemic risk carries every Article 55 duty and cannot transfer them to a vendor or consultant. Internal ownership covers the decisions that define compliance: which standardized evaluation protocols apply, how adversarial testing is scoped, how systemic risks are judged at Union level, whether a serious incident is reportable, and what corrective measures are adequate. Someone accountable inside the organization must sign these decisions and be able to explain them to the AI Office.
- Evaluation protocol decisions: choosing the state-of-the-art evaluation methods, setting pass criteria and deciding when a model is not released.
- Systemic risk assessment sign-off: owning the Union-level risk analysis and the mitigations chosen for each identified risk.
- Incident reporting: deciding what counts as a serious incident and sending reports to the AI Office without undue delay.
- Model documentation: keeping the Annex XI evidence on evaluation strategies, adversarial testing results and model adaptations current.
- Cybersecurity ownership: accountable for protecting the model and its physical infrastructure, including vendor-run hosting.
Before engaging any partner, confirm internally who holds each sign-off, how decisions are recorded, and how the team will answer AI Office requests.
An implementation partner such as DeployOpen prepares the technical environment in which the provider's evidence is produced. Work is fixed in a written scope with agreed deliverables and timelines. The partner builds and hardens self-hosted systems inside the provider's own infrastructure, so the provider keeps control of model weights, logs and test data. The partner does not decide whether a model is systemic risk, does not accept risk on the provider's behalf and does not issue any report or certificate.
- Test harnesses: building repeatable evaluation and adversarial testing pipelines, for example with garak, and keeping their outputs.
- Logging and tracing: deploying observability tooling such as Langfuse so model operations can be reconstructed.
- Incident tooling: configuring case management and detection content, such as DFIR-IRIS and OpenSearch Security Analytics, that supports serious incident handling.
- Evidence packs: assembling documentation exports, test records and access logs for the provider to review.
- Adversarial testing where contracted: running red teaming under a defined rules of engagement and written scope.
Confirm in the statement of work who owns each artifact, where data is stored, and that the provider can reproduce every test without the partner present.
Independent examination comes from parties that did not build the controls. Depending on the situation, this may be an independent auditor engaged for assurance or the supervisory authority itself. The AI Office supervises general-purpose AI model obligations under Article 88, so it is the authority that receives reports and requests documentation. An examiner reviews the evidence, tests whether controls work as described and records any findings. The examiner cannot design the controls it tests, because that would remove the independence on which its findings depend.
- Evidence review: checking that evaluation records, incident logs and documentation match what the provider claims.
- Findings: issuing observations and deficiencies that the provider must address.
- Scope limits: no authority to set the provider's risk decisions or write its mitigations.
- Separation of roles: an examiner that helped design the controls should not be the one judging them.
Before relying on any examination, confirm with the examiner which standards and articles it covers and what form its output will take.
Most providers buy technical build-out and specialist testing rather than governance. The split follows one test: could the work be done by someone outside the organization without the organization giving up a decision? Work that only prepares evidence can usually be outsourced. Work that makes a risk judgment, accepts residual risk or answers a regulator should stay internal. Costs follow the written scope and recur mainly for testing cycles, logging retention and support, and are one-time for environment design and tool deployment. Ask every partner for a quote that lists each deliverable, the responsible party, the hosting location and the re-testing assumptions.
- Usually outsourced: environment build, test harness development, logging deployment, incident tooling and specialist red teaming.
- Usually kept internal: systemic risk judgments, evaluation pass criteria, reporting decisions and release approvals.
- Shared: evidence assembly, where the partner prepares and the provider verifies.
- Recurring costs: retesting after model updates, log storage and support retainers.
- Quote questions: named deliverables, data location, handover format and what happens when scope changes.
Check that your internal owners can run every outsourced tool and test after the engagement ends.
Where providers usually fall short on Article 55
Article 55 duties are less about writing policies than about producing records that show what was tested, what was assessed, and what was reported. The six gaps below recur across providers, and each one leaves a hole an AI Office request would expose. Check them in order, because later evidence depends on the earlier records.
Evaluation protocols kept in ad hoc notebooks
Evaluations often live in personal notebooks with no versioning, no fixed inputs and no record of who approved the protocol. Article 55 expects standardized, state-of-the-art evaluation, so the protocol itself must be a controlled document. Check that each evaluation names its benchmark set, scoring method, model checkpoint and owner, and that changes to any of these are tracked in version control with a review record.
Adversarial testing not tied to release
Red teaming is sometimes run, but the results are not matched to the exact model version that was released. Annex XI expects documentation of internal or external adversarial testing, so a finding that cannot be traced to a specific checkpoint carries little weight. Confirm that each test run records the model identifier, the attack categories used, the findings and the mitigations applied before release. garak writes JSONL logs of every attempt and a hit log of vulnerabilities, which can be archived with each release.
No Union-level systemic risk register
Many providers identify systemic risks in meeting notes but keep no register that links each risk to an owner, an assessment, and a mitigation decision. Article 55 asks providers to assess and mitigate systemic risks at Union level, so an assessor will look for a traceable chain from risk to decision. Check that every risk entry has a rating, an assigned owner, the evaluation that informed it, and a dated record showing whether the mitigation was accepted, deferred or rejected.
Incident detection that does not open a case
Monitoring may flag unusual model behavior, yet the alert never becomes a tracked case with a timeline. Serious incidents must be tracked, documented and reported to the AI Office without undue delay, which requires a record of when the issue was detected, who acted, and what corrective measures followed. Confirm that alerts from logging and monitoring systems open a case with evidence logged and hashed. DFIR-IRIS keeps cases, assets, tasks and evidence with a full audit trail and chain of custody.
AI Office reporting path never drilled
Reporting routes are often documented on paper but never exercised, so the first real report exposes missing contacts, unclear authority to submit and undefined content. Because Article 55 requires reporting without undue delay, the time to discover these gaps is before an incident occurs. Run a tabletop exercise with a simulated serious incident, record the time each step took, and confirm who signs off, what template is used, and how corrective measures are logged afterward.
Model weight security not evidenced
Teams often state that model weights are protected but cannot show the access list, key management or storage controls that protect them. Article 55 requires adequate cybersecurity for the model and its physical infrastructure, and an assessor will ask for proof rather than design intent. Check that access to weights is restricted to named roles, that access reviews and logs exist, that copies in training and serving environments are inventoried, and that the logs can be retrieved for a given period. Logs from model serving can be captured with Langfuse traces, and the audit trail should show who accessed what.
Questions buyers ask about Article 55 cost, time and effort
What does Article 55 add beyond Articles 53 and 54?
Article 55 applies on top of the duties in Articles 53 and 54, and only to providers of general-purpose AI models with systemic risk. Every general-purpose model provider must keep technical documentation and supply information downstream, adopt a copyright policy and publish a training content summary. Systemic-risk providers must also evaluate the model with standardized state-of-the-art protocols, including documented adversarial testing, assess and mitigate systemic risks at Union level, track and report serious incidents to the AI Office without undue delay, and ensure adequate cybersecurity for the model and its physical infrastructure. Whether a model is in scope depends on its classification, so confirm that status before scoping the work.
Is red teaming strictly required under Article 55?
Article 55(1)(a) requires documented adversarial testing as part of model evaluation, so some form of adversarial testing is mandatory for these providers. The Article does not prescribe a method, scope or tool. The provider decides the form the testing takes and must be able to justify that choice, including the threat models it covers and the results it produced. Internal or external red teaming is one way to meet the duty, and Annex XI expects the provider to document any such testing in its technical documentation. Ask counsel and any independent assessor how they expect that justification to be written before the test plan is fixed.
How long does Article 55 implementation take?
The duration depends on the model, the provider's existing security maturity and the scope of the systemic risk work. A provider that already runs structured evaluations and incident handling has less to build than one starting from documentation. No fixed timeline applies to Article 55 itself, so treat any number you see as an estimate that needs its own basis. A fixed-scope quote, agreed in writing before work starts, sets the timeline for the specific deliverables, and it should name the systems, test cycles and evidence that the work covers.
What drives the cost of meeting Article 55?
Cost follows the work the provider must do, and most of it is labor and infrastructure. The main drivers are the number of evaluation protocols and test cycles, the depth of adversarial testing, the size of the logging and monitoring estate, the incident reporting process that must run to the AI Office, and the cybersecurity controls for the model weights and training and serving infrastructure. Some costs are one-time, such as building the evaluation pipeline and first documentation set. Others recur, such as repeat testing after model changes, monitoring and reporting. When requesting a quote, ask for the cost of each deliverable separately, the assumptions behind it and which items recur.
Can our team meet Article 55 in-house?
Many providers can meet Article 55 in-house if they already have mature security engineering, model evaluation capability and legal review. Outside help is commonly used for an independent view of the adversarial testing scope, for preparing systems and evidence, and for building the logging and incident workflow. The organization always owns its obligations and decisions. An implementation partner prepares systems and evidence, and only an independent auditor or assessor issues reports. Decide which parts you keep and which you buy by comparing your current capability with the deliverables listed in the written scope.
What does Article 55 need from engineering, legal and security teams?
The work spans three functions that must coordinate:
- Engineering maintains evaluation pipelines, adversarial test harnesses, logging of model and system activity, and the configuration of the infrastructure that hosts the model.
- Security runs or reviews adversarial testing, sets cybersecurity controls for the model and its physical infrastructure, and operates incident detection and triage.
- Legal and compliance interpret reporting duties to the AI Office, maintain the documentation set and track corrective measures.
Each function should name an owner for every Article 55 deliverable. Confirm these roles with your own governance model before the project starts.
Can a code of practice be used to show Article 55 compliance?
Yes, Article 55(2) lets systemic-risk providers rely on codes of practice until a harmonised standard is published, or demonstrate alternative adequate means of compliance. The Commission states that the Safety and Security chapter of the General-Purpose AI Code of Practice applies only to providers of models with systemic risk under Article 55. Using the code is a choice, and it does not replace the provider's own evidence. Read the chapter against your evaluation, testing, reporting and cybersecurity records, and confirm with counsel which signatory status and documentation your position requires.
How DeployOpen prepares Article 55 evidence
DeployOpen plans, builds and documents the self-hosted systems that produce Article 55 evidence inside your own infrastructure. We prepare the testing, logging, incident and cybersecurity records; your organization owns its obligations, and an independent auditor or certification body issues any report or certificate.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope lists which models, evaluation protocols and adversarial test suites are covered for Article 55 duties.
- Scope also names the incident reporting path to the AI Office and the cybersecurity boundary for model infrastructure.
How we build
- We deploy open-source evaluation and adversarial probing tools, such as garak, in your environment with logged configurations.
- Tracing with Langfuse records inputs, outputs, tool calls and token usage so evaluation runs can be reproduced.
- Security monitoring uses OpenSearch Security Analytics with Sigma rules and correlation for model and infrastructure events.
How we hand over
- Handover includes evaluation strategy, test results, adversarial testing records and architecture documentation mapped to Annex XI Section 2.
- Incident handling runs in DFIR-IRIS, with case records, evidence hashing, chain of custody and timelines for reporting.
- Your team receives runbooks, configuration records and an evidence index that your assessors can trace.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We can rerun evaluations after model adaptations such as fine-tuning, so records stay current.
- Confirm with us which tasks remain with your compliance team and which move to a retainer before signing.
