Article 14 human oversight: what the requirement asks for and why it is hard
Your high-risk system is being prepared for the EU market, and someone on the team, or in your board pack, has to prove that people can control it. Article 14 requires oversight to be designed into the system before it is placed on the market, not added as a policy after launch. The provider must either build oversight measures into the system, identify measures for the deployer to put in place, or do both. The measures must match the risks the system creates, how autonomous it is, and the context in which it will be used. A credit scoring model that a loan officer reviews before each decision and a fully automated triage tool that acts on its own call for very different designs, and the file should show why the chosen measures fit the system you actually ship.
Oversight is hard to prove because it is a property of people, process and interface working together, so no single control demonstrates it. A user interface can expose the right information and still fail if reviewers are not trained, are measured on throughput, or lack the authority to disagree with the output. Process can be sound on paper and still break if nobody is assigned to review, or if escalation paths are unclear. Confirm early which of these pieces you own as the provider and which you hand to the deployer, because the deployer side is governed by Article 26, which requires oversight to be assigned to people with the necessary competence, training, authority and support.
Start by writing down, for each high-risk use, who the overseer is, what they can see, what they can change, and how they stop the system. Then ask your engineering and product teams to demonstrate those paths in a test environment and record the results. Gaps found at this stage are cheap to close, while gaps found by an assessor or market surveillance authority after launch are expensive. Your legal and compliance leads should confirm the classification of each system first, since Article 14 applies only to systems that are high-risk, and the dates that apply to them.
Which systems, teams and third parties Article 14 reaches
Article 14 applies to the people who design, deploy and operate a high-risk system, and to the vendors whose choices shape what those people can do. Each card below names one scoping decision that changes the oversight work, so you can confirm your role before you plan the controls.
Systems you provide
Providers build oversight into the system before it is placed on the market. Article 14 expects human-machine interface tools that let people oversee the system in use, and oversight measures that are built into the system by the provider, identified for the deployer, or both. Confirm first whether your system falls under an Annex III category or is a product covered by Annex I legislation, because the Annex I route follows the sectoral conformity file. Also check whether you place the system on the market under your own name, since that decides who carries these duties.
Systems you deploy
Deployers run oversight the provider has specified, and Article 26(2) requires them to assign it to people with the necessary competence, training, authority and support. The scoping question is whether you use the system for its intended purpose or have changed how it is used, because that determines which oversight measures the provider identified for you. Check that named overseers can stop or override the system, that they have time to review output, and that their authority appears in written job roles.
Remote biometric identification
Annex III point 1(a) covers remote biometric identification, and Article 14(5) bars acting on an identification unless at least two competent people verify it separately. The scoping decision is whether your deployment falls within the law enforcement, migration, border control or asylum exception, where Union or national law may consider the two-person check disproportionate. Confirm the exception against the national law that applies to you. Document who the two verifiers are, what competence they hold, and how each check is recorded.
Third-party model and platform vendors
Vendors make design choices that limit overseers, such as whether confidence signals are shown, whether outputs can be overridden, and whether a stop control exists outside the vendor's own console. Article 14(4) expects overseers to interpret output and interrupt the system, so those capabilities must exist in what you deploy. Ask vendors for interface documentation, override logging, and contractual notice before changes that alter oversight behavior. Confirm which party controls each function.
Dual-role and self-hosted systems
An organization that builds a high-risk system in-house and runs it for its own staff holds both the provider and deployer roles. Self-hosting on your own infrastructure places the stop mechanism, logs and access control under your management, so the design record and the operating procedure become one body of evidence. Check whether a substantial modification to a purchased system turns you into a provider, and whether an open-source base model changes which duties sit with you. Confirm both roles with counsel before work starts.
What overseers must be able to do once a system is live
How can we show an overseer understands a high-risk AI system's limits?
Show it with a documented walkthrough that each overseer completes and passes before the system goes live. The provider should document the intended purpose, known failure modes, input conditions where accuracy drops, and populations the system was not validated for. A practical test places the overseer in front of cases that fall outside those limits and asks them to state, before reading the output, whether the system can be relied on in that case. The interface or procedure should display uncertainty or confidence signals, and the instructions for use must match what the screen shows. Evidence includes signed training records, the test scenarios with recorded answers, and the version of the instructions each overseer received. Keep these in version-controlled documentation such as XWiki so you can show which version applied on a given date.
How do we test whether overseers defer to AI output too readily?
Test it with seeded errors: include cases where the system is known to be wrong and measure how often overseers accept them. Run the same cases with and without the system's recommendation to see whether the recommendation changes the decision. The interface should not present the suggestion as the default action, and it should make the basis for the output visible. Training should name automation bias directly and show worked examples of it. Evidence includes the scenario set, each overseer's recorded decisions, the acceptance rate on incorrect outputs, and the corrective action taken when that rate is high. Any threshold you set is your own decision, so document the reasoning in your risk management file and confirm the approach with your assessor or legal team.
What does a test for correct interpretation of AI output involve?
The test checks whether an overseer can explain, in their own words, what an output means and what action it supports. Use a set of representative cases, including scores near decision boundaries, flags with different causes, and outputs that look plausible but are wrong. Ask overseers to write their interpretation before they see the system's explanation, then compare the two. Where the system gives a score, the documentation should define the scale, the units and what each band means. Evidence includes the case set, the interpretations recorded per overseer, and the gap analysis that led to retraining or interface changes. Logging matters here too. Tracing tools such as Langfuse can record the inputs, outputs and metadata of each request, so a reviewer can reconstruct what the overseer saw at the time of a decision.
How do overseers override an AI output and prove they did?
Overseers need a working override path that takes one clear action, with no extra approval step that makes it impractical in use. The override should change the downstream state of the process, so the human decision is the one that is carried out. Test it in a non-production environment by overriding outputs in each scenario and confirming that the downstream system follows the human decision. Record the user, timestamp, reason and resulting state for every override. Article 26(2) asks deployers to assign oversight to people with the necessary competence, training, authority and support, so the authority to override should be written into the deployer's role definitions. Tools such as BookStack can document which roles hold which abilities, though the permissions in your production system must be configured and tested separately.
How do we build and test a stop control for a high-risk AI system?
A stop control must halt the system in a safe state. That means it stops new actions, places pending actions into a defined condition, and avoids leaving partial writes or half-completed transactions. Design the control so it is reachable from the overseer's interface and from the operational procedure, and document who may trigger it and who may restart the system. Test it in every deployment environment by triggering the stop during normal operation and during a busy period, then checking the system state, queued work and downstream effects. Evidence includes the runbook, dated test records, screenshots or logs showing the stop, and the trace of the last operations before the halt. The time to halt is a figure you should set and measure yourself, and your engineering team or implementation partner should confirm the exact behavior for your architecture.
Who should the deployer assign to oversee the system, and who builds the controls?
The deployer assigns oversight to named people who have the competence, training, authority and support to carry it out, and the organization owns that assignment and the decisions made under it. The provider's role is to build the oversight measures into the system or to identify them so the deployer can implement them. An implementation partner can prepare the stop mechanism, logging, interface changes and documentation, and can help run the scenario tests. It does not decide who oversees the system and cannot issue an assessment or certificate, since only an independent assessor or certification body does that. Ask any partner for a written scope that lists each oversight deliverable, the environments it covers, and the evidence it will hand over. Cost depends mainly on the number of systems, the depth of interface work, and the staff time needed for training and testing.
How an assessor tests human oversight
This table compares the five checks an assessor is likely to run on Article 14 human oversight, what each check asks the organization to produce, and the failure patterns that show up most often. Read each row as a test the assessor will attempt, not as a self-assessment checklist. The main takeaway is that a documented stop control or a named overseer means little until someone has shown it works in a live walkthrough.
| Test approach | Evidence requested | Common findings |
|---|---|---|
| Review of the oversight design and human-machine interface | Design specification showing where oversight measures sit, the interface screens overseers use, and the displayed confidence, limits and alerts | Oversight is described in policy but the interface does not show the output context an overseer needs to interpret it |
| Walkthrough where the assessor tries to override and stop the system | Live demonstration or recorded test run of override and stop, with logs showing the system halted and the output was not acted on | Stop control is documented but never tested, or it stops the interface while a downstream process keeps running |
| Review of training and competence records for overseers | Training content, attendance records, competence criteria and records showing overseers understand capacities, limits and automation bias | Training is a one-time slide deck with no assessment, and no record ties individual overseers to the system they supervise |
| Review of the authority and support given to overseers | Role descriptions, escalation paths and written authority to decide not to use or override output, as the deployer must assign oversight under Article 26(2) | Overseers lack authority to override in practice, so they approve outputs by default under workload pressure |
| Review of the instructions that tell deployers what oversight to implement | Instructions for use describing the oversight measures the provider built in or expects the deployer to apply, with the matching controls | Instructions name oversight measures that the product does not provide, or leave the deployer to guess how to implement them |
| Check of the two-person verification step for remote biometric identification | Procedure and configuration showing that no identification is acted on until two competent people verify it separately, plus logs of each verification | Second check is a rubber stamp viewing the same result without independent review, or the workflow lets one person act alone |
| Check of monitoring and logs that show oversight happened in operation | Event logs and records of overrides, stops and reviewer decisions over the period under assessment | Logs capture system outputs but not the human decisions, so the assessor cannot show oversight took place |
Implementing Article 14 in six steps and the output of each
This sequence turns the Article 14 duty to design for effective human oversight into a set of documented measures, interface controls, competence requirements and tested stop procedures that a provider can hand to deployers and show to an assessor.
Confirm risk, autonomy and context of use
The provider starts by fixing the system's intended purpose, the level of autonomy its outputs have in practice, the setting where it runs and the people affected by it. Risk, product, legal and domain staff should agree this in writing, because every later oversight decision depends on it. The output is a context-of-use record that names the decisions the system supports, the failure modes that matter and the users who will oversee it. The step is done when a reviewer outside the build team can read the record and explain what the system is for and where it could cause harm.
Map risks to oversight measures
Using the context record, the provider decides which oversight measures to build into the system and which to identify for the deployer to implement, or a mix of both. Each identified risk should map to at least one measure and to an owner for that measure. The output is a risk-to-measure mapping that shows, for each measure, whether it is provider-built, deployer-implemented or shared. The step is complete when every high-impact risk from the risk management file has a named measure and the split of responsibility is clear enough to carry into the instructions for use.
Specify the interface and override and stop controls
The engineering team specifies the human-machine interface so overseers can see what the system is doing, understand its limits, notice when its output looks wrong and decide not to use it. This includes how outputs are presented, whether confidence or uncertainty is shown, how automation bias is countered in the design, and where override and interrupt controls sit. The output is an interface specification with a stop mechanism described as a procedure that halts the system safely, including what happens to work in progress. The step is done when the specification answers each Article 14(4) capability in a concrete design feature.
Define competence, training and authority for overseers
The provider and the deployer together define who may oversee the system, what competence they need, what training they receive and what authority and support they have to intervene. Under Article 26(2), deployers must assign oversight to people with this competence, training, authority and support, so the provider's documentation should state the profile clearly. The output is a training plan and a role profile that lists the knowledge, system access and escalation path for each overseer. The step is complete when each named oversight role has a defined profile and a training record that the deployer can keep.
Write instructions that assign oversight to deployers
The provider writes the instructions for use so the deployer knows which oversight measures it must implement, how to run them and what to monitor. The instructions should reflect the split from the mapping step and describe the interface, the override and stop procedures, the limits the overseer must watch for and the logs that support review. The output is a set of instructions for use sections on human oversight, reviewed by someone who will operate the system. The step is done when every deployer-side measure has a corresponding instruction and a responsible role.
Test controls with overseers before release
Before release, overseers who match the defined profile use the system in realistic scenarios, including cases where the output is wrong, and try to override and stop it. Testers record whether they could understand the output, detect errors, make a decision not to rely on the output and halt the system within the expected procedure. The outputs are a stop test record, an override test record and a list of defects with their fixes and retest results. The step is complete when the stop and override controls have been exercised by the people who will use them and every failed test has a documented resolution. Independent assessment of these records is for the relevant conformity assessment body or notified body where one applies.
How the two-person rule changes remote biometric identification
Article 14(5) bars a high-risk system from acting on a remote biometric identification unless at least two competent people have verified it separately. For systems listed under Annex III point 1(a), this means the match a system produces cannot trigger action on its own. Two natural persons must each review the identification, and neither review may depend on the other. The design question for the provider is therefore not only whether the system shows its output to a human, but whether the architecture can hold a result in a pending state until two independent confirmations are recorded. A single-operator approval screen, or a second reviewer who simply sees the first reviewer's decision, does not give you that separation.
The rule carries an exception. Where Union or national law considers the two-person check disproportionate in law enforcement, migration, border control or asylum, the requirement does not apply. Whether that exception covers your deployment depends on the legal basis for your use, the Member State concerned and the specific activity, so confirm it with counsel before you design around it or drop the second check. Record the decision, the legal provision relied on, the date and the person who approved it, and keep that record with the technical file so an assessor can trace why the verification step does or does not exist.
Whichever route applies, the system should be built to produce evidence of the verification. Log each reviewer's identity, the time of review, the decision and the reviewer's competence basis, such as training completed, role assigned or authority granted under the deployer's oversight procedure. The Article 26(2) duty on deployers to assign oversight to people with the necessary competence, training, authority and support gives the competence record its purpose. Test the pending-state workflow and the separation of reviewers before go-live, and make sure the logs can be exported for an independent assessor.
Evidence that passes an Article 14 review
An Article 14 review looks for proof that oversight was designed in, tested and is being exercised in operation. The six artifacts below connect the design decisions to the records an assessor can sample, and each one needs a refresh rhythm so that the evidence matches the system as it runs today.
Oversight design record
This record links each identified risk to the oversight measure that addresses it, the autonomy level of the system, and the context of use the measure was sized for. Under Article 14(3), the record must show whether each measure is built into the system by the provider, identified for the deployer to implement, or both. Review it whenever the intended purpose, model or deployment context changes, and confirm that each row still points to a live control. Check that every risk has a named measure and an owner.
Interface and control specifications
These documents describe the human-machine interface tools that let overseers see inputs, outputs, confidence signals and system state, along with the controls that let them intervene. Article 14(1) expects the interface to support effective oversight while the system is in use, so the specification should state what an overseer sees at each decision point. Version the specification with the software and reconcile it against the interface at each release.
Stop and override test records
Article 14(4) requires overseers to be able to decide not to use the output, override it, and interrupt the system through a stop control that halts it safely. Keep dated test records showing each override path and the stop procedure working under realistic load, with the observed result and the tester's name. Re-test the stop control after every release and after any change to the orchestration or deployment pipeline, because a stop path that worked last quarter can break silently.
Overseer competence and training records
Article 26(2) requires deployers to assign oversight to people with the necessary competence, training, authority and support. Records should show who the overseers are, the training they completed on the system's capacities, limitations and automation bias, and the authority they hold to halt or override. Review these records on a fixed cycle that the organization sets, and remove access for anyone whose training has lapsed or whose role has changed.
Deployer instructions assigning oversight
Where the provider identifies oversight measures for the deployer to implement, the instructions for use must say who is responsible, what the measures are, and how they operate in the deployer's environment. Assessors will compare these instructions against the design record to confirm nothing was left unassigned. Re-issue the instructions with each material change and keep a signed acknowledgment from each deployer organization that received them.
Logs of overseer decisions
Logs should capture when an overseer accepted, overrode or rejected an output, what information they had at the time, and whether they used the stop control. These entries show oversight operating in practice rather than existing only on paper. Use an observability tool with traces that record inputs, outputs and metadata for each request, and sample the overseer decisions against the policy on a schedule the organization sets.
Which self-hosted open-source tools support Article 14 evidence
Article 14 expects overseers to be able to interrupt a system and to decide not to use or to override its output. Showing that these measures work requires testing, and for language-model systems, garak can supply part of that evidence. It is an open-source scanner under the Apache-2.0 licence that probes language models for hallucination, prompt injection, data leakage and jailbreaks. Its outputs support tests of whether an overseer's stop or override procedure still holds when the model is pushed toward unsafe behaviour. garak does not test non-language-model systems, and it does not test people or the procedures they follow.
- Probe coverage: garak runs probes for the failure modes listed above, so you can select the ones that match the system's intended purpose.
- JSONL report: every attempt and evaluation is written to a JSONL report that can be attached to the oversight test record.
- Hit log: attempts that found a vulnerability are recorded separately, which lets reviewers trace each finding to the procedure it affected.
- Scope limit: results apply to the tested model and configuration only, so retest after material changes.
- Human steps still need testing: scripted drills of the stop button and the override path must be run and recorded by people.
Confirm with your assessor which test results they expect as oversight evidence for your system type before you design the test plan.
Overseers need to see what the system did and what it returned before they can judge the output. Langfuse, an MIT-licensed observability platform, records this for LLM-based workflows. Each trace captures every operation in a request, including LLM calls, retrieval steps, tool executions and custom logic. Traces give reviewers the context they need to spot automation bias patterns and to show that an overseer had access to the information needed to interpret output. Tracing is not the same as a decision log, so the oversight workflow must still record the human decision alongside the trace.
- Operation capture: each trace records LLM calls, retrieval, tool use and custom logic in one request.
- Input and output records: inputs and outputs are stored so reviewers can compare what the system received with what it returned.
- Timing and token data: timing and token usage show the sequence and pace of operations, which helps reviewers understand how fast output reached the overseer.
- Metadata: metadata fields can carry the system version, user or case identifier, which links traces to a specific oversight event.
- Retention and access: the organization must set how long traces are kept and who can read them, since they may contain personal data.
Confirm with your team how traces will be linked to recorded overseer decisions and whether that linkage meets the logging obligations that apply to your system.
Article 14 oversight depends on procedures that are current, approved and known to the people who run them. A wiki with version control shows which version of an oversight procedure was in force at a given date. XWiki, licensed under LGPL-2.1-or-later, keeps every change to a page under version control. Each change records what changed, when and by whom. Users can compare any two versions and roll back to an earlier one. This gives an assessor a dated history of the stop procedure, the override instructions and the training material.
- Change history: every edit records what changed, when and by whom.
- Version comparison: reviewers can compare any two versions to see how a procedure changed between approvals.
- Rollback: an earlier approved version can be restored if a change introduced an error.
- Licence check: the LGPL-2.1-or-later licence governs modifications to the library. Have counsel confirm how it applies to your planned customizations and distribution.
- Approval records: version history does not record formal sign-off, so keep approval evidence in a separate, dated record.
Confirm with your legal team how the LGPL-2.1-or-later licence applies to your deployment before you rely on XWiki for controlled oversight documents.
Article 26(2) requires deployers to assign oversight to people with the necessary competence, training, authority and support. Authority is a permission question as much as a policy one: only assigned overseers should be able to approve, override or halt a system. BookStack, an MIT-licensed wiki, handles access to documentation through roles. User abilities come from the roles assigned to them, and permissions can be overridden per role at the shelf, book, chapter or page level. This lets an organization restrict who can edit or approve oversight procedures while keeping them visible to the wider team.
- Role assignment: abilities are granted through roles, so the overseer role can be defined once and applied to each person.
- Granular overrides: permissions can be set per role at the shelf, book, chapter or page level, so a single oversight procedure can have its own rules.
- Separation of duties: editors who write procedures can be separated from approvers who sign them off.
- Access evidence: role assignments and permission settings can be exported or screenshotted as evidence of who held authority at a given date.
- Platform access controls: the wiki controls documentation access only. Access to the AI system's override and stop functions must be controlled separately in the system itself.
Confirm with your assessor how they expect role and permission records to show the assignment of competence and authority described in Article 26(2).
What meeting Article 14 costs in money and effort
This table lists the cost components of meeting Article 14 oversight duties, who is paid for each, whether it is one-time or recurring, what pushes it up, and how to keep it down. Use it to build a written, fixed-scope quote that itemizes each line before you compare implementation partners.
| Cost component | One-time or recurring | What drives it | How to keep it down |
|---|---|---|---|
| Tooling and licenses | Recurring (hosting), one-time (setup) | The supplied tools (garak, Langfuse, XWiki, BookStack) are open source under the licenses named, so license spend can be low. Hosting, storage, integration and support still cost money. | Confirm each license with the project and your legal team. Budget for infrastructure and support, not license fees. |
| Engineering time for interface and control design | One-time, with recurring changes | The number of oversight points, the autonomy of the system, and how many override and stop paths must be built into the human-machine interface. | Scope the oversight points against the risk assessment early. Reuse one interface pattern across similar systems. |
| Human factors and usability testing | One-time per major design, recurring after changes | How many overseer roles exist, how many user groups must be tested, and whether automation bias testing is run with real operators. | Test with a small, representative group of overseers and document findings in the same record as the design decisions. |
| Overseer training and competence records | Recurring | The number of people assigned to oversight under Article 26(2) logic, turnover, and the depth of training needed to interpret output and stop the system. | Build training into onboarding, keep records in a versioned wiki, and refresh content only when the system changes. |
| Evidence upkeep after each release | Recurring | Release frequency, how often oversight controls change, and how many systems share the same evidence set. | Automate log and trace capture, and keep oversight evidence under version control so each release adds a diff, not a rebuild. |
| External testing or review of oversight controls | One-time and periodic | The number of systems, the scope of override and stop testing, and whether an outside tester reviews the design or only the running system. | Agree the scope in writing, and separate design review from red teaming so each is priced against a defined deliverable. |
| Auditor or notified body sampling | Recurring, per assessment cycle | Whether the system is covered by internal control or needs a notified body, and how many oversight records the assessor samples. | Ask the assessor for its sampling approach before the engagement, and keep evidence indexed so samples can be pulled quickly. |
Who owns Article 14 work and where the auditor draws the line
Your organization remains responsible for the oversight design decisions. Article 14 places the duty on the system to be designed so people can oversee it, and Article 26(2) requires deployers to assign oversight to people with the necessary competence, training, authority and support. Those decisions cannot be handed to a contractor, because they reflect your risk appetite, your use case and your accountability chain.
- Oversight decisions: choose which oversight measures are built into the system and which are left for the deployer to implement, based on the risks, autonomy and context of use.
- Overseer assignment: name the people who oversee the system, and confirm each has the competence, training, authority and support the role needs.
- Override and stop authority: decide who may override an output or halt the system, and under what conditions.
- Residual risk sign-off: a named accountable owner accepts the residual risk after oversight measures are in place.
- Training records: keep evidence that overseers understand capacities, limitations and automation bias.
Before engaging any partner, confirm internally who holds each of these decisions and where the signed records will be kept.
An implementation partner such as DeployOpen prepares the technical and documentary groundwork that supports oversight. Work is performed inside your own cloud accounts, data centers or air-gapped networks, and the partner does not own your controls or certify them. Engagements are typically fixed-scope, with deliverables agreed in writing before work starts.
- Interface and control design: prepare the human-machine interface tools and control workflows that let overseers review, override and interrupt the system.
- Logging and testing tools: configure self-hosted tooling for traces, version-controlled procedures and adversarial testing in your environment.
- Stop and override tests: run and record tests showing the stop procedure halts the system safely and that overrides take effect.
- Evidence file preparation: assemble the oversight procedures, test results and change history into a file your team can review.
- Limits of the role: the partner issues no audit report, attestation or certificate.
Ask for the written scope, the named deliverables and whether the partner will hand over all artifacts in formats your own team can maintain.
The independent auditor or notified body tests the oversight controls on its own and issues the findings. Where a conformity assessment route requires a notified body, that body makes the decision. For most Annex III systems, the provider performs an internal-control assessment under Annex VI, but the evidence still has to withstand scrutiny by market surveillance authorities. Independence means the assessor was not the party that designed or built the controls.
- Independent testing: the assessor tests the controls directly, including by observing overseers and reviewing override and stop behavior.
- Findings and conclusions: only the assessor issues the report, finding or certificate.
- Scope of the engagement: confirm with the assessor which Article 14 controls it will test and which evidence it will request.
- Conflict checks: a firm that built the system cannot also serve as its independent assessor for the same controls.
- Route determination: confirm with the relevant authority or assessor whether a notified body is needed for your system.
Before engagement, confirm the assessor's independence rules, the evidence it expects, and the route that applies to your system.
Outsourcing in Article 14 work is usually partial. Technical preparation can be bought, while accountability for oversight stays in the organization. The split below reflects common practice, and your own contracts and assessor will define the final line.
- Usually outsourced: interface prototyping, logging and testing tool configuration, stop and override test execution and evidence packaging.
- Usually kept in-house: choice of oversight measures, overseer assignment, authority to override, and residual risk acceptance.
- Shared work: writing oversight procedures, where the partner drafts and your team approves and adopts them.
- Recurring work: keeping training records current, rerunning stop tests after changes, and reviewing logs, which can continue under a retainer.
- One-time versus recurring cost: setup is typically one-time, while testing and review recur with each system change.
When requesting a quote, ask the partner to separate setup, recurring testing and evidence maintenance, and to state which items your team must still perform.
Questions buyers ask about Article 14 before hiring help
Who owns Article 14 work, the provider or the deployer?
The provider owns the design duty. Article 14(1) requires the high-risk system itself to be built so people can oversee it while in use, and Article 14(3) lets the provider either build oversight measures into the system, identify them for the deployer to implement, or do both. The deployer then carries the operational duty under Article 26(2): assigning oversight to people with the necessary competence, training, authority and support. If you buy a system from a vendor, confirm in writing which oversight measures the vendor built in and which ones it expects you to run. If you build or substantially modify a system, you are likely the provider and own the full design duty.
Can we do Article 14 work in-house, and what do we need to keep internal?
Yes, most organizations can do part of it in-house, but the decisions that carry legal weight should stay with accountable staff. Overseers need to understand the system's capacities and limitations, watch for automation bias, interpret outputs correctly, and have authority to override or stop the system. Those people and their authority must be your own, because no outside party can be the overseer for you. Outside help is usually most useful for engineering the stop mechanism, building the interface and logging, and documenting the design. Ask any partner to state exactly which artifacts it will produce and which decisions remain with your staff.
What drives the effort for Article 14?
Effort is driven mainly by the number of oversight points, the autonomy of the system, and how many people operate it. A system that only recommends and a human always decides needs a simpler design than one that acts without review, and a single-operator tool is simpler than a multi-team workflow. Other drivers include how many override and stop paths must be engineered and tested, how much training the overseers need, and how much documentation of limitations and automation bias risk is required. Ask any quote to break the work down by interface, stop mechanism, training, and documentation, so you can see which parts scale with your system.
How long does Article 14 readiness take, and what must we supply?
Duration depends on your starting point and on the date your system must comply. The high-risk rules for Annex III systems apply from 2 December 2027 and for Annex I product systems from 2 August 2028, as amended by Regulation (EU) 2026/1744. Work ends up waiting on your inputs: a clear description of intended purpose and context of use, the list of people who will oversee the system, their roles and authority, access to the system in a test environment, and decisions on who can approve overrides. Ask a partner for a timeline tied to these inputs and to named deliverables, not to a generic number of weeks.
Do open-source tools satisfy the Article 14 requirement?
No tool satisfies Article 14 on its own, because the duty is about system design, operator competence and organizational authority. Open-source tools can produce evidence that supports the design. For example, Langfuse traces record inputs, outputs, tool executions and timing for each request, which helps overseers review what a system did. XWiki keeps version history of procedures and records who changed them, and BookStack can separate roles and permissions for documented oversight procedures. Confirm with each tool's documentation whether it supports the specific interaction you need, such as an interrupt or approval step, because a logging tool does not stop a system by itself.
Do we need a notified body for Article 14?
Article 14 itself does not name a notified body. Notified bodies appear in the conformity assessment route under Article 43, which applies to some biometric systems and to Annex I products, while most Annex III systems use internal control under Annex VI. Article 14(5) adds a specific rule for remote biometric identification: no action may be taken on an identification unless at least two competent people verify it separately, with the law enforcement, migration, border control and asylum exceptions described in the Act. Confirm with the regulation and your national market surveillance authority which conformity route applies to your system before you commit to an assessor.
What should we ask for in a quote for Article 14 help?
Ask for a fixed scope that lists each oversight measure, the interface and stop mechanism to be engineered, the test cases used to verify overseer actions, the training materials, and the documentation delivered. Ask which items are one-time work and which recur, such as retraining, log review, and updates after a model change. Ask who is responsible for each deliverable, what the partner does not cover, and how changes to scope are priced. DeployOpen plans and documents this kind of work under fixed-scope agreements, with scope, deliverables and timelines agreed in writing before work starts, and it does not issue conformity assessments or certifications.
How DeployOpen works on this
DeployOpen treats Article 14 as a design and evidence task: we help define how people can oversee a high-risk system, then build the controls, logs and records that show it works. Your organization owns the controls and the conformity decisions, and an independent assessor reviews the result.
How we scope
- We confirm which systems are in scope and whether each is a provider or deployer system for Article 14 purposes.
- We record the oversight measures in the written scope, with the risk, autonomy and context of use each one addresses.
- We agree in writing which human-machine interface, stop and override features are built, and which are assigned to deployers.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.
How we build
- We implement override and stop procedures in the self-hosted platform, and test that a halt leaves the system in a safe state.
- We configure logging so reviewers can see inputs, outputs and tool actions, which supports automation bias checks.
- For remote biometric identification, we can build a two-person verification step and record each separate confirmation.
How we hand over
- We document oversight roles, required competence and the decision points where overseers can decline or override output.
- We keep the procedures in version-controlled wiki and knowledge base tools, so changes and approvals stay traceable.
- We deliver the evidence pack in your infrastructure, and you confirm with your assessor which items they need to see.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We can re-test oversight controls when models, prompts or deployment contexts change, and update the records to match.
- Ask any implementation partner to confirm in writing who signs the conformity decision, which is your organization and its independent assessor, not DeployOpen.
