What Article 13 asks providers to hand deployers
Article 13 requires a provider of a high-risk AI system to build the system so that deployers can interpret its output and use it appropriately, and to supply complete instructions for use in a digital or other appropriate format. The obligation has two halves. Article 13(1) is system transparency: the design must make output understandable to the people who receive it, which means engineering choices about explanation, confidence signalling and output format, not a document written after the fact. Article 13(2) and (3) form the information package: the provider's identity, intended purpose, tested accuracy metrics, robustness and cybersecurity levels, foreseeable circumstances that create risk, performance for specific groups, input data specifications, how to read the output, pre-determined changes, the human oversight measures under Article 14, computing and hardware resources, expected lifetime and maintenance, and how logs are collected and interpreted. Deployers depend on this package. Article 26(1) requires them to use the system in line with the instructions, so a deployer who does not have them cannot show correct use. Article 26(9) requires deployers to use the information when carrying out a data protection impact assessment under the GDPR, so missing or vague statements about risks and input data leave the deployer's own assessment incomplete. Providers should expect procurement teams to ask for the instructions before signing.
The instructions are hard to get right because every declared number must match a test. Article 15(3) requires accuracy levels and metrics to be declared in the instructions, so the figures in the document must trace to a dated test report with the data, population and thresholds used. Engineering owns the metrics, legal owns the claims about intended purpose and foreseeable misuse, and product owns the operating guidance. Assign one owner to reconcile the three, and keep a register that links each statement in the instructions to its evidence. Confirm with your notified body or market surveillance contact which format they expect before finalising the document. Do not confuse this with Article 50. Article 50 governs disclosure to people who interact with an AI system or see AI-generated content, such as a chatbot user or a viewer of a deepfake, and it applies to AI systems in its scope whether or not they are high-risk. Article 13 concerns the information flow from provider to deployer. A system can need both, and the two sets of documents answer different audiences.
Which systems and teams Article 13 reaches
Article 13 applies only once a system is classified as high-risk, so the first decisions are which systems fall in scope and who inside the organization owns each piece of the information a deployer will rely on. The cards below separate the scoping questions that change the amount of work from the teams that must supply the content. Article 50 is a separate duty and is covered at the end.
Annex III high-risk systems
Annex III lists the use cases the Act treats as high-risk, such as employment screening, credit scoring, and access to essential services. Article 13 reaches these systems once they are placed on the EU market, and the 2026 amendment moves their high-risk rules to 2 December 2027. Check each system against the Annex III wording and record the reasoning, because a system outside the list may still need a documented exemption decision under Article 6(3).
Annex I product systems
AI that is a safety component of a regulated product, or is itself such a product, falls under Annex I and follows the sectoral product rules. These systems are not covered by the Annex III date, and the 2026 amendment sets 2 August 2028 for them. Confirm with the product's conformity route which documentation Article 13 content must sit inside, since providers of Annex I products may fold evidence into existing sectoral files.
Provider and deployer roles
The provider builds the system and writes the instructions for use, while the deployer must follow them under Article 26. An organization that customizes a system, changes its intended purpose, or puts its own name on it may become the provider in law, which moves the Article 13 duty onto it. Map each system to a role before drafting any instructions, and record who signs the information the deployer receives.
Versions and third-party models
Each version that changes intended purpose, accuracy, or the model underneath needs its own instructions, and pre-determined changes must be described in them. When the system runs on a third-party general-purpose model, ask the model supplier for tested accuracy and limitation data, because the Article 13 content about accuracy and foreseeable risk depends on it. Confirm in writing what the supplier will provide and how often it updates.
Teams that own the content
Article 13 content draws on several teams: data science owns tested accuracy metrics and group performance, security owns robustness and cybersecurity levels, platform engineering owns logs and the computing resources, and product or human factors teams own the human oversight design. No single team can write the instructions alone. Assign one owner to assemble the document and sign-off roles for each section before drafting starts.
Article 50 applies separately
Article 50 governs disclosure to people who interact with an AI system or view AI-generated content, and it applies to AI systems in its scope whether or not they are high-risk. A chatbot used for customer service may owe a disclosure under Article 50 while owing no Article 13 instructions at all. Run the two checks as separate scoping questions so a system that is not high-risk is not assumed to be outside all transparency duties.
How an assessor tests the instructions for use
This table sets out how an assessor tests each element of Article 13 against the technical file, the test reports and the shipped product. Read it as a checklist of what to prepare: each row names the check, the evidence requested and the findings that most often delay a conformity assessment.
| Check | What the assessor compares | Evidence requested | Common findings |
|---|---|---|---|
| Interpretability (Art. 13(1)) | Whether the output description lets a deployer understand and use results appropriately | Output format descriptions, sample outputs with interpretation notes, deployer training material | Output described only as a score or label with no guidance on confidence or limits |
| Provider identity and intended purpose (Art. 13(3)(a)) | Instructions against the intended purpose recorded in the technical file and risk management file | Intended purpose statement, provider contact details, version history of the instructions | Purpose written in marketing terms that is broader than the tested use case |
| Foreseeable misuse (Art. 13(3)(b)) | Described circumstances that create risk against the risk register under Article 9 | Risk register extract, misuse scenarios, warnings linked to each scenario | Known misuse cases from testing absent from the instructions |
| Declared accuracy and metrics (Art. 13(3)(b)(ii), Art. 15(3)) | Metrics in the instructions against the test reports and validation results | Test reports, metric definitions, datasets used, confidence intervals where computed | Metrics declared that do not appear in any test report, or test reports with metrics left out of the instructions |
| Group-level performance (Art. 13(3)(b)(iv)) | Performance for specific persons or groups against the bias and subgroup analysis | Subgroup results, stated limits where data for a group was insufficient | No subgroup performance stated, or only an overall figure presented |
| Input data and logs (Art. 13(3)(b)(vi), (f)) | Input specifications against the data governance file, and log descriptions against the logging design | Input schema, data quality limits, log field list and retention statement | Log mechanisms described in general terms that do not match what the system records |
| Oversight, resources and lifetime (Art. 13(3)(d), (e)) | Human oversight measures against the Article 14 design, and resource and maintenance statements against the deployment architecture | Oversight procedures, hardware and compute requirements, expected lifetime and maintenance plan | Oversight described as available but not assigned to a named role or interface |
| Version control (Art. 13(3)(c)) | Pre-determined changes and the shipped build against the instructions in force | Change log, release record, signed copy of instructions tied to each build | Instructions out of step with the shipped version after a model or threshold update |
How to build the instructions for use step by step
This sequence turns the Article 13 requirements into a set of instructions for use that a deployer can act on. Each step produces a named document or record, so the final release can be traced back to the evidence behind every statement.
Define intended purpose and foreseeable risks
The provider's product, compliance and safety owners write a purpose statement that names the intended use, the people affected, the deployment context and the conditions the system is not meant for. Next, they list foreseeable misuse and circumstances that could create risk to health, safety or fundamental rights. The step is done when the purpose statement and a dated risk list are approved and linked to the risk management file. Illustrative example: a resume-screening tool whose statement excludes final hiring decisions.
Collect tested accuracy and robustness results by group
Engineers and test leads gather the accuracy metrics declared for the system, along with robustness and cybersecurity results from pre-market testing. Results are broken down by the groups the system is expected to serve, so performance differences are visible rather than averaged away. The output is a metrics appendix that states the metric definitions, test datasets, test conditions and known limits. The step closes when every declared figure can be traced to a test run that someone can reproduce.
Document input data specifications and output interpretation
Data owners and the system designers describe the input the system needs, including format, ranges, required fields, quality checks and known data conditions that degrade results. They then write how deployers should read each output, including confidence indications, thresholds, and what a result does and does not mean. Reviewers test the text against sample inputs and outputs. The step is complete when a deployer could prepare a valid input and interpret a sample output using only the document.
Document human oversight, resources and expected lifetime
The product owner and safety lead describe the human oversight measures the system is designed for, cross-referenced to the Article 14 design, and state the computing and hardware resources needed to run it. They also record the expected lifetime, the maintenance the provider expects, and the process for pre-determined changes. The output is a section that names who oversees the system, what they can see and stop, and what the deployer must maintain. Confirm each claim against the actual design before the section is accepted.
Describe log collection and interpretation mechanisms
Platform engineers document how the system generates logs, where they are stored, which fields they contain and how a deployer can export and read them. The text should match the automatic event logging design described for Article 12. The output is a logging description with example log entries and a reviewed list of fields. The step closes when an engineer who did not build the logging can follow the description and locate a sample event.
Assemble and review the instructions in a versioned format
Technical writers combine the outputs of the earlier steps into one set of instructions in a digital or other appropriate format, covering the provider identity, intended purpose, metrics, risks and the remaining Article 13 items. Legal, compliance and security reviewers check each statement against its source record, and reviewers record their comments. Keep the document under version control with an author, date and change history, so every statement can be traced to its source. The step is done when no statement lacks a linked source.
Release the instructions with the system under a signed record
Before the system is placed on the market, an accountable owner signs a release record that names the system version, the instructions version, the metrics appendix version and the test evidence reference. The instructions are delivered with the system, and the record is stored with the technical file. The output is the signed release record and a delivery copy of the instructions. Confirm with counsel which copy must be provided to each deployer and in what format.
Update the instructions when the system changes
Whenever the model, data, intended purpose or oversight design changes, the owner reruns the affected steps and issues a new instructions version with its own release record. Deployers receive the new version and a summary of what changed. The output is a revision log that links each change to its test evidence and approval. Confirm the trigger criteria for updates in your own change-management policy, since the Article 13 text does not set a fixed interval.
What the interpretability duty means in practice
Engineers carry the technical side of interpretability. Article 13(1) asks that the system operate transparently enough for deployers to interpret its output and use it appropriately, and it does not name a method such as feature attribution, surrogate models or example-based explanations. The engineering task is to choose signals that a deployer can act on for this specific system and to document where those signals stop being reliable. Output should carry enough context to be read: the model version, the input conditions, and any confidence or uncertainty measure the design supports. Limitations belong in the build record as well as the instructions, so a later change in data or behavior is visible.
- Output explanations: Return the factors or evidence behind a result in a form matched to the decision, such as the input fields or retrieved sources that drove it.
- Confidence signals: Expose a calibrated uncertainty or score only where tests show it tracks errors, and state what it does not measure.
- Documented limitations: Record known failure modes, out-of-distribution inputs and groups where performance is lower.
- Version tagging: Attach model and configuration identifiers to every output so logs and explanations match.
- Testing the signals: Verify in pre-release tests that explanations change when inputs change in the expected way.
Before release, confirm that every signal shown to a deployer has a documented meaning and a test behind it.
Deployers are the people who receive the output and decide what to do with it. Under Article 26(1), a deployer must use the system in line with the instructions for use, so the interpretation guidance the provider supplies sets the boundary of appropriate use. A deployer needs to know what a result means, how much weight it can carry in the actual decision, and when the outcome should be overridden. Training should be tied to the workflow the deployer runs, not to general AI awareness, because appropriate use depends on the decision context. Illustrative example: a loan officer who sees a score flagged as low confidence should know the instructions direct a manual review rather than an automatic decision.
- Reading the output: Explain each field, score or label in plain terms, including its scale and its limits.
- Override conditions: List the circumstances in which the deployer should disregard or escalate a result.
- Escalation paths: Name who receives a flagged output and what record the deployer must keep.
- Role-based training: Train operators on the decisions they make, and refresh the training when the system changes.
- Feedback channel: Give deployers a route to report output that looks wrong, so the provider can act on it.
Confirm that each deployer can state, without reference to the manual, when to trust a result and when to override it.
Compliance leads have to show that the interpretability duty was met, which means producing evidence that a reviewer can test. Article 13 does not specify the form of that evidence, so the lead should define it in advance and tie each claim to a record. The core artifacts are the instructions for use, the test results behind the stated accuracy metrics, and the training and override records for deployers. Version control matters because an assessor will ask whether the instructions match the system in production on a given date. The assessor's question is whether a trained deployer could use the output appropriately, so the evidence should show the instructions were tested against real operator behavior, not only written.
- Instructions for use: Keep a versioned copy tied to each released system version and to the stated intended purpose.
- Test linkage: Map each interpretability claim to the test or measurement that supports it.
- Training records: Retain who was trained, on which version, and when.
- Override and escalation logs: Show that overrides and escalations occurred and were reviewed.
- Change control: Show that updates to outputs or limits triggered a revised instruction set.
When preparing for an assessment, ask the independent assessor which evidence format they expect, and confirm the record system can produce it. An implementation partner can prepare the records, but only the independent assessor or certification body issues any conclusion on conformity.
Evidence that shows the instructions meet Article 13
Article 13 is met on paper by the instructions for use, but an assessor will test whether each statement in them traces to a test result, a configuration and a release. The six artifacts below are the evidence set that connects the instructions to what the system actually does, and each needs an owner and a release tag so it stays accurate between assessments.
Versioned instructions for use
The instructions for use are the document a deployer relies on, so every released version needs its own identifier, change log and approval record. Tie each version to the software build and model version it describes, and keep superseded versions available so a deployer can see what they were told at the time of use. Store the document in a system that records who changed what and when, and that lets reviewers compare two versions side by side. Confirm with your document platform how it handles rollback and access control before relying on it.
Accuracy and robustness test reports
Article 15(3) requires accuracy levels and metrics to be declared in the instructions, so each declared figure needs a test report that reproduces it. Each report should name the metric, the dataset version, the threshold and the release it was run against, and it should record failed runs as well as passing ones. Robustness results belong in the same set because the instructions must also state robustness and cybersecurity levels. When a figure in the instructions no longer matches the latest test, the instructions must change before the next release ships.
Group-level performance results
Article 13 requires the instructions to describe performance for specific groups where the system is expected to behave differently. Keep a results table per group, with the group definitions, sample sizes and the metrics used, so the claim can be re-run. Where a group is too small to measure reliably, state that limit in the instructions rather than omitting the group. Refresh these results whenever training data, input handling or the deployment population changes, because group performance often shifts without any change to the headline accuracy.
Input specification and output interpretation guides
Deployers can only use the output appropriately if they know what input the system accepts and what the output means. Document the accepted input format, data ranges, languages, and the conditions that produce unreliable output, along with examples of how to read a score, label or confidence value. Mark these guides with the release they describe, and check them against the actual interface after each change. Illustrative example: a credit scoring output described as a probability needs a note on the population on which that probability was calibrated.
Oversight, resource and lifetime documentation
The instructions must describe the human oversight measures under Article 14, the computing and hardware resources needed, the expected lifetime and the maintenance required. Keep a current record of the oversight controls as built, the staffing or roles they assume, the hardware and capacity figures measured in your environment, and the planned end of support. Verify these against the deployed infrastructure, since a figure copied from an early design often no longer matches. Ask a deployer to confirm the resources they must provide before the instructions are issued.
Log mechanism descriptions
Article 13 requires the instructions to explain how logs are collected and interpreted, so the description must match the logging that the system performs. Describe each log type, what fields it records, where it is stored, how long it is kept and how a deployer retrieves it. Trace records from a sample run through the logging tool to confirm that every field named in the description appears in practice. Re-check this description after any change to the logging pipeline, since a silent change in field names is a common reason an assessor finds the description out of date.
What meeting Article 13 costs in money and effort
This table breaks down the cost components of meeting Article 13 for a high-risk system, showing who is paid, whether each item is one-time or recurring, and what drives it up. Read it to scope internal work against outside help, and use the quote column to decide what to request in writing. No prices or durations are given because none were supplied for this topic.
| Cost component | Who is paid or who does the work | One-time or recurring | What drives it and what to request in a quote |
|---|---|---|---|
| Interpretability and output explanation work | Internal ML engineers, or an implementation partner, to design how outputs are explained to deployers | One-time design, then recurring when the model changes | Model complexity and the number of output types. Request the deliverables in writing, such as explanation templates and worked examples. |
| Group-level accuracy testing | Internal data science or test teams, or a testing provider, to measure performance for specific population groups | Recurring with each release and each new test dataset | Number of population groups and intended-use scenarios. Ask whether the quote covers test data preparation and the report format. |
| Accuracy metric declaration | Internal quality or ML staff, reviewed by engineering leads | Recurring with each retest | Number of metrics and declared thresholds. Confirm which metric definitions the quote assumes and who signs off on them. |
| Technical writing of instructions for use | Internal technical writers, or a documentation partner, with engineering review | One-time drafting, then recurring updates | Number of systems and deployer audiences. Request a document outline and a review cycle so the quote states who edits and who approves. |
| Legal review of intended purpose and foreseeable misuse | Internal legal or compliance staff, or outside counsel | One-time per system, then recurring on scope change | Number of intended uses and jurisdictions. Ask for the scope of counsel's review in writing. |
| Logging and oversight documentation | Platform engineers and security staff, to describe logs and human oversight measures | One-time build, then recurring maintenance | Logging architecture and retention design. Confirm whether the quote covers the log collection mechanism described to deployers. |
| Evidence upkeep per release | Release managers and document owners, internally or through a retainer | Recurring with each release | Release cadence and the number of versions in deployer hands. Ask how changes to pre-determined changes are recorded and versioned. |
| Auditor or assessor sampling | The independent auditor or assessor, paid by the organization | Recurring at each assessment cycle | Sample size set by the assessor and the number of systems in scope. Ask the assessor to confirm sampling method before fieldwork. |
Which self-hosted tools can keep the evidence current
Can XWiki keep AI system instructions for use under version control?
Yes. XWiki keeps every change to a page under version control, recording what changed, when and by whom, so you can compare any two versions and roll back to an earlier one. That history is useful for showing which version of the instructions for use was in force when a deployer received them. XWiki is licensed under LGPL-2.1-or-later, which you should confirm against your own distribution and internal use. The tool keeps the record, but the organization still decides what the instructions must say and who approves each release.
How does BookStack control who can edit AI documentation?
BookStack gives users abilities through the roles assigned to them, and permissions can be overridden per role at the shelf, book, chapter or page level. You can therefore let product owners edit intended-purpose and limitation sections while restricting accuracy metrics and oversight measures to a smaller group of reviewers. This matters for Article 13 because the instructions must come from a controlled source. BookStack is licensed under MIT. Confirm that its role model meets your approval workflow, since it manages access to documents rather than enforcing review sign-off.
How can garak output support robustness evidence for deployers?
garak 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 attempts that found a vulnerability. Those files can support the robustness and cybersecurity levels you state in the instructions for use, and the probe results can be linked to the version of the system tested. garak is licensed under Apache-2.0. It probes language models only, so it will not cover the full system, retrieval layer or tools, and you should confirm its coverage against your own threat model.
How does Langfuse help describe the logging mechanism?
Langfuse records traces that capture each operation in a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. Those traces help you describe how logs are collected and interpreted, which Article 13(3) asks the instructions to cover. Langfuse is licensed under MIT. Check what your deployment stores, how long traces are retained, and whether personal data appears in inputs and outputs, because that affects GDPR obligations and the logs you can disclose.
Do these tools make a high-risk AI system compliant on their own?
No. These tools produce records and test results that support evidence, but they do not establish compliance alone. The provider must decide the intended purpose, declare accuracy levels, define oversight measures and approve the instructions for use. An independent assessor or notified body, where one is required, reviews the result, and only that body issues a report or certificate. DeployOpen can plan, install, configure and document these tools within your infrastructure, and it prepares evidence for assessment, but it does not issue audit reports or certifications.
Who should own the evidence that these tools generate?
The organization owns the controls and the evidence, and it should assign named owners for each document. Engineers usually own traces, probe reports and logs, while product, legal and compliance teams own the instructions for use and their approval. Setting these roles in BookStack or XWiki before the first release avoids unclear accountability later. DeployOpen can advise on the division of work and configure the systems, but the approvals and the final decisions remain with your staff.
What should we confirm before we rely on these tools for evidence?
Confirm that each tool's license terms fit your use, which are LGPL-2.1-or-later for XWiki, MIT for BookStack and Langfuse, and Apache-2.0 for garak. Then confirm the versions you deploy, retention settings for logs and traces, access controls, and backup procedures. Check with your assessor how they expect to see version history, approval records and test results. Finally, confirm that the tools cover the components in your architecture, since none of them covers the whole system alone.
How much effort is needed to run these tools, and what drives it?
The effort depends on how many systems you run, how many people edit documentation, how often you test, and how much trace data you collect. Setup work includes hosting the tools inside your own cloud account or data center, configuring roles and retention, and linking test outputs to model versions. Recurring work includes reviewing probe results, updating instructions when the system changes, and checking that logs are retained as planned. Ask any implementation partner for a written scope that lists these items, since a fixed scope makes the cost and timeline easier to compare.
Who does what for Article 13
The provider is the organization that develops the high-risk system or has it developed and places it on the market under its own name. The provider's team owns every accuracy claim, every statement of intended purpose and every line of the instructions for use. Those statements become commitments to deployers, so the people who approve them must be able to defend the underlying test results.
- Accuracy claims: Product, data science and quality leads agree the metrics, test populations and conditions that will be declared in the instructions, and they decide what the system is not claimed to do.
- Instructions for use: Technical writers, product owners and compliance staff draft the document covering purpose, risks, oversight measures, resources and log interpretation, then keep it aligned with each release.
- Pre-determined changes: The team defines which model or configuration updates were planned in advance and how those changes will be described to deployers.
- Release sign-off: A named accountable owner confirms that the instructions match the released version before the system is placed on the market.
- Post-release upkeep: The team updates the instructions when performance, risks or intended use change.
Confirm with your legal counsel which legal entity acts as provider in your supply chain, since the duties follow that role. Also confirm how your quality management system assigns sign-off authority for these documents.
An implementation partner helps the provider build the systems that produce the documentation and evidence. This work is preparation and engineering. The partner does not decide what the system claims, and it does not approve the instructions for use or confirm that the system conforms.
- Documentation systems: Partners configure a version-controlled knowledge base, set roles and approval workflows, and link instructions to specific model and release identifiers.
- Test harnesses: They build repeatable evaluation pipelines that measure the declared accuracy, robustness and group-level performance, and they store the raw outputs.
- Evidence capture: They configure tracing and logging so that the provider can show how the system behaved in testing and in operation, including the log mechanisms that the instructions describe.
- Security and oversight tooling: They support the cybersecurity testing and human oversight interfaces that the instructions reference.
- Handover: They document how each artifact was produced so the provider's team can maintain it without the partner.
When you request a quote, ask the partner to state in writing which deliverables it prepares and which decisions remain with your team, and ask how it handles access to your test data and models.
An independent assessor or notified body checks conformity where the Act requires one. Most Annex III high-risk systems use the internal-control route in Annex VI, which means the provider assesses its own conformity without a third party. Notified bodies become involved for some biometric systems and for Annex I products under Article 43, so confirm which route applies before planning any external review.
- Independence: The assessor must not have designed, built or maintained the system or its documentation, so the partner that prepared the evidence cannot also be the reviewer.
- Scope of review: The assessor tests whether the instructions match the system's behavior and the test results, not whether they are well written.
- Evidence requests: Expect requests for test records, version history, approval records and log samples.
- Output: Only the assessor or notified body issues a conformity finding or certificate. Nobody else may describe a system as certified.
- Timing: Ask whether the assessment is required before placement on the market and whether it covers later changes.
Read the applicable sections of the Act and confirm with the assessor, in writing, whether its engagement covers Article 13 or the full conformity file.
Where Article 13 work usually falls short
Instructions for use are the document a deployer relies on to run a high-risk system correctly, so most shortfalls trace back to information that was written too early, drawn from the wrong model, or left out. The five gaps below connect because each one leaves a deployer unable to interpret output, judge accuracy or assess risk. Each card names the check that closes it.
Instructions written before tests finish
Teams often draft instructions for use from the design brief, then leave accuracy, robustness and limitation statements as placeholders until testing ends. The result is a document that describes intent rather than tested behavior. Close the gap by making the instructions a controlled document with a release gate: no version ships until every tested accuracy metric, limitation and oversight measure has a cited test result. Ask for the test report reference beside each claim.
Metrics that differ from the shipped model
Accuracy figures quoted in instructions often come from an earlier model, a development dataset or a configuration that was later changed. Article 15(3) expects the declared accuracy levels and metrics to match the system as placed on the market. Check that each reported metric records the model version, dataset, threshold and test date, and that a change to any of them triggers a review of the instructions before the next release.
Missing foreseeable misuse
Instructions frequently describe the intended purpose and omit the foreseeable circumstances that create risk, such as use on populations outside the test data, unsupported input formats or reliance on outputs without review. Article 13 requires these to be stated. Run structured misuse analysis with product, support and red team staff, and record each scenario with its risk and the mitigation the deployer must apply. Adversarial probing of language-model components can surface failure modes that the design team did not anticipate.
Log mechanisms undocumented
Teams often generate logs but never explain to deployers what is recorded, where it is stored, how long it is kept or how to interpret an entry. Article 13 requires the instructions to describe the mechanisms for collecting and interpreting logs. Document the log schema, retention location, access method and an example of reading one event, and confirm that the logging design meets the record-keeping duties in Article 12 before the documentation is published.
Deployers without DPIA inputs
Article 26(9) expects deployers to use the instructions when carrying out a GDPR data protection impact assessment, so a thin document leaves them unable to complete the assessment. Provide input data specifications, the categories of personal data the system processes, performance for specific groups and the resources needed for oversight. Ask a sample deployer to draft a DPIA from the document alone and record every question they could not answer. Treat each unanswered question as a gap in the instructions.
Questions buyers ask about Article 13 effort and outside help
How much effort does Article 13 compliance take for a high-risk system?
The effort depends on how many high-risk systems are in scope and how much usable documentation already exists. Article 13 is mostly structured writing: instructions for use that cover the provider's identity, intended purpose, tested accuracy metrics, robustness and cybersecurity levels, foreseeable risks, performance for specific groups, input data specifications, output interpretation, pre-determined changes, human oversight measures, computing resources, expected lifetime and log mechanisms. Effort rises when metrics have never been measured, when logs are not yet collected, or when several teams must agree on the intended purpose. Ask any partner or internal lead to estimate effort per system, listing which of these items already exist and which must be created.
Can we write Article 13 instructions for use in-house?
Yes. The organization owns its controls, so an internal team can draft the instructions for use. The work usually needs a product owner to define intended purpose, engineers to produce and document metrics and log mechanisms, a security lead to describe robustness and cybersecurity levels, and legal or compliance staff to review every claim before release. Teams often bring in outside help for gaps such as metric design, log architecture or a second review of the wording. An implementation partner can prepare the systems and evidence, but the organization remains responsible for what the instructions say.
What does Article 13 need from engineering and legal teams?
Engineering and legal teams share the work, and each has a distinct set of inputs to produce:
- Engineering: tested accuracy metrics that Article 15(3) requires to be declared in the instructions, performance results for specific groups, input data specifications, hardware and computing resource figures, and a documented method for collecting and interpreting logs.
- Legal and compliance: the wording of the intended purpose, the list of foreseeable circumstances that create risk, consistency with the deployer duties in Article 26, and support for the data protection impact assessments that Article 26(9) expects deployers to run.
Agree early on who signs off each statement, because an accuracy figure that engineering cannot reproduce will create problems in review.
When do the Article 13 duties for high-risk systems apply?
The high-risk rules in Chapter III Sections 1 to 3, which include Article 13, apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems. Regulation (EU) 2026/1744 moved both dates back from 2 August 2026 and 2 August 2027, as set out in the consolidated text of the AI Act. Teams should not treat these dates as the start of the work. Metrics, logs and instructions need to exist before a system is placed on the market, so the plan should work backward from each system's planned release. Confirm the dates against the consolidated EUR-Lex text before fixing a project schedule.
Does an assessor certify our Article 13 instructions for use?
No assessor certifies the instructions for use as a standalone document. Most Annex III high-risk systems use the internal-control conformity assessment in Annex VI, so the provider carries out the assessment itself. Notified bodies are involved for some biometric systems and for Annex I products under Article 43. An independent auditor can test the instructions and their supporting evidence as part of a voluntary review, and that report is the auditor's opinion, not a certificate issued by the Act. DeployOpen prepares the documents, metrics and logging evidence for that review, but it does not issue audit reports, attestations or certifications.
What should we ask a partner to include in an Article 13 quote?
Ask for a written scope before any work starts. A useful quote lists each high-risk system in scope, the Article 13 deliverables for each one, which accuracy metrics and group-level tests are included, how log collection will be configured, how many review cycles are covered, and how documents will be handed over and kept current. It should also state what is excluded, such as legal opinions, notified body fees, auditor fees and ongoing testing. DeployOpen works on fixed scope agreed in writing, does not publish a price list, and provides a quote that follows from that written scope.
Which Article 13 costs recur after the first set of instructions is written?
Article 13 is not a one-time document. The instructions must reflect pre-determined changes, updated accuracy metrics and any change to the expected lifetime or maintenance plan, so each model update can trigger a revision. Log mechanisms also need upkeep, including storage, retention and periodic checks that logs still capture what the instructions describe. Recurring costs therefore depend on how often systems change and how many people maintain the documents. Ask a partner which items are included in the first delivery and which fall under a retainer for upgrades, support and continuous testing.
Can open-source tools help produce Article 13 evidence?
Open-source tools can produce supporting evidence, but they do not satisfy Article 13 on their own. Self-hosted XWiki keeps version history of each page, showing what changed, when and by whom, which helps show how the instructions were maintained. BookStack role-based permissions can control who edits and approves the instructions. Langfuse traces record inputs, outputs, timing and tool calls for LLM-based systems, which can support the log mechanisms described in the instructions. garak writes JSONL reports of probing attempts, which can feed robustness statements. Confirm each tool's capabilities against your own environment before relying on it in an assessment.
How DeployOpen prepares Article 13 evidence
DeployOpen starts Article 13 work with a written scope that names the high-risk system, the provider organization that owns the instructions for use, and the deliverables the client expects before anything is built. The scope should state which parts of the instructions for use DeployOpen drafts, which parts only the provider can confirm (such as tested accuracy metrics, robustness levels and expected lifetime), and which parts the client's engineering and legal teams sign off. Deciding those owners up front is the difference between an instructions document that is complete on paper and one that a deployer can actually act on. The client owns the content and the conclusions; DeployOpen prepares the structure, the source material and the evidence trail.
Inside the client's own cloud account, data center or air-gapped network, DeployOpen can set up a self-hosted wiki such as XWiki, which keeps every change under version control and lets reviewers compare versions and roll back. Access to the instructions for use can be controlled with BookStack roles, with permissions overridden per shelf, book, chapter or page, so that engineering, compliance and deployer-facing staff each see the sections they own. Runtime evidence for the Article 13(3)(f) log mechanisms and the transparency of the system's outputs can be captured with Langfuse traces, and the accuracy and robustness claims that Article 15(3) requires the instructions to state can be checked with garak probes. Each of these tools produces records, not conclusions. Whether the declared metrics are adequate, and whether the instructions are sufficient for deployers, remains a determination for the provider and its independent assessor.
DeployOpen also runs security testing against the system and its interfaces, which feeds the cybersecurity levels that the instructions must describe. Before any assessment, the client should confirm with its assessor which evidence the assessment will accept, how the instructions will be tested, and who will issue any report. DeployOpen does not issue audit reports, attestations or certifications. Independent auditors, assessors and certification bodies do that work, and the client should choose them separately. Where a conformity route requires a notified body, that body is also independent of DeployOpen. The client should ask for the scope, deliverables and evidence list in writing and confirm them against the EUR-Lex text of Article 13 before work begins.
