Does AI Agent Certification Transfer If You Switch Vendors?

Q: Does AI agent certification transfer when you switch vendors?

Only partially, and the honest answer depends on what actually changed. The organisational parts of a certification, your documented governance policy, your incident response plan, and your human oversight design, generally survive a vendor switch because they describe how your business manages AI risk, not which model does the work. The technical evidence, including adversarial testing results and behavioural evaluation specific to the agent that was assessed, does not transfer, because it was produced against a system that no longer exists in its assessed form once the vendor or model changes.

Q: What happens to my certification level if I change my underlying AI model?

A material model change, such as moving from one foundation model provider to another, generally requires the technical evidence portion of an assessment to be redone, because the new model's behaviour, failure modes, and adversarial resistance have not been independently verified. Depending on the certification level held, this can range from a lighter delta review, where the organisational governance evidence is reused and only the technical layer is retested, to a full reassessment if the change is significant enough that prior findings no longer describe the deployed system.

Q: Does switching from one AI vendor to another trigger a full re-assessment?

Not automatically, but it usually triggers a scoped review to determine how much of the prior assessment still applies. If the vendor switch changes only the infrastructure layer while the model, configuration, and governance controls stay materially the same, a lighter delta assessment is typically sufficient. If the switch changes the model itself, the prompt architecture, or the autonomy scope the agent operates under, the technical evidence needs to be regenerated, which in practice resembles a substantial portion of a full assessment even if it is not labelled one.

Q: What parts of an AI governance programme stay valid across a vendor switch?

The parts that describe organisational process rather than technical behaviour generally stay valid: your documented risk management policy, your incident response and escalation plan, your human oversight design and approval workflow, your data governance policy, and your record of past incidents and how they were handled. These are evaluated under the Governance and Trust and Transparency dimensions of the Agent Certified methodology and are largely vendor-agnostic, because they describe how your organisation behaves, not how a specific model behaves.

Q: Should procurement teams ask about vendor-switch portability before certifying?

Yes, and this is a reasonable question to raise during the intake conversation for any certification or audit engagement, not just this one. A procurement team planning a multi-year AI vendor relationship should ask upfront which parts of an assessment are organisational and reusable versus technical and vendor-specific, because that materially affects the cost and disruption of a future vendor migration. Any credible assessment framework, including ISO/IEC 42001 audits, should be able to answer this question clearly rather than treating the entire certification as an all-or-nothing artefact.

Key takeaways

Certification is not a single portable artefact. The organisational governance evidence, policy, oversight design, and incident response plan, generally survives a vendor switch. The technical evidence, adversarial testing and behavioural evaluation of the specific agent, does not.
Whether a vendor switch triggers a full reassessment or a lighter delta review depends on what actually changed: infrastructure-only changes are usually lighter, while a change to the underlying model, prompt architecture, or autonomy scope usually is not.
This pattern is not unique to Agent Certified. ISO/IEC 42001 management system certifications separate organisational management system evidence from technical control evidence in a comparable way when scope changes.
Procurement teams planning a multi-year AI vendor relationship should ask about this portability distinction during intake, before committing to an assessment, because it directly affects the cost and disruption of any future vendor migration.
Treating a certification as an all-or-nothing artefact that must be discarded entirely at the first vendor change overstates the disruption; treating it as fully portable regardless of what changed understates the risk. The honest position sits between the two.

Why this question gets asked more than most

Enterprises evaluating AI agent certification are increasingly asking about vendor portability before they commit to an assessment, and the reason is practical rather than theoretical. Most organisations do not expect to stay on a single foundation model provider or agent orchestration platform indefinitely. Pricing changes, model capability improves elsewhere, or a strategic vendor relationship shifts. A procurement team weighing the cost of a certification engagement reasonably wants to know whether that investment survives the next vendor decision, or whether it needs to be written off entirely the moment the underlying technology changes.

The honest answer requires separating certification into the two kinds of evidence it is actually built from, because they behave completely differently when a vendor changes.

The two kinds of evidence, and why they travel differently

Organisational evidence describes how your business manages AI risk, independent of which model does the work. This includes your documented risk management policy, your human oversight design and approval workflow, your data governance policy, your incident response and escalation plan, and your record of past incidents and how they were resolved. None of this evidence describes the technical behaviour of a specific model. It describes your organisation's process, which does not disappear when you change vendors. This is the evidence assessed primarily under the Governance and Trust and Transparency dimensions covered in the Governance dimension guide and the Trust and Transparency dimension guide on this site.

Technical evidence describes how a specific deployed system actually behaves. This includes adversarial testing results, behavioural evaluation against defined failure modes, and performance data specific to the model and configuration that was assessed. This evidence is inherently tied to the system it was produced against. Once that system is replaced, the evidence describes a system that no longer exists in its assessed form, whatever the new system's actual quality turns out to be. There is no honest way to certify that a system you have not tested behaves the way the one you did test behaved, even if the vendor claims broad equivalence.

The practical consequence is that a certification level is really a snapshot of two things measured at once: an organisation's governance maturity, which is comparatively stable, and a specific system's tested behaviour, which is not. Switching vendors leaves the first mostly intact and invalidates the second.

What actually determines whether you need a full reassessment

Not every vendor change has the same effect, and treating all vendor switches as equivalent overstates the disruption in some cases and understates it in others. The determining factor is what layer of the stack actually changed.

Infrastructure-only changes. If an organisation moves the same model, with the same configuration and the same governance controls, to a different cloud hosting provider or a different orchestration layer that does not alter the model's behaviour, the technical evidence produced against that model's behaviour generally remains valid, because the thing that was tested has not materially changed. This is the lightest case and usually requires only a documentation update confirming the infrastructure change, covered in more detail in the post-assessment obligations guide.

Model or prompt architecture changes. Moving to a different foundation model, even one from the same provider's next generation, changes the thing that was actually tested. Adversarial testing results, behavioural evaluation, and failure-mode analysis were produced against the prior model's specific behaviour and do not transfer to a new one, regardless of whether the new model is described by its vendor as an improvement. This tier typically requires the technical evidence to be regenerated even where the organisational governance evidence is reused, which the third-party AI models certification guide on this site addresses directly for deployers who depend on an external model provider.

Autonomy scope changes. If a vendor switch coincides with expanding what the agent is authorised to do, moving from a narrowly scoped customer service function to a broader set of autonomous actions, this is treated as a materially different system regardless of whether the underlying model changed, because the risk surface being assessed is different. The autonomy envelope dimension guide covers how this specific factor is scored.

How this compares to ISO/IEC 42001

The closest established comparator for how portability should work is ISO/IEC 42001, the international standard for AI management systems. An ISO 42001 certification is fundamentally a certification of an organisation's management system, its policies, processes, and controls, rather than a certification of a specific piece of software. When an organisation changes a technical component within its management system, a competent ISO 42001 auditor distinguishes between a change that affects the management system itself, which may require reassessment of that element, and a change that leaves the management system intact while altering an underlying technical dependency. This is the same organisational-versus-technical distinction described above, applied within an established and widely recognised certification model. It is not a novel idea specific to this category; it is standard audit and certification practice extended to a newer subject matter.

What procurement teams should ask before certifying

Given that a vendor switch is a realistic possibility for most enterprises over a multi-year horizon, it is reasonable for a procurement team to raise portability directly during the intake conversation for any certification engagement, not only this one. The specific questions worth asking are which parts of the assessment produce organisational evidence versus system-specific technical evidence, what triggers a full reassessment versus a lighter delta review, and what the delta review actually costs relative to a full engagement. Any credible assessment framework should have a clear, documented answer to these questions. A framework that cannot articulate this distinction is treating certification as a single black-box artefact, which does not reflect how the evidence underneath it is actually produced or how it actually ages.

The Agent Certified seven-dimension methodology and the five certification levels it produces are structured with this distinction in mind from the outset, which is why organisational governance dimensions and system-specific technical dimensions are scored and reported separately rather than collapsed into a single undifferentiated number. This is also directly relevant to insurance underwriting, since the certification feeds underwriting guide on this site explains why underwriters increasingly want to see this same organisational-versus-technical split in the evidence file they are given, a point developed further in who insures AI agents in Europe on agentinsured.eu.

Frequently asked questions

Does AI agent certification transfer when you switch vendors?

Only partially. The organisational parts, documented governance policy, incident response plan, and human oversight design, generally survive a vendor switch because they describe how your business manages AI risk, not which model does the work. The technical evidence, including adversarial testing specific to the assessed agent, does not transfer, because it was produced against a system that no longer exists in its assessed form once the vendor or model changes.

What happens to my certification level if I change my underlying AI model?

A material model change generally requires the technical evidence portion of an assessment to be redone, because the new model's behaviour and failure modes have not been independently verified. Depending on the certification level held, this ranges from a lighter delta review reusing organisational evidence to a full reassessment if the change is significant enough that prior findings no longer describe the deployed system.

Does switching from one AI vendor to another trigger a full re-assessment?

Not automatically. If the switch changes only infrastructure while the model, configuration, and governance controls stay materially the same, a lighter delta assessment is typically sufficient. If the switch changes the model itself, the prompt architecture, or the autonomy scope, the technical evidence needs to be regenerated, which in practice resembles a substantial portion of a full assessment.

What parts of an AI governance programme stay valid across a vendor switch?

The parts describing organisational process rather than technical behaviour: documented risk management policy, incident response and escalation plan, human oversight design, data governance policy, and the record of past incidents and how they were handled. These are largely vendor-agnostic because they describe organisational behaviour, not model behaviour.

Should procurement teams ask about vendor-switch portability before certifying?

Yes. A procurement team planning a multi-year AI vendor relationship should ask upfront which parts of an assessment are organisational and reusable versus technical and vendor-specific, since that affects the cost and disruption of a future vendor migration. Any credible assessment framework, including ISO/IEC 42001 audits, should answer this clearly rather than treating certification as an all-or-nothing artefact.

References

International Organization for Standardization. ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system. Distinguishes management system evidence from technical control evidence when assessing scope changes.
Agent Certified. Methodology specification, seven dimensions including Governance, Trust and Transparency, and Autonomy Envelope, published at agentcertified.eu/methodology.
Agent Certified. Certification levels, Pre-Assessment through Elite, published at agentcertified.eu/certification-levels.
Agent Certified. Intake and scoping process, published at agentcertified.eu/request-assessment.

Does AI agent certification transfer if you switch vendors?