The AI Questions on Vendor Forms, and How to Answer Them

Vendor questionnaires have grown an AI section. If you sell to companies bigger than you, you are increasingly likely to meet one, and it arrives from procurement, not from the person who wants to hire you.

That detail matters. The person who wants to hire you will forgive a rough answer. Procurement or risk may be comparing your answers against other suppliers, and an unexplained blank field creates an easy reason to ask more questions.

The forms themselves vary. Some are three questions bolted onto an existing security review, some run to several pages, and a few are built from published control frameworks. The themes recur even when the wording doesn't, and once you know what a good answer looks like you also know what to ask your own vendors. Many small businesses eventually find themselves on both sides of this, so each question below gets two readings.

A strong answer usually has four parts: the control, who owns it, what proves it is actually happening, and when it was last checked. "We use MFA" is a start. "We use MFA on all workflow admin accounts" is better. "We use MFA on all workflow admin accounts, access is reviewed quarterly, and the owner can produce the current access list" sounds like governance instead of a policy statement. Keep that shape in mind through the questions below.

Not every workflow deserves the same scrutiny, either. The more sensitive the data, the more the automation can reach, the bigger the consequence of a bad output, and the less a person checks it before it acts, the harder these questions should hit. A newsletter-sorting automation and one that moves money are not the same conversation, even if they run on the same platform.

What AI tools do you use, and where does our data go?

What they want to know: whether their information ends up somewhere they have not approved.

Answering it: name the tools and the data each one touches. "We use two AI tools. One drafts internal summaries from meeting notes and does not receive client data. The other categorizes inbound email, which includes sender names and message content."

Do not answer with a category like "we use AI for productivity." That reads as someone who has not looked. This is where the tool inventory from part one pays for itself, because you either have the list or you spend a day building it under deadline.

Asking it: watch for a vendor who names a capability instead of a product. Some architectures legitimately route across several providers, and some details sit behind an NDA. But if they cannot identify the products and providers in the path even confidentially, treat that as a gap in their own knowledge, not as confidentiality.

Where matters too, not just which tools. Ask which country or region actually processes the data, whether a subprocessor accesses it from somewhere else, and whether support staff anywhere in that chain can see it. "Where does our data go" has a literal answer as well as a product-list answer, and buyers increasingly want both.

Data minimization belongs in this question too. Ask whether every field being sent is actually needed, because the safest customer data to hand an AI service is the data the workflow never needed in the first place.

Do humans review AI output before it reaches us?

What they want to know: whether a model can send them something nobody looked at.

Answering it: be specific about which outputs are reviewed. A blanket claim that everything gets checked invites the follow-up question of who checks it, against what, and what record survives, so only make it if you can answer that. A low-volume supplier genuinely can.

Answer on consequence rather than destination. "Anything that affects a person, moves money, changes a record, or commits us to something is reviewed before it goes out. Low-stakes drafting and sorting runs without per-item review." That is a rule someone can picture you following.

Asking it: if the answer is that everything gets reviewed, ask who does it and how long it takes. Universal review is often aspirational, and a reviewer approving forty items in ten minutes is a formality. The gap between the policy and the practice is what you are buying.

Is our data used to train models?

What they want to know: whether their information is being used beyond the service they hired you to provide, including to train or improve models.

Answering it: go read your actual agreements before answering, because this depends on the specific product, the plan you are on, your settings, and sometimes your region. Do not infer it from the vendor's name or from the word "business" appearing on a pricing page. Terms differ between a company's consumer product and its business product, and between plans within each.

One thing worth stating plainly, because buyers increasingly ask it as a separate question: not used for training does not mean not retained, not logged, not reviewed by humans, and not passed to subprocessors. Those are four different commitments and a vendor can make one without making the others.

If a free-tier product has been touching client data, deal with it properly instead of quietly. Check what the terms actually allowed, fix the configuration, and answer honestly about both current and past use if the question asks. Cleaning something up the week before a form arrives and then answering as though it was always that way is the kind of thing that surfaces later, at a worse moment.

Asking it: ask which product and plan, not what the policy page says. People quote the enterprise terms while using the free product.

Who owns the automated processes that touch our account?

What they want to know: whether there is a person, or whether the thing just runs.

When a task moves from a person to an automation, the checking that person was doing informally does not transfer with it. Somebody has to be assigned it, and that assignment is frequently where the gap shows up.

Answering it: internally, put a name on it, not just a role, since a role can sit unfilled for months without anyone noticing. Externally, lead with the accountable role and hand over the named owner when asked, since people change jobs and the role is what should stay durable in a contract. "Each automation has a named owner, reporting into [role], responsible for its output and for stopping it if needed."

Asking it: if the answer is a team, ask for a person. A team name does not tell you who is accountable when something goes wrong.

How do you know when an automated process fails or drifts?

What they want to know: whether you would catch a problem before they did.

Answering it: describe the mechanism, not the intention. "We monitor run volume, failure rates, and whether scheduled jobs produced output at all. Thresholds alert the named owner, and a weekly digest confirms the checks themselves ran. We sample output monthly against a reference set." That describes something that exists. "We monitor our automations closely" does not.

Asking it: ask how they found out about their last automation problem. If the answer is that a customer told them, you have learned what their monitoring is worth.

What will you tell us if something changes?

What they want to know: whether an accurate answer today stays accurate.

A vendor can answer every question above correctly in June and be wrong by September without anyone lying. The model changes. The provider changes. A new subprocessor gets added. The workflow picks up a permission it didn't have. The retention setting changes. None of that needs a new contract to happen.

Answering it: name the specific list rather than promising to "keep them posted," and separate what you control from what you are told. Commit to flagging material changes you make yourself, such as a new permission on the workflow or a different retention setting, and material provider or subprocessor changes you are notified of, such as a new subprocessor or a model update your vendor announces. "We'll tell you before we add a subprocessor or change what this workflow can touch, and we'll pass along any material change our provider tells us about" is a commitment you can keep. "We'll keep you posted" is not.

Asking it: ask what counts as a material change and how fast you would hear about it. If they cannot name the list, they have not thought about this either, and you are counting on them noticing on your own behalf.

Can you turn it off?

What they want to know: whether there is a stop, and who can reach it.

Answering it: state the time and who has the access, whether that is their own or a documented emergency route. A stop that no one can reach in time is not really a stop.

Asking it: ask for a shutdown commitment sized to what the workflow can actually do and how fast the damage piles up, the same cadence-follows-consequence logic from part three. A weekly reporting job does not need weekend coverage. A workflow where harm can compound quickly may need weekend coverage, and a kill switch that only works during office hours is not enough for a process that keeps running outside them.

What happens when something goes wrong?

What they want to know: whether stopping the automation is the end of it, or the start of a response.

Turning something off answers containment. It does not answer what already went out while it was wrong, who fixes the records, or who tells the customer. Too many answers stop at the switch.

Answering it: say what counts as an incident for this workflow, who decides, how fast you would notify, and what information comes with that notice. "A named owner decides within a defined response window whether an incident has occurred, and we notify within the agreed period with what happened, what it touched, and what we've done about it" is a plan. That window should scale with what the workflow can do: a process that moves money or touches customer records needs a shorter one than a newsletter job. "We'll let you know if something happens" is not a plan at all.

Asking it: ask the same four questions of your vendor: what counts as an incident, who decides, how fast you hear, and what you get told. If a vendor has a kill switch but no answer to any of that, you have found the gap.

How is the workflow protected from misuse?

What they want to know: whether someone unauthorized, or something unexpected arriving in the input, could get at their data or make the automation do something it should not.

This is the question the rest of the form implies and rarely asks directly, and it is the one most small suppliers are least ready for. It is also the one that matters most for the automations that are worth building. A workflow that reads email, opens attachments, or pulls from web pages is taking instructions from outside your company all day. Text inside a document or a message can be written to steer a model, a pattern known as indirect prompt injection, and if that model can send, approve, or change something downstream, the content is no longer just data being processed.

Answering it: describe controls that exist, not intentions. Individual logins with multifactor authentication, so access can be traced and removed. Permissions scoped to what each automation needs rather than to whatever was convenient. API keys stored in the platform's credential system and not pasted into a prompt or a workflow node. A defined list of what the automation is allowed to change, with everything else out of reach. And a check on the output before another system acts on it, so a malformed or manipulated result stops there. In practice that means things like schema validation, an allow-list of permitted actions, limits on the parameters a workflow can pass, or a human approval step before anything high-impact goes through.

Say plainly which of these you have. This is a good place to be honest about a gap and name the fix, because it is the section where overclaiming is most likely to be tested.

Asking it: find out what the automation can actually do, not just what it reads. Can it send email, change records, approve anything, move money, delete anything. Then ask what stops it, and where a person has to say yes. The answer to what a workflow can reach tells you more about your exposure than any policy document will.

Who else touches our data?

What they want to know: the chain behind you. Their review does not stop at you if you are passing data to three other services.

Answering it: list everything in the path, including the automation platform itself. An n8n instance, its host, and a model provider are all part of the answer.

Asking it: ask for the list, not a yes or no. This is frequently where people answering the form have not looked past their own product.

How long do you keep it, and what happens when we leave?

What they want to know: whether their data sits in your systems indefinitely.

Answering it: know your retention settings before you answer. Automation platforms retain execution data, and execution data often contains the full content that ran through it. "We delete on request" is not true if your workflow logs hold six months of message bodies.

Worth fixing rather than disclosing: log what you need to diagnose problems, not every field of every record. Monitoring that quietly becomes your largest store of client data creates the exposure the monitoring was supposed to reduce.

Asking it: ask about logs and backups specifically. People answer about their database and forget the pipeline.

Say no clearly when the answer is no

The instinct on these forms is to make everything sound handled. Resist it.

A clear "we do not do this today" is survivable and often fine, particularly for a small supplier where nobody expects a compliance function. An overclaim that gets tested during an incident is not survivable, because now the problem is your answer, not the gap.

If a question exposes something you should fix, say what you do now and what you are changing. Be careful with dates, though. A commitment written on a questionnaire can end up referenced in a contract, so only put one down if you own it and intend to hit it.

The thing that makes this easy

Every question above is straightforward to answer when the record already exists, and surprisingly painful when it does not.

That record is what this series describes. The tool list, the ownership decisions, and the incident plan from part one. The reference pairs and change log from part two. The alerting, the heartbeat, and the quarterly page from part three. None of it was built for a questionnaire, which is exactly why it answers one well.

If you are looking at a form now and cannot answer half of it, start with the inventory and the ownership question. Those two give you the foundation for much of what gets asked.

We build automations for small businesses, and we set this up as part of the build instead of as a separate exercise. If you have workflows running today and cannot say who owns them or how you would know if they stopped, that is the place to start.

Sources

1. The four stage lifecycle for third-party service providers, covering identification and due diligence, contracting, ongoing monitoring, and termination: NYDFS industry letter of October 21, 2025, clarifying 23 NYCRR Part 500.11. It is cybersecurity guidance for third-party relationships rather than an AI-specific standard, and it expressly does not impose new obligations.
2. AI-related risk within existing Part 500 obligations, including vendor AI risk: NYDFS guidance of October 16, 2024.
3. Interagency guidance on third-party relationships, Federal Reserve, FDIC and OCC, June 2023.
4. The definition and mechanics of indirect prompt injection: OWASP Top 10 for LLM Applications, LLM01:2025 Prompt Injection.
5. Limiting the functions, extensions, and permissions available to an automation, the idea behind the scoped-permissions and output-check language above: OWASP LLM06:2025 Excessive Agency.
6. OWASP's GenAI Security Project released an updated Top 10 for LLM Applications in 2026, alongside a new Agent Control Standard for agentic security controls; prompt injection remains a top-ranked risk in both editions: OWASP GenAI Security Project, September 2026.
7. Change management and post-deployment monitoring as parts of AI risk management rather than separate concerns: NIST AI 600-1, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile.
8. The control, owner, evidence, and last-checked shape used throughout this piece echoes the structure of the Cloud Security Alliance's AI-CAIQ v1.1, which pairs its own control questions with justification and evidence fields.
9. The questions themselves, and what each one is really checking, come from having sat on both sides of these forms rather than from any published questionnaire template.

A note on images across this site. Illustrations and workflow diagrams are made with AI, from prompts we write and refine, and we edit most of them afterwards. Screenshots taken in n8n are not, since they show workflows we built in the tool.