What Article 54 requires from non-EU general-purpose AI model providers
A provider established outside the EU that wants to place a general-purpose AI model on the EU market must first appoint an EU-established authorised representative by written mandate. That is the core requirement of Article 54(1), and it applies before the model is placed on the market, not after a regulator asks. The purpose is practical: the AI Office needs a reachable point of contact inside the Union that holds the Annex XI technical documentation, can verify it, and can answer questions on the provider's behalf. Without that contact, a supervisor has no straightforward way to reach a provider that sits in another legal jurisdiction.
The mandate has to be drafted with care. Under Article 54(3), it must authorise the representative to verify the Annex XI documentation and the provider's compliance with Articles 53 and 55, to keep that documentation for 10 years after the model is placed on the market, to provide information to the AI Office on request, and to cooperate with the authorities. Teams often find that the documentation sits with a model development group, the legal and procurement teams hold the contract, and nobody has checked that the representative can actually obtain the files on request. Confirm that the mandate, the document store and the named contacts line up before the first placement.
The hardest part is often knowing when placement happens. A provider may release weights through a download, an API or a partner platform, and each route can count as placing the model on the market in the EU. Record each release channel, the date of first availability to EU users and the version concerned, and tie each entry to the representative's mandate. The representative must terminate the mandate if the provider acts contrary to its obligations and must immediately inform the AI Office, so the provider also needs an internal path that escalates compliance problems to whoever holds the appointment.
Which non-EU model providers need an authorised representative
Article 54 applies to a narrow set of providers: those established outside the EU who place a general-purpose AI model on the EU market. Five scoping questions decide whether the duty applies, whether an exemption removes it, and who holds the documentation the representative must verify. Confirm each conclusion with counsel for each model.
Article 2 reach to non-EU providers
Article 2 extends the Act to providers placing AI models on the EU market wherever they are established. A provider in the United States or elsewhere outside the EU is caught once its general-purpose model is made available in the Union, even if the company has no EU office. Check where the model is offered, downloaded, licensed or made available to EU customers, not only where the company is incorporated. Counsel should confirm this reading for each model and each market.
Placing on the market through partners or APIs
The duty attaches when a model is placed on the EU market, which can happen through your own API, through an EU cloud marketplace, or through a reseller or integration partner. Map every route by which EU users reach the model, including downstream products that embed it. Where a partner distributes the model under its own name, confirm who places it on the market and whether a written mandate is still needed. Keep this map current as distribution channels change.
Open-source exemption and its conditions
Article 54(6) exempts free and open-source models that publish their weights, architecture and usage information. The exemption is conditional: a provider must meet all three publication elements and the model must not present systemic risk. Check the license, the published weights, the architecture documentation and the usage information against the exemption, and record the reasoning. A model released with weights but without usage information does not qualify on this basis.
Systemic risk removes the exemption
A model with systemic risk does not benefit from the open-source exemption, even when it is free and publicly released. Classification depends on the model's capabilities and the compute used in training, so an open model can still fall within the systemic risk category. Before relying on the exemption, check whether the model meets the systemic risk criteria in the Act and whether the Commission has designated it. Document the assessment and revisit it when the model is updated or retrained.
Teams and third parties holding Annex XI documentation
The authorised representative must be able to verify the Annex XI technical documentation, so you need to know where that file lives and who maintains it. Identify the internal teams responsible for training records, evaluations, and model cards, and any contractors, cloud providers or dataset vendors that hold parts of the record. Confirm that the documentation can be produced on request and kept for the retention period. Gaps found here often decide whether the exemption argument holds.
What the written mandate must empower the representative to do
Article 54(3) sets the minimum content of the written mandate that a non-EU provider gives its authorised representative. The mandate must empower the representative to verify the Annex XI technical documentation and the provider's compliance with Articles 53 and 55. It must also require the representative to keep that documentation for 10 years after the model is placed on the market, to provide information to the AI Office on request, and to cooperate with the competent authorities. In practice, the provider should check that the mandate names each of these four duties in plain terms and that the representative has been given working access to the Annex XI file, not just a copy delivered once. Ask the representative which documents it will hold, where they will sit, and how it will be notified of a new model version or a material change to training or evaluation evidence.
The ten-year retention period runs from placing on the market, not from the last update, so the provider's documentation system has to outlive the model's commercial life. Confirm with counsel how the retention clock applies if a model is withdrawn, replaced or re-released, and whether the representative's archive can be exported in a usable format if the appointment ends. The provider's own version history should match what the representative holds, so that the same document can be compared across dates. A documentation platform that records versions, authors and changes, such as XWiki with its version history, can help the provider show what was current at each release, but the retention obligation itself stays with the appointed representative and the provider's mandate.
Article 54(5) adds a duty that providers often overlook. If the provider acts contrary to its obligations under the Act, the representative must terminate the mandate and immediately inform the AI Office. A provider therefore needs a contingency plan before any problem arises: who decides on remediation, how quickly the provider can supply a replacement representative, and how the handover of the Annex XI file will be executed. The contract should set out notice and cooperation steps for that scenario, including who contacts the AI Office and what evidence the representative will need to see. Treat this as a tabletop exercise to run before the model reaches the EU market, not a clause that is read for the first time after a dispute.
How an assessor tests the authorised representative mandate
This table compares each test an assessor runs on an Article 54 authorised representative arrangement, the evidence they request and the findings that most often appear. Read it as a checklist: a gap in any row can block the provider from showing that the representative was appointed and empowered correctly. The assessment is carried out by the supervising authority or an independent auditor, not by DeployOpen.
| Test area | Evidence requested | Common findings |
|---|---|---|
| Representative is EU-established | Registered address of the representative, company registry extract, and confirmation that the entity is established in an EU member state | Representative is a mailbox or service address with no established entity, or the registration does not match the name in the mandate |
| Written mandate against the four Article 54(3) powers | Signed mandate that covers verifying Annex XI documentation, verifying compliance with Articles 53 and 55, providing information to the AI Office on request, and cooperating with authorities | Mandate is unsigned or undated, or it omits one of the four powers, such as the duty to cooperate with authorities |
| Annex XI documentation is retrievable and dated | Current documentation set, version history, and a record showing when each version was created and approved | Documentation set is undated, held in several unlinked files, or cannot be produced within the time an information request allows |
| Ten-year retention start point | Retention policy stating that the ten-year period runs from the placement date of each model, and records of placement dates for each model version | Retention clock is tied to the last update or the document date rather than the placement on the market, or no placement date is recorded |
| Request-response path to the AI Office | Named contact, documented escalation steps, and a test request with timestamps showing how fast the representative can route and answer it | No named contact, the path depends on one person, or the test request was never run and the response time is unknown |
| Termination procedure | Written termination steps that trigger if the provider breaches its obligations, including the immediate notice to the AI Office under Article 54(5) | Procedure does not state who decides to terminate or how the AI Office is informed, or the termination clause is missing from the mandate |
How to implement the representative appointment and its evidence
This sequence takes a non-EU general-purpose AI model provider from scoping its open-source position to a tested route for answering AI Office requests, with a signed mandate and retention schedule on file at each stage.
Confirm the model scope and open-source position
Legal and product leads list every general-purpose AI model the organization places on the EU market, including versions, weights releases and hosted access. For each model, they record whether it is released as free and open source with public weights, architecture and usage information, and whether it could present systemic risk, since Article 54(6) exempts open models only when that systemic risk condition does not apply. Confirm the position with counsel and the AI Office guidance where needed. The output is a signed model register stating which models need a representative and the reason for each exemption decision.
Select and appoint an EU-established representative
Procurement and legal shortlist candidates established in the EU and ask each to confirm in writing that it can meet the Article 54 duties, including staff who can read technical documentation and respond to the AI Office. The provider's board or an authorised signatory approves the appointment. Confirm the candidate's capacity, conflicts of interest and continuity arrangements, and the terms on which it will be paid. The output is a signed appointment decision naming the representative, its EU address and a named contact person.
Draft the written mandate with the Article 54(3) powers
Counsel drafts a written mandate that gives the representative the four powers set out in Article 54(3): verifying the Annex XI documentation and compliance with Articles 53 and 55, keeping the documentation for the required period, providing information to the AI Office on request, and cooperating with authorities. The mandate also includes the termination clause from Article 54(5), which requires the representative to end the mandate if the provider acts contrary to its obligations and to inform the AI Office immediately. Both parties sign before the model is placed on the market. The output is an executed mandate stored with the model register.
Define where the Annex XI documentation lives and who updates it
Technical leads set up a single controlled repository for the Annex XI technical documentation for each model, with version control that records what changed, when and by whom. Assign an owner for each document section and a reviewer who must confirm changes before they are released to the representative. Give the representative read access so it can verify the documentation as its mandate requires. Commercial tools such as XWiki provide page version history and rollback, and BookStack lets administrators limit edit and view rights by role at shelf, book, chapter or page level. Confirm that any tool chosen can export a complete, dated copy. The output is a documented repository map with named owners and access rights.
Set the 10-year retention schedule from placement
Records and compliance staff build a retention schedule that counts ten years from the date each model is placed on the EU market, as Article 54(3) requires for the documentation. The schedule lists each document, its storage location, the legal hold process, and the disposal step that runs only after the period ends. Confirm with counsel how the date of placement is recorded for each model version and whether later versions reset or extend the clock. The output is a retention register, approved by legal, that the representative can also see.
Set up the AI Office request procedure
Compliance leads write a short procedure that describes how an AI Office request reaches the representative, how the provider's named contact is alerted, who gathers the information, who approves the response, and how the response is logged. The procedure also covers the cooperation duty with other authorities and the steps for ending the mandate if a breach is found. Test that the contact details are current and that a second person can cover absence. The output is an approved request-handling procedure and a current contact list held by the representative and the provider.
Run a dry-run request and record the result
Compliance staff send a simulated, clearly labelled request to the representative, asking for the Annex XI documentation for one model and a summary of its compliance status. Time how long the team takes to locate, review and deliver the material, and note any gaps in access, versioning or sign-off. Correct the procedure, repository or mandate where the dry run exposes a weakness, then file the test record with the model register. The output is a signed dry-run report with findings and a dated list of fixes, which the team repeats after material changes to the model or the representative.
Evidence that shows a valid authorised representative mandate
An authorised representative mandate is only as good as the records behind it. The cards below are the artifacts an assessor or the AI Office would expect to see, and they connect because each one proves a different part of Article 54: who was appointed, where they are established, what they can verify, how long records are kept, and how the relationship ends. Confirm each artifact with your own legal and compliance team before relying on it.
Signed written mandate
Article 54(1) requires a non-EU provider to appoint an EU-established representative by written mandate before placing a general-purpose AI model on the EU market. Keep the signed instrument dated before the first placement, with the representative's legal name, registered address and the model or models it covers. Check that the mandate text includes each power listed in Article 54(3), not only the appointment itself. Ask counsel whether the mandate needs notarization or specific signatory authority under your own jurisdiction.
Representative establishment record
The representative must be established in the EU, so the file should hold proof of that establishment, such as a registration extract from the relevant national register and a current contact address. Record the date you last verified it. A mandate with a representative who has moved, dissolved or lost capacity to act is a gap an assessor will find quickly. Schedule periodic re-checks and log each one with the reviewer's name.
Annex XI documentation register
The mandate must let the representative verify the Annex XI technical documentation and compliance with Articles 53 and 55. A register lists each document, its version, its owner and the release it describes, so the representative can see exactly what they are verifying. Version history matters here: XWiki keeps every page change under version control with what changed, when and by whom, and lets users compare or roll back versions. Confirm that your chosen tool preserves the same history for every document in scope.
Retention schedule tied to placement date
Article 54(3) requires the representative to keep the documentation for 10 years after the model is placed on the market. Tie the schedule to the placement date of each model version, not to the date a document was last edited, and record who may delete records and when. Include a legal hold procedure so records are not purged while an inquiry is open. Confirm with counsel how the schedule interacts with other retention duties that apply to your organization.
Access roles and permission overrides
The representative and the provider should each see only what their role requires, and those roles should be auditable. BookStack assigns user abilities through roles, and permissions can be overridden per shelf, book, chapter or page. Use that to give the representative read access to the Annex XI register while restricting edits to the provider's technical team. Review role assignments on a set schedule and keep the review record. Whether your chosen tool meets your retention and access needs is your decision, and you should confirm it against your own requirements before deployment.
AI Office request and termination log
Article 54(3) requires the representative to provide information to the AI Office on request and to cooperate with authorities. Keep a log of each request with its date, the information sent, the sender and the response time. Under Article 54(5), if the provider acts contrary to its obligations the representative must terminate the mandate and immediately inform the AI Office. Document a termination procedure that names who makes that decision, how the notice is sent and how a replacement representative would be appointed before the model stays on the market.
What meeting Article 54 costs in money and effort
This table compares each cost component of an Article 54 authorised representative arrangement by who is paid, whether the cost is one-time or recurring, and what drives it up or down. No supplied fact gives a fee for the representative, so use the table to structure written quotes and compare them line by line. The main takeaway is that the representative fee is the largest recurring item to price, and a self-hosted register removes license spend but not that fee.
| Cost component | One-time or recurring | What drives it | How to keep it down |
|---|---|---|---|
| Representative service fee, paid to the EU-established representative | Recurring, usually annual | Number of models covered, scope of mandate, volume of AI Office requests handled | Ask for a per-model fee schedule, confirm what counts as one model, and limit the mandate to Article 54(3) tasks |
| Legal drafting of the written mandate | One-time, with review on change | Whether the representative's standard form is used or the mandate is negotiated, and legal review hours | Start from the representative's template, and ask that the mandate name Articles 53 and 55 and the 10-year retention duty |
| Documentation register setup | One-time | Number of Annex XI and Annex XII documents, how many versions exist, and whether pages must be migrated from other tools | Reuse an existing wiki or document system, and map documents to a fixed index before migration |
| Retention storage and version history for 10 years | Recurring, for the full retention period | Document size, backup copies, storage location and the version history kept for each document | Keep archived versions in one controlled location, and confirm with the representative which copy is the official record |
| Staff time for handling AI Office and authority requests | Recurring | Frequency of requests, number of people who must answer them, and how quickly the representative must forward them | Name one owner and a backup, and keep a current contact sheet and document index ready |
| Outside review of the mandate | One-time, or on change | Changes to the model, the provider's structure, or the representative's terms, and whether counsel reviews each revision | Limit reviews to material changes and agree the review trigger in the mandate |
Who owns the representative, the evidence and the audit
The non-EU provider remains legally responsible for Article 54 compliance. It must make the written appointment of an EU-established authorised representative, decide what the mandate covers, and keep the representative informed. Legal, compliance and the teams that train and release the model each have a role, and the organization decides who signs the mandate and who answers when the AI Office asks a question.
- Legal owner of the appointment: Signs the written mandate, confirms the representative is established in the EU, and tracks renewals, changes of representative and the termination conditions in Article 54(5).
- Documentation owner: Maintains the Annex XI documentation that the representative must be able to verify, and confirms that every version handed over is the one the provider stands behind.
- Request-handling owner: Receives requests from the representative or the AI Office, sets a response path, and records who answered and when.
- Retention owner: Holds the 10-year retention duty for documentation after the model is placed on the market and confirms the storage survives staff changes and system migrations.
- Model release owner: Notifies the representative of material changes to the model so the mandate and the documentation stay current.
Before relying on any of this, confirm with your legal team which entity is the provider and which affiliate, if any, is named in the mandate.
An implementation partner such as DeployOpen can prepare the systems and evidence that the provider and the representative rely on. Under a fixed written scope, the work covers the documentation register, retention settings, access roles and evidence packs. The partner does not act as the authorised representative, does not sign mandates and does not issue any report or certificate.
- Documentation register: Builds a controlled index of Annex XI documents, their versions and owners, so that a request can be answered from a known source.
- Retention setup: Configures storage, backups and version history for a 10-year horizon in the client's own infrastructure, with written retention rules.
- Access roles: Defines who can edit, approve and export documentation, so the representative and auditors see approved versions without editing rights.
- Evidence packs: Assembles dated, traceable bundles that map each duty to the artifacts that show it, ready for an assessor to test.
- Handover documentation: Records how the systems were configured, how to restore them and how to run the register after the engagement ends.
The scope, deliverables and timeline are agreed in writing before work starts, and the client owns the resulting systems and records.
Independent auditors and certification bodies test controls and issue findings or reports. Where the question is compliance with the Act itself, the AI Office supervises general-purpose AI model providers under Article 88 and can request information directly. An auditor's work is only credible if it is separate from the people who built the evidence.
- Testing the mandate: Reviews the written appointment, its scope and whether it empowers the representative to verify documentation and cooperate with authorities.
- Testing retention: Samples documents and checks that the retained record matches what was placed on the market, for the required period.
- Testing access and change control: Checks who can alter documentation and whether changes are logged and reversible.
- Issuing findings: Only the auditor or supervising authority issues findings, reports or conclusions. No implementation partner or representative can do so on their behalf.
- Independence line: An auditor should not design the controls it tests, and a partner should not give an opinion on whether the provider complies.
Confirm with the AI Office and your counsel which assurance route applies to your model before you commission any external review.
Most organizations outsource technical preparation and keep legal accountability. Outsourcing the representative function itself is a separate decision, and the contract with that party determines whether the mandate can be carried out in practice. The question is what each party can actually deliver, not only what it is called.
- Usually outsourced: Storage configuration, register building, evidence pack assembly and access role design.
- Usually kept in-house: The decision to appoint, the content of the mandate, responses to the AI Office and the sign-off of the documentation.
- Appointed representative contract: Check whether it covers verification of Annex XI documentation, the 10-year retention duty, information requests, cooperation with authorities and the termination obligation.
- Quote requirements: Ask any partner for a written scope listing deliverables, what is excluded and who holds the records at the end.
- Confirm before signing: Identify the appointed representative by name and check what that party's contract covers, including who pays for work and who is liable for missed requests.
Where providers usually fall short on the representative duty
Article 54 is short, but the gaps that cause trouble sit in its timing, its mandate and the records behind it. Each card below names one gap, what it looks like in practice and the check that closes it before the AI Office asks.
Representative appointed after market entry
Article 54(1) requires a written mandate before the model is placed on the EU market, so an appointment made after the model was already offered in the EU leaves a compliance gap from day one. Providers often treat the representative as a later paperwork step tied to a contract or a launch announcement. Check the date of the signed mandate against the date the model first became available to EU customers, including API access and downloads.
Mandate missing required powers
A mandate must let the representative verify the Annex XI documentation and compliance with Articles 53 and 55, provide information to the AI Office on request, and cooperate with authorities. Generic engagement letters often cover fees and contact details but omit these powers. Also confirm the mandate requires the representative to end the arrangement if the provider acts contrary to its obligations and to inform the AI Office immediately.
Documentation without version history
The representative can only verify what it can see, and it must be able to show which version of the technical documentation applied at each date. When engineering teams keep model cards and training records in shared folders or chat threads, earlier versions are overwritten and the record of changes is lost. Use a documentation system that keeps version history with authorship and dates, and confirm that old versions can be restored and compared.
Retention clock started on the wrong date
Article 54(3) requires the documentation to be kept for 10 years after the model is placed on the market, so the clock is tied to market placement, not to the date a document was written or the date an internal project closed. Records created during training can be older than the placement date by years. Ask counsel to confirm the placement date for each model version and set retention periods from that date, with a legal hold process for open investigations.
Assuming open-source exemption without checking
Article 54(6) exempts free and open-source models with public weights, architecture and usage information, but only if the model does not present systemic risk. Providers often assume the exemption applies because the weights are public, without checking the model's systemic risk position. Record the classification analysis for each release, and treat any model that may cross the systemic risk threshold as requiring a representative until the analysis says otherwise.
No tested path for AI Office requests
The representative must provide information to the AI Office on request, and that can arrive with a short deadline. A mandate on paper does not show that the provider can pull the right documentation, route it through the representative and answer accurately. Run a tabletop exercise once a year with a sample request, time each step, and record who approves the response and where the evidence is stored.
What buyers ask before appointing an authorised representative
Does a non-EU general-purpose AI model provider have to appoint an EU representative?
Yes, unless an exemption applies. Article 54(1) requires a provider established outside the EU to appoint an EU-established authorised representative by written mandate before placing a general-purpose AI model on the EU market. The appointment has to be in place before the first placement, not after a regulator asks. The representative acts for the provider on compliance matters, so the mandate should be signed by someone with authority to bind the provider and should name the models it covers. Check the exact wording of the mandate against Article 54 in the consolidated EUR-Lex text before you sign.
Are open-source AI models exempt from the representative requirement, and when does that end?
Partly. Article 54(6) exempts free and open-source models that publish their weights, architecture and usage information, but only if the model does not present systemic risk. A model with systemic risk loses the exemption and the representative duty applies. Whether a model presents systemic risk is a classification question, so confirm the status of each model you place on the market rather than assuming it. Also confirm that the public information meets the conditions in the Article itself, because a model that withholds any of the three items does not qualify for the exemption.
How long must the representative keep the documentation, and from when does the period run?
The representative must keep the documentation for 10 years after the model is placed on the market, as set out in Article 54(3). The period is counted from placement, not from the date of appointment or the date the documentation was created. Retention is a duty of the appointment, so the storage system must be able to hold, retrieve and version the records for the full period, and access must be controlled so that the right people can answer requests from the AI Office. Confirm with your legal team how the 10-year period interacts with other retention rules that apply to your organization.
How much effort does the evidence work take, and what makes it larger or smaller?
The effort depends mostly on how complete your Annex XI and Annex XII documentation already is, and on how many models and versions you place on the EU market. The representative must be able to verify the Annex XI documentation and compliance with Articles 53 and 55, so the evidence set is effectively the provider's technical file plus proof that it is current. Effort rises with the number of model versions, the number of downstream providers you supply, and gaps in version history. It falls when documents are kept under version control with clear owners and dates. Ask your team to inventory the documents before you estimate effort, because that inventory sets the scope of the work.
Can our team handle the appointment and evidence work in-house?
Often yes, if you have a legal owner for the mandate, a documentation owner for Annex XI and XII, and a records process that keeps everything current. Appointing a representative is a contract and legal task, and the representative itself must be a separate EU-established entity, so most providers engage a firm for that role. The evidence work is an internal discipline: it needs a single source of truth, version history that shows what changed and when, and access controls that let authorised people answer AI Office requests. Teams that already run document control for other frameworks usually adapt faster. Be honest about who will be on call when a request arrives with a short deadline.
What can an implementation partner prepare for us, and what must we keep ourselves?
A partner such as DeployOpen can plan, set up and maintain the self-hosted systems that hold your documentation, including version control, access roles and retention settings, and can prepare the evidence pack in a structure your representative can review. Under the fixed-scope model, the scope, deliverables and timeline are agreed in writing before work starts. A partner cannot act as your authorised representative, sign the mandate, make compliance decisions for you, or certify your conformity. You keep ownership of the controls and the classification of your models, and the representative and the AI Office remain the parties that rely on your records.
What should we request in a written quote for this work?
Ask for a written scope that lists the models covered, the documents to be organized and version controlled, the systems to be deployed in your own infrastructure, the access roles and retention settings to be configured, and the handover materials. The quote should separate one-time setup from any recurring support, state what the partner will not do, and name the responsibilities of your legal representative and internal owners. Ask how changes to scope are handled, how the retention period will be configured and tested, and what acceptance criteria apply. Pricing follows from that written scope, so a vague scope will produce a vague quote.
How DeployOpen prepares Article 54 evidence
DeployOpen helps non-EU general-purpose AI model providers set up the systems and records that an EU authorised representative needs to verify, retain and produce. The organization keeps ownership of the appointment and the mandate, and an independent assessor or the AI Office reviews the result, while DeployOpen prepares the documentation environment and evidence trail.
How we scope
- We agree in writing which Article 54 duties the engagement covers, including the mandate, documentation retention and information requests.
- We confirm which model documentation sets the representative must verify, based on the provider's own Annex XI and Article 53 records.
- We confirm with your counsel which parts of the appointment and mandate remain outside DeployOpen's scope before work starts.
How we build
- We configure a self-hosted document repository with version history so each change to model documentation is traceable by author and date.
- We set role-based access so the EU representative and internal reviewers can see the records their mandate covers, and nothing beyond it.
- We map each retention and information-request duty to a named owner, a storage location and a review step inside your own infrastructure.
How we hand over
- We deliver the documentation structure, access model, runbooks and an evidence index that shows where each Article 54 record is held.
- We document the procedure for responding to an AI Office request, including who signs off and how responses are logged.
- We train your team and the representative's staff on the repository, so ownership of the records stays with your organization after handover.
How we support
- Ongoing support, upgrades and periodic reviews of the evidence set are available as a retainer, scoped separately in writing.
- We can update the repository and procedures when the Commission or the AI Office issues guidance that changes what must be kept.
- Confirm with DeployOpen and your legal advisers how retainer scope, response times and handover terms are written before you sign.
