Keeping AI audit evidence intact when exiting an AI control plane vendor

Why vendor exit is an evidence-continuity problem

When a regulated enterprise replaces an AI control plane vendor, the migration plan usually centers on policies, integrations and traffic. The evidence tends to be an afterthought. Yet that evidence is what lets you show a regulator or auditor what your AI systems were permitted to do and what they actually did.

The risk is concrete. Evidence may sit in vendor-hosted storage, in a proprietary format, or under retention terms that end with the agreement. Policy versions, enforcement decisions, approvals and timestamps can become unverifiable, and records can lose the context needed to interpret them.

The obligations do not pause for a tooling change. The EU AI Act requires a risk management system for high-risk AI systems to be established, implemented, documented and maintained, and requires technical documentation to be kept up to date. Its recitals describe records and documentation as essential for traceability, compliance verification and monitoring across a system's lifetime. A notified body may also ask a provider for further evidence during an assessment. NIST guidance on agent identity goes further on design: evidence should remain verifiable after retirement, without requiring the retired component to stay online. That is a useful test for any exit plan.

Step 2: Define portability, format and integrity requirements

Portability is not just the ability to download records. Exported evidence must be readable, complete and verifiable by someone who has no access to the vendor's systems. Treat the following as practitioner guidance for your export specification, and confirm the details with your own security and audit teams.

Use documented, non-proprietary formats with stable field definitions, and include a schema or data dictionary with every export. Keep identifiers that tie decisions to policy versions, so a decision can be traced to the exact rule set in force at that moment. Preserve original timestamps and time zone conventions rather than normalizing them away.

For integrity, record a cryptographic hash for each exported file and a manifest listing all files, counts and date ranges. Where the vendor signs records or chains them, export the signatures and whatever is needed to verify them, such as the identity chain and public keys. NIST describes the design target as an unbroken, tamper-evident chain of custody over an append-only body of evidence, and notes that a signed chain can be verified when anchored in a registry that no single vendor controls. If your verification depends on keys only the outgoing vendor holds, you have an exit risk to resolve before cutover.

Keep a chain-of-custody record of the export itself: who ran it, when, from which system, and where the verified copy now lives.

Step 3: Align retention, residency and contract terms

Retention periods differ by framework and by evidence type. HIPAA, NYDFS, NAIC, the EU AI Act and NIST AI RMF each bear on documentation in different ways, and NIST AI RMF is voluntary guidance that links documentation, provenance and audit to transparency and accountability. Set the retention period for each evidence class with compliance counsel, then apply the longest applicable period to the preserved archive. Retention that depends on the vendor agreement is the weakest point, because it ends when the agreement does.

Residency matters as much as duration. Decide where the preserved evidence may be stored, and confirm the export path does not move it somewhere your obligations do not allow.

In the contract, ask for terms that match your plan:

A right to export all evidence types, including policy history and denied attempts, in the agreed formats.

A defined post-termination period during which the vendor keeps data available for retrieval.

Written deletion certification, issued only after you confirm that the export is verified.

A commitment to supply schemas and verification materials with the export.

Negotiate these before notice of termination, while the relationship still gives you leverage.

Design evidence storage so the next exit is easier

The most reliable way to reduce exit risk is to avoid needing a rescue export at all. If evidence is written to storage you own, in a format you can read, with retention and residency you set, then a vendor change becomes a change of producer rather than a change of custodian. The archive, its keys and its verification procedure remain with you.

Trussed is designed along these lines. It enforces policy in the execution path, so allow, redact, block, rate limit and escalate decisions are enforced at runtime, not reviewed after the fact, and it generates audit-ready evidence from that enforcement, mapped to HIPAA, NAIC, NYDFS, the EU AI Act and NIST. It supports self-managed deployment in the customer cloud with configurable retention and data residency, so evidence stays under customer control.

Whatever tooling you choose, apply the same test: can your team verify and produce the evidence without the vendor present? If the answer is yes today, a future exit is a planned project. If it is no, the first task is to fix that, before any contract renewal or termination decision.