The AI vendor evaluation process at most companies goes something like this: a team lead finds a tool that solves a real problem, gets a demo, checks for SOC 2 certification, and moves it to procurement. That's it. The SOC 2 badge does a lot of heavy lifting — and for most SaaS tools, it's sufficient.

AI tools are different. When you grant an AI compliance tool, a security scanner, or an infrastructure monitoring platform access to your systems, you're not just adding another SaaS vendor. You're handing someone a read — and sometimes write — key to the most sensitive data in your organization: your cloud configurations, your access logs, your employee data, your customer records.

A SOC 2 Type II report tells you the vendor has internal controls. It does not tell you where your data lives when you use their product, who at that company can look at it, or what happens to it after you cancel. Those answers require asking directly.

Here are the seven questions that separate AI vendors who are genuinely safe to trust from ones that carry compliance risk you're not accounting for.

Question 01 / 07
Where does my data physically reside when your tool processes it?
Every AI tool processes data somewhere. The question is whether that somewhere is a server you control or a server the vendor controls. For regulated industries, data residency isn't a preference — it's often a legal requirement. Your HIPAA BAA may restrict where PHI can be processed. Your enterprise customers' security questionnaires will ask you to list every subprocessor and where their infrastructure runs.
✓ Good answer
"Your data is processed within your own cloud account. We deploy into your AWS/GCP/Azure environment. Nothing leaves your perimeter."
✗ Red flag
"Data is processed on our secure, SOC 2-certified infrastructure in US-East." (Translation: their servers, not yours.)
Question 02 / 07
Who at your company can access my data — and under what conditions?
Vendor employees accessing your data is one of the most underappreciated risks in the AI vendor landscape. Support engineers need to debug issues. ML teams may train on customer data. Security engineers may review logs. If the vendor's infrastructure touches your data, there is almost certainly some path — however restricted — by which their employees can reach it. You need to know: who, how, under what authorization, and is there a log you can audit?
✓ Good answer
"No Vendor employees can access your data. Our agents run in your cloud and send back only operational metadata — run status, completion signals. There is no raw data path to us."
✗ Red flag
"Access is limited to authorized support personnel for troubleshooting purposes." (Authorized by whom? Logged where? Reviewable by you? Probably no to all three.)
Question 03 / 07
Can I deploy this in my own cloud environment?
BYOC — Bring Your Own Cloud — is the architectural answer to the data residency problem. Instead of your data going to the vendor, the vendor's software comes to your data. This isn't possible for every category of tool, but for compliance automation, security scanning, and infrastructure monitoring, it's technically feasible and increasingly expected by security-conscious buyers. If a vendor hasn't built a BYOC option, that's a product strategy signal.
✓ Good answer
"Yes. We deploy agents directly into your AWS, GCP, or Azure account. All processing runs on your compute. This is our standard deployment model, not a premium add-on."
✗ Red flag
"We offer a private cloud deployment for enterprise customers at additional cost." (Often means hosted on their dedicated infrastructure, not yours.)

Why this question is decisive: A vendor who cannot answer yes to question 3 will also have difficulty answering questions 1 and 2 cleanly. Architecture determines data flow. If the architecture puts your data on their servers, the subsequent controls — encryption, access logging, employee NDAs — are mitigations, not solutions.

Question 04 / 07
What happens to my data if I cancel?
Offboarding is where many vendor relationships get messy. You need to know: how long does the vendor retain copies of your data after termination, in what form, who can still access it, and what does the deletion process look like? Some vendors retain data for months for "operational purposes." Others have no clear deletion policy at all — which means your infrastructure data potentially sits in their systems indefinitely after you leave.
✓ Good answer
"There is nothing to delete on our end. All data lives in your cloud account. You remove our deployment and we retain only anonymized aggregate telemetry, which contains no customer data."
✗ Red flag
"Data is retained for 90 days post-termination per our data retention policy, after which it is deleted in accordance with our standard data destruction procedures."
Question 05 / 07
How do you handle SOC 2 / HIPAA / ISO 27001 evidence collection?
This question is specifically for compliance automation tools — but it applies broadly to any AI tool that touches regulated data. If you're in healthcare, you need to know whether using this vendor creates a new Business Associate relationship under HIPAA. If you're pursuing SOC 2, you need to know whether this vendor appears in your audit scope as a new third-party subprocessor. The wrong answer here doesn't just create compliance risk — it can invalidate your certification.
✓ Good answer
"Because we process nothing, we don't appear as a subprocessor in your audit scope. No BAA required. Your auditor sees agents running in your infrastructure — which is yours."
✗ Red flag
"We have a standard BAA available. Our platform is in scope for your audit as a third-party system, which you'll document in your vendor risk register." (Now you're adding audit surface to solve an audit problem.)
Question 06 / 07
Do you use my data to train models?
This has become the most frequently asked AI security question, but it's often answered poorly. "We don't use customer data to train models" means very little if the vendor's underlying AI provider — OpenAI, Anthropic, Google — has their own data usage terms. You need the complete picture: does the vendor pass your data to third-party AI providers, and under what terms? Does your data appear in any training pipeline, including fine-tuning?
✓ Good answer
"No. And the question doesn't apply — we never receive your raw data. No model sees your infrastructure data because it never leaves your cloud account."
✗ Red flag
"We don't train on customer data, but we use third-party AI providers subject to their enterprise terms." (Your data may still flow through systems with their own retention and training policies.)
Question 07 / 07
Can I audit your infrastructure independently?
For enterprise buyers and regulated industries, trust but verify is the baseline. SOC 2 Type II reports are the starting point — not the finish line. You should be able to request penetration test results, security architecture documentation, and data flow diagrams that show exactly what data moves where. If a vendor stonewalls reasonable requests for technical documentation, that's the most reliable signal you have that they're not ready for the scrutiny your customers will apply.
✓ Good answer
"Yes. We provide SOC 2 Type II, data flow diagrams, and architecture documentation as part of standard enterprise onboarding. Our BYOC model means you can inspect exactly what runs in your account."
✗ Red flag
"Security documentation is available under NDA to enterprise customers after contract execution." (You shouldn't have to sign a contract to learn what a vendor does with your data.)

One Vendor, Seven Clean Answers

Foundri was built to answer all seven of these questions the same way: your data never leaves your cloud.

Here's why that's possible: Foundri deploys compliance automation agents directly into your AWS, GCP, or Azure account. Those agents have read access to your infrastructure — CloudTrail logs, IAM configurations, GuardDuty findings — and process everything locally. The output (your audit evidence package, your policy documents, your gap analysis) lives in your storage. What Foundri receives is operational telemetry: run status, completion signals, configuration summaries. No raw data. No subprocessor relationship. No BAA. No audit scope expansion.

The checklist above isn't a sales tool. It's genuinely useful for evaluating any AI vendor — and most of them will struggle with questions 1 through 4. Use it. The answers you get will tell you more about a vendor's architecture than their marketing page ever will.