What Should a Compliance Officer Ask Before Approving an AI Tool?

A compliance officer approving an AI tool needs answers in four areas before signing off: where data goes and who can see it, whether the vendor trains on your inputs, what happens when the tool fails or gets something wrong, and whether the vendor's own claims about security and compliance hold up on paper. Skip any one of those and the approval is a guess dressed up as a decision. The rest of this piece breaks each area into the specific questions worth asking, plus where those questions come from and why vague answers should worry you.

What Questions Cover Where the Data Actually Goes?

Start with the boring, literal question: where does the data physically or contractually live once it leaves your systems? Ask the vendor to name their subprocessors, not just describe them in general terms. A vendor that says "we use industry-leading cloud infrastructure" without naming AWS, Azure, or Google Cloud specifically is giving you marketing copy, not an answer you can put in a vendor file.

Follow up with retention. How long does the tool keep prompts, outputs, and any documents it processes after the session ends? Can you request deletion, and does deletion actually propagate to backups and logs, or just the primary database? If the vendor can't answer that in writing, treat it as an open risk rather than assuming the best case.

What Should You Ask About Training on Your Data?

This is where a lot of approvals go wrong, because "we don't sell your data" and "we don't train on your data" are two completely different promises. Ask directly: does any input your employees submit get used to improve the vendor's underlying model, whether for your account specifically or in aggregate across customers? Many consumer-facing AI products train on free-tier usage by default and only exclude enterprise or paid tiers through a separate contractual opt-out.

Get that opt-out in writing, tied to the actual contract, not a settings toggle that a vendor could change unilaterally in a future product update. If a salesperson tells you training is off "by default," ask what happens if an employee logs in with a personal account instead of the company-provisioned one, since that's often the gap where sensitive data leaks into a model nobody meant to feed it.

What Should You Ask About Vendor Accountability When Something Breaks?

Every AI tool eventually gets something wrong: a hallucinated citation, a misrouted document, an output that leaks context from one user session into another. The NIST AI Risk Management Framework (opens in a new tab) (NIST AI RMF) puts this under its Govern function, which calls on organizations to maintain contingency processes for failures in vendor-supplied AI systems and to keep the ability to disengage or deactivate an underperforming tool. Ask the vendor what their incident notification timeline looks like, in hours, not "promptly." Ask who at your organization gets notified, and whether that includes anyone outside IT.

Then ask what evidence they can actually produce after an incident. A vendor that can't show you audit logs of what a given user asked and what the model returned can't help you investigate anything, no matter how good their uptime numbers look.

How Do NIST AI RMF and ISO/IEC 42001 Fit Into Vendor Vetting?

These two frameworks answer different questions, and conflating them leads to weaker vetting. The NIST AI RMF is a voluntary U.S. framework built around four functions, Govern, Map, Measure, and Manage, and it's meant to guide how an organization manages AI risk internally and across its vendor relationships. It's a methodology, not a certificate a vendor can hand you.

ISO/IEC 42001 is different: it's an actual certifiable standard for an organization's AI management system (opens in a new tab), built on the same plan-do-check-act structure as ISO 27001. If a vendor claims ISO/IEC 42001 certification, ask for the certificate and the accredited certification body that issued it, and verify the certificate's scope actually covers the product you're buying rather than some other part of the vendor's business. Certification scope creep, where a company holds a real certificate that doesn't cover the system in question, is a common way vendors overstate what the badge on their website actually means.

What Should You Verify Before Trusting a Vendor's Compliance Claims?

Vendor claims about accuracy, security, or regulatory compliance deserve the same scrutiny you'd apply to any other procurement pitch, maybe more. The Federal Trade Commission (FTC) has brought enforcement actions (opens in a new tab) against companies for deceptive AI marketing claims, on the theory that overstating what an AI product can do, or can be trusted to do, is a form of consumer deception regardless of whether the underlying model is any good. That enforcement risk sits with the vendor, but the operational risk of an overstated tool lands on you.

If the tool will touch protected health information, don't take a vendor's word that they're "HIPAA compliant." The Health Insurance Portability and Accountability Act (HIPAA) requires a signed Business Associate Agreement (opens in a new tab) with any vendor that creates, receives, maintains, or transmits protected health information on your behalf, and that agreement has to spell out permitted uses, required safeguards, and breach reporting obligations. No BAA means no HIPAA compliance claim worth anything, no matter what the vendor's sales deck says.

What Contract Terms Should Back Up the Vendor's Answers?

Verbal assurances from a sales call don't survive an audit. Whatever the vendor tells you about data handling, training, retention, and incident response needs to show up as contract language, not a FAQ page that can change without notice. That includes the subprocessor list, the no-training commitment if one was made, data deletion timelines, audit rights, and notification windows for security incidents.

This is also where the location of the AI system itself becomes a real variable rather than a marketing detail. A tool that runs on infrastructure your organization actually controls changes which of these questions you're asking a third party versus answering yourself; ForgeAI's rundown of how private, on-premise AI plays out across regulated industries (opens in a new tab) is a useful reference for compliance teams weighing that tradeoff. Either way, running the model on your own hardware doesn't replace a signed agreement covering the parts of the relationship that remain contractual, like support, updates, and liability.

What Are the Red Flags That Should Stop an Approval?

A few answers should end the conversation rather than get negotiated around. A vendor that won't name its subprocessors, won't put a no-training commitment in the contract, or can't describe its incident response process beyond "we take security seriously" hasn't earned trust, they've dodged the question. The same goes for a compliance certification claim you can't verify against an actual certificate and a defined scope.

None of this means every AI tool needs to clear every bar perfectly before a compliance officer can approve it. It means the approval should rest on documented answers to specific questions, not on a demo that looked impressive or a sales rep's confidence. Write the answers down, attach them to the contract, and revisit them when the vendor changes its product, because an approval based on today's answers doesn't cover tomorrow's silent feature update.