A Customer Sent You a Security Questionnaire With an AI Section — How Do You Answer It?

Detailed Explanation

Security questionnaires with an AI section have become common for a simple reason: a customer's own risk team has been told to ask every supplier how AI touches their data, and the questionnaire template they were handed was written for a very different kind of company. Almost everything published to help answer one — the guides from Bitsight, Drata, Trustible and similar platforms — is written from the buyer's side, telling a large enterprise what to ask its AI vendors. Almost nothing is written for the business actually filling the form in, especially one that doesn't build or train any AI model at all.

That's the first thing to get straight before answering a single question: for the overwhelming majority of small and mid-sized Australian businesses, the honest starting position is "we use third-party AI tools inside our own processes; we don't build or train models ourselves." That single sentence resolves a large share of the questionnaire's most alarming-sounding items — questions about model training data, model bias testing, or algorithm transparency are usually aimed at an AI product company, and a business that just uses ChatGPT, Claude, or Copilot inside its workflow can answer them by explaining what it is, rather than trying to answer a question that doesn't actually apply.

Australia's regulatory settings support that framing. The National AI Plan, released 2 December 2025, governs AI use through Australia's existing legal frameworks rather than a dedicated AI Act — which means for most businesses, a customer's own security questionnaire, not a regulator, is the practical enforcement mechanism for how AI gets used responsibly. Answering these questionnaires well is not a compliance formality; for many suppliers it is currently the main external check on AI practice.

What These Questionnaires Actually Ask

Most AI sections cluster around the same handful of concerns, even when the wording varies:

• Where does the data go, and who processes it? Which AI tools touch the customer's data, and in which country is that data processed and stored.
• Is our data used to train the AI model? Whether inputs are used to improve the vendor's underlying model, and whether that can be turned off.
• How long is the data kept, and can it be deleted? Retention periods for prompts, outputs, and any logs, and whether deletion on request is actually possible.
• Who can access it inside your business? Which staff or roles can use the AI tool with this customer's data, and whether that access is controlled or open to everyone.
• Do any other parties see it? Sub-processors the AI vendor itself relies on — for example, the cloud infrastructure or model provider sitting behind the product you use.
• What happens if something goes wrong? How an AI-related incident (a wrong output reaching the customer, an access breach) gets detected, reported, and resolved.

Every one of these has a real answer for a business using third-party AI tools — it's just a different kind of answer than the questionnaire's authors were expecting, and the job is translating your actual setup into their categories rather than trying to force your setup to sound like theirs.

How to Answer Honestly When You Use AI Tools, Rather Than Build Them

Answer each section for the specific tools in actual use, not in the abstract. "We use AI tools" is not an answer; "we use Claude (Team plan) for internal drafting and Microsoft Copilot (included in our Microsoft 365 E3 licence) for document summarisation; neither is used to process this customer's data directly" is. For each tool that does touch the customer's data:

1. Name the vendor and the specific plan or tier. Data-handling terms differ meaningfully between a free consumer plan and a paid business plan from the same vendor — a paid business or enterprise plan typically excludes inputs from model training by default, while a free consumer account often does not. If your business is on the wrong tier for the answer you want to give, that's worth fixing before the questionnaire goes out, not after.
2. State the processing location as the vendor documents it, not as assumed. Vendor documentation on data regions changes without much notice, and answering from memory rather than the vendor's current terms is one of the more common ways this section goes stale. See does it matter which country an AI tool stores your data in for why this matters under the Australian Privacy Principles specifically.
3. Confirm the training-use setting explicitly, in writing, rather than assuming a default. Most reputable business-tier AI vendors publish a clear statement on whether customer inputs train their models; quote it directly rather than paraphrasing from memory.
4. Describe access control as it's actually configured, not as a policy document says it should be — if your AI usage policy restricts a tool to two roles but everyone in the business actually has a login, the honest answer describes the login list, and fixing that gap becomes the real action item. See what should an employee AI usage policy include for building a policy that access controls can actually be checked against.
5. Name the sub-processors you know about. Most AI vendors publish a sub-processor list (their cloud host, and sometimes the underlying model provider if it isn't their own). You are not expected to audit that vendor's entire supply chain yourself — stating that you rely on the vendor's own published sub-processor disclosures, and that you review them periodically, is a legitimate and common answer.
6. Describe the actual incident path. Who inside the business would notice an AI-related problem, who they'd tell, and roughly how fast — this doesn't need to be an elaborate policy, but it does need to be a real answer rather than "we would investigate."

Where a question genuinely doesn't apply — training data provenance, model bias audits, algorithm explainability — say so directly and explain why: "Not applicable; [business name] does not build, train, or fine-tune AI models. We use [vendor]'s AI product as a customer under its standard business terms." A reviewer who has read a hundred of these questionnaires recognises a clear, correctly-scoped "not applicable" as a good sign, not an evasive one.

Building the Evidence Base for Future Questionnaires

The questionnaire that arrives unannounced is painful mainly because most businesses don't have the answers sitting anywhere — they have to reconstruct them under time pressure. The fix is a short, living internal record, not a policy document, covering for each AI tool in business use: the vendor and plan, what data categories it's approved to touch, who approved that use, and where its data-handling terms are documented (a link to the vendor's own DPA or trust page is enough).

That record does two things at once. It turns answering a questionnaire into finding the relevant row and copying its facts across, rather than starting from scratch. And it's the same underlying discipline as keeping a record of which model was used, when, and by whom for any AI-assisted output your business produces — see how long should you keep records of AI tool conversations and outputs for the retention side of that same record. A business that already runs AI-assisted work through a managed process with that kind of run record — see what records can a Glivent workflow keep for review and audit for what that looks like in practice — is usually answering these questionnaires from an existing record rather than reconstructing one under deadline.

Things to Consider

• A questionnaire response is only as good as the evidence behind it. Stating a control exists and being able to show it are different things — keep whatever you'd point to (a vendor DPA, an access-control screenshot, a policy document) findable, not just the fact that it exists.
• Certifications don't automatically answer AI-specific questions. If your business holds SOC 2 or ISO 27001, that speaks to general information-security practice, not specifically to how AI tools within the business are governed — see what do SOC 2 and ISO 27001 actually mean when you're choosing an AI vendor for the gap between a general security certification and an AI-specific claim.
• The same questionnaire will come again, from a different customer, worded differently. Keep your answers in a reusable document rather than rewriting them from scratch each time — most of the substance doesn't change between customers, only the specific questions asked.
• A vague or overly broad "yes, we're compliant" answer invites more questions, not fewer. Specific, scoped answers close the loop faster than a confident-sounding generality that a careful reviewer will probe further.
• If a question exposes a genuine gap, say what you're doing about it rather than glossing over it. "We don't currently restrict this tool to specific roles; we're implementing role-based access by [date]" is a stronger answer than an inaccurate "yes" that a follow-up audit could contradict.

Common Mistakes

• Answering as if the business builds AI models, because the questionnaire was written that way. Most of these forms are templates built for AI product companies; force-fitting your answer to match their assumed context makes the response less accurate, not more credible.
• Giving one answer for "AI" in general, rather than tool-by-tool. Different AI tools in the same business can have entirely different data-handling terms, especially if some are on paid business plans and others are on free consumer accounts — a single blended answer hides that difference from the reviewer.
• Assuming a general security certification covers AI-specific questions. SOC 2 or ISO 27001 says nothing about whether a specific AI tool trains on your inputs; treat AI-specific items as their own category.
• Not knowing the answer and guessing rather than checking. A questionnaire answer that turns out to be wrong under a later audit is worse for the relationship than taking an extra day to confirm it with the vendor first.
• Leaving the "not applicable" items blank instead of explaining why. A blank field reads as an unanswered question; a one-line explanation of why it doesn't apply reads as a complete one.