Privilege AIMKC2 results

Count
the copies.

An AI system creates derivatives of your data at every layer: prompts, embeddings, caches, logs, training sets. Each one is a copy with its own access control.

READ THE DEFINITION ↓COPIES · DERIVATIVES · BOUNDARIES

01 / DEFINITION

The short answer first.

What is AI data security?

AI data security is the protection of data as it moves through an AI system, including every derivative the system creates: prompt payloads, embeddings, retrieval indexes, caches, logs and training sets. Each derivative is a copy, and a control applied only to the original protects none of them.

Access control on a document store is the part everyone implements. The gap is that an AI deployment reproduces the same content in five or six other places with entirely different access models, and those copies are created by the pipeline rather than by a person, so they rarely appear in a data inventory.

02 / THE COPIES

Every derivative an AI pipeline creates.
Data derivatives in a typical retrieval-augmented deployment, and what each requires. The right-hand column is where audits find gaps.
DerivativeCreated byControl it needs
Prompt payloadEvery requestTransport security; no third-party transit if material is confidential
EmbeddingsIndexingSame access control as the source; treat as sensitive, not as numbers
Retrieval indexIndexingPer-document permission metadata, filtered at query time
Response cacheOptimisationKeyed by identity, never shared across users or tenants
Prompt and output logsObservabilityThe strictest access control in the system; explicit retention
Fine-tuning setTrainingCurated provenance; consideration of what the weights may reproduce
Model weightsTrainingTreated as a data asset, because they encode training material

Two rows deserve emphasis. Embeddings are frequently treated as anonymous vectors and stored with looser controls than the documents they came from; they are a lossy but informative representation of the source text and belong under the same access policy. Logs are the most common real-world exposure: a debugging pipeline that records full prompts and responses recreates the entire confidential corpus in a store built for engineers.

03 / THE INFERENCE BOUNDARY

The question that decides most of the architecture.

What leaves,
and to whom?

Using a hosted model means every prompt — including the retrieved documents inside it — is transmitted to and processed by a third party. Contractual terms about retention and training are meaningful and are a different kind of assurance from the material never leaving. Where the data is confidential by default, that distinction usually decides the deployment.

Privilege AI's work sits on the private side: local model execution with explicit hardware, network and operational constraints, and MKC2 running entirely offline for exactly this reason — material reviewed in a legal setting is privileged, and the simplest defensible statement about it is that it does not leave the environment. See private AI inference and on-premise AI.

Where hosted inference is used, the controls that matter are concrete rather than contractual: what the retrieval layer is allowed to place in a prompt, whether logging is disabled at the provider, which region processes the request, and whether the same data can be re-identified from the responses that come back.

04 / PRACTICAL CONTROLS

What holds up under audit.
↳ 01

Minimise before you send.

Retrieve the passages the task needs rather than whole documents. The cheapest data protection is not moving the data.

↳ 02

Permission the index, not the answer.

Filter retrieval by identity at query time. Filtering after generation is too late — the content is already in the context.

↳ 03

Treat logs as the crown jewels.

Prompt and output logs are the highest-concentration copy of sensitive material in the system, and usually the most widely readable.

One further control is worth naming because it is easy and rarely done: deletion has to reach the derivatives. When a document is deleted or a client relationship ends, the source record is removed and the embeddings, caches, logs and any fine-tuning set that absorbed it often are not. A deletion procedure that does not enumerate derivatives does not actually delete anything.

05 / QUESTIONS

Asked by data protection and security reviewers.

Can embeddings leak the original text?

+

They are a lossy representation and research has repeatedly shown that meaningful information can be recovered from them, particularly for short texts. The safe operating assumption is that an embedding is sensitive in the same way its source is, and should carry the same access controls.

Is it safe to log prompts and responses?

+

It is necessary for debugging and it creates the most concentrated copy of sensitive material in the system. Log with the strictest access control you have, redact where possible, set an explicit retention period, and include the log store in every access review.

Does a data processing agreement make hosted inference acceptable?

+

It may satisfy a legal requirement. It does not change the technical fact that the material was transmitted and processed elsewhere, and for data that is confidential by default that distinction is often decisive on its own.

How do you handle deletion requests in an AI system?

+

Enumerate the derivatives first: source record, index entries, embeddings, caches, logs and any training set. Deletion has to reach all of them. Material absorbed into model weights is the hardest case and is a reason to be careful about what enters a fine-tuning set.

What about data from one client reaching another?

+

That is the cross-tenant case, and it is prevented at the retrieval layer rather than in the prompt: identity-filtered queries, no shared caches, and separate indexes where the isolation requirement is strict. See RAG access control.

Know where
the copies are.

Privilege AI builds retrieval and inference architectures where the data boundary is explicit rather than assumed.