ISO/IEC 42001 FAQ Provider and Deployer Roles

Build the AIMS responsibility map from the actual lifecycle. Record who specifies, develops, supplies, integrates, configures, validates, deploys, operates, monitors, supports, changes, and retires the AI system; who provides data, models, tools, and infrastructure; who gives users instructions; and who acts on limitations, complaints, incidents, or corrections. Include shared and externally performed work instead of treating outsourced activity as outside the AIMS.

Run the EU AI Act role test separately for each system and transaction. A provider develops an AI system or general-purpose AI model, or has one developed, and places it on the market or puts the system into service under its own name or trademark. A deployer uses an AI system under its authority in a professional activity, excluding personal non-professional use. Importers, distributors, product manufacturers, authorised representatives, and affected persons are separate categories. These definitions do not map automatically to AIMS job titles or contract labels.

Confirm territorial scope before assigning EU duties. Article 2 covers providers placing systems or general-purpose AI models on the Union market, deployers established or located in the Union, and third-country providers and deployers where system output is used in the Union, plus specified supply-chain actors. Conditional exclusions include military, defence and national-security uses, sole-purpose scientific research and development, pre-market research and testing other than real-world testing, purely personal non-professional use, and some free and open-source releases.

Recheck Article 25 before rebranding or changing a high-risk system. A distributor, importer, deployer, or other party becomes the provider for the high-risk system if it puts its name or trademark on it, makes a substantial modification while it remains high-risk, or changes the intended purpose of a non-high-risk system so it becomes high-risk. Product manufacturers also become providers in the specified Annex I safety-component circumstances.

Keep a system inventory and responsibility matrix tied to the actual lifecycle, plus supplier and customer agreements, intended-purpose and branding records, system instructions and limitations, technical-documentation access, data and model dependencies, change notices, acceptance records, monitoring ownership, incident routes, correction rights, retention, exit arrangements, and unresolved gaps.

For each EU role conclusion, retain the system and version, actor and legal entity, activity, market and location facts, name or trademark, intended purpose, who developed or commissioned development, who controls use, relevant Article 2 scope or exclusion, Article 3 definition, Article 25 analysis, effective date, approver, and reassessment trigger.

For high-risk systems, written agreements with component or service suppliers should specify the information, capabilities, technical access, and assistance needed for the provider to comply, subject to the Article 25(4) scope and open-source exception. The agreement supports compliance but does not change who meets the statutory definition.

Assign internal accountability to a process or system owner who can operate and correct the relationship. Legal owners determine statutory roles, procurement manages supplier commitments, technical and operational owners verify integration and monitoring, and governance resolves unallocated or conflicting responsibilities.

A contract can allocate work, information, access, assistance, and remedies, but it cannot rewrite a statutory definition. Record any gap between the contractual allocation, actual conduct, and legal role, then escalate it before deployment or material change.

For EU high-risk systems, the provider owns provider obligations, while the deployer must follow instructions, assign suitable human oversight, control relevant input data where applicable, monitor use, retain automatically generated logs under its control for at least six months unless other applicable Union or national law provides otherwise, make specified notifications, and cooperate with authorities. The exact duties depend on the role, system, use, and applicable exceptions.

Review allocation when the system, model, service terms, supplier, customer use, branding, integration, intended purpose, territory, contract, technical access, monitoring access, or incident route changes. Review before a white-label release, material integration, new market, new intended use, or modification goes live.

Record the effective date and evidence for each allocation, then update agreements, instructions, access to records, monitoring, change notification, incident communication, and escalation routes together when facts change.

Align statutory readiness with the applicable AI Act date and the legal text then in force. The published AI Act sets 2 August 2026 for Annex III provider and deployer obligations and 2 August 2027 for corresponding Article 6(1) product-route obligations. The Council gave final approval to the Digital Omnibus on AI on 29 June 2026; the adopted amendment moves those dates to 2 December 2027 and 2 August 2028 respectively, but it must still be published in the Official Journal and enter into force. Chapter V obligations began applying on 2 August 2025, while Article 111 gives providers of general-purpose AI models placed on the market before that date until 2 August 2027 to comply. Article 111 also has separate transition rules for existing high-risk systems. ISO/IEC 42001 and other laws or contracts can require responsibility allocation earlier.