Enterprise AI Data Privacy: A Team Guide

Enterprise AI data privacy is the set of operating rules that decide which company data an AI workflow may use, who may reach it, how long it stays, and how it is deleted — enforced by the platform, not left to a policy PDF nobody reads.

This is not legal advice, and it is not a certification checklist. Your legal and privacy teams still own the decision to approve any given use case, and a badge on a vendor’s security page — SOC 2, ISO 27001, GDPR — tells you the vendor runs a controlled shop, not what happens to your customer list when a sales rep pastes it into a chat.

The gap most guides leave open is the one business teams actually stand in every day: a well-meaning person, a real deadline, and a question they cannot answer — is it okay to put this data in here? This guide answers that at the workflow level. It maps the concrete decisions — what data may enter, who reads it, where it lives, when it leaves — onto controls you can point to in the product, using Insulin as the worked example. Where a rule is enforced by the platform, we say so; where it is a judgment call your policy owns, we say that too.

What company data can safely enter an AI workflow?

Company data can enter an AI workflow when its sensitivity, the workflow’s audience, and the platform’s data-use terms all line up — and the safest default is to classify first and connect second. The question is never “can the model handle this text”; it is “should the people and systems downstream of this workflow be able to see it.”

Start by sorting what you have into three buckets, because the right answer differs sharply across them:

Public or already-shared — your published docs, help centre, marketing pages, price lists. Low risk. This is exactly what you want grounding an agent, and it is the first thing to connect.
Internal, non-personal — playbooks, runbooks, internal policies, closed deal notes with no personal data. Usable, but scope it to the teams who should read it. This is the bulk of what a knowledge base holds.
Regulated or personal — anything with customer PII, employee records, health or payment data, or contract terms under NDA. This is where a use case needs your privacy team’s sign-off before it is wired up, not after an incident.

The mistake is treating the AI workflow as a single privacy boundary. It is not one boundary; it is four decisions — classification, access, retention, and residency — and each has its own control. The rest of this guide takes them one at a time.

A note on the model itself, because it changes the calculus. On Insulin, retrieval is grounding, not training: your documents and conversations are searched at query time to answer a question, and are not used to train models. Insulin’s knowledge base documentation states it plainly — “Suger does not use your documents or conversations to train AI models,” and “your documents stay yours.” That matters because the usual fear — “our data becomes part of the model and leaks to another customer” — does not apply to a retrieval architecture. The data is read to answer, then it is done. What you still have to govern is who can trigger that read, which is an access question, not a training one.

Retrieval-time grounding vs training: why it changes the privacy question

Retrieval-time grounding is when an AI reads your documents at the moment it answers, cites what it used, and retains nothing for training; training is when your data is absorbed into a model’s weights and shapes its future outputs for everyone. The two have completely different privacy profiles, and conflating them is the single most common reason a good use case gets blocked for the wrong reason.

With training, the classic worry is real: data folded into weights cannot be cleanly extracted, deletion is fuzzy, and one tenant’s data can influence another tenant’s output. That is the architecture legal teams are right to interrogate.

With retrieval-time grounding — how Insulin works — the flow is different. An agent reaches a knowledge base, runs a hybrid search (vector plus keyword) against the documents in it, and grounds its answer in what it finds, carrying the source documents with the response. Nothing is written back into a model. Delete a document from the base and the next answer cannot draw on it, because there is no residue in a weight matrix — the source is simply gone from the index. This is why “does the vendor train on my data” is the first question to ask a platform, and why the answer determines how much of the rest of your review even applies.

The practical upshot for a business team: you can put internal knowledge to work grounding answers without it becoming training data, provided the platform retrieves rather than trains. Confirm that in the vendor’s own terms, then govern access — which is the next decision.

Access scoping and RBAC: who can reach the data

Access scoping is deciding which people and which agents can reach a given store of data, and role-based access control (RBAC) is how you enforce it — assigning viewer, editor, or owner rights so a person’s actions match their responsibility. This is the control that does the most work in day-to-day privacy, because most real exposure is not a breach; it is the wrong internal person, or the wrong automated agent, reaching data they had no business seeing.

Insulin enforces this at two levels, and you should use both:

People get one of three roles — viewer, editor, or owner. A viewer reads and runs; an editor changes configuration; an owner controls sharing and membership. Match the role to the job: most people on a team are viewers of the shared tools, not owners of them.
Agents reach only the knowledge bases you attach to them. This is the sharpest privacy line in the product. As the knowledge base documentation puts it, “an agent only reaches the knowledge bases you attach to it.” Attach the deal-desk base to the deal-desk agent and it stays there; the finance agent never sees it because it was never attached. You compartmentalize by attachment, not by hoping a prompt stays on-topic.

The operating rule: scope an agent to the narrowest set of sources it needs to do its job, and no more. An agent that only answers billing questions needs the billing base, not the whole org’s knowledge. Over-attaching is the AI-era version of over-provisioning a database login — it works, right up until it is the thing you wish you hadn’t done. For a step-by-step on drawing that boundary, see how to scope an agent to its integrations.

There is a second, human-in-the-loop layer worth naming: for actions that leave the system — sending an email, writing to a CRM — Insulin routes them through an approvals queue rather than firing them automatically. That is an access control too, applied to consequences rather than reads: the reversible work runs unattended, the irreversible action stays a person’s decision.

Retention, deletion, and data residency

Retention is how long the platform keeps your data, deletion is your ability to remove it and have it actually gone, and data residency is where the data physically lives and is processed. These three are what a privacy review examines after “how is it used,” and they are where a vendor’s specifics matter more than its slogans.

Handle them as three distinct questions:

Residency — where does the data sit? Ask for a named location, not a reassurance. Suger’s stance is concrete: customer data is stored and processed in the United States, on AWS, across multiple availability zones with automated backups. If your policy requires a specific region, this is the line to check against it, and to raise with your team if it does not match.
Deletion — can you remove it and is it gone? Because Insulin retrieves rather than trains, deletion is clean by design: remove a document from a knowledge base and it drops out of the index, so subsequent answers cannot ground on it. There is no separate step to “unlearn” it from a model, because it was never learned into one. Verify a source is actually gone the same way you verify it arrived — by its sync state.
Retention — how long is it kept, and under what terms? This is governed by the contract, not by vibes. Suger processes data under a Data Processing Addendum (DPA) and the terms; the specific retention windows for your account are what your legal team should confirm in that agreement. Do not infer a retention period from a blog post — read it from the DPA.

The encryption underneath all three is table stakes and worth confirming once: data in transit is protected with TLS 1.3 and at rest with AES-256. That is necessary, not sufficient — encryption protects data from outsiders, while the access and retention rules above protect it from the wrong insiders and the wrong lifespan.

PII handling: the rules that keep you out of trouble

PII handling in an AI workflow means deciding, before the data is connected, whether personal data belongs in that workflow at all — and if it does, scoping who and what can reach it as tightly as the workflow allows. The default answer for a general-purpose knowledge base is: keep regulated PII out unless a specific, approved use case requires it.

A short checklist that keeps most teams safe:

Minimize at the source. If a document has a column of customer emails that the agent does not need to answer the question, the safest place to remove it is in the source system before you connect it — not by trusting the agent to ignore it.
Prefer non-personal grounding. Most useful grounding is playbooks, policies, and product docs, none of which contain PII. Reach for those first; a huge share of value needs no personal data at all.
Isolate the cases that do need it. When a workflow genuinely needs personal data — a support agent answering account questions — put that data in its own knowledge base, attach it only to that one agent, and give that agent’s users the minimum role. Do not pool it into a base everyone’s agents can reach.
Gate the outputs, not just the inputs. An agent that drafts an email to a customer is touching PII on the way out. Keep those actions behind approvals so a person sees the draft before it sends.
Get sign-off, and keep the record. For anything regulated, your privacy team approves the use case, and the job run history gives you the audit trail of what actually ran. Approval plus a run record is what turns “we think it’s fine” into something you can show.

None of this replaces your obligations under GDPR or your own policy — it operationalizes them. The platform gives you the levers; your policy decides where to set them.

Frequently asked questions

Does Insulin train AI models on our company data? No. Insulin retrieves, it does not train. Suger does not use your documents or conversations to train AI models — they are searched at query time to ground an answer, then retained for no training purpose. Your documents stay yours.

What company data can safely enter an AI workflow? Public and internal non-personal data — docs, playbooks, policies — is the safe default. Regulated or personal data needs your privacy team’s sign-off before it is connected. Classify data first, then decide what to connect.

How do I stop an AI agent from reaching data it shouldn’t? An agent only reaches the knowledge bases you attach to it, so scope each agent to the narrowest set of sources it needs. Combine that with viewer, editor, or owner roles for people, and route outbound actions through approvals.

Can we delete data from an AI workflow, and is it actually gone? Yes. Because Insulin retrieves rather than trains, deleting a document from a knowledge base drops it from the index, so later answers cannot ground on it. There is no model to unlearn it from — the source is simply gone.

Where is our data stored, and is this legal advice? Customer data is stored and processed in the United States on AWS, encrypted with TLS 1.3 in transit and AES-256 at rest, under a DPA. This guide is not legal advice — your legal and privacy teams own approving any use case.

Takeaways

Certifications tell you the vendor runs a controlled shop; they do not tell you what happens to your data in a specific workflow. Govern the workflow, not just the badge.
Classify data into public, internal non-personal, and regulated before connecting it. The first two are the safe default; the third needs privacy sign-off first.
Retrieval-time grounding is not training. Insulin retrieves and does not train on your data, which is why deletion is clean and one tenant’s data cannot leak into another’s model.
Scope every agent to the narrowest knowledge bases it needs, give people the least-privilege role they need, and route outbound actions through approvals.
Confirm the specifics — US-on-AWS residency, TLS 1.3 / AES-256 encryption, and retention windows in the DPA — in the vendor’s own terms, and keep your privacy team in the approval loop.

Privacy-by-design is not a document; it is where you set the levers. Insulin gives business teams scoped knowledge bases, role-based access, and approval gates to enforce it — and it retrieves rather than trains on your data. Explore how Insulin knowledge bases ground answers in cited sources, read the Suger security and privacy practices, or get a demo.

Enterprise AI Data Privacy: A Practical Guide for Business Teams