Twelve questions to ask an AI decision vendor before 10 December 2026

On 10 December 2026 the APP 1.7–1.9 transparency obligation starts. The OAIC republished Chapter 1 of the APP Guidelines as version 2.0 on 30 September 2026, and the guidance makes one thing unambiguous: the obligation sits with your organisation, and you must be able to stand behind the statements you publish.

Most buying conversations about "AI decision logging" still revolve around whether a tool captures enough fields. That is the wrong question, and it is why the checklist below is organised around what you have to prove rather than what a product stores. Every question here is one you should be able to answer with a screen showing real data, not a slide.

The context for why evidence rather than description is the threshold: read what APP 1.7, 1.8 and 1.9 actually require first, then work through these.

1. Can you produce evidence for a decision you took six months ago?

Ask for a real historical decision - not one created for the demo - and produce the evidence on screen while you watch. Push back if they offer only "recent" records.

This is the single most important question, because it separates an evidence product from a logging product. A privacy policy describes categories of decisions; what an auditor tests is whether a specific decision can be reconstructed. If your history is not reconstructable, no wording you publish will be true when it matters.

Watch for the deflection: a dashboard that shows aggregate counts is not evidence of a decision. Neither is a record created by the demo script.

2. Does the record distinguish decisions made solely by automation?

APP 1.8(b) covers decisions made solely by the operation of the computer program. You can only disclose that category accurately if your evidence layer can identify it. Ask what field in the record carries it and what the values are.

If the answer is "we infer it from whether a human was logged in", that is a proxy rather than a record, and it will be wrong exactly where it matters - the borderline cases an auditor is most likely to pull.

3. Can it evidence an advisory output a human relied on?

This is the limb most vendors have never been asked about. APP 1.8(c) captures decisions for which the program does a thing substantially and directly related to making the decision. The OAIC's scholarship example is captured even though the panel could disregard the ranking; a loan officer who follows a risk score is captured; staff who can override an auto-suspension but rarely do are captured.

Ask: "If our risk model recommends a decline and a human approves it, does your product record the recommendation, the fact it was relied on, and who the human was?"

A vendor whose answer is "we only log final outcomes" cannot support a disclosure under 1.8(c), and you should establish that now rather than at audit.

4. For a named decision, can I see the model version and the inputs?

You need to answer: what information was used, by which system, by which version, and has anything been altered since. Ask them to walk one receipt end to end. If the answer describes capabilities rather than showing a record, keep asking.

Note what you do not need. Proprietary model weights and commercial-in-confidence detail are excluded from the disclosure obligation, and you should not disclose them. You do need the categories and the version, verifiably.

5. Can I verify a receipt without your platform?

Ask for the published public key, a sample receipt, and the open specification, then confirm the verification runs with no account, no network call to the vendor, and no cooperation from them.

This is the sovereignty test. If verification only works inside the vendor's console, the evidence sits inside someone else's trust boundary, and the same administrators who can alter production logs can alter the evidence. Your auditor will identify this without help. See Vendor-neutral assurance for how to frame it in the evaluation.

6. Is the record tamper-evident, and can I prove the tampering happened?

"Append-only" in a contract is a promise; a hash chain is evidence. Ask specifically whether each entry is cryptographically bound to the one before it, then ask them to demonstrate that altering entry #42 invalidates everything downstream.

Then ask the better question: what did you detect in production? A control nobody has ever seen fire is an untested control.

7. Is there an independent time anchor, and who controls it?

"Wherever the decision was signed" and "when it was signed" are different claims. An RFC 3161 timestamp from an authority outside both your and the vendor's control converts the second into something independently witnessed.

Ask whether timestamping is included or optional, who pays for it, and whether the timestamp authority is one the vendor also operates.

8. Who holds the signing key, and who can alter records?

There are two answers you need separately: who holds the root of trust for signing, and who can alter the store. The right answer is that your organisation holds the signing key and the operational layer cannot reach the audit trail.

A vendor that signs with its own key has made itself the trusted party, which is the dependency you are trying to remove. In Custodian-style modes the payload may be sealed to your key so the vendor never sees plaintext - ask specifically whether you can prove that claim or whether it is an assurance.

9. Can you show me the sub-processor list and where data is processed?

You need this for your own APP 1.4(f)–(g) overseas disclosure statement and your DPA, so ask for it as a maintained list rather than an answer in a call. Include the timestamp authority and any analytics or support tooling that touches your data.

Then ask the sharper question: which of these could ever touch decision content, as opposed to account metadata? The honest answer is usually that content never leaves infrastructure you control - but get it in writing, because your privacy policy will assert it.

10. What happens to the evidence when I need to erase, or when I leave?

Two tensions collide here. A data subject may request deletion; a regulator may require retention. Your control needs to do both, and prove it.

Ask how erasure works and whether it leaves a signed proof. Then ask what happens on termination: is the evidence exportable in an open format, or does it leave with the vendor? Exit without exportable evidence is lock-in with an audit consequence.

11. Can you support our Privacy Impact Assessment and an external audit?

The OAIC names a Privacy Impact Assessment in its APP 1.2 examples for exactly this kind of project. Ask whether the vendor will support a PIA, an external audit, a regulator production request, and an EDRS complaint - and get the answer in the contract rather than in a sales call.

12. Can you give me the categories, or only the records?

To draft an APP 1.8 disclosure you need the kinds of personal information used and the kinds of decisions in each limb, expressed as groups rather than per-system. The OAIC permits grouping.

Ask whether you can export that summary. A vendor who can only hand you raw records leaves you to do the classification yourself, which is the part the deadline will not wait for. A good vendor treats the grouping exercise as part of the product.

How to use this in a procurement

Weight the questions. If you only have an hour, ask 1, 3 and 5. Question 1 tells you whether the product can do its job, question 3 tells you whether it understands the new obligation's least obvious limb, and question 5 tells you whether you will own the result. A vendor strong on all three will be strong on the rest.

Red flags worth stopping on: evidence that only exists inside a console; a demo that only shows recent or synthetic records; no distinction between autonomous and advised outcomes; signing keys the vendor controls; and no answer on exit. Each of those is a small gap today and a finding in an audit.

Where Decision Keep sits against this list

We build to the same standard we describe, which is worth stating plainly so you can hold us to it: your organisation's key signs; entries are hash-chained; RFC 3161 timestamping is available; verification runs offline against a published key via /verify with no account; the open receipt format is documented in the specification; erasure produces a signed proof; and the routing outcome distinguishes autonomous from human-involved decisions. The sub-processor position is set out on the security page.

The reasoning behind the standard - what a forensic witness is and why it is the right one - is in Forensic witness for automated decisions, and the control framework an auditor will test is in Audit-ready AI: how GRC teams prove every automated decision.