# PII in your AI pilot: what to handle before day one

_Personal data does not become a problem when you scale. It is a problem the moment the pilot touches it. Decide the rules before the first record moves._

How to handle PII and sensitive data in an AI pilot before day one. Anonymized stories from a field CISO and an engineering lead on secrets, scoped access, and the non-human agent risk.

# PII in your AI pilot: what to handle before day one

The most common mistake with personal data in an AI pilot is treating it as a scaling concern, something to sort out before production. By then it is already everywhere. Sensitive data is a day-one decision, because a pilot that ingests it without rules has already created the exposure you were planning to prevent.

## The cost of getting it wrong is not abstract

The numbers are worth sitting with. Breaches involving shadow AI, the unsanctioned tools employees reach for, run about $4.63 million on average, and roughly 65% of them involve customer personal data. And this is not a fringe behavior: surveys put unapproved AI tool use above 80% of employees. If your pilot has not made an explicit decision about what data goes where, someone on the team is probably making that decision for you, badly, by pasting records into a tool nobody reviewed.

## Governance is the gap, not the tool

A field CISO who advises mid-market companies told us governance is the security gap he sees most often when he walks into a new organization. The reflex is to buy a tool to solve the problem, which usually compounds it, because you have added capability without adding process. His first question is never "what tool," it is "what does good look like here." For a pilot handling PII, that means deciding, before day one, which fields the feature is allowed to see, where they are allowed to travel, and who answers when something leaks.

## Scope the access, protect the secrets

An engineering lead who has moved billions of records between systems is strict about a related point: your workflow should not let an agent read your secrets. Environment variables, cloud keys, credentials, those files stay off limits, and you set the guardrails so the rule cannot be bypassed, because even when a vendor promises it is not processing your data, you do not truly know what happens downstream. The same logic applies to personal data in a pilot. Give the feature scoped access to exactly the fields it needs, not a blanket connection to the whole database.

## The new insider risk has no face

The CISO named a risk that is easy to miss. An AI agent is a non-human identity, and it can become an unintentional insider. It is not malicious, but if you have not thought through its purpose and its guardrails, it may be operating exactly within the access you gave it while quietly sharing data it should never touch. Agents get delegated a lot of power and a lot of reach. If you have not scoped what a pilot's agent can read and send, you have not removed the human in the loop, you have hidden the exposure.

## A short day-one checklist

Before the first record moves, answer five things. Which specific fields does this use case need. Which of those are personal or regulated. Where is each field allowed to go, and where is it forbidden. What access does the feature get, scoped to the task rather than the whole store. And who gets paged if data ends up somewhere it should not. If those answers do not exist, the pilot is not ready to touch real data yet.

## How we approach it at Density Labs

In the AI Readiness Assessment, our fixed two week, $2,500 engagement, sensitive-data handling is a design input, not an afterthought. We map which fields the use case actually needs, flag the regulated ones, scope the access, and write down who owns the response if something goes wrong. It is a short, cheap conversation before a pilot, and a very expensive one after a breach.

Personal data does not wait for production to matter. Decide the rules while the cost of deciding is still just a conversation.