ISO 42001 for AI model providers: GPAI duties and certification

Does ISO 42001 certification satisfy AI model provider duties?

A developer that trains or fine-tunes a general-purpose model, places it on the market under its own name, and must answer downstream customers and the AI Office needs to know what an ISO 42001 certificate can and cannot prove. ISO/IEC 42001 is a voluntary management system standard that an accredited certification body can certify, and it does not by itself meet the obligations in Article 53 of the EU AI Act. Those obligations concern technical documentation, information for downstream providers, a copyright policy and a public summary of training content, and they are enforced by the AI Office. A certificate shows that an AI management system exists and operates, which is useful evidence but not a substitute for the model-level documentation the regulation asks for.

Responsibility is split in a way that affects planning. The organization owns its controls, its policies and the decisions about which risks it accepts. An implementation partner can prepare the management system, the technical documentation pack and the evidence trail, but cannot issue a certificate or attest to compliance. Only an independent certification body can do that. Before engaging anyone, confirm the certification body's accreditation status with its national accreditation body, and confirm that it is competent to certify AI management systems under the requirements of ISO/IEC 42006:2025.

Annex A is not a checklist that must be fully adopted. Clause 6.1.3 requires a statement of applicability that lists the necessary controls and justifies including or excluding each one. For a model provider, the controls on technical documentation for interested parties (A.6.2.7), information for users (A.8.2) and data provenance (A.7.5) are the ones most likely to be in scope, because they map closely to what downstream customers request. Developers should document the reasoning for every exclusion, since an assessor and a downstream customer will both read the statement of applicability as the organization's own account of its AI governance.

Which ISO 42001 controls matter most to a model developer?

A developer of general-purpose AI models carries the heaviest documentation and data burden in the Annex A set. The six controls below cover what downstream parties receive, what the organization records about its training data, and how the life cycle and supplier relationships are governed, so each one should be planned and evidenced before an assessor arrives.

Technical documentation for each audience

A.6.2.7 asks the organization to decide which technical documentation each category of interested party needs, such as users, partners and supervisory authorities, and to provide it in a suitable form. For a model developer, the set usually differs for downstream integrators, enterprise customers and regulators. An assessor will look for a documented list of audiences, the document set produced for each, version control on those documents, and records showing the documents were issued and kept current with each model release. Confirm that the Model Documentation Form content used for EU AI Act purposes is mapped to these audience records.

Information provided to users

A.8.2 asks the organization to determine and provide the information that users of the AI system need. For a model provider, this means the capabilities, known limitations, intended and out-of-scope uses, and the conditions under which downstream systems should be monitored. An assessor typically checks for a documented information set, evidence that it reached the users who need it, and a process that updates it when the model changes. Ask whether downstream licensing terms and usage policies point to the current version of this information.

Data provenance records

A.7.5 asks the organization to define and document a process for recording the provenance of the data used in its AI systems across the life cycles of both the data and the system. For a foundation model, provenance covers web crawls, licensed corpora, user-provided data and synthetic data, each with its source, acquisition date, license basis and processing steps. An assessor will look for a written provenance procedure, dataset records that trace each training input to its source, and evidence that opt-outs or license terms were applied during collection. Confirm who owns the records and how they are retained.

Life cycle controls for training and release

The A.6 controls cover responsible design, requirements, verification and validation, deployment, operation, and event logging across the AI system life cycle. For a model developer, this includes evaluation before each release, red-team and safety testing results, gated release approvals, and monitoring after deployment. An assessor will look for documented design decisions, test plans with recorded results, sign-off records for each release, and logs that show what changed between model versions. Confirm that these records exist for past releases, not only the current one.

Impact assessment before release

The A.5 controls require a documented process to assess the impacts of AI systems on individuals, groups and society, with the assessment itself recorded. ISO/IEC 42005:2025, published 28 May 2025, provides related guidance on AI system impact assessment. For a general-purpose model, the assessment should cover foreseeable misuse, harms to affected groups and mitigations adopted before release. An assessor will look for a dated impact assessment for each significant release, the reasoning behind accepted residual risks, and evidence that findings fed back into design or documentation.

Supplier and customer relationships

The A.10 controls address responsibilities across organizational boundaries: allocating life cycle duties, managing suppliers of AI products and services, and meeting customer expectations. A model developer usually depends on cloud compute, annotation vendors and data suppliers, and passes its model to customers who build products on it. An assessor will look for a written allocation of responsibilities with each customer, supplier due diligence records, and contract clauses covering data, updates and incident notice. Confirm which obligations stay with the developer and which move to the downstream provider.

How technical documentation for AI Act and ISO 42001 can share one record

Downstream users are the organizations and developers that integrate your model into their own products. They need enough information to decide whether the model fits their use, to build their own risk assessments, and to meet their own obligations. Under the AI Act, the Commission's guidelines point providers to the transparency chapter of the GPAI Code of Practice and its Model Documentation Form as a route for meeting these duties. Under ISO/IEC 42001, the relevant control asks you to determine what technical documentation each interested party category needs and to provide it in an appropriate form. The two tracks ask for overlapping content, so one user-facing version can serve both if it is versioned and approved.

Capabilities and limits: Describe intended tasks, known failure modes and the conditions under which performance is not established.
Integration details: Document inputs, outputs, supported modalities, context limits and the interfaces downstream systems need.
Usage constraints: State prohibited or unsupported uses and the terms that apply to downstream deployment.
Version identifiers: Tie each documentation release to a specific model version so users can see which statements apply.
Update channel: Explain how changes are communicated and how users receive revised documentation.

Confirm with counsel and your auditor which sections of the form and which ISO outputs will be presented to users, and keep the approval record for each release.

How certification of a model provider's management system runs

The certification sequence moves from scoping and gap analysis to a statement of applicability, internal audit and management review, and then to the two certification audits run by an independent certification body. Each phase produces a named output that the next phase depends on, and the organization owns every output while the certification body decides the outcome.

Define scope and the AI management system boundary
The organization decides which models, products, APIs and internal teams fall inside the AI management system, including any general-purpose models it develops and places on the market under its own name. Leadership approves the scope in writing, and the organization owns this decision. The output is a documented scope statement that names the models, the life cycle stages covered and the interfaces with downstream users and suppliers. The step is complete when the scope can be read by an assessor and matched against the products actually offered.
Run a gap analysis against clauses 4 to 10
The team compares current practice with the management system requirements in clauses 4 to 10 and with the Annex A controls relevant to model development, such as technical documentation, data provenance and information for downstream users. An implementation partner can prepare the gap analysis, but staff who own each process must confirm the findings. The output is a gap register that lists each missing or weak requirement, its owner and the evidence that would close it. The step is complete when every requirement has a status and an owner.
Prepare the statement of applicability
Under clause 6.1.3, the organization lists the Annex A controls it needs and records a justification for including or excluding each control. For a model provider, development-stage controls in the life cycle and data objectives usually carry the most weight, while some use-stage or customer controls may apply differently. Leadership and the people who run each control review the draft. The output is an approved statement of applicability that links each control to its owner, implementation status and evidence location. The step is complete when every exclusion has a documented reason an assessor can test.
Implement controls and collect operating evidence
Teams put the included controls into operation and keep records as they work, including impact assessments, model design records, verification and validation results, data provenance logs and technical documentation for downstream users. Evidence must show the control operating over time, not only that a document exists. The output is an evidence library indexed by control, with dates and owners. The step is complete when each in-scope control has a record that a person outside the team could follow.
Complete internal audit and management review
Before an external audit, the organization tests its own AI management system through an internal audit and then holds a management review that considers audit results, risks, incidents and objectives. Management records decisions and actions. Internal audit is performed by people independent of the work they check. The outputs are an internal audit report, a management review record and a corrective action log. The step is complete when findings are closed or have an accepted plan, and management has signed the review.
Pass the stage 1 documentation review
The certification body reviews the organization's documented management system, scope and statement of applicability to judge whether the system is designed to meet the standard and whether the organization is ready for a full audit. The auditor identifies gaps that must be fixed before stage 2. The output is a stage 1 report with findings and any conditions that must be resolved. The step is complete when the certification body confirms readiness or the organization has addressed the open items. Ask the certification body in advance how it will sample evidence and which documents it expects.
Pass the stage 2 certification audit
The certification body tests whether the AI management system is implemented and operating as documented. Auditors interview staff, sample evidence across the life cycle, check model and data records and trace claims made to customers back to controls. The output is an audit report with nonconformities, if any, and a certification decision made by the certification body, not by the implementation partner. The step is complete when nonconformities are closed within the timeline set by the certification body and the certificate is issued.
Maintain the certificate through surveillance
After issue, the certification body performs periodic surveillance audits and a recertification audit before the certificate expires. The organization keeps its evidence current and reports material changes, such as a new general-purpose model or a major change in downstream documentation. Accreditation of the certification body is voluntary, so the organization should confirm the body's accreditation status and whether it is qualified under ISO/IEC 42006:2025, which sets additional requirements for bodies certifying AI management systems. The output is a continuing certificate and an updated evidence library. Ask the body for its surveillance plan in writing before signing.

Where the EU AI Act fines and enforcement sit beside certification

Certification does not decide who enforces the EU AI Act or how much a general-purpose AI model provider can be fined. For providers of general-purpose AI models, Article 101(1) lets the Commission impose fines of up to 3% of annual total worldwide turnover in the preceding financial year or EUR 15 million, whichever is higher, for intentional or negligent infringements. The AI Office, inside the Commission, holds exclusive enforcement powers for Chapter V (Article 88), which covers the general-purpose AI model obligations. Under Article 75(1), as amended in 2026, the AI Office is also exclusively competent, with exceptions, for AI systems built on a provider's own general-purpose model. A provider that holds an ISO/IEC 42001 certificate still answers to the AI Office for these duties, and the certificate does not reduce that exposure.

ISO/IEC 42001 is not the EU AI Act quality management system. The European Commission says the standard helps you set up an AI management system but does not match the quality management system the Act requires. CEN and CENELEC approved EN 18286 in June 2026, and the Commission cited EN 18286:2026 in the Official Journal on 14 October 2026 under Implementing Decision (EU) 2026/2274. Before you describe your program to a customer, regulator or notified body as meeting the Act, confirm with counsel which standard, if any, presumptively applies to your system and which obligations remain open. Check the Commission's standardisation FAQ for the current position.

Treat the two tracks as separate workstreams with a shared evidence base. The Model Documentation Form in the transparency chapter of the GPAI Code of Practice is the route the Commission describes for meeting the documentation duties, so map your ISO 42001 technical documentation and information-for-users records against it, not the other way round. Ask your certification body and counsel to confirm in writing which evidence they will accept for each track, and record that decision in your statement of applicability and regulatory register.

Who owns the controls, who prepares evidence, and who certifies

The organization owns every control in its ISO/IEC 42001 statement of applicability. For a general-purpose AI model provider, that means the decisions about which models are released, what training data is acceptable, what technical documentation is published, and which downstream users receive which information. These decisions cannot be delegated to a consultant or a vendor, and an assessor will ask who made them and when.

AI governance owner: A named executive or manager who holds accountability for the AI policy, the statement of applicability and management review under clauses 4 to 10.
Engineering: Owners of model training pipelines, data provenance records, evaluation results and release processes, who produce most of the evidence for the life cycle and data controls.
Legal and regulatory: Staff who interpret Regulation (EU) 2024/1689 obligations for providers, decide what downstream information is disclosed, and maintain the link between certification and EU AI Act duties.
Product and customer teams: Owners of the documentation that reaches users and suppliers under the information and third-party controls.
Internal audit and management review: Personnel independent of the work they check, who test the system before the external auditor arrives.

Before engaging anyone, confirm that each named owner can show decisions, records and approvals from the past operating cycle, not only from the time of writing.

What must exist before a certification audit can pass

An ISO 42001 certification audit tests whether the AI management system works in practice, not just whether documents exist. The five cards below are the pieces an assessor looks at first for a provider of general-purpose AI models, and each one can be checked internally before the certification body arrives.

A documented AI policy

The AI policy sets management direction for how the organization develops and provides AI systems and models. For a model provider, it should name the commitments that downstream users and regulators will rely on, such as documentation, data handling and incident communication. Check it internally by asking whether every senior owner can explain the policy from memory, whether it is approved by top management, and whether the review date has been set and recorded.

A complete statement of applicability

Clause 6.1.3 requires a statement of applicability that lists the necessary Annex A controls and justifies including or excluding each one. A model provider usually includes the life cycle, data and information-for-interested-parties controls, so exclusions need strong reasons. Check it internally by confirming that all 38 controls appear, that every exclusion has a written justification tied to the organization's actual activities, and that the document matches the controls described elsewhere in the management system.

Versioned technical documentation records

Control A.6.2.7 asks the organization to decide what technical documentation each group of interested parties needs and to provide it in a suitable form. For general-purpose models, this record feeds the documentation that downstream integrators and supervisory authorities receive. Check it internally by picking one released model version and confirming that its documentation has an owner, a version number, a change history and a link to the training and evaluation records it describes.

Data provenance logs

Control A.7.5 asks the organization to define and document a process for recording the provenance of data used in its AI systems across the life cycles of the data and the system. Gaps here are hard to repair after training, so the log should exist before a release. Check it internally by tracing a sample of training data sources back to their acquisition record, license or contract, and the processing steps applied, and confirming that the log is kept as the data changes.

A working internal audit and management review cycle

Clauses 9.2 and 9.3 of ISO 42001 require internal audit and management review of the AI management system. Auditors look for evidence that these reviews happened, that they found issues, and that the issues were tracked to closure. Check it internally by reviewing the last internal audit report and the most recent management review minutes, then confirming that each finding has an action, an owner and a closing date.

A named owner for each control

Every Annex A control needs a person accountable for its design and operation, and the owner should be able to show the evidence without help from the compliance team. For model providers, control ownership often spans research, safety, legal and product teams, which is where gaps appear. Check it internally by building a register that lists each control, its owner, the evidence location and the last review date, then asking each owner to walk an internal reviewer through one example.

Questions model developers ask before buying ISO 42001 help

Is ISO 42001 required for general-purpose AI model providers?

No. ISO/IEC 42001 is a voluntary management system standard, so no law makes certification a requirement for a general-purpose AI model provider. It becomes necessary when a customer contract, procurement rule or internal board decision requires it. The EU AI Act's obligations for general-purpose AI model providers, including the technical documentation and downstream information duties in Article 53, apply on their own terms. Confirm with your legal counsel which obligations apply to your model, and check your contracts for any named certification requirement before you commit to a timeline.

What drives the effort of an ISO 42001 implementation for a model provider?

Effort depends mostly on how much of the AI life cycle sits inside your organization and how many controls you include in scope. The main drivers are the number of models and versions, the maturity of existing documentation for training data and evaluations, and how many Annex A controls you keep in the statement of applicability. Teams that already run ISO 27001 or a secure software development life cycle usually reuse much of that evidence. Ask any provider to break its estimate down by model portfolio, documentation gaps, and internal roles, so you can see which parts are one-time work and which recur each year.

Can our team implement ISO 42001 internally without outside help?

Yes, an organization can implement the standard with its own staff, and the standard does not require an outside consultant. Internal teams own the controls, the AI policy, the risk and impact assessments, and the statement of applicability. What internal teams often underestimate is the evidence work: documenting data provenance, technical documentation for downstream users, and internal audit. Outside help is most useful for a gap analysis, for building repeatable evidence pipelines, or for preparing systems for assessment. Whichever route you choose, the certification body performs the audit, not your consultant.

How long does ISO 42001 certification take for a model provider?

No researched timeline is available for this page, so do not plan around a duration from a vendor brochure. Certification timing depends on your readiness, the number of models in scope, and the schedule of the accredited certification body. Ask the certification body for its stage 1 and stage 2 timeline in writing, and ask any implementation partner to tie its work plan to your readiness assessment. Confirm the expected duration against your contract deadlines before you sign any agreement.

Does an ISO 42001 certificate cover our EU AI Act obligations?

No. The European Commission states that ISO/IEC 42001 helps set up an AI management system but does not match the EU AI Act's quality management system. A certificate shows that your management system meets the standard's requirements, and it does not confirm compliance with each article of the regulation. For general-purpose model providers, the transparency chapter of the General-Purpose AI Code of Practice and its Model Documentation Form are the Commission's stated route to meeting the documentation duties. Map each obligation to evidence separately, and check the Commission's current guidance before relying on any mapping.

What does an implementation partner hand over at the end of the engagement?

A partner should hand over the systems, controls and evidence it was contracted to prepare, and nothing that implies certification. Typical deliverables, as agreed in a written scope, include the AI policy and its supporting documents, the statement of applicability with justifications for exclusions, the risk and impact assessment records, technical documentation templates for downstream users, data provenance records, and configuration of the tooling that produces logs. Ask for a deliverables list with owners, file locations and handover sessions. The organization keeps ownership of the controls, and the certification body issues the certificate.

Which parts of ISO 42001 work stay inside our organization?

Accountability for AI governance must remain with your organization. Management must approve the AI policy, set objectives, accept residual risk, and run management review. Staff must make decisions about intended purpose, model release criteria, and how documentation is used with customers. An outside partner can prepare systems and evidence, but it cannot sign off on your risk acceptance or act as your AI governance owner. Keep a named internal owner for each Annex A area so that evidence stays current after the engagement ends.

How DeployOpen prepares model provider evidence

DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, and prepares the systems and evidence an ISO 42001 assessment will examine. We do not issue audit reports or certificates; an independent certification body does that. The work below follows a written scope from start to handover.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
The written scope names which AI systems, models and documentation sets fall inside the AI management system boundary.
We map the Annex A controls you need against your statement of applicability, with the justification for each inclusion or exclusion.

How we build

We set up self-hosted tooling that holds technical documentation, data provenance records and model life cycle logs in your environment.
We configure version control and approval workflows so documentation changes are dated, attributed and reviewable.
We test the documentation pipeline and evidence collection, and document the results for your internal review before any assessor sees them.

How we hand over

You receive the documentation set, configuration records, runbooks and evidence index, organized by control.
We train the people who will maintain the evidence so ownership stays with your team after handover.
We confirm with your certification body which artifacts they expect, since their requirements decide the final evidence format.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope work is complete.
We can help update technical documentation when a model, its training data or its intended use changes.
Ask any implementation partner to confirm in writing which EU AI Act obligations their work does and does not cover.

ISO 42001 for AI model providers and general-purpose AI developers