What to outsource for the EU AI Act and what to keep in-house

Your organization keeps legal responsibility and every control decision under the AI Act. A partner can prepare technical documentation, test evidence and system changes, and your team reviews and adopts that work. Where the Act requires a notified body, only that body issues the conformity outcome. Where an independent assessor is involved, it reports its own findings and does not certify the system. Before you split any work, confirm three things for each system: whether you are the provider or the deployer, its risk category, and whether its conformity route is internal control under Annex VI or third-party assessment. Those answers decide what can be handed over.

Decisions about intended purpose, risk acceptance, the people who oversee the system and the final sign-off stay in-house. Article 14(4) expects overseers to understand the system's capacities and limits, stay alert to automation bias and halt the system when needed. Article 26 requires deployers to assign oversight to people with the necessary competence, training, authority and support. Those people should be appointed by your organization and accountable to it. Documentation, metric-based testing under Article 9, log design and training material are often prepared with outside help. Your team should still own the content, approve it and be able to explain every figure to an assessor. Article 4(1) requires measures for AI literacy, so plan training for each role instead of relying on a single vendor course.

Sequence the work by date. Under Regulation (EU) 2026/1744, the high-risk rules apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems. Systems in the first group need documentation, testing and logging ready earlier in your plan. Agree the split in writing with every supplier. Article 25 requires providers and third parties supplying AI systems, models, tools, services, components or processes to agree in writing the information, technical access and assistance each side provides. The clause does not apply to free and open-source tools other than general-purpose AI models, so confirm the license and supplier role of each component before assuming it is covered.

Which AI Act duties stay with your organization

Partners can prepare documents, tests and system changes, but the legal duties under the AI Act attach to your organization by role. The cards below cover the decisions and signatures that remain yours, and the article each one traces back to.

Owning the risk decision

Whether a system is high-risk, and which role you hold for it, is a determination your organization must make and be able to defend. A consultant can run the analysis and draft the reasoning, but the record should name the accountable person who approved it. Check that the risk management system under Article 9 is documented, reviewed when the system changes, and tied to a named owner.

Naming the provider or deployer

Your role under the Act decides which duties apply to you, so the role must be assigned deliberately rather than inherited from a vendor contract. Under Article 16, a provider carries the full set of obligations for a high-risk system, including the name and contact address on the system or its documentation. Confirm which entity appears on the product, in the user documentation and in the register entry.

Accepting the conformity assessment outcome

Conformity assessment produces a result that your organization must accept and act on. For most Annex III systems, the provider runs an internal-control procedure, and for some biometric systems and Annex I products a notified body is involved. Whichever route applies, the decision to place the system on the market stays with a named executive who has read the assessment file and the open findings.

Signing the EU declaration of conformity

The EU declaration of conformity is a formal statement by the provider that the system meets the requirements, and it is not something an implementation partner can sign for you. Before signature, check that the technical documentation, the quality management system records and the CE marking are consistent with the version on the market. Keep the signed declaration with the technical file for the period the Act requires.

Keeping human oversight with competent staff

Under Article 26, a deployer must assign human oversight to people with the necessary competence, training, authority and support. Under Article 14(4), those overseers must understand the system's limits, watch for automation bias and be able to override or stop it. Confirm that the named overseers have written authority to halt use, and that their training is recorded and kept current.

Making go or no-go deployment calls

Deciding whether a high-risk system goes live, is changed or is withdrawn is an operational decision that the organization must own. Tests under Article 9 and the instructions for use under Article 26(1) should be reviewed before that decision, and the outcome should be recorded with the reasons. A partner can run the test plan and report results, but the accountable manager should sign the release decision.

Who does what: your team, a partner and the assessor

Your organization keeps the legal duties under the Act. Whether you are the provider, the deployer or both for a given system, the decisions about risk classification, the intended purpose, the human oversight design and the acceptance of residual risk sit with your management and accountable owners. A partner can gather facts and draft material, but it cannot make those decisions for you or sign off on them as your position.

Decisions and accountability: Name an owner for each AI system, approve the intended purpose and the risk classification, and record why each decision was taken.
Oversight and literacy: Assign people with the competence, training, authority and support that Article 26 and Article 14 expect, and keep records of the training you deliver.
Technical judgment: Your engineers decide model choices, data governance, logging design and the metrics used in testing under Article 9.
Supplier contracts: Negotiate the written information, technical access and assistance terms needed under Article 25(4) with each vendor and third party.
Ongoing operation: Monitor performance, handle incidents and keep documentation current after launch.

Before you hire anyone, confirm which of these items you will hold internally and which you will ask a partner to draft.

Human oversight and AI literacy: why they are hard to outsource

Keep the people who oversee high-risk AI systems inside your organization. Article 14(4) describes what an overseer must be able to do: understand the system's capacities and limitations, stay alert to automation bias, interpret the output correctly, decide not to use it or to override it, and interrupt the system through a stop button or a similar procedure that halts it safely. Those are judgment calls about your business and your affected people, and no outside party can make them on your behalf. Article 26(2) adds that you must assign oversight to people with the necessary competence, training, authority and support. Confirm for each high-risk system who holds that authority, who can halt it in production, and whether they have the written power to override the output without asking permission from a vendor.

Article 4(1), as replaced by Regulation (EU) 2026/1744, requires you to take measures that support the AI literacy of staff and others who operate AI for you. It does not require you to guarantee a specific level for any individual. That shifts the work from proving a score for each person to showing a documented program: who received what training, which roles it targeted, and how you reviewed whether it fit the systems those people run. The AI literacy questions and answers published by the European Commission is the natural starting point for scoping that program.

A partner can help build the material. It can draft training modules, write oversight procedures and runbooks, set up the logging that shows an overseer's intervention, and run tabletop exercises on a stop decision. Keep the ownership of those artifacts, the sign-off on who the overseers are, and the records of their decisions in-house. Ask any partner to show how each deliverable feeds a decision your staff makes, and make sure your own people can explain and defend the procedure to a market surveillance authority without the consultant in the room.

Documentation and testing work commonly outsourced

Most of the paperwork and testing behind an AI Act file can be prepared with outside help, but the provider or deployer still owns each decision and signs off on the result. The cards below cover the six artifacts assessors ask for first, and each one separates what a partner drafts from what your team must review and approve.

Technical documentation

A partner typically drafts the technical documentation file for a high-risk system, mapping each Annex IV element to the system's design, data, training, validation and intended purpose. Your product and legal owners must review the description of capabilities and limitations, then approve the file before it is placed on the market. Assessors will ask for a dated file that is kept up to date after release, with a clear link from each claim to the evidence behind it. Check that the partner works from your actual system, not a template.

Risk management system

A partner usually builds the risk register, the method for identifying foreseeable risks to health, safety and fundamental rights, and the residual risk review process. Your risk owners must accept each residual risk and decide which mitigations are in scope for the release. Assessors will look for a documented, iterative process that runs across the system's lifecycle and records how new findings changed the design. Confirm who holds the register after the partner leaves and how updates are triggered.

Testing against defined metrics

Testing partners often design test plans, select datasets, run accuracy, robustness and bias evaluations, and set the probabilistic thresholds the system must meet. Your teams must approve the metrics and thresholds before testing begins, because they tie the results to the intended purpose. Assessors will ask for the prior metric definitions, test logs, datasets with their provenance, and results showing that testing ran before the system was placed on the market. Confirm that the partner's test environment matches production conditions.

Logging and record keeping

A partner commonly configures logging pipelines, sets retention rules and writes the procedures that collect automatically generated logs for the system. Your operations and security teams must decide retention periods, access rights and who can read logs during an incident. Assessors will want evidence that logs are captured throughout the system's operation, can be tied to specific versions, and are available to deployers and authorities on request. Check which logs your existing tooling already produces before commissioning new ones.

QMS documentation

Partners often draft the quality management system policies, procedures, roles, change control and post-market monitoring plan, and set up the audit trail that proves they run. Your leadership must approve the QMS scope, assign accountable owners and confirm that the procedures match how staff actually work. Assessors will ask for signed policies, records of management review, corrective action logs and evidence that the QMS is applied to each system. If a notified body is involved, confirm early which QMS standard it will assess against.

AI system inventory

A partner typically builds the first inventory of AI systems, records each system's purpose, provider or deployer role, and the classification reasoning, and sets up a process to keep it current. Your governance owners must confirm the list is complete, including shadow tools and third-party AI embedded in other products. Assessors and market surveillance authorities will expect a current inventory that matches the systems actually in use. Ask who updates the inventory when a new AI feature ships.

How Article 25(4) shapes supplier and partner contracts

Article 25(4) requires a written agreement between a provider of a high-risk AI system and any third party that supplies AI systems, models, tools, services, components or processes that the system relies on. The agreement must set out the information, technical access and assistance the provider needs to meet its obligations under the Act. The duty sits with the provider, so a supplier that never signs anything still leaves the provider exposed. Start by listing every external element in each high-risk system, including hosted models, vector stores, labeling services, monitoring tools, cloud platforms and consultants who prepare documentation, and record who supplies each one and under what license.

The exemption for free and open-source tools is narrow. Article 25(4) does not apply to free and open-source tools other than general-purpose AI models. A component that is open source but is a general-purpose AI model does not fall under that exemption, and a commercial support contract for an open-source tool may change its status. Confirm the license, the role of the component and whether it is a general-purpose AI model for each item on the list, and record the answer. Where the answer is unclear, treat the component as covered and ask the supplier to confirm in writing. Your legal or compliance team should own that classification, not the engineering team that chose the tool.

A useful agreement names the evidence it will deliver. Cover the information to be supplied (model cards, training data descriptions, known limitations, test results and the version history behind each release), technical access for testing and log review, assistance during conformity work and post-market monitoring, and advance notice of changes to models, data or hosting that could affect conformity. Set response times for incident and vulnerability information, and state what happens to data and records when the contract ends. Keep in mind that the contract is the organization's control, not the partner's. Your procurement and legal teams should own its terms, and a partner's standard template should be reviewed against that list before signature.

How the split works from scoping to assessment

This sequence turns a vague idea of outsourcing into a written split of AI Act duties, so each obligation has one owner, one piece of evidence and one sign-off before anyone is assessed. It ends with either a notified body assessment or the organization's own internal control route.

Confirm role and risk route
Start by deciding, for each AI system in scope, whether your organization is the provider or the deployer, and whether the system is high-risk under Annex III or as an Annex I product. Legal and product owners do this together, using the system inventory and the intended purpose as written in your documentation. The output is a short classification record per system that names the role, the route and the reasons. The step is done when a named person has signed the record and no system is left unclassified.
Build the duty split matrix
Next, list every obligation that applies to the role and route from the classification record, and assign each duty one of three owners: kept in-house, prepared with a partner, or supplied by a tool vendor or supplier under written terms. Duties such as human oversight assignments and AI literacy measures usually stay with your own managers, while technical documentation drafting or test preparation are common candidates for partner help. The output is a matrix with one owner and one evidence item per row. It is complete when every row has an accountable internal owner, including the rows you outsource.
Agree deliverables and supplier terms in writing
For each duty you plan to outsource, agree a written statement of work that names the artifacts to be produced, the format, the review points and who receives them. Where a supplier, tool vendor or model provider contributes information, technical access or assistance, record what they will provide under a written agreement, as Article 25(4) expects for the value chain. The output is a signed scope with deliverables and an acceptance criterion for each. The step closes when you can point to the clause that obliges each external party to deliver.
Prepare evidence against agreed deliverables
The partner then prepares the evidence named in the scope, such as technical documentation, risk management records, test plans and results, and logging design, working in your environment and using your system's real outputs. Your engineers provide access and answer questions, and the partner keeps a change log so later edits are traceable. The output is a versioned evidence pack mapped to each Article and Annex IV element in the matrix. The step is done when every deliverable has been handed over and no item is marked as draft without a stated owner.
Review and sign off internally
Your accountable owners then review each artifact against their duty row, checking that the content reflects how the system actually operates and that the people named for human oversight have the competence, training and authority the matrix assumes. Gaps go back into the partner's scope as tracked items with due owners. The output is a sign-off record per duty, dated and approved by an accountable executive or delegate. The step closes only when open findings are either resolved or formally accepted by a named person with the authority to accept them.
Complete the assessment route
Finally, take the system through the route its classification requires. For systems on the internal-control route, the organization performs the conformity assessment itself and issues its own EU declaration of conformity, with the evidence pack as the record. For systems that need a notified body, the body assesses the quality management system and technical documentation, and the organization keeps the body's findings and surveillance obligations in its own plan. The output is either the internal declaration with its evidence or the notified body's decision and certificate. Confirm the current scope, fees and certificate terms with the chosen body before the assessment begins.

Choosing the split for each duty

This table compares three ways to split each AI Act duty: kept in-house, prepared by a partner with internal approval, or issued by a third party. Read each row against your risk route, system count and team capacity, since the right split changes with them. The main takeaway is that the provider or deployer keeps accountability for every row, even where a partner does the work.

Duty	In-house	Partner-prepared, internal approval	Third-party issued
Risk management (Article 9)	Owned by the provider; fits when one team runs few high-risk systems	Common for first cycle; owner signs off risk register	Not issued; assessor reviews it in conformity evidence
Technical documentation (Article 11)	Fits teams with engineering capacity to keep it current	Common for initial Annex IV drafting; engineers verify facts	Not issued; notified body reviews where required
Quality management system (Article 17)	Fits organizations with existing ISO-style management systems	Common for building procedures and records from scratch	Notified body assesses and surveils it for certain systems
Testing against metrics (Article 9)	Fits teams with ML evaluation skills and test infrastructure	Common for independent test design and red teaming	Not issued by default; check whether a notified body requires test reports
Logging and records (Article 12)	Usually in-house, since logs come from your own systems	Partner may configure log pipelines and retention	Not issued; verified during assessment
Human oversight design (Article 14)	Must stay in-house: owners define who oversees and how stop works	Partner may draft procedures and training material	Not issued; assessed through documentation and records
Supplier contracts (Article 25(4))	Owned by legal and procurement; written terms must be yours	Partner may draft clauses and information request lists	Not issued; suppliers provide information under agreed terms
Conformity assessment (Article 43)	Internal control route is run and signed by the provider	Partner may compile the evidence file for internal control	Notified body issues certificates where the route requires it

What usually delays the split and how to avoid it

Most delays in AI Act work do not come from missing tools. They come from unclear ownership, supplier terms that were never written down, and evidence that arrives after the system is already in use. The cards below name the problems we see most often and the step that prevents each one.

Partner treated as decision owner

A consultant or integrator can prepare a risk classification, draft a quality management system and build the technical file, but the provider still decides whether a system is placed on the market and which risks are accepted. When the partner signs off on these decisions, nobody inside the organization can defend them to a market surveillance authority. Before work starts, write down who approves each classification, each risk acceptance and each release, and name a person on your side for every one of those decisions.

Missing supplier clauses under Article 25(4)

Article 25(4) requires providers and third parties that supply AI systems, models, tools, services, components or processes to agree in writing the information, technical access and assistance needed to meet the Act. Teams often sign statements of work that cover delivery but omit access to logs, model documentation and change notices. Before signing, check that each supplier agreement states what information the supplier provides, what technical access you receive and how assistance is requested and timed. Confirm the exclusion for free and open-source tools with counsel, since it does not extend to general-purpose AI models.

Open-source components with unclear roles

A self-hosted platform may combine an open-source model server, a vector store, a monitoring stack and a guardrail library, each maintained by a different project. Nobody in the chain may be the provider of the combined system, yet the organization that puts it into service may still carry deployer or provider duties. Map each component to a named owner, record the version and license of each, and decide in writing which party assumes provider responsibility for the integrated system before the technical documentation is drafted.

Testing evidence arriving late

Article 9 expects testing against defined metrics and probabilistic thresholds suited to the intended purpose, and the Act requires that testing happen before placing on the market in any event. When test plans are written after a model has already been tuned, the results cannot show what the system was designed to meet. Agree the metrics, thresholds and test datasets at the design stage, store each test run with its configuration and date, and link results to the risk management file so an assessor can trace them.

Oversight roles without authority

Article 14(4) expects overseers to understand the system's limits, watch for automation bias, override or decline its output, and interrupt it through a stop procedure. Article 26(2) requires deployers to assign oversight to people with the necessary competence, training, authority and support. Many organizations name a reviewer who has no right to stop a process or no time to do so. Before go-live, document who can halt the system, how the halt is executed, and which overseer training record backs each assignment.

Questions buyers ask before splitting AI Act work

Can an implementation partner sign the EU declaration of conformity for us?

No. Under Article 16, the provider must draw up the EU declaration of conformity and affix the CE marking, so that legal responsibility stays with the provider. A partner can prepare a draft from your technical documentation, check each statement against the evidence behind it, and track version changes. Your own authorised signatory signs it. DeployOpen prepares systems and evidence for assessment, but it does not sign declarations or issue reports or certificates. Ask any partner to map each claim in the declaration to a named document and an internal owner.

Can we outsource all of our AI Act documentation?

Partly. A partner can draft the technical documentation required by Article 11, populate the Annex IV elements, prepare test reports and maintain templates. The provider still owns the content, must keep it up to date, and needs internal approval before anything is relied on. Agree in writing which documents the partner produces, who reviews each revision, who approves it, and where the controlled copy is stored. Keep a named internal owner for each section so that engineers can answer questions about the system design without the partner acting as a go-between.

Do we need a notified body for our AI system?

It depends on the system's annex and conformity route. Most Annex III high-risk systems use internal control under Annex VI, so the provider carries out the conformity assessment itself without a third party. Notified bodies are involved for some biometric systems and for Annex I product systems, as set out in Article 43. First classify the system, then check whether it falls into a route that requires third-party assessment. Where a notified body is needed, certificates last up to four years for Annex III systems and up to five years for Annex I systems under Article 44(2).

What does an AI Act partner need from our team to start?

A partner needs four inputs to produce usable evidence:

Technical access to the system, including code repositories, model and data descriptions, logs, and test environments
Named system owners who can explain design choices, known limitations and change history
Facts about real use, such as who relies on the outputs, which decisions they inform, and who oversees them
Supplier and vendor contracts, instructions for use, and any third-party components

Article 25(4) expects providers and suppliers to agree in writing the information, technical access and assistance each party provides. Put that list into the scope before work begins, with a named contact for each input and a date for delivery.

Does the AI Act change how we use open-source models?

It depends on your role and on whether the model is a general-purpose AI model. If you only deploy an open-source tool, your deployer duties under Article 26 apply to the high-risk use you make of it. The written-agreement duty in Article 25(4) does not apply to free and open-source tools other than general-purpose AI models, so supplier agreements still matter for those models. Modifying a model or placing a system on the market under your name can make you a provider. Confirm your role with counsel before scoping the work, because it determines which duties your partner must cover.

How early should we start before the 2027 and 2028 dates?

Start the inventory and classification now, because the dates are already fixed in the Act as amended. Under Regulation (EU) 2026/1744, the high-risk rules for Annex III systems apply from 2 December 2027, and those for Annex I product systems from 2 August 2028. Chapters I and II, which include the AI literacy duty, have applied since 2 February 2025. Work backward from each date: classification, documentation, testing, quality management, and, where it applies, time with a notified body. Ask any partner for a dated plan that shows which steps depend on your inputs and which depend on an assessor's schedule.

How DeployOpen prepares AI Act evidence with your team

DeployOpen works on what to outsource for the EU AI Act and what to keep in-house as an implementation partner. Your organization keeps ownership of its AI systems, role decisions and compliance obligations, while DeployOpen prepares the systems, records and evidence that your team and an independent assessor will review.

How we scope

Engagements are fixed-scope, with the work split between your teams, partners, tool vendors and notified bodies agreed in writing before work starts.
The written scope names which AI systems, roles and obligations are covered, and which duties stay with your legal, risk and product owners.
Scope documents list the supplier agreements, technical access and assistance points that your organization must request from third parties.

How we build

We set up the self-hosted systems, logging and test environments inside your own infrastructure so that the evidence stays under your control.
We draft the documentation, oversight procedures and AI literacy records that your staff will own and maintain after handover.
We run agreed testing against the metrics your organization defines, and record the results alongside the decisions made on them.

How we hand over

Deliverables include the configured systems, documentation sets, test records and a responsibility map showing who owns each duty.
We walk your teams through the procedures so that human oversight staff understand their role, limits and stop procedures.
We hand over an evidence index that tells your assessor where each requirement is evidenced, while the assessment itself stays with the independent body.

How we support

Ongoing support, upgrades and continuous testing are available as retainers once the initial scope is delivered.
Retainers can keep documentation current as systems change, which matters because the dates in the 2026 amendments may shift your plan.
Ask any partner, including DeployOpen, to confirm in writing which parts it prepares and which parts only your organization or an independent assessor can complete.