Know what data leaves your system and who is allowed to see it.
Every GenAI feature is also a data flow. A prompt carries user messages, retrieved documents and tool results to a model provider; responses come back and get logged, cached, embedded and sometimes used for fine-tuning. Each step creates a copy of data that someone, somewhere, is now responsible for. This chapter is about knowing exactly what leaves your system, who may see it, where it lives and for how long, and how to keep one customer's or one employee's data from reaching someone who should not have it.
The mental model is simple: the model is not a security boundary. It will repeat whatever is in its context, so privacy and access control have to be enforced in the plumbing around it, in contracts with providers, in redaction before content is sent or stored, in permission filters before retrieval, in database policies under generated SQL, and in retention rules on every derived copy.
The first questions cover the basics a reviewer will ask about any GenAI feature: what data goes out, whether it trains models, what counts as personal data, redaction, residency, retention and tenant isolation. The advanced questions turn those into engineering: zero-data-retention, permission-aware RAG, row-level security, logging design and multi-tenant architecture, then the organisational layer of governance and shadow AI, plus two problems teams usually discover late: deletion requests and the sensitivity of embeddings.
Everything you put in the request: the system prompt, the user's message, conversation history, retrieved documents, tool definitions and tool results, plus metadata such as your account, IP address and any user identifiers you attach.
A model call is a network request, and the provider receives its full contents. Teams tend to think of the user's question as "the data", but in a real application the question is often the smallest part. The request also carries the system prompt (which may describe internal policy), the conversation history, any retrieved chunks from your RAG index, the tool schemas and every tool result the agent has read so far. If a tool fetched a customer record, that record now travels to the provider on every later turn of the loop.
The response comes back through the same channel, and depending on the product the provider may also hold stored state: uploaded files, vector stores, conversation threads, batch job inputs, fine-tuning datasets, or cached prompt prefixes. Each of these has its own retention rules, which are often different from the rules for a plain stateless request. Metadata travels too: the API key identifies your organisation, the source IP identifies your network, and if you pass an end-user id for abuse tracking, that is personal data as well.
What the provider does with this data is set by the contract, not by the API. Typical terms cover whether inputs are used for training, how long they are kept for abuse monitoring, which subprocessors (other companies the provider relies on) can see them, and in which regions they are processed. These terms differ between consumer apps, business plans and the raw API, and between providers, so the only reliable answer comes from the agreement your organisation actually signed.
The practical habit is to treat the prompt as an outbound data export and inventory it the way you would any other integration. Write down every field that can reach the model, where it came from and how sensitive it is. That inventory is what your security review, your privacy notice and your redaction rules are built on.
It depends on the product tier and the signed agreement. Many providers state that business and API traffic is not used for training by default, while consumer apps often are unless the user opts out. Verify the current terms rather than assuming.
Providers generally separate consumer products (a free or personal chat app) from business products (team or enterprise plans, and the developer API). For business products, the common default in published terms is that customer inputs and outputs are not used to train the provider's general models. For consumer products, training on conversations is more often the default, with an opt-out setting. These are tendencies, not rules: terms vary by provider, change over time, and sometimes differ for specific features such as feedback buttons, where a thumbs-up can explicitly send that conversation for review.
"Not used for training" is narrower than "not stored" or "not seen". A provider can commit to no training while still retaining requests for a limited period for abuse and safety monitoring, during which authorised staff may review flagged content. Those are separate clauses, and a security reviewer should read both. The same applies in reverse: an opt-out of training does not by itself shorten retention.
The biggest real-world exposure is rarely the API your engineers integrate. It is staff pasting contracts, source code or customer lists into a personal consumer account, which sits outside your agreement entirely. That is a governance problem (see the question on shadow AI) rather than an API configuration problem.
Fine-tuning is a special case. When you fine-tune a model on your data, the result is normally a private model available only to your organisation, but the training data is uploaded and stored until you delete it, and the resulting weights may memorise parts of it. That is a different risk from the provider training its shared models.
Personally identifiable information is any data that identifies a person directly, like a name or passport number, or indirectly when combined with other data, like birth date plus postcode. Privacy laws usually use the broader term personal data.
PII is the common US term; laws such as the EU's GDPR and India's DPDP Act speak of personal data, defined broadly as any information relating to an identifiable person. The difference matters because "identifiable" is wider than most people expect. Direct identifiers (name, email, phone, government id, account number) are obvious. Quasi-identifiers are less so: a study by Latanya Sweeney estimated that ZIP code, birth date and sex together were enough to identify most of the US population. A support transcript that mentions "the cardiologist at the Pune branch who joined in March" can identify someone without containing a single name.
Some categories carry extra obligations. Health, biometric, genetic, financial, religious, sexual orientation, and data about children are treated as sensitive or special-category data in many regimes, with stricter rules for processing and stronger penalties for leaks. Sector rules add their own terms, such as protected health information in US healthcare.
GenAI makes PII harder to track for three reasons. First, it arrives in free text, not in labelled columns, so a schema-level rule cannot find it. Second, models can infer personal attributes that were never stated, such as guessing health conditions from purchase history, and an inference about a person can itself be personal data. Third, PII spreads into derived stores: logs, embeddings, caches, eval datasets and fine-tuned weights all inherit whatever went in.
Note that pseudonymised data, where names are replaced with tokens but a mapping exists somewhere, is still personal data under GDPR. Only data that cannot reasonably be re-identified counts as anonymous, and that bar is high.
Redaction removes or masks sensitive values before text is stored, logged or sent to a model. It can be irreversible (replace with a label) or reversible (swap for a token you can map back later inside your own system).
Redaction is a pre-processing step that finds sensitive spans and replaces them. The irreversible form substitutes a category label, such as [PHONE], and throws the value away; use it for logs and analytics where nobody needs the original. The reversible form, often called tokenisation or pseudonymisation, replaces each value with a consistent placeholder like <PERSON_1> and keeps the mapping in your own store, so you can restore real values in the model's answer before showing it to the user. The provider sees placeholders; your user sees names.
Detection is the hard part. Pattern matching (regular expressions plus checksums such as the Luhn check for card numbers) is fast and precise for structured identifiers. Named-entity recognition models catch names, organisations and addresses in free text but miss some and over-flag others. Production systems combine both, and add allow-lists (your own company name is not a secret) and context rules. No detector reaches 100% recall, so redaction lowers exposure; it does not eliminate it.
There is a quality trade-off. If you redact everything the model needs, it cannot do the task: a model drafting a reply to <PERSON_1> about <DATE_1> works fine, but one asked whether a contract deadline has passed needs the real date. Consistent placeholders help, because the model can still reason that <PERSON_1> in turn three is the same person as in turn one. Decide per field whether the model needs the value, its type, or nothing.
Placement matters as much as technique. Redact at a single choke point, such as your AI gateway, so every feature gets the same treatment, and redact before writing to logs, not after.
Data residency is the requirement that data is stored, and sometimes processed, within a specific geography such as the EU or India. For GenAI it covers where prompts are processed by the model, not only where your database sits.
Residency questions come from law, contracts or customer policy. Some sectors (public sector, banking, health) and some customer contracts require data to stay in a named country or region. Separately, privacy laws often restrict cross-border transfers without being strict residency rules: GDPR, for example, allows transfers out of the EU under mechanisms such as adequacy decisions or standard contractual clauses, while India's DPDP Act permits transfers except to countries the government restricts. Your legal team decides which applies; engineering has to make the answer true.
For GenAI, distinguish three things. Storage residency is where data rests: your vector index, logs, uploaded files. Processing residency is where the GPU that runs inference sits, because the prompt is decrypted and held in memory there. Support and access residency is where staff who can see the data are located. A provider might store your files in the EU yet route inference to whichever region has spare capacity, unless you choose a region-pinned endpoint. Many providers and cloud platforms now offer regional or in-region processing options, but availability differs by model, feature and region, and newer models often reach some regions later.
Every hop in the pipeline counts. An EU deployment that calls an embedding model in another region, sends traces to an observability vendor elsewhere, or uses a reranking API without regional options has broken residency even if the main model is compliant.
Self-hosting an open-weight model in your own region is the most direct way to guarantee processing residency, at the cost of running inference yourself.
Data retention is how long each copy of the data is kept before deletion: by the provider, in your logs, traces, caches, vector stores and backups. Good retention is a short, written period per data type, enforced automatically.
Retention is the time dimension of privacy. The less time a copy exists, the less there is to leak, subpoena or misuse. Privacy laws generally require storage limitation: keep personal data only as long as the purpose needs. In practice that means setting a period per data type and deleting on schedule, not keeping everything forever because storage is cheap.
GenAI systems create more copies than teams expect. On the provider side, stateless API calls may be retained for a limited period for abuse monitoring, while stateful features (stored conversations, files, assistants, batch inputs and outputs, fine-tuning data) persist until you delete them or a documented expiry passes. On your side there are request logs, traces in your observability tool, eval datasets built from production samples, semantic caches keyed on prompts, conversation memory, vector indexes and backups of all of these. Each needs its own period.
Retention interacts with other duties. Legal holds can require you to keep specific data despite your normal schedule. Audit requirements may need proof that an action happened for years, which is why you separate the audit record (who did what, when, with ids) from the content (the full text of the prompt). The audit record can live long; the content should not.
Deletion must reach derived data. Deleting a document from your CMS does not remove its chunks from the vector index, its text from cached answers, or its quotes from stored conversations. Design deletion as a pipeline that follows the data's lineage.
Tenant isolation ensures one customer's data, actions and resources can never reach another customer in a shared system. In GenAI it must hold in storage, retrieval, prompts, caches, tools, logs and any fine-tuned or adapted models.
A tenant is a customer organisation sharing your platform. Isolation means that whatever Tenant A does, no data of Tenant B can appear in A's answers, no action A triggers can touch B's resources, and A's heavy usage cannot starve B. Classic SaaS solves this at the database and API layer. GenAI adds new places where data mixes, and the model itself does not respect boundaries: anything you put in its context, it may repeat.
There are three common models. Silo: each tenant gets separate databases, indexes and sometimes separate model deployments; strongest isolation, highest cost. Pool: tenants share infrastructure and every row, vector and cache entry carries a tenant id that every query filters on; cheapest, but one missing filter leaks data. Bridge: shared compute with separate logical stores, such as one vector index namespace or collection per tenant. Many products mix them, siloing large regulated customers and pooling the long tail.
The leaks that actually happen in GenAI products tend to be in the new layers: a semantic cache returning Tenant A's answer to a similar question from Tenant B; a shared vector index queried without a tenant filter; a conversation memory keyed by user id where user ids collide across tenants; a prompt template that includes few-shot examples copied from a real customer; or a model fine-tuned on pooled customer data that later reproduces one customer's text for another.
The principle that holds them together: derive the tenant from the authenticated session on the server, never from the model or the request body, and pass it into every layer explicitly.
Zero-data-retention (ZDR) is a contractual arrangement in which the provider does not store request and response content after the response is returned, typically removing the abuse-monitoring window. It is usually opt-in, approval-based, and limited to stateless features.
By default, many providers keep API inputs and outputs for a limited period, commonly a few weeks, so automated systems and authorised reviewers can investigate abuse. Zero-data-retention removes that window: content is processed in memory, the response is returned, and the content is not written to persistent storage. Some providers call the arrangement something else, or offer a reduced-retention tier rather than true zero, so read the definition in the agreement rather than relying on the label.
ZDR is rarely a switch you flip yourself. It is typically granted per organisation or per project after a review, often tied to an enterprise agreement and a use-case justification, because the provider loses one of its tools for detecting misuse. In exchange, the provider may rely more on real-time classifiers, and may still keep non-content metadata: timestamps, token counts, model used, request ids and safety classifier results, which are needed for billing and operations.
The arrangement only covers features that do not need storage by design. Anything stateful is either excluded or behaves differently: stored conversations or response objects, uploaded files, vector stores managed by the provider, batch jobs (which must hold inputs until processed), fine-tuning datasets, and sometimes prompt caching, which holds prefixes in memory or storage for minutes. If your architecture leans on those features, ZDR does not protect that data, and you need to manage its lifecycle with explicit deletes.
ZDR addresses the provider side only. Your own logs, traces, caches and eval stores still retain whatever you write to them, and in most real incidents those are the larger exposure. A team that negotiates ZDR and then sends full prompts to a third-party tracing tool has moved the risk, not removed it.
Regulated buyers often combine ZDR with regional processing and a data processing agreement. Where even that is insufficient, the alternatives are a cloud platform's private deployment of the model or self-hosting an open-weight model inside your own boundary.
Carry the authenticated user's identity from the request into retrieval, and filter candidate chunks by that user's access rights before anything reaches the model. Permissions are copied from source systems at ingestion and re-checked or synced so revocations take effect.
A RAG index is a copy of your documents, and copies lose their original access controls unless you bring them along. If the HR folder in your document store is restricted to HR, but its chunks sit in a shared vector index with no access metadata, the assistant becomes a way around the restriction. The model cannot be trusted to withhold what it has been shown, so the only safe point to enforce access is before chunks enter the context.
The usual pattern has three parts. At ingestion, store each chunk with access metadata from the source: tenant id, document id, and the groups or principals allowed to read it (an ACL, access control list). At query time, resolve the user's identity and group memberships from your identity provider, on the server, and apply them as a pre-filter inside the vector search. After retrieval, optionally run a post-check against the source system for high-sensitivity content, which catches permissions that changed since the last sync.
Pre-filtering matters for both security and quality. If you retrieve the top 10 from everyone's documents and then drop the ones the user cannot see, you may be left with two results, or none, while relevant permitted chunks ranked 11 to 50 never surfaced. Most vector databases support metadata filters applied during search; check whether yours filters before or after the approximate nearest-neighbour step, because post-filtering can silently shrink recall.
Staleness is the hard problem. Group memberships and document shares change constantly. Options include syncing ACLs on a schedule (simple, with a revocation lag), subscribing to change events from the source system, storing only document ids in the index and checking the source at query time (accurate, slower), or a mix: cached ACLs for filtering plus a live check for documents tagged confidential. Whatever you choose, state the revocation lag explicitly so security can accept it.
Remember the other paths that bypass retrieval filters: semantic caches, conversation memory that already contains a quoted chunk, and summaries generated from restricted documents and stored without their source's ACL.
Row-level security (RLS) is a database feature that applies an access policy to every query on a table, so a session can only read or change rows the policy allows. It enforces tenant and user scope even when application or LLM-generated SQL forgets a filter.
Most access control lives in application code: every query includes WHERE tenant_id = ?. That works until one query forgets the clause. Row-level security moves the rule into the database. In PostgreSQL, for example, you enable RLS on a table and attach a policy, a boolean expression evaluated per row. The database silently adds it to every select, update and delete for roles the policy applies to, so a query that forgets the filter returns only permitted rows instead of everyone's. Other databases offer similar features under different names, such as security policies or virtual private database.
RLS matters more for GenAI because of text-to-SQL and database tools. If an agent writes SQL, you cannot review every query it generates, and a prompt injection can ask it to drop the tenant filter. With RLS, the generated SQL runs inside a session already bound to one tenant and user, so even SELECT * FROM invoices returns only that tenant's invoices. The model's mistakes become wrong answers, not data breaches.
The policy needs to know who is asking. A common approach is to set a session or transaction variable from the authenticated request (for example SET LOCAL app.tenant_id = ... inside a transaction) and have the policy read it. With connection pooling, use transaction-scoped settings so one request's tenant cannot leak into the next request on the same connection. Never let the model set this variable; your server sets it before handing the connection to the tool.
Know the bypasses. In PostgreSQL, superusers and roles with the BYPASSRLS attribute ignore policies, and a table's owner bypasses them unless you also run FORCE ROW LEVEL SECURITY. So the role your application and agents use must be a dedicated, non-owner role. RLS also costs some query performance, since the policy predicate runs on every row; index the columns it uses.
RLS is defence in depth, not a replacement for authorisation in your API. Use it as the backstop that holds when the layer above fails.
Log enough to debug, audit and evaluate: ids, model and prompt versions, token counts, latency, tool calls, retrieval ids, outcomes and user feedback. Keep raw prompt and response text minimised, redacted, access-controlled and short-lived.
GenAI logging serves four audiences with different needs. Engineers debugging a bad answer need the assembled prompt, retrieved chunks and tool calls. Auditors need to know who triggered which action, on what data, with what result. Product and eval teams need samples of real traffic and feedback. Finance needs token counts and costs. Raw text serves the first and third; structured metadata serves all four. That split is the key design decision.
A good default is to log structured metadata always and content selectively. Metadata includes request and trace ids, tenant and user ids (or a pseudonymous hash), model and prompt template versions, token counts, latency, finish reason, retrieved document ids and scores, tool names with argument hashes, guardrail decisions, and the outcome. Content (the full prompt and response) goes to a separate store with redaction applied before write, tighter access, and a short retention period measured in days. Sampled, consented content can be copied into eval datasets with its own review.
Audit events need different properties from debug logs. They should be append-only, tamper-evident (for example hash-chained or written to write-once storage), retained as long as the regulation requires, and should record actions rather than text: "agent called refund.create for order 8812, amount 40, approved by user 311". Write actions by agents deserve a full audit trail; read-only chat may need far less.
Watch for leaks through the observability stack itself. Tracing libraries often capture prompts and completions by default, and third-party tools may store them in another region or for a long time. Configure capture explicitly, and test that redaction runs before export, not only in your own database.
Finally, logging is a promise to users. If your privacy notice says conversations are not stored, your traces cannot contain them.
Bind every request to a tenant derived from authentication on the server, then enforce that scope independently in each layer: database, vector index, caches, memory, tools, logs, rate limits and any customised models. Prove it with automated cross-tenant tests.
Multi-tenant AI fails in a specific way: the model is a universal mixer. Whatever lands in its context can come out in its answer, so a single unscoped lookup anywhere in the pipeline becomes a cross-tenant disclosure, phrased fluently and with no error raised. The design goal is that the tenant boundary is enforced by infrastructure in every layer, so no single bug or injected instruction can cross it.
Start with a tenant context object created once per request from the verified token: tenant id, user id, roles, data region, plan limits. Pass it explicitly to every component. Never read the tenant from the request body, a URL parameter the client controls, or anything the model outputs. Tools receive the context from the runtime, not as model-chosen arguments, and call downstream APIs with tenant-scoped credentials so even a confused agent lacks the keys to another tenant.
Then enforce per layer. Relational data uses row-level security. Vector search uses a namespace or collection per tenant, or a mandatory filter that the search wrapper adds and callers cannot remove. Semantic and prompt caches include tenant id and permission scope in the key. Conversation memory and files are keyed by tenant plus user. Logs and traces carry the tenant tag, and support staff access is per tenant and audited. Noisy-neighbour protection matters too: per-tenant rate limits and token budgets stop one customer's batch job from exhausting shared provider quota.
Customisation is where pooled designs are most tempting and most dangerous. Fine-tuning one model on all customers' data can make it reproduce one tenant's text for another. Prefer retrieval over fine-tuning for tenant knowledge; if you must adapt models per tenant, use separate adapters (for example LoRA adapters) loaded per request, and never train shared weights on tenant data without explicit agreement.
Finally, choose isolation per customer tier. Large or regulated tenants may justify a silo with dedicated indexes, keys and even a dedicated model deployment; the long tail shares a pool. Both paths should use the same code with the tenant context as the switch.
AI governance is the set of policies, owners, approval processes and controls that decide which AI uses are allowed, with what data, under what risk checks, and how they are monitored. It turns principles into a register, reviews and evidence.
Without governance, AI adoption happens by accident: teams sign up for tools, paste data in, ship features, and nobody can answer basic questions such as which systems use customer data, which vendors hold it, or who approved an agent that can send emails. Governance answers those questions with ownership (each AI system has a named accountable owner), inventory (a register of models, vendors, use cases and data classes), risk classification, and lifecycle controls from approval to retirement.
Risk tiering is the core mechanism. A meeting summariser on internal notes is not the same risk as a model that screens job applicants or approves credit. Most frameworks sort uses by impact on people and by autonomy, then scale the controls: low tier gets a lightweight checklist, high tier gets a privacy impact assessment, bias and accuracy evaluation, human oversight, documented limitations and periodic re-review. The EU AI Act formalises this idea with prohibited, high-risk and limited-risk categories; the NIST AI Risk Management Framework (Govern, Map, Measure, Manage) and the ISO/IEC 42001 management-system standard are commonly used to structure the programme. Which ones apply to you depends on jurisdiction and sector, so involve legal early.
Governance must connect to engineering or it becomes paperwork. Practical links include: an approved-vendor list enforced by routing all model traffic through a gateway; data classification labels that the gateway checks before sending content to a given provider; eval results and red-team findings attached to each release; and incident reporting that feeds back into the register.
Good governance also makes the approved path the easy path. If the only sanctioned option is slow or worse than a consumer chat app, staff will use the consumer app anyway. Providing a vetted internal assistant with enterprise terms reduces shadow AI more than any policy memo.
Trace the person's data through every copy the system made (source records, chunks and embeddings, caches, memory, logs, eval sets, provider-side files and any fine-tuned weights) and delete or re-derive each one, then record proof. Design for lineage before the first request arrives.
Privacy laws such as GDPR and India's DPDP Act give people a right to have their personal data erased in many circumstances, and customers' contracts often add their own deletion clauses. In a traditional app, deletion means removing rows. In a GenAI system the same data has usually been copied and transformed several times, and some of those transformations are hard to reverse.
The easy copies are the ones keyed by an id: source documents, conversation history, user memory, and uploaded files. Derived indexes are harder: a person's details may be inside chunks of documents that are mostly about other things. If chunks carry a source document id and a subject or customer id, you can find and re-embed the affected documents after redacting or removing the person's data. Without that lineage, you are left grepping vectors you cannot read. Caches should simply be short-lived so they expire. Logs and traces need a search by user reference, or retention short enough that they age out within the legal deadline (commonly about one month under GDPR, extendable in some cases).
Provider-side copies are your responsibility to trigger: delete stored files, threads, batch inputs and fine-tuning datasets through the provider's API, and confirm any abuse-monitoring retention falls within your commitments.
Model weights are the hardest case. Removing a specific person's influence from a fine-tuned model (machine unlearning) is an active research area with no reliable general method today. The practical answer is to avoid putting personal data into training sets in the first place, and if you did, to retrain or re-fine-tune from a cleaned dataset, which is why keeping fine-tuning data versioned and reproducible matters.
Close with evidence. Record what was deleted, from where, when, and by which job, without keeping the deleted data itself in the record.
Yes, partly. Research has shown that text can be substantially reconstructed from its embedding, especially short passages, and embeddings also leak attributes and membership. Treat vectors with the same sensitivity as the text they were made from.
It is tempting to think of an embedding as a one-way hash: a list of numbers that captures meaning but not words. That intuition is wrong. An embedding is designed to preserve as much of the text's content as possible so that similar texts land close together, and that preserved content can be extracted. The 2023 paper Text Embeddings Reveal (Almost) As Much As Text demonstrated embedding inversion: a trained model iteratively generated text whose embedding matched a target vector, and for short inputs it recovered a large share of the exact words, including names, from some widely used embedding models.
Inversion is not the only risk. Attribute inference trains a small classifier on vectors to predict properties such as topic, sentiment, or whether the text mentions a health condition. Membership inference tests whether a particular text is in an index by querying for near-duplicates. And the simplest attack needs no research at all: anyone who can query the vector database can run similarity search and read back the stored chunk text, which most indexes keep alongside the vector.
So the practical consequences are about classification and access. Vectors derived from personal or confidential text inherit that classification. They fall under the same retention, residency and deletion obligations, need encryption at rest and access control, and should not be sent to analytics tools or shared between tenants on the assumption that they are anonymous.
Mitigations exist but each has a cost. Redacting text before embedding reduces what can be recovered, at some loss of retrieval quality for the redacted entities. Adding noise or applying a secret transformation to vectors raises the bar for inversion but can hurt recall and is not a proven guarantee. Keeping the embedding model private helps, because inversion attacks typically need query access to the same model. The robust control remains treating the vector store as a sensitive database.
Give staff a sanctioned assistant with enterprise terms that is as good as the consumer tools, classify which data may go where, and back the policy with technical controls such as SSO-only access, a gateway and data loss prevention. Bans alone push usage out of sight.
Shadow AI is the use of AI tools the organisation has not approved: personal chat accounts, browser extensions, transcription bots joining meetings, and coding assistants installed without review. It is usually the largest real data exposure in an enterprise, larger than any carefully reviewed API integration, because it involves contracts, source code, customer lists and board papers pasted into services operating under consumer terms. Those terms may allow training, may keep data longer, and the organisation has no admin view, no audit log and no way to delete what was shared.
Blanket bans tend to fail. The tools are useful, people use them on personal devices, and a ban simply removes visibility. The approaches that work combine a better sanctioned option with proportionate controls. First, provide an approved assistant under a business agreement, with SSO, audit logs, admin-controlled retention and no-training terms, and make it genuinely good. Second, publish a short data classification rule staff can remember: public data anywhere, internal data only in approved tools, confidential and regulated data only in specific approved systems.
Third, add technical controls in proportion to risk. Route sanctioned AI traffic through a gateway that applies redaction and logging. Use the organisation's identity provider so that only company-managed accounts can access approved tools. Many secure web gateways and data loss prevention (DLP) products can detect uploads to known AI domains and block or warn when the content matches sensitive patterns. Review browser extensions and meeting bots, which often get broad data access with little scrutiny.
Finally, measure. Network and identity logs show which AI services are in use and how often; a rising share of traffic through the sanctioned tool is the best sign the programme is working. Pair this with training that uses concrete examples rather than abstract warnings.