What Should We Ask an AI Vendor Before Trusting Its Decision Records?

Seven questions procurement and risk leaders can put to any AI vendor to find out whether its decision records are evidence or just logs.

By Avik Ghosh, Managing Founder, illuminis

Saying a system is auditable does not prove anything

Most AI vendors say their systems are auditable. In practice, that usually means outputs are written to a log or database with a timestamp attached. That is good practice for debugging. It does not give you evidence.

When a regulator, examiner or plaintiff's attorney asks you to prove what the AI did, the vendor's log becomes your exhibit, and its weaknesses become your problem. The organization that deploys the AI is responsible for proving what it decided. Procurement and risk teams should test a vendor's records the way an opponent in court would.

Seven questions show whether a record is evidence or just information

Put these questions to any vendor whose AI makes decisions with consequences:

• When is the record created? Is it created before or after the output passes through application code, middleware and network calls? Outputs can change in the gap between inference and record.
• Who controls the record? If the system that makes the decision also stores the record, the author is also the custodian.
• Is the record signed, or only encrypted? Encryption protects confidentiality, not integrity. Anyone with the key can decrypt a record, edit it and encrypt it again.
• Can the record prove which device ran the inference? Without proof of origin, a fabricated record looks the same as a genuine one.
• Would you notice if a record were deleted? Without sequence integrity, records can disappear without a trace.
• Does each record identify the model version and policy in effect? Tracking versions only at the deployment level gives no answer during rolling deployments, A/B testing or fallback to a backup model.
• Can a third party verify the record without trusting you?

Weak answers leave you carrying the risk

Vendors often reply with write-once storage, access controls and periodic integrity checks. These lower the risk but do not remove it. Write-once storage cannot detect changes made before data reached storage. Access controls cannot stop an authorized administrator. Periodic checks find changes only after they happen.

No contract clause turns an editable record into evidence. If the vendor's answers are vague, the gap passes to you.

A strong answer seals the record at the moment of inference

InferTrust™ shows what strong answers look like. It signs each decision record at the execution boundary, before any network call, UI update or application process can see or change the output. The signing key is bound to tamper-resistant hardware, such as a TPM or Secure Enclave, and cannot be extracted or used from another machine.

Each record holds seven fields: model version ID, confidence score, policy hash, input feature hash, timestamp, decision action and sequence counter. One combined signature covers all seven, so changing any field invalidates the whole record. Records go into an append-only log, and anyone who holds the matching public key can verify them independently. Where confidence gating is used, the confidence score, the threshold and the routing decision are sealed together at inference time.

Ask these questions before you sign, not after an incident

Fixing record keeping during an investigation is technically hard and puts you at a disadvantage. Add these questions to your RFPs and security questionnaires now, while you can still negotiate. If a vendor's current pipeline falls short, InferTrust™ plugs into the inference pipeline without changes to existing models.

To see how InferTrust™ answers each of these questions, visit the product page.