In Build Data access
B / Build

Data access

Connecting builders to the data they need through masking, scoping, approvals, and permission-aware retrieval.

View as Markdown

AI projects can stall on data access. Builders and running applications need the right data under controls that survive review.

Builder and runtime access

Builder access governs the data a person may use during development. An analyst working with claims data still needs the usual role, scope, purpose, approval, and audit record. AI can increase the request volume, but the governance model remains applicable.

Runtime access governs the data an application may read while acting for a user. It needs an authorization path that retains the user's permissions throughout the request.

A broad service account paired with prompt-level filtering weakens that boundary. A user can ask for data outside their role, and a retrieved document can contain instructions that alter the model's response.

Enforce the data boundary outside the model. The application requests data as the user, and the data layer applies that user's permissions before any content reaches the model. External authorization limits prompt injection to information the caller may read.

Masking, scoping, and synthetic data

Use the least sensitive data that meets the development need:

  1. Use synthetic or generated data where shape matters more than content. This covers most development and demo work.
  2. Use masked or tokenized production data where realistic distributions matter. Mask at the source so the unmasked copy does not reach application logs.
  3. Use scoped real data for the rows and columns the job needs, with a time limit.
  4. Grant full production access by exception, with approval and an expiry.

Synthetic and masked datasets can satisfy development requests without production access.

Retrieval indexes

Retrieval augmented generation creates another governed copy of source data. Its design has to cover freshness, permissions, provenance, and deletion.

Freshness degrades when the source changes without a corresponding index update. Record the source version and define an update target for each collection.

An index built with broad credentials can expose documents across audiences. Carry permissions into the index and apply them at query time, or partition the index by audience.

Provenance connects an answer to the document and version that produced it. Keep a citation trail so teams can correct the source and verify the result.

Deletion must propagate from the source into the index. Several jurisdictions require deletion of personal data from each copy, including retrieval stores.

Prompt logs are a data store

Each stored prompt and completion is a record. It may contain governed data that a user included while seeking an answer.

Give the prompt log a classification, retention period, owner, and access control list. Choose whether the provider retains it, your account retains it, or it is discarded.

Questions to ask your vendor, or your own team

  • When an AI application reads data, whose permissions apply: the user's, or a service account's?
  • Is there a supported way to get realistic non-production data, and how long does it take?
  • Are permissions applied at query time against your retrieval index, or baked in at index time?
  • When a record is deleted from the source system, what removes it from the index?
  • Where do prompts and completions land, who can read them, and how long are they kept?
  • Is the vector store in the data catalogue?