Vendor-neutral assurance: why 'trust us' is not a control

When a vendor tells you their AI decision platform is auditable, ask a simple question: can you verify that claim without logging into their system?

If the answer is no, you do not have an audit trail. You have a story the vendor controls.

Most organisations discover this too late. The logs, dashboards, and audit trails live inside vendor platforms - Snowflake, Datadog, AWS CloudWatch, a model registry, a vendor's SaaS console. When a regulator, auditor, or risk committee asks for proof, the organisation hands over a story. The evidence belongs to the vendor.

This post explains what vendor-neutral assurance means, why it is the only form of assurance that satisfies modern regulators, and how to evaluate whether your current stack passes the sovereignty test.

The vendor-attestation trap

The most common response to an audit request for AI decision evidence is a vendor attestation. The vendor says their platform is compliant, their logs are immutable, their controls are SOC 2 certified. The organisation passes that attestation up the chain.

But attestation is not evidence. A SOC 2 report covers the vendor's control environment, not your specific decisions. The report says the vendor's platform is well-managed. It does not prove that a specific loan decision was made on a specific date, by a specific model version, and that the record has not been altered since.

As EY's AI assessments work explains, confidence in AI systems is essential, but it cannot rest on self-reported logs. McKinsey's 2025 state of AI research shows organisations moving from experimentation to value, while Gartner predicts responsible AI governance will be a board-level priority. The gap between adoption and accountability is widening.

The problem is not the vendor's integrity. The problem is separation. In a forensic context, the entity that executes the decision must not be the entity that records it. When the vendor controls both the model and the record, the record is a point of failure, not a control.

What vendor-neutral means

Vendor-neutral assurance has three parts:

1. Your key, your signature. The record is signed with your organisation's Ed25519 key, not the vendor's. The signature proves origin. Anyone can verify it against your published public key.

2. Your ledger, your export. The chain lives on infrastructure you control or can export in full. You can run the verifier offline, in a script, in a regulator's office, without asking the vendor for permission.

3. Independent time. The timestamp comes from an authority outside the vendor's control. An RFC 3161 timestamp proves when the decision was signed, independently witnessed.

If any of these three is missing, the evidence is not vendor-neutral. It is vendor-attested. And vendor-attested evidence is not evidence - it is a story the vendor told you about what happened.

The sovereignty test

The simplest way to evaluate any AI decision evidence platform is the sovereignty test. An external party should be able to answer yes to five questions:

1. Can the ledger be read and verified without relying on the operator's word?
2. Can the organisation rotate or hold its own keys?
3. Can the operator (or any other party) alter a recorded decision or forge a receipt?
4. Is "when" independently provable?
5. Is the verification tooling available to run independently?

If the answer to all five is yes, the evidence is sovereign - owned by the organisation, self-proving through cryptography, and independently verifiable. That is the bar the EU AI Act, NIST AI RMF, and Australia's APP 1.7-1.9 are converging on. For the full regulatory context, see The Forensic Witness: why automated decisions need an independent record.

Why vendor lock-in is an audit risk

Vendor lock-in creates three specific exposures:

Regulatory exposure. The EU AI Act requires providers to keep automatic logs of high-risk AI system use and deployers to keep records of their use. Australia's APP 1.7-1.9 requires meaningful information about the logic used in automated decisions. Both frameworks expect evidence an independent party can verify. A vendor-controlled console does not satisfy that test. See AI decision logging in Australia: meeting APP 1.7-1.9 for the regulatory mapping.

Procurement exposure. When you evaluate a vendor for AI decision recording, ask for a sample receipt you can verify offline against a published public key. Ask whether the records are hash-chained. Ask how erasure works. Ask whether the format is open. If the vendor cannot answer these questions, "auditable" is marketing. For a vendor assessment checklist, see Audit-ready AI: how GRC teams prove every automated decision.

Operational exposure. If the vendor changes their pricing, shuts down the platform, or is acquired, your evidence goes with them. A sovereign evidence store is portable. It survives vendor changes because it lives on infrastructure you control and uses an open format you own.

How to evaluate a vendor's "auditable" claim

When a vendor says their AI decision platform is auditable, run this checklist:

• Sample receipt. Can they give you a receipt you can verify offline against a published public key, with no account?
• Hash-chained. Are records cryptographically linked so tampering is detectable?
• Independent timestamp. Is there an RFC 3161 timestamp from an authority outside the vendor's control?
• Erasure with proof. When retention expires, is content deleted while a signed proof preserves the chain anchor?
• Open format. Is the evidence format documented and exportable, or locked inside the vendor's database?
• Production proof. Can they show evidence the control runs in production, not just in a demo?

If a vendor cannot satisfy all six, "auditable" is a marketing claim, not a control. For a deeper dive into what auditors actually need, see Audit-ready AI: how GRC teams prove every automated decision.

How portability works in practice

Portability is not a feature you turn on. It is an architecture you choose from the start.

The evidence format should be open and documented. The chain should be exportable in a single file. The verifier should be open source or publicly available. The key should be yours, generated in your environment, stored in your KMS or HSM.

When you can run verify against an exported chain with no account, no network call, and no trust in the platform, the evidence is portable. When you need a vendor login to see your own audit trail, it is not.

For engineering teams implementing this, see Adding a Forensic Witness to your AI stack: an engineering guide. For legal teams interpreting the regulatory obligations, see What legal and compliance teams need to know about AI decision records.

The bottom line

Vendor-neutral assurance is not a preference. It is a requirement. The regulatory timeline is real. Australia's APP 1.7-1.9 takes effect on 10 December 2026. The EU AI Act's high-risk logging requirements are in force now. US audit standards and the NIST AI RMF are pushing the same direction.

If your evidence lives inside a vendor platform, you do not have an audit trail. You have a story. And stories do not survive cross-examination.

The sovereignty test is the only test that matters. If your current stack fails it, the question is not whether you will need vendor-neutral assurance. It is whether you will have it before the auditor asks.

• Verify a sample receipt with no account.
• Read the receipt specification.
• Book a demo to map the sovereignty test to your stack.