Where Your Data Lives When You Use an AI Employee

A customer's security questionnaire lands in your inbox. Question 14 reads: "List all subprocessors with access to our data, including AI model providers, and describe retention periods for each." Six weeks ago your ops lead connected an AI assistant to Gmail, HubSpot, and Stripe because it saved everyone an hour a day. Nobody in the company can answer question 14.

That gap is what this article closes. AI data privacy is not a policy-page question, it is a data-flow question. Once an AI employee can read your CRM and your payment records, your data exists in more places than it did before, and most vendors are vague about exactly where. This is the honest map: what gets stored, what merely passes through, what reaches the model provider, and what you should demand in writing before you sign anything.

The Five Places Your Data Can End Up

Every AI employee, regardless of vendor, moves your data through some subset of five layers. The whole discipline of evaluating AI data privacy comes down to knowing which layers a given product uses, how long data sits in each one, and who can see it there.

The table is ordered by how reversible each layer is. Transient processing is forgettable by design. Training is forever. Most vendor privacy conversations focus on the last row because "we don't train on your data" is an easy sentence to say. The rows that actually bite you in practice are the middle three, because that is where data quietly accumulates.

AI Data Privacy Is a Data Flow Question, Not a Policy Question

Privacy policies describe intentions. Data flows describe reality. To evaluate any AI employee, walk one concrete task through the pipeline and ask what happens at each step.

Take a real example: "Summarize the last five emails from our biggest customer and check whether their latest invoice was paid."

Step one, authorization. The AI employee holds an OAuth token for Gmail and an API key for Stripe. Those credentials are themselves sensitive data. Where are they stored, and how? Encrypted at rest is the floor. Ask specifically whether credentials are encrypted with keys the application servers can only access at runtime, and whether support staff can read them. A vendor that stores OAuth tokens in plaintext has already failed, whatever the marketing page says.

Step two, retrieval. The system calls the Gmail API and the Stripe API and pulls five emails and one invoice into memory. This is pass-through data. The right architecture touches it, uses it, and drops it. The wrong architecture syncs your entire mailbox into the vendor's database "for performance" and now holds a second copy of everything, forever, under someone else's security program.

Step three, prompt assembly. The emails and invoice get packed into a prompt. This is the moment your customer's name, their complaint about the renewal price, and their invoice amount all sit in one string of text.

Step four, the model call. That prompt leaves the vendor's infrastructure and travels to a model provider. This is the step most buyers never think about, and it is where the subprocessor chain gets real. Your data is now governed by a third company's terms.

Step five, storage of the result. The answer comes back and gets saved as chat history so you can scroll up tomorrow. Reasonable, but note what just happened: a derived copy of your Gmail and Stripe data now lives in the vendor's database. Chat history is a data store. Treat it like one.

Any vendor that cannot narrate these five steps for their own product, specifically and without hedging, has not done the work. That is a due-diligence signal in itself, and it belongs near the top of your security due diligence checklist.

What Actually Reaches the Model Provider

Here is the part most explainers get wrong: the model provider does not get "access to your Gmail." It gets whatever text the vendor puts in the prompt, one request at a time.

That distinction cuts both ways.

The reassuring side: the model provider never holds your OAuth tokens, never calls your APIs, and never sees records that were not part of a specific request. If you ask about one deal, one deal's data makes the trip.

The uncomfortable side: over months of daily use, the sum of those individual requests is a substantial cross-section of your business. Pipeline numbers, customer names, churn conversations, salary discussions if someone pastes them into chat. Each request is small. The stream is not.

So the questions that matter about the model-provider hop are:

• Which providers, exactly? "Leading AI models" is not an answer. You need names, because each name comes with its own terms.
• Under which terms? The major providers' business API terms, as published in their public docs as of mid-2026, generally exclude API traffic from training by default. Consumer products often have different defaults. Confirm which class of agreement your vendor actually signed.
• What retention window? API traffic is commonly held briefly for abuse monitoring, then deleted. Some providers offer zero-retention arrangements for qualifying customers. Ask your vendor which arrangement covers your traffic, and get the answer in the DPA rather than an email.
• Whose API key? This one changes the legal shape entirely. If the vendor calls the model on their key, the model provider is the vendor's subprocessor. If you bring your own key, you have a direct relationship with the provider and their terms apply to you directly. Skopx supports both structures: the Team plan at $16 per seat includes 2.3 million AI tokens per seat monthly with no key required, and the Solo plan runs on your own key at provider rates with zero markup, which means you can read the model provider's terms yourself and know exactly what governs your traffic.

What the Vendor Stores, and For How Long

Vendors accumulate data in four buckets. Interrogate each separately, because "what do you store?" asked generically always gets the softest possible answer.

Chat and task history. Every question, every answer, every document generated. Useful for continuity, and a growing archive of business-sensitive text. Ask: can an org admin delete a conversation, and does deletion actually purge it from backups within a stated window?

Synced or ingested content. Some products index your documents so they can answer questions from them. Skopx's Company Brain works this way: documents you choose to add become searchable, and answers cite the source document, which also means you can see exactly what the system knew and where it came from. Whatever the vendor, the questions are the same: which documents, chosen by whom, deletable how, and are the derived embeddings deleted along with the source?

Connection metadata and credentials. Tokens, key material, account identifiers. Encrypted at rest, rotated, revocable from your side of the connection (revoking the Google OAuth grant kills access even if the vendor's UI lags).

Operational logs. The layer nobody asks about. Application logs that capture request contents are a shadow database with none of the access controls. A serious vendor can tell you their logging policy: what fields are logged, whether payloads are redacted, and log retention length. If the answer is a blank look, assume payloads are in the logs.

On isolation: multi-tenant SaaS is fine, most of the software you already trust is multi-tenant. What you are checking is whether tenant boundaries are enforced in the database layer itself, not just in application code. Row-level isolation per organization, the model Skopx uses, means a query physically cannot return another org's rows even if application code has a bug. Application-level filtering alone means one missed WHERE clause is a breach.

Training Is the Question Everyone Asks. Retention Is the One That Matters

"Do you train on our data?" has become the reflexive question, and any vendor selling to businesses in 2026 has a rehearsed no. Take the win, get it in the contract, and then spend your remaining energy on retention, because that is where the real exposure lives.

Reasoning it through: training risk is severe but increasingly rare in B2B agreements, because vendors know it is a deal-breaker and because model providers' business terms exclude it by default. Retention risk is less dramatic but nearly universal. Data that sits in a vendor's database for years is exposed to every future breach, every future subpoena, every future acquisition of that vendor, and every future employee with too much access. The probability-weighted damage of indefinite retention usually exceeds the training risk you spent the whole meeting on.

The retention questions worth asking, in descending order of how often they surface problems:

1. What is deleted when a user deletes it in the UI, and what merely gets hidden?
2. What is the backup retention tail? Deleted data commonly persists in backups for 30 to 90 days; you want that number written down.
3. What happens to our data when we cancel? A stated purge window, not "contact support."
4. Can we set org-level retention limits, for example auto-deleting chat history older than a year?

A vendor with good answers to all four is rare. A vendor with confident, specific answers to the first three is acceptable. A vendor that stalls on all of them is telling you the data outlives your relationship with them.

The AI Data Privacy Clauses to Demand in the Contract

Marketing pages are not commitments. These are the terms that belong in the signed agreement, and none of them are exotic asks in 2026:

• A DPA with a complete subprocessor list, including model providers by name. Plus notice before new subprocessors are added, with a right to object. If the model provider is missing from the list, the vendor either does not understand their own data flow or hopes you will not ask.
• A no-training clause covering the vendor and flowing down to subprocessors. "Customer data will not be used to train or improve machine learning models" in the agreement, not the FAQ. Skopx makes this commitment flatly: customer data never trains models.
• Stated retention and deletion windows. For live data, for backups, and for post-termination purge. Numbers, not adverbs.
• Encryption specifics. AES-256 at rest and TLS 1.3 in transit is the current baseline; a vendor should state theirs without being asked twice.
• Security program evidence. SOC 2 controls in place, a recent penetration test summary, or both. Ask for the actual report under NDA rather than accepting the badge on the website.
• Breach notification with a clock. Seventy-two hours is the common ask. "Prompt notification" with no number is unenforceable.
• Audit and deletion verification rights. At minimum, written confirmation of deletion on request.

If procurement pushback is slowing you down, remember the asymmetry: every clause above costs a well-run vendor nothing, because they already operate this way. Resistance is information.

Verify Instead of Trusting

Contracts constrain the vendor. Verification tells you what is actually happening. Three practices, all cheap:

Audit the OAuth scopes at connection time. When the AI employee requests Gmail access, read the consent screen. Read-only where read-only suffices. A tool that demands full mailbox control to summarize emails is over-scoped, and scope is the blast radius when anything goes wrong. Scoping is the heart of access control for an AI employee, and it is the single highest-leverage privacy decision you make, because data the system cannot reach is data you never have to worry about.

Keep a human between the AI and irreversible actions. Privacy exposure is not only about reading data; it is about the AI sending data somewhere on your behalf. An AI employee that drafts the email for your approval leaks nothing a human did not sign off on. This is the standard human-in-the-loop argument applied to privacy, and it is why Skopx's design keeps actions inside your tools on your instruction with your approval, while the autonomous surfaces are the ones with contained blast radius: morning briefings, monitoring, and scheduled publishing.

Demand citations, then spot-check them. An answer that cites its source shows you which records were pulled to produce it, which is a privacy audit trail as much as an accuracy feature. Every answer in Skopx cites its source for exactly this reason. Make source-checking part of how you verify an AI employee's work generally; the same habit catches both hallucinations and over-reaching data access.

Where Skopx Sits in This Picture

Applying this article's own framework, honestly, to Skopx: connections to your tools happen over OAuth or API keys, credentials are encrypted, and task data is pulled at request time rather than bulk-synced. Chat history, workflow run history, and any documents you add to Company Brain are stored, encrypted with AES-256 at rest and TLS 1.3 in transit, isolated per organization at the row level. Model calls go out per request; on Solo you bring your own key and the provider's terms apply to you directly, on Team the included tokens carry zero markup. SOC 2 controls are in place, and customer data never trains models. The details and plan structure are on the pricing page, and every question in this article is one we think you should ask us too.

FAQ: AI Data Privacy for AI Employees

Does the AI vendor's model train on my data?

Almost certainly not through the API path, if the vendor uses major providers under business terms: those exclude training by default per the providers' public docs as of mid-2026. The residual risks are a vendor on consumer-grade terms, or a vendor training their own auxiliary models on your usage. Both are resolved the same way: a no-training clause in the contract that covers the vendor and all subprocessors.

Is bring-your-own-key better for privacy?

It is better for transparency and control. With your own key, you hold a direct agreement with the model provider, you can read their retention terms yourself, and revoking the key instantly cuts off all model traffic. What BYOK does not change: the vendor's application still assembles the prompts and stores the history, so vendor-side questions still matter just as much.

What OAuth scopes should an AI employee actually have?

The narrowest set that covers tasks you will assign in the next month, not tasks you might assign someday. Read-only scopes for read work. Expand later when a real need appears; expanding a scope takes two minutes, while un-leaking data that an over-scoped integration touched takes forever. Review granted scopes quarterly, because they only ever grow.

How do I delete data an AI employee has already ingested?

Three layers, in order. First, delete in the vendor's UI: conversations, documents, connected accounts. Second, invoke the contractual deletion right and ask for written confirmation, which is what flushes backups and derived indexes on the vendor's stated schedule. Third, revoke the OAuth grants from inside Google, HubSpot, or wherever, which guarantees no further access regardless of vendor behavior. If you skip the third step, you are trusting instead of verifying.

Does self-hosting solve AI data privacy?

It relocates the problem rather than solving it. Self-hosting removes the vendor's storage layer but leaves the model-provider hop unless you also run open-weight models on your own hardware, and it makes your team responsible for encryption, isolation, patching, and access controls that a competent vendor handles full-time. For most teams under a few hundred people, a well-contracted SaaS vendor with named subprocessors and real deletion SLAs is the stronger practical posture. Regulated industries with data-residency mandates are the honest exception.

Is chat history a real privacy risk or a theoretical one?

Real, and usually the largest store of sensitive data in the whole system. Months of chat history is a searchable digest of your deals, customers, finances, and internal debates, sitting in one place. Treat it with the same seriousness as the CRM it summarizes: limit who in the org can see shared conversations, set retention limits if the vendor offers them, and delete what no longer needs to exist.

Walk the Flow Before You Sign

One page of notes beats any badge wall. Pick one real task, walk it through the five layers, and write down what you learn: what passes through, what is stored, which model provider sees it under which terms, and what dies when you hit delete. Then put the seven contract clauses in front of the vendor and watch how they respond. Specific answers mean a partner who has done the work. Vague answers mean your data's future locations are unknown, including to them. The vendors worth trusting are the ones who can narrate their own data flow without notes, because they are the ones who actually drew the map.