Draw the data boundary before AI sees the input

A team can agree that a workflow is useful and still disagree about what the model may see. The phrase “remove personal data” does not settle the question. A document can lose a name while retaining an account number, a rare incident, or a combination of details that points back to one person. The practical unit of review is therefore not the whole database or document. It is each field, passage, attachment, and derived signal that crosses the model boundary.

The aim is not to make every input anonymous. The aim is to make an explicit route decision before transfer, then prove that the chosen route is enforced.

Start with the purpose, not the available dataset

Write one sentence describing the output and the person who will use it. Then ask which input elements are necessary for that output. “Available” and “useful someday” are not reasons to include a field.

For each element, record its origin, the permission attached to it, who can access the result, where prompts and responses are logged, and how long copies survive. Include free-text fields and attachments. They often contain details that a tidy schema hides.

Also record what the model could infer. A postal code may be harmless in one task and expose a household when combined with a rare medical event. An inference is part of the boundary even when it is not a literal input column.

Use four routes instead of one yes-or-no decision

Allow means the exact value is necessary, permitted, and supported by the chosen service configuration. It is not a blanket approval for similar data.

Transform means the task needs some information but not the original form. Replace dates with age bands, names with stable case labels, long documents with approved extracts, or precise locations with a useful region.

Isolate means sensitive material stays inside a separately controlled step. A local system can extract permitted facts and send only that smaller result onward. The isolation boundary needs its own owner and failure behavior.

Exclude means the workflow remains useful without the element, so it never enters the AI path. Exclusion is often the most dependable control because it does not rely on a promise made after transfer.

Decide per field. A support ticket might allow the product name, transform the customer identity, isolate a diagnostic attachment, and exclude payment details.

Example: draft a support reply without exposing the account

A support team wants first-draft replies for installation failures. The initial proposal sends the complete ticket and account history. A field review finds that the draft only needs product version, operating environment, error text, previous troubleshooting steps, and the relevant support policy.

The route map allows the version and error code. It replaces the customer name with a case label and converts the purchase date into warranty status. A preprocessing step isolates uploaded logs and extracts only an approved diagnostic section. Billing notes, street address, and unrelated conversation history are excluded.

The test is concrete: seed a test ticket with forbidden strings, run the actual pipeline, and inspect the provider request, application logs, saved traces, and exported result. A clean prompt preview is not enough if another layer keeps the original attachment.

Example: summarise interview notes for a hiring panel

Interview notes mix evidence relevant to the role with observations that should not influence the decision. Sending every note to a summariser could preserve or amplify those observations.

The hiring team first defines the output as a structured comparison against published role criteria. It allows examples of work and answers to job-related questions. Names become candidate labels. Scheduling details and contact information are excluded. Notes about protected or non-job-related characteristics do not enter the workflow. Access to the generated comparison remains limited to the authorised panel and follows the existing retention period for hiring material.

The boundary also covers the output: the model may only cite allowed evidence and must leave a criterion blank when the permitted input does not support a conclusion. That prevents the system from filling removed gaps with guesses.

Verify the route where data actually moves

A boundary document is unfinished until it has a test. Use a synthetic record containing recognisable markers for each prohibited field. Observe the request after preprocessing, retry payloads, tool arguments, telemetry, error reports, caches, and human review screens. Then delete the test record and confirm that each retained copy follows the stated rule.

Name an exception approver and an expiry date. A temporary exception without an owner becomes a permanent hidden route. Review the map when the task, data source, provider configuration, logging system, or audience changes—not only when the model changes.

Connect every boundary decision to a system control

A field map is complete only when each decision has an enforcement point in the real path. For every allow, transform, isolate, or exclude route, name where it runs and what proves it worked: what the entry validator rejects, what preprocessing replaces, what reaches the provider request, what logs and caches retain, and what the result screen reveals to each audience.

Route	Minimum control	Evidence before release
Allow	Fixed field allowlist, purpose, and recipient	Capture a realistic test request and find only approved fields
Transform	Conversion before transfer; failure stops safely	Use recognizable markers to prove original values stay upstream
Isolate	Separate identity, narrow output, and deletion path	Show that the isolated step returns only approved derived facts
Exclude	Removal at entry rather than an instruction to ignore	Confirm absence in requests, retries, telemetry, and exports

Do not limit change review to model replacement. A new source, wider audience, debug logging, longer retention, or additional tool call can invalidate the old boundary. Give the map a version, accountable owner, and explicit review triggers. Every exception needs a reason, approver, scope, and automatic expiry.

Does de-identification make the data free to use?

No. Transformation may reduce one risk while purpose, permission, combined inference, and retention still require decisions. Free text, screenshots, and attachments are especially capable of preserving identity after obvious names have been removed.

Can a prompt tell the model to ignore sensitive fields?

That is not a transfer control. Once the field is inside the request, it has crossed the boundary. An instruction may change what appears in the answer, but exclusion and transformation must happen before sending and must also apply to retries, logs, and tool arguments.

How often should the map be reviewed?

Event-driven review is more reliable than a calendar alone. Revisit affected fields whenever the task, source, provider configuration, logging, tools, audience, or retention changes. A periodic review is a useful backstop, not a replacement for checking a material change.

Boundary

This map is a workflow design aid, not a legal determination or a substitute for security review. It cannot decide whether an organisation has a lawful basis, contractual permission, required consent, or an appropriate vendor agreement. Those questions belong to accountable privacy, legal, security, and data owners.

Do not use transformation as a claim that re-identification is impossible. If harm would remain serious after a leak or mistaken inference, keep the material out of the workflow or use an environment whose controls have been independently approved. When the team cannot identify the owner, retention rule, or deletion path, the correct route is exclude until those facts exist.