AI Vendor Privacy: The Questions to Ask Before You Connect Anything

Every AI tool sold to your company arrives with the same pitch: connect your systems, and it gets smarter. What that sentence actually means is that you are about to hand a third party a live authenticated pipe into your CRM, your ticketing system, your document store, and your inbox. The AI vendor privacy questions you ask in the twenty minutes before you click "Authorize" determine whether that pipe is a controlled integration or an unbounded copy of your business sitting on someone else's infrastructure.

Most security reviews still treat AI vendors like SaaS vendors from 2018. They ask about encryption and uptime, which are table stakes, and skip the five things that actually differ: whether your data trains a model, how long it is kept, how it is isolated from other customers, who else touches it downstream, and what the tool is permitted to do rather than just read. This article gives you those questions in a form you can paste into an email, plus what a strong answer sounds like versus a weak one. Skopx answers each of them at the end, plainly, including where the honest answer is "ask us and we will put it in the contract."

Why the standard security questionnaire misses AI vendors

A traditional vendor questionnaire assumes data moves in one direction and sits still. You upload files, the vendor stores them, you delete them, done. AI vendors break three assumptions in that model.

First, the data does not sit still. It gets chunked, embedded, indexed, cached, and passed to a model provider that may be a different company entirely. A "we do not store your data" claim can be technically true of the vendor's primary database and completely false of its vector index, its prompt logs, and its error tracking.

Second, the surface is wider than the tool. A single OAuth grant to a modern integration layer can carry read access to every file in a Drive, every channel in a Slack workspace, and every deal in a CRM. The scope screen you clicked through in three seconds is the real security boundary, not the vendor's marketing page.

Third, AI vendors increasingly write as well as read. A tool that can send email, update records, or post to channels is not a data-privacy question anymore, it is an authorization question. The blast radius of a compromised read-only key is embarrassment. The blast radius of a compromised write key is your customers' inboxes.

So the questionnaire has to change shape. Ask about the data lifecycle, the identity model, and the action model separately, because a vendor can be excellent at one and careless about the others.

The five AI vendor privacy questions that matter most

These five cover the majority of real risk. Ask them in this order, because each one changes how much you care about the next.

1. Does our data train your models, or anyone else's?

This is the question with the most weasel room in the industry. "We do not sell your data" is not an answer. "We do not use customer data for training" is closer. What you want is a statement that covers three separate parties: the vendor's own models, the underlying model provider's models, and any fine-tuning or evaluation done by either.

Push for specificity. Ask whether the training exclusion is contractual or a setting, whether it applies to all plans or only enterprise ones, and whether human reviewers ever read prompts and outputs for quality purposes. Human review is a legitimate practice that many vendors run, but you deserve to know it exists and to be able to opt out.

Ask for the answer in writing in the agreement, not in a support-chat transcript. Settings get toggled. Contracts do not.

2. What is retained, where, and for how long?

Break this into four buckets, because vendors habitually answer for one and let you assume the rest:

• Source content: the documents, messages, and records pulled from your connected tools.
• Derived artifacts: embeddings, summaries, extracted entities, and search indexes built from that content.
• Prompts and outputs: the actual text sent to and returned from the model, including anything logged for debugging.
• Metadata and telemetry: who queried what, when, from where.

Embeddings deserve their own line item. They are commonly treated as "not your data" because they are numeric vectors, but published research has repeatedly demonstrated that meaningful text can be reconstructed from embeddings. Treat a vector index as a copy of the source, and require it be covered by the same retention and deletion terms.

Then ask the deletion question in operational terms: if we terminate tomorrow, what is deleted, on what timeline, from which systems including backups, and do you provide written confirmation?

3. How is our data isolated from other customers?

There are three broad answers, and they are not equally good: separate infrastructure per customer, a shared database with row-level or tenant-scoped isolation enforced in the data layer, and a shared database with isolation enforced only in application code.

The third is where most cross-tenant leaks come from. If the only thing standing between your data and another customer's is a WHERE org_id = ? clause that a developer must remember to write, one missed clause is a breach. Isolation enforced at the database layer, where the engine rejects the query regardless of what the application asked for, is a materially stronger design. Ask which one it is, in those words.

Also ask specifically about the search index. A common failure pattern is strong isolation in the primary database and a single shared vector collection where filters are applied after retrieval rather than enforced during it.

4. Who are your subprocessors, and how do we hear about changes?

Any AI vendor has subprocessors: a hosting provider, a model provider, an integration layer, an email sender, an error tracker. That is normal. What matters is whether the list is published, whether it is complete, and whether you get advance notice with a right to object before a new one is added.

For AI specifically, ask which model providers can receive your content and whether you can choose or restrict them. A vendor that routes to whichever provider is cheapest that week, without telling you, has effectively outsourced your data governance to its procurement team.

5. Who can access our data, and what can the tool do on our behalf?

Two halves. The human half: which vendor employees can access customer data, under what approval, with what logging, and is that access broken glass or routine. The machine half: what scopes does the integration request, are they read-only, and can the tool take actions without a human confirming.

Ask for least-privilege scopes and find out whether the vendor supports them at all. Many tools request broad scopes because it is easier than handling partial permissions, then tell you it is required. Sometimes it genuinely is. Sometimes it is laziness that becomes your risk.

The questionnaire, with scoring

Paste this into your vendor email. The value is in the third and fourth columns: they let a non-specialist tell a real answer from a rehearsed one.

Two notes on using this. First, ask for answers in one document, not spread across calls, so you can attach it to the contract. Second, a vendor that answers "we do not have that yet, here is our timeline" is often safer than one that answers everything perfectly in four minutes.

Reading the answers: what a red flag actually sounds like

Bad answers rarely say anything false outright. They redirect.

The most common tell is a one-word summary of a SOC 2 engagement. SOC 2 produces an auditor's attestation report covering a defined scope over a defined period. It is not a badge, and the adjective a vendor picks tells you nothing about what was actually examined. A vendor that has genuinely been through the process will tell you the report type, which trust services criteria were in scope, which observation window the report covers, and what the auditor listed as exceptions, and will send the report under NDA. A vendor that compresses all of that into one word is either being loose with language or hoping you skip the follow-up. Ask it anyway.

One related trap: a real report can still cover a parent company or infrastructure rather than the application you are buying, so read the scope section, not the cover page.

"Enterprise-grade security" and "bank-level encryption" mean nothing. Encryption at rest is a checkbox that every major hosting provider gives you by default.

"We do not store your data" deserves an immediate follow-up: then what is in your vector index, and what is in your logs.

"Your data is isolated in your own workspace" describes a UI, not an architecture.

And when a vendor cannot tell you which model provider sees your content, you have found the real answer to question four.

Where the AI vendor privacy questions get harder: tools that take actions

Read access is a confidentiality problem. Write access is an integrity problem, and it needs its own review.

Ask whether actions require explicit approval, whether approval is per action or a blanket session grant, and whether there is a full audit trail showing what was executed, with what inputs, against which account. Ask what happens when an automated run fails halfway: does it retry, and can a retry duplicate an outbound message or a record.

Then ask the prompt injection question directly. If the tool reads a document or an email and that content contains instructions, can those instructions cause an action? The honest answer from any vendor is that this is an unsolved class of problem across the industry and the mitigation is layered: approval gates, restricted scopes, and audit logs. A vendor who says injection is fully solved is telling you they have not thought about it.

This is also where you should look at scheduling. An automation that runs unattended every fifteen minutes with write access is a different risk profile than a chat assistant a human is watching. Both can be fine. They should not go through the same approval.

How Skopx answers these AI vendor privacy questions

Here are our answers to the same questionnaire, held to the same standard we just asked you to apply.

Training. Your data does not train a model. Not ours, and not a provider's, because of how the architecture works: Skopx uses bring your own key, so requests go to Anthropic, OpenAI, Google, or another provider on your own account under your own provider terms. We do not sit in the middle marking up AI usage, and we do not accumulate a training corpus from customer content. If that model is new to you, Bring Your Own Key AI: What It Means for Cost and Control explains the cost and governance implications in detail.

Isolation. Row-level isolation per organization, enforced in the data layer rather than only in application code. Data is AES-256 encrypted at rest and TLS 1.3 in transit.

Actions. Skopx acts only with your approval. Workflows you build by describing them in chat are inspectable step by step after every run, so you can see exactly which integration action fired with which inputs. Those workflows are deliberately constrained: acyclic, a maximum of 20 steps, no custom code steps, and AI steps run on your key. You can see the full model on the workflows page.

Audit posture. Skopx has SOC 2 controls in place. That phrase is the ceiling of what we will claim, and we would rather lose a deal than stretch it into something that sounds like a finished report we do not have. Apply the same skepticism to us that the table above tells you to apply to everyone else.

Subprocessors and retention. Integrations run through Composio, which is how Skopx reaches nearly 1,000 tools, and your model provider is whichever one your key belongs to. For the complete current subprocessor list and for retention windows written into your agreement, ask us and we will send them in writing. We would rather answer that in a contract than publish a number in an article that drifts out of date.

Pricing, since procurement always asks. Skopx is paid from day one: Solo at $5 per month, Team at $16 per seat per month with no seat caps, and Enterprise and White Label at $5,000 per month. There is no free tier and no trial. See pricing.

Using Skopx to run the review itself

The vendor review process is itself a document problem, and this is a place where the tool honestly fits. If your signed agreements live in Drive, Notion, or a contract system you have connected, you can ask in chat:

Search our connected Drive and Notion for every signed vendor agreement that mentions data retention or model training, and list the vendor, the exact clause, and a link to the source document.

What comes back is a list with the clause text and a citation to the file it came from, so you can verify each line rather than trusting a summary. That is company knowledge search, not a dashboard, and the difference matters: it answers a question and shows its work. The mechanics are covered in Company Knowledge Search: Finding the Answer, Not the Document.

From there, the drafting step is AI document generation: turn the findings into a review memo where every claim points back to the contract clause it came from. And if you want renewals and newly connected integrations surfaced without anyone remembering to check, that belongs in a daily morning briefing rather than a recurring calendar reminder nobody reads.

To be clear about the boundary: Skopx is not a GRC platform, not a controls-monitoring product, and not a BI tool. If you need continuous control monitoring and evidence collection for an audit, buy a dedicated GRC product. Skopx catches what falls between your tools, which in this case means the review that was supposed to happen and quietly did not.

Running the review without becoming the department of no

The failure mode of a good questionnaire is that it takes six weeks and the team connects the tool anyway on a personal account. Tier it instead.

Read-only, no sensitive systems, single user: a short form, five questions, same-day answer. Read access to a system of record, or any team-wide deployment: the full questionnaire plus a data processing agreement. Write access, unattended automation, or regulated data: full questionnaire, DPA, audit report under NDA, a named internal owner, and a review date on the calendar.

Two habits make the tiers work. Give every connected tool an internal owner who is accountable for its scopes, and re-check scopes on a schedule, because vendors expand permissions during upgrades and the consent screen is easy to click through. Keep the answers you collected attached to the contract, so the next person who asks "did we ever check this" has somewhere to look. If you are standardizing which tools are approved in the first place, our integrations directory is a reasonable place to see what a connected footprint actually looks like at scale.

Frequently asked questions

What is the single most important AI vendor privacy question?

"Which third parties can receive our content, and is our exclusion from model training contractual?" It forces the vendor to be concrete about both the data flow and the enforcement mechanism, and the quality of that one answer predicts the quality of every other answer you will get.

Does bring your own key eliminate the privacy risk?

No, but it removes a real one. With your own provider key, model requests bill to and are governed by your account under that provider's terms, so the AI vendor is not accumulating your content in a relationship you cannot see. You still need to ask about retention, isolation, subprocessors, and action permissions, because those live in the application, not the model.

How do I verify answers instead of just trusting them?

Three cheap checks. Read the actual OAuth consent screen and compare the scopes to what the vendor told you. Request the audit report under NDA and confirm its scope section matches the product you are buying, not a sibling product or a parent company. And run a deletion test during a pilot: remove a document, query for it, then ask the vendor to confirm removal from derived indexes.

What should I do if a vendor will not answer in writing?

Treat refusal as an answer. A vendor with good practices finds it easy to restate them in an email, because their legal team already wrote the language. Persistent vagueness about retention or subprocessors, in particular, usually means the practice is worse than the marketing.

Do we need a DPA if the tool only reads data?

Reading is processing. If the tool touches personal data belonging to your customers or employees, you generally want a data processing agreement regardless of direction, and your counsel should decide based on the jurisdictions involved. Read-only lowers the integrity risk, not the confidentiality or regulatory one.

What is Skopx's SOC 2 status?

Skopx has SOC 2 controls in place. That is the accurate description of where we are, and we do not stretch the phrasing further. When you ask any vendor the same question, insist on the report type, the trust services criteria in scope, the observation period, and the exceptions the auditor noted, because a vendor's willingness to be precise there is the best single predictor of how precise the rest of their answers will be.