What your AI governance review will ask about an RFP tool, and how to answer it

An AI governance review of an RFP tool comes down to six questions. Is the vendor independently audited? What data does the tool read, and where does it go? Does that data train anyone's model? Who can see what? How is a wrong answer caught before a buyer sees it? And what record is left behind? Reviews move fastest when the team buying the tool arrives with the answers and the evidence before the committee asks.

An RFP tool gets a closer look than most AI software for a simple reason. It reads your security policies, contracts and pricing by design, and what it writes goes to customers under your name. Below, each question comes with what the reviewer is really asking, what a good answer contains, the evidence to request from any vendor, and our own answer where we have an approved one.

Where the questions come from

On seven prospect calls we reviewed from August to October 2026, an AI committee or a security review of AI was a named step in buying. Those reviewers asked about data protection, hallucinations, the EU AI Act, access to SharePoint, and in one case whether the AI could be switched off. Several buyers expected the review to start after a proof of concept, with IT questionnaires they said would stretch the timeline.

The questions are predictable because most committees borrow them from a handful of public frameworks:

• FS-ISAC's Generative AI Vendor Risk Assessment Guide (February 2024) scores a tool across five areas, including its use of confidential data and its potential for exposure, then uses those scores to set how deep the review goes.
• The Shared Assessments SIG, one of the most widely used third-party risk questionnaires, has carried an Artificial Intelligence domain since its 2024 edition.
• The Cloud Security Alliance's AI Controls Matrix (version 1.1, June 2026) sets out 247 control objectives across 18 domains, with a vendor questionnaire, the AI-CAIQ, mapped to them.
• The NIST AI Risk Management Framework and its generative AI profile give many US committees their vocabulary.

An RFP tool scores high on exactly the areas these frameworks weigh most, so expect the fuller version of the review and plan for it from the first demo.

Is the vendor independently audited?

What they are really asking: has someone outside the company checked the security controls, recently?

A good answer is a current SOC 2 Type II report, which covers how controls worked over a period of months rather than on one day. Reviewers will want the report itself under NDA, not a badge on a website, and they will read the exceptions section.

Ask for: the full SOC 2 Type II report, its period, and any bridge letter covering the time since.

Tribble: has a SOC 2 Type II report. Ask for it, and its period, as you would from any vendor. The report describes customer data as logically separated by customer.

What data does the tool read, and where does it go?

What they are really asking: what is the blast radius if something goes wrong?

A good answer names every source the tool connects to, where the data is processed and stored, and every company that touches it on the way, including the providers of the AI models. A reviewer wants a data flow diagram and a sub-processor list, not a paragraph.

Ask for: a data flow diagram, the current sub-processor list with each AI model provider named, the data processing agreement, and the hosting regions.

Some companies approve only tools that work inside their Microsoft estate, so ask early whether the tool runs in Microsoft Teams and reads SharePoint with its existing permissions. If your policy requires data to stay in one region end to end, ask that in the first week too. It is the question most likely to change a shortlist, and it is cheaper to learn early than late.

Tribble: hosted on Microsoft Azure. It runs in Microsoft Teams, Slack and the web app, and reads SharePoint with the permissions each document already has.

Does our data train anyone's model?

What they are really asking: could our pricing, our pen test findings or our contract terms end up shaping answers for someone else?

A good answer says no, for the vendor and for every AI provider it uses, and says it in the contract. It also covers retention: whether the AI providers keep prompts and outputs at all.

Ask for: the contract clause on model training, and the vendor's retention terms with its AI providers.

Tribble: customer data is not used to train models, by us or by the AI providers we use, and that includes anonymised or aggregated versions of it. Zero-data-retention agreements with those providers apply by default. Answers are drafted by retrieving your content when a question is asked, not from a model trained on it.

Who can see what?

What they are really asking: can a sales rep get to the full pen test report by asking the AI for it?

A good answer is that every answer draws only on documents the person asking could already open, because the tool uses each source's own permissions. On top of that come roles inside the tool, and single sign-on with automatic provisioning, so leavers lose access when they leave.

Ask for: a live test. Have two people with different access ask the same question and compare what comes back. A policy document tells you the intent. The test tells you what happens.

Tribble: each connected source keeps the permissions it already has, so nobody gets an answer drawn from a document they could not open. SSO and SCIM are supported, with roles that control who can view, edit and approve answers.

How is a wrong answer caught before a buyer sees it?

What they are really asking: when the AI is wrong, and sometimes it will be, who notices, and when?

A good answer has three layers. Every claim cites its source, so a reviewer can check it. Questions the sources cannot support go to a named person instead of being drafted. And nothing leaves without review, enforced by the tool rather than by habit.

Ask for: a trial where you ask questions you already know the answer to, including some where the right answer is no. We wrote up five tests for made-up answers, with what happened when we ran three of them on our own account.

Tribble: every answer cites the passage it came from, with its owner and approval date. Questions no source supports are routed to the expert who owns them. Teams can lock approved answers and block export until every answer has been reviewed.

What record is left behind?

What they are really asking: six months from now, can we show why an answer said what it said, and who let it go out?

A good answer is a trail at the level of each answer: who drafted it, who edited it, who approved it, which source it came from, and when.

Ask for: the full history of one real answer, an audit log export if the vendor offers one, and how long the history is kept.

Tribble: each answer keeps its history of who changed it and when, with earlier versions you can view or restore, and review workflows record each assignment and approval. Citations name the source behind every answer.

The one-page brief to send your committee

Copy this into an email to your reviewers before the first meeting, and attach the evidence in the right-hand column. Reviewers who get it early spend the meeting on judgment, not on collecting documents.

What no vendor answer can settle for you

Two parts of the review are yours, whichever tool you choose.

The first is the use case. A reviewer will ask what the tool is for and who will use it, and that answer has to come from you. "Drafting RFP and security questionnaire answers from approved sources, reviewed before anything goes to a customer" is a narrower and easier case to approve than "an AI assistant for the sales team".

The second is ownership. The tool can route a question to the security lead, but someone has to agree to be that security lead. Committees approve faster when every source that feeds answers has a named owner, because that is who they will hold to account.