The governance questions about an AI system are mostly the same questions you would ask about any system that processes business data: what data goes in, where it is sent and stored, who can see the results, and how you would prove all of that to an auditor. What changes with LLMs is that data flows are less obvious. A prompt can contain anything a user pastes, retrieval can pull documents from across the organisation, logs capture full conversations, and agents can move data between systems on their own initiative.
This post sets out a practical control set. It is not legal advice, and the specifics depend on your jurisdictions and sector, but these controls map onto the requirements most privacy and AI regulations share, from GDPR and India's DPDP Act to the EU AI Act's obligations for higher-risk uses.
1. Map the data flow
Start with a diagram, per AI feature, of every place data travels. In practice it usually looks like this:
User input ──► Application ──► [Redaction] ──► Model provider API
│ │
├──► Retrieval index (documents, ACLs)
├──► Tools / business systems (agent actions)
├──► Logs & traces (prompts, outputs, tool calls)
└──► Eval datasets & human review queuesEach arrow needs an answer to: what data classes cross it, who operates the destination, which region it lives in, and how long it is retained. The logs and eval datasets are the arrows most often forgotten, and they frequently end up holding the most sensitive data in the system.
2. Classify and minimise
- Decide which data classes each feature may process: public, internal, confidential, personal data, special-category personal data, regulated data (payment, health).
- Send the model only what the task needs. A support classifier rarely needs the customer's full address or card details.
- Block or redact data classes a feature should never handle, before the request leaves your boundary.
def prepare_prompt(text: str, policy: FeaturePolicy) -> tuple[str, dict]:
findings = pii_detector.scan(text) # emails, phones, IDs, card numbers, names
if any(f.kind in policy.blocked for f in findings):
raise PolicyViolation("blocked data class in input")
redacted, mapping = pseudonymise(text, [f for f in findings if f.kind in policy.redact])
# "Call Priya on +91 98xxx" -> "Call <PERSON_1> on <PHONE_1>"; mapping stays server-side
return redacted, mapping
def restore(output: str, mapping: dict) -> str:
return reinsert(output, mapping) # only if the user is entitled to see the values3. Vendor and deployment choices
For each model provider or hosting option, get clear written answers on the following before production data flows:
| Question | Why it matters |
|---|---|
| Is customer data used to train or improve models? | Most enterprise API terms say no by default; confirm it, and check consumer tools staff may use |
| How long are prompts and outputs retained, and why? | Abuse-monitoring retention may still apply; some providers offer reduced or zero retention options |
| Which regions process and store the data? | Data residency obligations and cross-border transfer rules |
| Which sub-processors are involved? | Needed for your records of processing and customer contracts |
| What certifications and audit reports are available? | Evidence for your own audits and customer due diligence |
Options range from a provider's public API, to the same models through a cloud platform in a chosen region, to self-hosted open-weight models. Stricter residency or confidentiality requirements push toward the latter, at an operational cost discussed in LLM cost control.
4. Access control follows the user
An AI feature must never become a way around existing permissions. Two rules cover most cases:
- Retrieval respects source ACLs. Filter documents by the requesting user's permissions in the index query. See RAG for enterprise documents.
- Tools run as the user. Agents and assistants act with the caller's identity and scopes, not a shared privileged account. See AI agents in the enterprise and, for standardised tool access, the Model Context Protocol.
5. Prompt injection is a data-exfiltration risk
When a model reads untrusted content (an inbound email, a web page, a document uploaded by a customer) that content can contain instructions. If the same model also has access to sensitive data and a way to send data out, such as a tool that sends email, posts to a URL or renders external images, injected instructions can cause it to leak that data. Mitigations are architectural:
- Avoid combining untrusted input, sensitive data access and an outbound channel in one agent without a human approval step.
- Allow-list destinations for any tool that sends data externally.
- Strip or disable external links and images in model output rendered to users.
- Log and review tool calls triggered while processing external content.
6. Logging and audit
You need logs to debug, evaluate and prove compliance, and those logs are themselves sensitive. Log enough to reconstruct what happened, under the same controls as the source data.
{
"event": "llm_call",
"ts": "2026-10-26T11:03:52Z",
"feature": "hr_policy_assistant",
"actor": {
"user_id": "u-48213",
"auth": "sso"
},
"model": {
"provider": "provider-a",
"name": "general-large",
"region": "eu-west"
},
"prompt_version": "hr-assist-v7",
"retrieved_docs": [
"hr-policy-2026-04#s3.2-c1",
"hr-faq-2026#q14"
],
"redactions": {
"PERSON": 1,
"PHONE": 1
},
"tool_calls": [],
"output_ref": "s3://ai-logs-eu/2026/10/26/abc123.json",
"retention_days": 90
}- Store full prompt and output bodies separately from metadata, with tighter access and a defined retention period.
- Record prompt versions and model versions so any output can be traced to the configuration that produced it.
- Apply the same rules to eval datasets and human-review queues built from production traffic. See evaluating LLM applications.
7. Governance that people will actually follow
- An AI system register: each feature, its owner, purpose, data classes, model and provider, risk level and review date.
- A risk tier per use case. Internal drafting assistance needs lighter controls than automated decisions about customers or employees, which may carry specific legal obligations around transparency and human review.
- Human oversight where decisions affect people, with the ability to explain and contest outcomes.
- A sanctioned path for staff. If employees have no approved tools, they will paste data into consumer ones. Providing a governed option is a control.
- A pre-production review covering the data flow, vendor answers, evals and access model, proportionate to the risk tier.
These are the questions we noted in LLMs in production that never show up in a prototype and always show up in a compliance review. Building them in from the first design is far cheaper than retrofitting.
Key takeaways
- Map every data flow per feature, including logs, traces and eval sets.
- Minimise and redact before data leaves your boundary; get vendor retention, training and residency terms in writing.
- Enforce access through the user's identity in retrieval and tools.
- Treat prompt injection as an exfiltration path and design it out.
- Keep a register and risk tiers so governance scales with the number of AI features.
HashTech includes governance design, from data-flow mapping to audit logging, in its AI enablement engagements.
