How Article 56 codes of practice help general-purpose AI providers prove compliance
A code of practice is a voluntary route for a general-purpose AI provider to demonstrate compliance with its obligations under Articles 53 and 55. It is not a certification, and no body issues a badge for adhering to it. A provider that signs up is still responsible for showing, with its own documentation, that its model meets the duties. The Commission published the General-Purpose AI Code of Practice on 10 July 2025. It has three chapters: transparency and copyright, which applies to all providers of general-purpose AI models, and safety and security, which applies to providers of models with systemic risk. On 1 August 2025 the Commission issued an opinion, reached with the AI Board, finding that the code is an adequate voluntary tool for demonstrating compliance.
The two main ways a provider gets this wrong are over-claiming and under-documenting. Over-claiming happens when a provider says it follows the code but cannot show evidence for the measures it reports. Under-documenting happens when a provider signs or relies on the code but keeps no internal record of how each commitment is met for its specific model, training process and release. Before relying on the code, the provider should confirm which chapters apply to its model, check the current signatory list on the Commission's code page, and map each commitment to a named owner and a dated artifact. Where a signatory has only signed one chapter, as the Commission's page describes for one provider, the remaining obligations must be shown by other adequate means.
What usually makes this hard is the gap between a policy statement and a working process. Teams often find that copyright opt-out handling, evaluation records and incident channels exist in some form but are scattered across tickets, notebooks and email. Tracing each obligation to a versioned document, a test result or a log entry takes more effort than writing the policy. Confirm with counsel which commitments your own model's documentation must satisfy and ask any consultant to show how their evidence would stand up to an AI Office request.
Which providers can rely on the code and where it stops
The code of practice is a voluntary route, and its two chapters apply to different providers. The cards below cover who can rely on each chapter, how open-source, non-EU and fine-tuning cases fall, and where signing does not settle compliance on its own.
Transparency and copyright chapter
Every general-purpose AI model provider can rely on this chapter to show how it meets the documentation duties and the copyright policy duty. It is the part of the code that applies regardless of model size. Check that your documentation and copyright policy map to the chapter's commitments, and that you can produce the same material for the AI Office on request.
Safety and security chapter
Only providers of models with systemic risk can rely on this chapter for their extra duties. A provider that has not been classified as having systemic risk gains nothing from it, and should not describe its model as covered by it. Confirm your classification status before you scope the chapter into your compliance plan.
Open-source models
Open-source status exempts some documentation duties, but it does not remove the copyright policy or the training content summary. Providers of open-source models that are not classified as having systemic risk should confirm which exemptions apply to their specific release before relying on the code for those duties.
Non-EU providers under Article 2
A provider established outside the EU that places a general-purpose model on the EU market falls within the Act. It can use the code to show compliance, but it must also meet the authorised representative duty under Article 54 unless an exemption applies. Confirm the representative arrangement with counsel before treating the code as the full compliance route.
Downstream fine-tuners
An organization that fine-tunes a model may or may not become a provider of a general-purpose AI model, depending on the compute it used and how much it changed the model. A fine-tuner that is not a provider does not inherit the code's commitments, but it still needs documentation from the upstream provider. Check the Commission's thresholds before assuming either role.
Partial signatories and signing limits
A signatory that accepts only the safety and security chapter must show compliance with the other obligations by alternative adequate means. Signing is therefore not automatically full coverage. Ask each provider you rely on which chapters it signed, and document how you meet any chapter it did not sign.
What the three chapters of the General-Purpose AI Code of Practice cover
The code is organized into three chapters, and they do not reach every provider in the same way. Transparency and copyright apply to all general-purpose AI model providers, while the safety and security chapter applies only to providers of models with systemic risk. A provider can therefore adopt the code in full or in part, depending on the models it places on the EU market, and the Commission's signatory list shows partial sign-ups in practice.
- Modular structure: Map each chapter to your own models and obligations before deciding what to adopt.
- Adequacy: The Commission, with the AI Board, found the code an adequate voluntary tool, so adherence is one route among others to show compliance.
- Partial signature: Where a provider signs only some chapters, it must show compliance for the rest by alternative adequate means.
- Bridge to standards: Adherence lets providers demonstrate compliance until a harmonised standard is published under Articles 53(4) and 55(2).
- Fines: Article 101(1) requires the Commission to take code commitments into account when fixing fines.
Check the current signatory list and the chapter text on the Commission's code page before relying on the code in a contract or board paper.
This chapter applies to every general-purpose AI model provider, and it centers on documentation that downstream providers and the AI Office can read. It expects a written model record, a copyright compliance policy and a process for honoring machine-readable opt-outs during data collection. Providers should also be able to show how these records stay current as each model version changes.
- Model documentation: A technical record covering the model's design, training process, compute and intended uses, kept current for each version.
- Downstream information: A separate package for providers that build on the model, covering capabilities, known limits and integration guidance.
- Copyright policy: A written policy showing how the provider complies with EU copyright law across data sourcing, including how it handles rights reservations.
- Opt-out records: Logs showing which data sources honored machine-readable reservations, and how exceptions were handled and approved.
- Training content summary: A published summary of training content, prepared to the AI Office template, backed by a traceable record of its sources.
Ask legal and data teams to confirm which items your models must produce, and where each record is stored with its version history.
This chapter applies to providers of models with systemic risk and asks for a lifecycle approach to identifying, assessing and reducing large-scale risks, along with protection of the model and its infrastructure. Evidence is mostly the operating record of these processes over time, not a single document produced at release. Providers should expect to show who decided what, when, and on what evidence.
- Risk framework: A written framework that defines the systemic risk categories for each model, the owners responsible, and the thresholds that trigger a release decision.
- Adversarial evaluation: Test plans and results covering jailbreaks, prompt injection, data leakage and misuse, saved per model version. Tools such as garak write a JSONL report of every attempt and a hit log of successful attempts, which can serve as raw evidence.
- Incident monitoring: Procedures for detecting serious incidents after release and reporting them to the AI Office, with timelines confirmed against Article 55.
- Security controls: Documented and tested access control, secrets management and protection for model weights and training infrastructure.
- Release sign-off: Records of who approved each release, which residual risks were accepted, and the reasoning behind each decision.
Confirm the evaluation scope and reporting timelines against the current code text with your security and legal teams before you commit to a test calendar.
How an assessor or the AI Office tests adherence to the code
This table compares the four points where adherence to the General-Purpose AI Code of Practice is examined: adequacy of the code itself, the AI Office review of a provider, documentation requests, and partial signatories. Read each row as a question the reviewer asks, the proof they expect, and the gaps that most often surface. The main takeaway is that signing the code is only the start, because providers must still show that their own practices match the commitments they made.
| Review point | Evidence requested | Common findings |
|---|---|---|
| Commission assessment of code adequacy | The published code text, the Commission opinion of 1 August 2025 and the Commission's code page showing signatories and chapters | Providers assume adequacy settles their own compliance, when the opinion only found the code an adequate voluntary tool for demonstrating compliance |
| AI Office review of a provider's adherence | Documented mapping from each committed measure to internal policies, model records and named owners, dated before the review | Commitments exist on paper but no process, owner or record shows they run in practice |
| Documentation requests | Model documentation, copyright policy, training content summary and safety and security records kept ready for production | Records are scattered across teams, lack version history, or cannot be produced quickly for a specific model version |
| Partial signatories handling | Written explanation of which chapters are signed and the alternative adequate means used for any chapter not signed | Providers that signed only some chapters give no clear account of how the remaining obligations are met |
| Weight of code commitments in fines | Records showing which code commitments were adopted and how they were followed, since Article 101(1) requires these to be considered when fixing fines | Adoption is claimed without evidence of follow-through, which weakens any argument that the provider acted in good faith |
How a provider adopts the code and maps its own evidence to it
This sequence takes a general-purpose AI model provider from an initial classification check to a documented, versioned set of evidence that shows how each chapter of the General-Purpose AI Code of Practice is met. Each step closes with an output that the next step depends on, so the provider can explain its position to the AI Office, its customers and its auditors.
Confirm model classification and provider role
Start by establishing which obligations apply. Legal and compliance leads, with the model owners, confirm whether the organization is a provider of a general-purpose AI model, whether it places the model on the EU market, and whether the model may be classified as having systemic risk under the presumption and designation routes covered in the sibling topic on classification. This also settles whether the organization is a provider of an AI system built on that model, which changes the enforcing authority under Article 75(1). The step is done when a dated classification memo names the role, the model versions in scope and the reasoning behind any systemic risk conclusion. Confirm the open-source treatment and any authorised representative needs with counsel before moving on.
Decide whether to sign and which chapters
Leadership and counsel decide whether the organization will sign the code, and if so, whether it will sign all three chapters or only the chapters that fit its position. The transparency and copyright chapter applies to all providers, and the safety and security chapter applies to providers of models with systemic risk. Public signatories are listed on the Commission's code page, and that list is the place to confirm current status before a decision is recorded. If a provider signs fewer chapters, it must plan alternative means for the rest, as the xWiki-style public record of partial signing shows for other providers. The output is a signed decision record that lists each chapter, the reasons for it, and the named executive owner.
Gap-assess current documentation against each chapter
Compare the provider's existing model documentation, training content records, copyright policies, evaluation reports, incident procedures and security controls against each commitment in the chosen chapters. The assessment should read the code's measures and sub-measures directly rather than working from summaries. Record each commitment as met, partly met or not met, with the document or system that supports it. Illustrative example: a team may find that its evaluation reports exist but do not include adversarial testing results in a form the AI Office can review. The output is a gap register tied to specific commitments, with a named source document for every finding.
Assign owners for each commitment
Each commitment in the gap register needs one accountable owner, usually a person in engineering, legal, security, data governance or research, not a committee. The owner decides how the commitment will be met, what the evidence will be and when the evidence is refreshed. Owners also agree how they will escalate findings to the executive sponsor. The step is done when every commitment has a named owner, a deputy and a documented escalation route, recorded in the same register as the gap assessment. Without owners, evidence tends to be produced once for the initial review and then not kept current.
Build the evidence set
Owners produce or update the evidence for each commitment: model documentation, copyright policy and opt-out handling records, training content summaries, evaluation and red-teaming reports, incident and reporting procedures, and cybersecurity records for the model and its infrastructure where systemic risk applies. Store each artifact under version control, record who changed it and when, and keep the ability to compare and roll back earlier versions. Test logs and traces should be retained in a form that can be queried later. The step is complete when each commitment has a current, versioned artifact that a reviewer can locate from the register. Confirm with counsel and the assessor what format and detail they expect, because the code does not replace legal review.
Record commitments and deviations with alternative means
Where the provider does not meet a commitment in the way the code describes, it should record the deviation, the reason, and the alternative means it uses to demonstrate compliance with the underlying obligation. The Commission's assessment and the signatory list show that partial adherence is possible, but the provider must still explain how it meets the requirement. Legal and the executive sponsor review each deviation and approve the wording used with regulators and customers. The output is a commitments and deviations register that can be shared with the AI Office on request and that matches the public statements the provider makes about its compliance.
Set a review cycle tied to model releases
Define when each evidence item is reviewed and what triggers an early review. Model releases, material changes to training data or architecture, new evaluation findings, serious incidents and updates to the code or the Commission's assessment should all trigger a check of the register. Owners confirm that evidence still matches the released model version, and the register records the version each artifact covers. The step is done when a written review procedure exists, the first review after the current release is scheduled, and the executive sponsor has accepted the procedure. Confirm with the AI Office and counsel whether any additional reporting is expected between releases.
Evidence that shows a provider adheres to the code
A provider that adheres to the General-Purpose AI Code of Practice needs a file of evidence it can show the AI Office and an independent view of its own compliance. The cards below cover the records that connect adherence to the obligations in Articles 53 and 55, and the routine that keeps each record current between model releases.
Signed commitment and scope statement
Keep the signed commitment record, the chapters the provider adhered to, and a written scope statement listing which models, versions and deployment routes it covers. Signatories such as Amazon, Anthropic, Google, IBM, Microsoft, Mistral AI and OpenAI are listed on the Commission's code page, and the page notes that xAI signed only the Safety and Security chapter. Check that the scope statement names each model release, because a commitment signed for one generation does not automatically cover the next. Re-check the Commission's signatory list before each release and record the date you checked.
Version-controlled policy and documentation
Store the copyright policy, the transparency documentation and the safety and security framework under version control, so each change records what changed, when and by whom. Keep the approved version that was in force for every model release, since an assessor will ask which text governed a given model. Compare versions before each release to confirm that every commitment still has a current, approved text behind it. Rollback should be possible for any earlier approved version.
Model documentation and training-content records
Maintain the technical documentation for the model, the information passed to downstream providers, and the public summary of training content, each dated and tied to a model version. Record the sources used, the copyright opt-out handling and the data processing steps behind each summary. Ask whether your records can show what changed between two releases, since a summary that no longer matches the trained model is a common gap. Assign one owner for each document so that updates do not wait for an audit.
Safety and security test records
Keep the evaluation plans, adversarial test results and the mitigation decisions that followed them for each model with systemic risk. Record the test tools, configurations, prompts used and pass or fail outcomes, so that a later reviewer can repeat the tests. For language models, automated probes such as garak write a JSONL report of every attempt and a hit log of vulnerabilities found, which can be archived with each release. Record why any finding was accepted or fixed, not only that a test ran.
Incident and change logs
Keep a change log that links each model update to the test results, documentation changes and approvals it required, and an incident log for serious incidents and their reporting timeline. Traces from observability tooling, such as Langfuse, capture inputs, outputs, tool calls and token usage, which can support investigation of a reported incident. Confirm which logs your organization must keep, how long, and where they are stored, since the code does not replace your own retention decisions. Review the logs at each release to show that changes followed the approved process.
Register of deviations and alternative evidence
Record every chapter, commitment or measure the provider does not follow in full, the reason, and the alternative compliance evidence used instead. The xAI case on the Commission's page shows why this matters: a provider that signs only part of the code must show the remaining obligations by alternative adequate means. Review the register at each release, and have counsel confirm that each alternative is defensible before you rely on it. Keep the register separate from the commitment record so that gaps stay visible.
What adopting the code costs in money and staff effort
This table breaks down the cost components of adopting the General-Purpose AI Code of Practice, who is paid for each, whether it is one-time or recurring, and what drives it up or down. No figures are stated because none were supplied, so use the drivers to frame a written scope and quote. The main takeaway is that recurring evidence upkeep per model release usually outweighs the initial setup.
| Cost component | Who is paid or who does the work | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Internal legal and policy staff time | Own legal, compliance and policy staff mapping the code's chapters to internal policies | One-time setup, then recurring review | Number of models in scope, number of chapters adopted, and how often policies change |
| Engineering time for documentation and evaluation records | Own ML, platform and safety engineers producing model documentation and evaluation records | Recurring per model release | Model count, release cadence, and whether templates and automated logging already exist |
| External testing or review | Independent testers or reviewers, where the provider chooses or the code expects outside evaluation | Usually recurring, tied to major releases | Whether the model is under systemic risk, the depth of adversarial testing, and scope agreed in writing |
| Evidence upkeep per model release | Own documentation owners, with support from any implementation partner preparing evidence | Recurring for every release and update | Release frequency, number of downstream versions, and how well evidence is versioned and stored |
| Legal counsel for alternative-means arguments | External counsel, needed where a provider signs only some chapters or uses other compliance routes | Mostly one-time per argument, revisited when the code or the Commission's position changes | Number of chapters not adopted, complexity of the argument, and regulator feedback |
| Systemic risk additional duties | Safety and security teams and any external evaluators for the Safety and Security chapter | Recurring, with a larger upfront build | Whether the model is designated or presumed to have systemic risk, and the cadence of risk assessments |
| Tooling and self-hosted infrastructure | Own platform team, or an implementation partner for deployment and hardening | One-time build, then recurring operation | Choice of self-hosted tools, retention periods, and whether evidence is generated automatically |
Self-hosted tools that can keep the code evidence current
Can XWiki keep a versioned record of our code of practice policy pages?
Yes, XWiki keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one, which gives an assessor a dated history of how your AI policy and code of practice mapping evolved. XWiki is licensed under LGPL-2.1-or-later, so you can host it in your own infrastructure. Confirm with your team that the page history is retained for the period your records policy requires, and that exports of the history can be produced on request. The history shows that a document changed. It does not prove the controls described in it operate.
How does BookStack control who can read and edit AI compliance documentation?
BookStack assigns user abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. In practice, this lets you open the general-purpose AI documentation to engineering while restricting the safety and security evidence pages to a named compliance group. BookStack is licensed under MIT. Ask your team to document which roles can publish, approve and edit each evidence area, because an assessor will look for segregation between the people who produce evidence and the people who sign it off. BookStack controls access to documents. It does not validate their content.
What does garak produce as safety testing evidence for a model?
garak is an open-source scanner, licensed under Apache-2.0, that probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. It writes a JSONL report of every attempt and evaluation, plus a hit log of the attempts that found a vulnerability. Those files give you a repeatable record of what was tested, against which model version and with what result. Retain the configuration, the model identifier and the date of each run alongside the output. garak results do not measure the adversarial testing expected of models with systemic risk. Confirm what additional testing your obligations require and who will perform it.
How can Langfuse traces support operational evidence for a deployed model?
Langfuse, licensed under MIT, records traces that capture every operation in a request, including LLM calls, retrieval steps, tool executions and custom logic. Each trace stores timing, inputs, outputs, token usage and metadata. For code of practice evidence, this helps show how a deployed system behaved over time, how incidents were reconstructed and how usage patterns changed. Decide in advance what personal data enters traces, because inputs and outputs can contain it and the GDPR still applies to them. Confirm retention periods and access controls before you rely on traces as evidence.
Do these tools prove that we follow the General-Purpose AI Code of Practice?
No. Tool output supports your compliance evidence but does not replace your own assessment. Version histories, access logs, test reports and traces show what happened in your systems. They do not decide whether your policies meet the code's commitments, whether your safety measures are adequate or whether your documentation is sufficient for the AI Office. Your organization owns those judgments and should record them in a dated review. An independent assessor is needed only where a specific obligation calls for one, and the assessor, not any tool, issues any formal opinion.
Who sets up and maintains these tools, and what does that cost?
Your organization pays for the infrastructure, the staff who operate the tools and the time spent keeping evidence current. Licenses for XWiki, BookStack, garak and Langfuse are open source, so the recurring costs are hosting, administration, storage and review effort. An implementation partner such as DeployOpen can install, configure, back up and document self-hosted platforms in your own cloud accounts or data centers under a written scope. Ask any provider for the components in scope, who maintains upgrades and how evidence exports will be delivered. Cost depends mainly on the number of systems covered, retention requirements and how much integration work is needed.
What should an engineer check before trusting these tools as evidence?
Check four things. First, confirm that each tool records the fields you will cite, such as model identifier, test date, user and change author. Second, confirm that logs and version histories cannot be altered by the people they describe. Third, confirm that you can export complete records in a usable format for an assessor. Fourth, test a restore from backup to confirm that evidence survives an outage. Document each check with a date and a named owner. Limitations in a tool's reporting should be recorded as known gaps, not hidden.
Who does what: the provider, a partner and the independent reviewer
The general-purpose AI model provider remains responsible for every commitment it makes under the code and for every claim it makes to the AI Office, downstream providers and customers. Adherence is a choice the provider makes, so its legal and model teams decide which chapters it signs, which measures it adopts, and which statements appear in its documentation. Those decisions cannot be delegated to a vendor or consultant.
- Signing decisions: Legal confirms which chapters the provider adheres to, such as the transparency and copyright chapter alone or both chapters when the model has systemic risk.
- Commitment ownership: Model and safety teams own the measures they promise, including evaluation, incident handling and cybersecurity for the model and its infrastructure.
- Claim review: Legal reviews public summaries, technical documentation and marketing statements so they match what the model actually does.
- Internal records: The provider keeps its own evidence of training data handling, copyright policy and testing results for the period the Act requires.
- Alternative means: Where a provider signs only part of the code, its own team must document how it shows compliance for the remaining obligations.
Before relying on any adherence statement, confirm the current signatory status and chapter scope on the Commission's code page.
An implementation partner such as DeployOpen can help the provider prepare the systems and records that show how its measures work. The partner builds and documents the environment, configures logging and version control for evidence, runs security tests the provider asks for, and organizes records so the provider can answer questions quickly. The partner does not decide what the provider commits to, and it does not assess whether the code or the provider meets it.
- Evidence preparation: The partner structures documentation, change history and test records so that each commitment points to a retrievable artifact.
- Tooling: Self-hosted tools can record model evaluation runs, adversarial probe results and traces in the provider's own infrastructure.
- Testing support: Security testing of models, APIs and surrounding infrastructure can be scoped in writing and reported to the provider.
- Document control: Version-controlled wikis and permission-managed knowledge bases keep policies and technical documentation traceable.
- Limits: The partner cannot sign adherence, issue a conformity statement or represent the provider to the AI Office.
Ask any partner to put in writing which deliverables it produces and which decisions remain with the provider.
The Commission assesses whether codes of practice cover the obligations in Articles 53 and 55, and publishes its assessment. The AI Office, part of the Commission, enforces the rules for general-purpose AI models under Article 88. The assessment of a code is a public, institutional judgment. It is not a certification that any single provider can obtain from a consultant.
- Adequacy assessment: The Commission, taking utmost account of the AI Board's opinion, decides whether a code is an adequate tool, as it did for the General-Purpose AI Code of Practice on 1 August 2025.
- Enforcement: The AI Office supervises general-purpose AI model providers and can request information and take enforcement steps.
- Fallback powers: Under Article 56(9), the Commission can adopt common rules by implementing act if a code is not finalized or is inadequate.
- Fine context: Article 101(1) requires the Commission to take code commitments into account when it sets fines, so adherence affects how commitments are weighed.
- No partner role: Consultants do not receive or pass on an AI Office judgment on a provider's compliance.
Check the Commission's pages for the current assessment and signatory list before making a compliance statement.
Where providers fall short when relying on the code
Adhering to the General-Purpose AI Code of Practice gives providers a recognized route to show compliance, but the route only works if the evidence behind it is specific, current and traceable. The gaps below recur across providers, and each one is something an assessor or the AI Office can test.
Signing without mapping evidence
Signing the code does not by itself demonstrate anything. Providers need a written map from each commitment in the transparency, copyright and safety and security chapters to the document, log or test result that proves it. Without that map, a team cannot show which obligation a given artifact covers. Check that every commitment has a named owner and a named evidence location.
Treating the code as a certification
The code is a voluntary tool for demonstrating compliance. It is not a certificate, and no body issues a stamp of approval for signing it. Providers that describe their status as certified invite questions they cannot answer. Check that internal and external statements describe the code as a route to demonstrate compliance, and that any independent assessment comes from a body with the authority to give it.
Missing alternative evidence for partial signing
A signatory may adhere to only some chapters. xiAI-style partial adherence, where a provider signs only the safety and security chapter, leaves the other obligations to be shown by alternative adequate means. Teams that signed partially often have no record of what those alternative means are. Check which chapters your organization signed, then document the evidence path for each remaining obligation before a regulator asks.
Documentation without version control
Model documentation, copyright policies and training content summaries change over time, and an assessor will ask which version applied on a given date. Documents kept as loose files or overwritten pages cannot show that history. Store each document in a system that records changes, authors and dates and allows comparison and rollback. Confirm that the version in force at each release is retrievable.
Safety test records without reproducible reports
Safety and security chapter commitments depend on adversarial testing that another person can repeat and verify. A record that says a model was tested, without the probes, configuration and outcomes, does not establish what was tested. Keep machine-readable reports of every attempt and evaluation, along with the logs of attempts that found a vulnerability. Check that a second engineer can rerun the suite and get comparable results.
No plan to refresh evidence per release
Evidence gathered for one model version can go stale when weights, training data or deployment settings change. Providers that rebuild their evidence only before a launch tend to fall behind on later releases. Set a release checklist that re-runs safety testing, updates documentation and records which evidence applies to which version. Confirm who approves a release only after this checklist is complete.
Questions buyers ask about codes of practice
Is signing the General-Purpose AI Code of Practice mandatory?
No. Signing the code is voluntary. Providers can instead show compliance through other adequate means, which the Commission's code page describes for xAI: it signed only the Safety and Security chapter and must show its other compliance by alternative adequate means. Under Articles 53(4) and 55(2), adherence lets providers demonstrate compliance until a harmonised standard is published. The Commission's opinion of 1 August 2025, reached with the AI Board, found the code an adequate voluntary tool. If you do not sign, you carry the full burden of building and explaining your own evidence to the AI Office, so decide with your legal and compliance leads before you commit to a route. Check the code page for the current signatory list.
How much effort does code of practice compliance take?
Effort depends mainly on which chapters apply to your models and how much documentation you already have. The code has three chapters: transparency and copyright for all providers, and safety and security for providers of models with systemic risk. A provider with one open model and no systemic risk faces a much smaller load than one with several frontier models, each needing adversarial testing, incident reporting and cybersecurity work. The main drivers are the number of models, the state of your training data records, how mature your evaluation and logging practice is, and how many releases you ship each year. No effort figure is supplied for this topic, so ask any partner for hours or days broken down by chapter, by model and by recurring activity, and for the assumptions behind each number.
Can our in-house team prepare the code of practice evidence alone?
Many teams can, provided they have people covering legal and copyright review, technical documentation, model evaluation and security testing. The work is mostly documentation and repeatable testing, so the tooling matters. Version-controlled wikis such as XWiki record what changed, when and by whom, which helps show how a policy evolved. BookStack's role-based permissions can separate who writes documentation from who approves it. For evaluation, garak writes a JSONL report of every probe attempt and a hit log of vulnerabilities found, and Langfuse traces capture inputs, outputs, timing and token usage. Confirm each tool's current capabilities in its own documentation before you rely on it. An outside partner can prepare systems and evidence, but only you own the obligations.
How long does preparing for the code of practice take?
The timing depends on scope, and no fixed duration is supplied for this topic. The main factors are how many models are in scope, whether any of them carry systemic risk, how complete your existing documentation and testing records are, and when your next model release is due. Preparation for a model you are about to launch usually runs on that release schedule, so a late-stage launch leaves little room for gaps. Ask for a milestone plan that lists the documents, test runs and reviews in order, with dates tied to your release calendar. Treat any single duration offered without that plan as a starting point for questions, not a commitment.
Can a consultant issue an AI Act code of practice certificate?
No. The code of practice does not produce a certificate, and no consultant or implementation partner can issue one. The Commission assesses the code's adequacy, and national and EU authorities supervise compliance, with the AI Office enforcing the general-purpose AI model rules. A consultant or partner can help you map obligations, prepare documentation, run testing and organize evidence so that the responsible authority can review it. DeployOpen prepares systems, controls and evidence for compliance work. It does not issue audit reports, attestations or certifications, and that boundary should be written into any engagement.
What should a written scope cover before hiring an implementation partner?
A written scope should name the exact deliverables, so both sides can test whether the work is finished. Include at least these parts:
- The models in scope, by name and version, and which code chapters apply to each.
- The evidence each chapter requires, listed as named documents, test reports and logs.
- The systems and tools to be configured, hardened and integrated inside your own infrastructure.
- Who approves each deliverable, and who owns legal conclusions such as copyright positions.
- Milestones and dates tied to your release calendar.
- Exclusions, such as legal opinions or assessments by authorities.
- Handover, training and any ongoing support retainer.
DeployOpen works from fixed scopes agreed in writing before work starts, and it provides a quote based on that scope. Ask any partner to show you a sample scope before you sign.
Official sources to read before scoping
Start with the text of Article 56 itself. The EUR-Lex page for Regulation (EU) 2024/1689 has an anchor that jumps straight to the article, and it sets out what the AI Office must encourage and how the Commission assesses codes of practice. Read the article alongside the Article 53 and Article 55 duties it refers to, because a code is only useful to you if it covers the obligations you actually carry. Before you scope any work, confirm which of those duties apply to your model, since that determines which chapters of the code matter to your program.
Next, read the Commission's code page for the General-Purpose AI Code of Practice and the Commission's opinion of 1 August 2025 that assessed it. The code page lists signatories and the chapters each one has signed, and it notes that one signatory signed only the safety and security chapter and must show compliance for the rest by other adequate means. Read the opinion for the reasoning behind the adequacy finding. Note the page's last update date when you cite it in a internal document, and check the page again before any procurement or board decision, because signatory lists change. Finally, read the 2026 amended consolidated text of the Act on EUR-Lex, not only the original 2024 publication, because Article 56 was changed by Regulation (EU) 2026/1744. Confirm the current wording of the article and any dates that affect your plan with your legal counsel, and record which version you relied on.
How DeployOpen prepares evidence for the GPAI code
This sequence turns a provider's existing model documentation, testing records and governance material into an organized evidence package, mapped to the code's chapters, that the provider can review and submit under its own responsibility. DeployOpen prepares the systems and records only; it does not issue attestations or assess adequacy.
Scope the engagement in writing
The provider and DeployOpen agree in writing which code chapters are in scope, whether the model is treated as having systemic risk, which systems and repositories hold the relevant records, and who on each side owns each deliverable. The scope also states what DeployOpen will not do, including issuing any attestation or judging whether the code or the provider's own compliance is adequate. The output is a signed scope document that names the provider's accountable owner and the reviewers who will receive the package. Confirm the current status of the code and the signatory position with the AI Office before scoping, because both can change.
Inventory existing documentation and records
DeployOpen reviews the documents the provider already keeps, such as model cards, training data records, copyright policies, safety evaluations, incident procedures and governance minutes, and lists where each one lives and who maintains it. Gaps are recorded against the chapter and commitment they relate to, without judging whether the provider meets them. The output is a source register that shows each existing document, its owner, its version and its location inside the client's environment.
Map documentation to code chapters
The inventory is cross-referenced to the transparency and copyright chapter and, where the model is treated as having systemic risk, to the safety and security chapter. Each commitment is paired with the evidence that addresses it, and open items are flagged for the provider's legal, policy or safety staff to decide. The mapping is the provider's own working document; DeployOpen does not declare any commitment satisfied. The output is a traceability matrix reviewed by the provider's compliance lead.
Implement self-hosted evidence tooling
Where the provider needs a controlled place to keep documents and an audit trail, DeployOpen deploys open-source tools inside the provider's own infrastructure. A wiki such as XWiki keeps every page change under version control, recording what changed, when and by whom, with the ability to compare and roll back versions. Access to these records is set by role in a tool such as BookStack. The output is a working, hardened instance and a documented procedure for how records are created, reviewed and retained.
Run agreed safety test records
Where the scope includes safety and security testing for a model with systemic risk, DeployOpen runs the agreed tests and captures their records. Tools such as garak can probe a language model and write a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. Langfuse can record traces of model interactions in a deployed system, if the scope covers observability. The output is a set of raw test records, a summary of methods, and a list of findings that the provider must assess and decide how to handle.
Assemble the package for client review
DeployOpen compiles the traceability matrix, documentation register, tool configuration notes and test records into one package with an index, version labels and a list of known gaps. Every item is linked to its source record so that a reviewer can trace each statement. The output is a package delivered to the provider, who decides what to submit, to whom, and in what form. DeployOpen does not submit the package on the provider's behalf unless the written scope says so and the provider authorizes it.
Hand over and confirm ownership
DeployOpen walks the provider's owners through the tools, procedures and package, and records who will maintain each system after handover. The provider confirms in writing that the deliverables match the agreed scope and that it accepts responsibility for its own compliance position. Ongoing upgrades, testing or support are handled under a separate written agreement, if the provider chooses one. The output is a signed handover record and a maintenance schedule owned by the provider.
