Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How Do You Pilot an AI Agent on Real Customer Data Without Creating a Breach?

Run the pilot on one workflow and one record type, with a page policy that replaces identifiers before the first run, a named approver for every change, and a record reviewed after each run. The point to check is that the values are replaced before the model reads the screen and the task still completes.

Customer records pass through a field filter and a controlled test ring before reaching a small pilot output.

Run the pilot on one workflow and one record type, with a page policy that replaces identifiers before the first run, a named approver for every change, and a record reviewed after each run. The point to check is that the values are replaced before the model reads the screen and the task still completes. A pilot is the first time an agent reads live records, and it is usually set up quickly: a team points the agent at production, scopes it loosely, and plans to tighten things once the results are in. That order is backwards, because the regulations that govern the records apply from the first screen the model reads, not from go-live. This page lays the pilot out as a sequence, ties each step to the rule that makes it necessary, shows one record before and after the page policy, describes what the approver and the run record look like, reports what vendors document about masking and logging, and states what a governed environment changes. It builds on research on deploying AI agents in regulated enterprise environments.

Key findings

  • The GDPR's data minimisation principle, Article 5(1)(c), limits personal data to what is necessary for the purpose, and Article 83 sets fines of up to EUR 10 million or 2 percent of worldwide annual turnover, and up to EUR 20 million or 4 percent for the higher tier (EUR-Lex, 2016).
  • The European Data Protection Board's pseudonymisation guidelines state that pseudonymised data which can be attributed to a person remains personal data, so tokens do not take a pilot out of GDPR scope, though they can reduce risk (EDPB, 2025).
  • Tencent's Zhuque Lab reported a local test in which a malicious web page induced an agent to leak a stored API key one character at a time through URL path requests in about 1.5 minutes (Tencent Matrix, 2026).
  • The U.S. Treasury's report on AI in financial services recommends that firms review AI use cases for compliance with existing laws and regulations before deployment, which places the review before the pilot (U.S. Department of the Treasury, 2024).
  • Salesforce's Trailhead module on the Agentforce Trust Layer states that data masking for LLMs is currently disabled for agents, so a team piloting on that platform cannot assume the model reads masked records (Salesforce Trailhead, 2026).
  • A record of each screen as the model received it is what turns a pilot result into evidence, as set out in research on what an AI control record is.

Why is the pilot on real records the point where exposure begins?

Most agent programs start with a demonstration on synthetic data, which proves little, because synthetic records lack the edge cases that make a workflow hard. The team then moves to real records, and that move is where the exposure happens. The pilot agent reads the same claims screens, account pages and student records the production agent will read, with fewer controls around it, because the controls were planned for later.

Three features of a pilot make it riskier than the deployment it precedes. Scope is loose: the agent is given a broad role so that it does not stall, and the role is rarely narrowed afterward. Nobody owns the record of what the model read, because the success metric is task completion. And the pilot runs on whatever browser or connector the vendor provides, so the agent can be induced to act on content it reads. Tencent's Zhuque Lab test is the concrete case: a web page the agent visited caused it to leak a stored API key through URL requests in about 1.5 minutes, and attackers, the lab noted, do not query the agent for secrets directly (Tencent Matrix, 2026). A pilot that lets the agent browse while it holds customer identifiers has the same shape.

The regulations do not carve out pilots. The HIPAA Privacy Rule's limits on uses and disclosures of protected health information apply whenever that information is used (eCFR, 45 CFR 164.502), and the FTC Safeguards Rule's information security program for customer information does not pause for a trial (eCFR, 16 CFR Part 314). A pilot is a deployment to the regulator.

Which regulation makes each step of the pilot necessary?

The pilot described here has five steps, and each answers a specific obligation, which the team can state to counsel and assessors in advance.

Pilot step Obligation it answers Regime
One workflow, one record type Limit processing to what is necessary for the purpose GDPR Article 5(1)(c) (EUR-Lex, 2016)
Page policy before the first run Minimum necessary use and disclosure of protected health information HIPAA Privacy Rule, 45 CFR 164.502
Named approver for each change Access control and audit controls as technical safeguards HIPAA Security Rule, 45 CFR 164.312
Record reviewed after each run Monitoring and testing of safeguards for customer information FTC Safeguards Rule, 16 CFR Part 314
Compliance review before the first run Review AI use cases against existing law before deployment Treasury report, December 2024

For an education record type the pairing shifts to FERPA. A vendor's agent acting on student records does so under the school official exception, which requires the provider to be under the school's direct control with respect to the use and maintenance of education records (eCFR, 34 CFR 99.31), a condition examined in research on reducing the risk of AI agent access to FERPA-protected student records. The NIST AI Risk Management Framework gives the pilot a structure assessors recognize (NIST, 2023). None of these rules names agents; all apply to what the agent reads.

What does one record look like before and after the page policy?

Take a patient account screen in a billing system, the record type a healthcare pilot would most likely start with because the task is repetitive: reconcile a remittance against the account and post an adjustment. Before any page policy, the screen the agent opens shows the patient's name, date of birth, member identifier, address, the diagnosis codes on the claim, the balance, and the payer's remittance reference. The model reads all of it. If the agent also opens the payer's portal to check the remittance, the model carries those values into a second application, where any text the agent treats as instruction can act on them.

With a page policy applied before the first run, the same screen renders to the model as PATIENT_001 for the name, DOB_001 for the date of birth, MEMBER_001 for the identifier, ADDR_001 for the address, with the diagnosis codes, balance and remittance reference as they are, because the task needs them and the policy says so. The agent reconciles the remittance against the balance, drafts the adjustment, and submits it. The adjustment lands on the real account, because the destination is the billing system itself, where the account is already identified. The task completes. The model's context for the run contains no name, date of birth, member identifier or address.

The before-and-after is the pilot's first deliverable, produced on one record before the agent runs on any. It tells the privacy officer which fields the policy tokenizes and which it leaves, and it is the document that officer signs. The EDPB's position matters here: tokenized data that the organization can re-attribute remains personal data (EDPB, 2025), so the policy reduces what the model reads without taking the pilot out of scope. The mechanism is described in research on render-layer tokenization.

Who approves during the pilot, and what does the record after each run contain?

The approver is a named person, not a role, and the name is fixed before the first run. For the patient account example the approver is the billing supervisor who would approve a manual adjustment today; the pilot does not invent a new authority. Every action that changes a record, submits a form or moves money pauses for that person, who sees the proposed adjustment with the tokens the model saw and the resolved account in the destination system. The HIPAA Security Rule's technical safeguards call for access control and audit controls over systems holding electronic protected health information (eCFR, 45 CFR 164.312); a named approver with a recorded decision is how a pilot meets both for the agent's actions.

The record after each run has four parts: every screen as the model received it, in token form, so a reviewer can state which identifiers the model never read; every action the agent took, with the field and value entered; every approval, with the approver's name and time; and any token resolution, with the destination and the approval it ran under. The record is reviewed after each run, not sampled at the end, because the pilot's purpose is to find the run where the policy missed a field or the agent reached a page it should not have.

The review has a stopping rule. If a run shows an identifier in the model's input that the policy should have replaced, the pilot pauses, the policy is corrected on the before-and-after document, and the run is repeated. If a run shows an action committed without the approver, the pilot stops until the cause is found. The FTC Safeguards Rule requires regular testing or monitoring of the effectiveness of safeguards (eCFR, 16 CFR Part 314); the per-run review is that testing, documented as it happens. A pilot with these records ends with evidence, which distinguishes it from a demonstration.

What do the vendors themselves say?

The platforms a team is likely to pilot on document their own masking and logging, and that documentation sets expectations before the first run. Salesforce's Trailhead module on the Agentforce Trust Layer states that data masking for LLMs is currently disabled for agents, and that an audit trail tracks a prompt through each step of its journey (Salesforce Trailhead, 2026). A team piloting an Agentforce agent on customer records therefore starts from the position that the model reads the record as it is, and the audit trail records the prompt, not a tokenized screen. Whether the masking setting changes is not described in the pages reviewed.

UiPath documents in-flight PII masking in its AI Trust Layer: the feature detects and replaces PII entities with contextual placeholders before the LLM, then restores values in the response (UiPath, 2026). That is the shape of the page policy described above, applied to text passed to the model. Which entity types are detected, and how the feature behaves on a rendered screen rather than a text payload, are not described in the pages reviewed, so a pilot on that platform should test both.

Microsoft documents that Microsoft 365 Copilot can only summarize or reference content the user is authorized to access, and that audit records capture Copilot prompts, responses and referenced content (Microsoft Learn, 2026). For a pilot, the user's permissions define the ceiling of what the agent reads, so the pilot account should be scoped to the one record type, and the audit record supplies part of the run record, as the user saw the content rather than in token form. Each vendor's logging is one input to the run record, not the record itself.

What does a governed environment change?

In a governed environment, the pilot agent reads every customer record as tokens from the first run, so the pilot produces evidence of what the model never saw instead of exposure that the team hopes to tighten later.

The mechanism is a class of control that sits between the rendered page and the model. Identifiers on each screen are replaced with consistent tokens before any model reads the page, and the task runs on the tokens: the patient account screen reaches the model as PATIENT_001 and MEMBER_001 with the balance and remittance reference intact, and the reconciliation completes on those values. Real values resolve only at the approved destination at the moment of an approved action, which in the example is the adjustment posted to the billing system under the supervisor's confirmation. A named person confirms what the policy tokenizes before the first run and approves every record change, submission and payment during the pilot. Every screen as the model received it, every action and every approval is recorded and exported to the organization's own logging.

This bears on the title question because the breach risk in a pilot is the model's context, and each of the five steps is simpler when that context holds tokens. The minimum necessary standard under the HIPAA Privacy Rule (eCFR, 45 CFR 164.502) is met for the model's input by construction, and the data minimisation principle under GDPR Article 5(1)(c) (EUR-Lex, 2016) has a record behind it. The tokens remain personal data in the EDPB's sense, so the pilot stays in scope, with less in the model to be induced out of it. The control covers the rendered page and not the vendor's own connectors, model training or storage.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. For a pilot, its design places the agent inside a governed environment in the customer's own cloud from the first run. On every rendered page, substitution happens at the render layer before any model reads the screen, so the patient account, customer account or student record reaches the model as consistent tokens such as PATIENT_001 or ACCT_001 for the whole run. Real values resolve only at approved destinations at the moment of an approved action, which for the reconciliation example is the adjustment posted to the billing system. A named person confirms the tokenization policy on the before-and-after document and approves every payment, submission and record change during the pilot, the arrangement RedactSure calls Supervised Delegation. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged.

Deployments are in pilot. A pilot on the reader's own workflow would show the before-and-after of one record, each run's screens as the model received them, the approvals, and the exported record. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on the text of Regulation (EU) 2016/679 as published on EUR-Lex, the European Data Protection Board's January 2025 announcement of its pseudonymisation guidelines, Tencent Zhuque Lab's August 2026 analysis of agent memory leakage, the HIPAA Privacy and Security Rules at 45 CFR 164.502 and 164.312, the FTC Safeguards Rule at 16 CFR Part 314, the FERPA school official exception at 34 CFR 99.31, the NIST AI Risk Management Framework, the U.S. Treasury's December 2024 report on AI in financial services, Salesforce, UiPath and Microsoft documentation on masking and auditing, and published RedactSure research pages on regulated environments, FERPA-protected records, render-layer tokenization and the AI control record. All sources were read as of October 16, 2026.

No hands-on testing of any product was performed for this page. Where a vendor feature is described as not covering a case, the statement means not described in the pages reviewed, not that the product lacks the capability. Vendor features change, masking defaults in particular, and the page carries its date. The GDPR is cited by article number; the Tencent result is quoted as the lab reported it. Statements about RedactSure describe its current design, with deployments in pilot. The patient account screen, the payer portal and the student record describe record types, not any organization; the token names and the task are illustrative.

Whether a given pilot meets an organization's obligations under HIPAA, the GDPR, FERPA, the FTC Safeguards Rule or its own policies is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

A pilot on real customer records is a deployment in every sense the regulations recognize, and the exposure it creates comes from the order in which teams usually work: broad scope first, controls later, no record of what the model read in between. Reversing the order is the method. One workflow and one record type bound the processing; a page policy, signed on a before-and-after of one record, fixes what the model reads before the first run; a named approver stands in front of every change; and a record reviewed after each run turns the pilot into evidence, with a stopping rule when the policy misses a field. Vendor masking and audit features are inputs to that record, and on at least one platform masking for agents is documented as disabled. A governed environment such as RedactSure's makes the model's context tokens throughout. The test is to name one agent and one record type, run one task, and ask for the screen as the model received it.

Frequently asked questions

Can we pilot on a copy of production data instead?

A copy carries the same identifiers as production, so the regulations apply to it in the same way, and the copy adds a second store to protect and later to delete. Synthetic data avoids that but rarely reproduces the edge cases that make the workflow hard, which is why teams move to real records in the end. A page policy on real records is the middle path: the agent works on live screens, the model reads tokens, and the team gets a real result without creating a second data set.

Does tokenizing the screen take the pilot out of GDPR scope?

No. The EDPB's pseudonymisation guidelines state that pseudonymised data which can be attributed to a person remains personal data. The organization holds the mapping from token to value, so the pilot remains a processing activity under the regulation. What tokenization changes is the amount of personal data in the model's context, which supports the data minimisation principle and reduces the consequence if the agent is induced to disclose what it read.

How small should the first pilot be?

One workflow and one record type, with one named approver and a defined number of runs before review. The patient account reconciliation, a claims status check, or a student enrollment update are the right size. Breadth is added workflow by workflow after each has a before-and-after document and clean run records. A pilot that starts with a broad role and several record types has no baseline to compare against when a run goes wrong.

Who should be the named approver?

The person who approves the same action today when a human performs it. For a billing adjustment that is the billing supervisor; for a student record change it is the registrar's designee. Using the existing authority keeps the pilot inside the organization's current controls and makes the approver's record meaningful to an assessor. A new role created for the pilot has no history of judgment on that action.

What should stop a pilot?

Two findings. An identifier appearing in the model's input that the page policy should have replaced, which means the policy is corrected on the before-and-after document and the run repeated. An action committed to a record, a submission or a payment without the named approver's confirmation, which means the pilot stops until the cause is found. Both are visible only if the record of each run is reviewed as it happens rather than sampled at the end, which is why the review step belongs in the pilot plan.

Does the vendor's audit log serve as the pilot record?

It is one input. Microsoft documents that Copilot audit records capture prompts, responses and referenced content; Salesforce documents an audit trail that tracks a prompt through each step. Neither is described in the pages reviewed as recording the screen in token form or the approver's decision. The pilot record needs the screens as the model received them, the actions, the approvals and any token resolutions, and the vendor log supplies part of the second item.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.