Business & Money
How Do You Explain Your AI Use to Customers and Auditors Without Overpromising?
By Jim Vernon, Editor, AI Intelligence International · Published 25 August 2026 · Reviewed against our editorial standards · About the author
Procurement teams now ask where AI sits in your product, what data it touches and who is accountable for its output. Answering badly costs deals; answering with claims you cannot support costs more later.
This article covers the documentation to prepare once, the language that holds up under questioning, and the specific claims to avoid.
Key takeaways
- Prepare one internal AI inventory; almost every customer and auditor question is answerable from it.
- Describe the human accountability path, because that is what a buyer is actually assessing.
- Never claim accuracy figures you cannot reproduce on request.
- Disclosure that is specific and modest closes more deals than vague reassurance.
What should the internal inventory contain?
One row per AI-assisted feature: what it does, which provider and model family, what data is sent, whether that data is retained or used for training, whether output is shown to end users or only to staff, and who reviews it.
Add the failure handling: what the user sees when it is uncertain or unavailable, and how a wrong output would be detected and corrected.
Keep it current with a named owner and a quarterly review. Most of the pain in security questionnaires comes from having to reconstruct this under time pressure.
What do procurement teams actually want to know?
Three things, in this order: does our data leave your system and where does it go, is a human accountable for output that affects us, and what happens when it is wrong.
Model choice and technical architecture are rarely the concern. Answers that dive into architecture while skipping data flow read as evasive.
Have a two-page summary ready, derived from the inventory, and offer it before it is requested. Volunteering it materially shortens security review.
How should you phrase capability claims?
Bound every claim by task, input type and measurement. 'On our benchmark of 500 customer invoices, field extraction matched a human reviewer on 97% of fields, measured monthly' is defensible. 'Highly accurate extraction' is not.
Prefer describing the process over the outcome where you lack measurement: 'every extracted total is checked against the document sum before it is accepted' tells a buyer something real and commits you to something you control.
Avoid absolute words entirely — never, always, fully automated, guaranteed. They convert a quality issue into a misrepresentation issue.
What should you disclose to end users?
That AI is involved, what it is doing, and how to challenge or correct the result. Users are largely untroubled by AI involvement and strongly troubled by discovering it after a bad outcome.
Place the disclosure where the output is, not only in a policy page. A short line at the point of use satisfies most emerging expectations and reduces support load.
Where a decision materially affects someone — pricing, eligibility, employment — provide a human review route and say so plainly.
How do you handle the training-data question?
Answer it directly with your provider's contractual position and your own configuration, and be prepared to show the relevant terms. 'Customer data is not used to train third-party models under our enterprise agreement' is a sentence you must be able to evidence.
If you do use customer data to improve your own system, say so, describe the scope, and offer an opt-out. Discovery of undisclosed use is one of the fastest ways to lose an enterprise account.
Keep a dated copy of provider terms. They change, and you will be asked what was true at the time of a specific transaction.
What does an auditor look for that a customer does not?
Evidence rather than assertion: change logs on prompts and models, records of the evaluation runs you claim to perform, incident records, and proof that the human review you describe actually happened.
Retain the review artefacts. A workflow where a person approves output but leaves no record is, from an audit perspective, an unreviewed workflow.
Version your prompts and configurations in source control. Being able to state exactly what the system was doing on a given date resolves most audit questions in minutes.
Worked example: a security review that went well
A 40-person contract-analytics vendor was in procurement with a bank. The questionnaire included eleven AI-specific questions, several of which assumed a much larger organisation.
They had maintained a six-row inventory for a year. It showed that only two features sent customer text to a provider, both under terms excluding training use, with a 30-day zero-retention configuration documented by a dated screenshot and contract clause.
For accuracy, they declined to give a headline figure and instead supplied their benchmark methodology: 500 held-out contracts, monthly runs, clause-identification agreement with a lawyer reviewer at 93% over the last six runs, with the run history attached.
For accountability, they described the mandatory human sign-off before any extracted obligation entered the client's system, and supplied a sample audit record showing reviewer, timestamp and changes made.
The review closed in nine days against a typical six-week cycle. The bank's security lead specifically cited the absence of unsupported accuracy claims as the reason the file moved quickly.
Frequently asked questions
Do we have to disclose AI use if the output is reviewed by a person?
Increasingly yes, and it is the safer default regardless of jurisdiction. Human review changes the accountability story but not the fact of AI involvement, and buyers treat non-disclosure as a trust problem.
What if we do not have accuracy numbers?
Say so and describe your controls instead. Buyers accept 'we do not publish an accuracy figure because our inputs vary too widely; here is our review process' far more readily than a number that collapses under questioning.
How often should the inventory be reviewed?
Quarterly, plus whenever a feature ships or a provider changes. The review is short once the document exists — usually under an hour — and it keeps questionnaire responses accurate.
Should legal write the customer-facing language?
Legal should review it, but it should be drafted by whoever knows how the system actually works. Legal-drafted descriptions tend to be accurate about liability and vague about mechanism, which is the opposite of what buyers want.