Security and Data Governance for AI Software: Access, PII and Logging

AI features have a way of making data governance urgent in a way traditional software rarely does. The moment a model can read across your entire dataset to answer a question, the boundaries between what a user should see and what the system can technically access become the whole security problem. Getting this right is not a compliance box to tick after launch, it has to be part of the architecture from day one.

Row-level access in AI systems

Traditional applications typically enforce access at the page or feature level: you either have permission to open a screen or you do not. AI agents cut across that model, because a single query can span records the user should and should not see. The fix is enforcing access at the data layer, not the application layer.

Why application-level checks are not enough

If an AI agent constructs its own queries or retrieves context dynamically, a permission check that only guards the user interface will miss anything the agent fetches directly from the database or a retrieval index. Access control needs to live where the data is read, so it applies no matter which code path, human or AI, is doing the reading.

A workable pattern

• Enforce row-level security at the database layer, not just in application code
• Scope every retrieval call, including those made by an AI agent, to the requesting user's actual permissions
• Never grant an AI agent broader database access than the least-privileged human user it acts on behalf of

Handling PII in AI pipelines

Personally identifiable information moving through an AI pipeline needs the same discipline as PII anywhere else, plus extra caution about where it ends up, logs, model provider requests, and any cached context.

Where PII commonly leaks in AI systems

In prompts sent to external model providers

Sending full customer records to a third-party model as context is a common shortcut. It is worth actively redacting or tokenising direct identifiers, names, emails, phone numbers, before they leave your environment, and rehydrating them afterwards where the output needs to reference a real person.

In logs and observability tooling

Debug logs are a frequent, unglamorous source of PII exposure, because engineers log full request payloads to diagnose an issue and forget the log itself is a new copy of sensitive data with its own retention and access rules.

A simple rule of thumb

If a field would need masking on a customer-facing screen, it needs masking in a log line too.

Data retention for AI-generated content

AI outputs that reference personal data inherit the same retention obligations as the source data. A summary generated from a customer's support history is still customer data, and needs to be deleted or anonymised on the same schedule as the record it was derived from.

Audit logging that actually helps

Logging "an AI response was generated" is not useful after the fact. Useful audit logging captures enough to answer a real question when something goes wrong: what was asked, what data was retrieved to answer it, which model produced the response, and who saw the result.

What to log for every AI interaction

1. The requesting user and their permission scope at the time of the request
2. The data sources or records actually retrieved, not just the final answer
3. The model and version used to generate the response
4. The response delivered, with a timestamp

Balancing logging with privacy

Comprehensive logging can itself become a governance risk if the logs are treated more casually than the source data. Apply the same access controls and retention limits to your audit logs as you do to the underlying records they describe.

Building this in from the start

Row-level access, PII handling and audit logging are far cheaper to design in from the outset than to retrofit once an AI feature is already in production and already has users depending on it. Treat governance as part of the initial architecture conversation, not a security review that happens after the build is finished, and the resulting system is both safer and easier to reason about.