The question is not simply “is this confidential?”

An accounts-payable coordinator opens a shared inbox. A supplier invoice has arrived without a purchase-order number. It includes the supplier name, contact details, bank information, line items, a cost centre and an email trail about a delayed delivery.

The obvious thought is: Could an AI tool extract the missing fields and draft the follow-up?

The important question comes first: Which parts of this material can enter which AI system, for which purpose, under which controls?

“Confidential” is too blunt to answer that question. One file can contain several different categories at once: commercially sensitive information, personal contact details, payment data, client obligations and ordinary operational context. The same file may be usable in a controlled internal workspace, usable only in redacted form in an approved external service, or entirely out of bounds for a general-purpose assistant.

That is why data categories are not a filing exercise. They are a routing decision for AI work.

The PathPatron move is to make that routing decision visible before a useful convenience becomes an unmanaged dependency. The question is not only what the label says. It is a Compass question: who is accountable for the normal case and exceptions, where in the workflow should the decision happen, and which tools and controls make the safe route practical?

Good news: you probably do not need to invent data categories

Most established organisations already have a data-classification system for general use. It may be called a classification policy, information-handling standard, confidentiality scheme, records policy or sensitivity-label model. In Europe this is common; it is increasingly normal across jurisdictions and sectors more broadly.

The gap is usually not the absence of labels. It is that the existing scheme has not yet been translated into clear rules for AI: which category may enter which AI environment, for which purpose, with what settings, retention, connections and human approval?

If you do not know whether such a scheme exists, ask the people who own the decision rather than starting a parallel taxonomy. Depending on the organisation, that may be information security or the CISO team, privacy/DPO, data governance, legal, IT risk, records management, or the operational owner of a client-data process. Look for an information-security policy, data-handling guidance, client-confidentiality rules, a tool-approval register, data-loss-prevention labels in Microsoft 365 or Google Workspace, or a supplier/security questionnaire. The language varies; the underlying intent is usually there.

PathPatron’s contribution is not to replace that existing classification. It is to translate it into a decision people can use where work happens. Keep the company’s labels, then add the missing AI route: approved tool, permitted purpose, required controls and named exception owner.

A data boundary is set up once — then used many times

Not every employee should have to interpret legal terms, client contracts and model settings every time they open a chat window. The organisation needs two different practices:

Set-up: agree a small, usable protocol for recurring types of information, approved tools and exception owners.
Use: apply that protocol quickly to a live task, escalating only when the material or use case falls outside it.

Confusing the two creates the usual extremes. Teams either make every prompt a mini compliance review, so people work around the process; or they provide a generic “be careful with data” instruction, so everybody makes up their own rule.

The goal is neither. It is a reusable default with clear exceptions.

The PathPatron Compass check for a data boundary

The protocol becomes more useful when it is treated as a Compass decision, not an IT rule handed down to everyone else:

People: Who may classify the normal case, who owns the policy and who can approve an exception?
Process: At which point in the workflow should the category check happen, and what is the safe hand-off when it does not fit the normal route?
Power: Which AI tool, connection or reusable skill is appropriate for the permitted inputs — and which technical controls must back up the instruction?

This is what makes a data category operational. A label without an owner will be ignored. A policy without a place in the workflow will be bypassed. A tool approval without a usable instruction will be misunderstood.

Extend your existing categories for AI — or start with four practical routes

Do not relabel a mature company taxonomy just because an AI tool is new. Take the categories already in use and translate each one into an AI-specific route. For each category, agree: which tool or environment is approved, which purpose is allowed, whether redaction or other controls are required, and who owns an exception.

If a team genuinely has no usable scheme, it can begin with four plain-language routes and refine them with the people who own policy:

Public — material already approved for public release: published website copy, public reports, press releases and open regulations. It may be suitable for approved AI tools, but source quality and copyright still matter.
Internal — ordinary non-public operational material that does not contain client commitments, personal data, financial details or commercially sensitive information. It may be usable in a designated internal AI workspace under stated settings.
Confidential or client-confidential — commercial plans, customer material, pricing, contract drafts, unreleased product information and internal decisions. It requires a named approved route, purpose and controls; it is not default chat context.
Restricted — personal data, special-category personal data, bank or payment details, credentials, security information, regulated records and material subject to explicit client or legal restrictions. Keep it out of general AI tools unless an explicitly approved, purpose-specific environment and process say otherwise.

These are operating labels, not legal advice. A category is not a permission slip: it does not settle contractual permission, retention, access, technical settings or applicable legal obligations by itself. The point is to give a non-specialist a usable first question: Which route applies before I paste, attach or connect this?

The invoice example: classify the work, not only the document

Return to the invoice in the shared inbox.

The coordinator does not need to decide whether “the invoice” is allowed or forbidden as one indivisible thing. Break the task down:

Material	Likely category	Possible safe route	What still needs a human decision?
A public supplier address	Public	Approved tool, if needed	Whether it is relevant to the task
Internal approval-flow map	Internal	Approved internal workspace	Whether the process is current
Supplier contact name and email	Personal / confidential	Redact or use only an approved controlled workflow	Whether this purpose and tool are permitted
Bank details, tax identifiers and payment terms	Restricted / financial	Do not place in a general assistant	The approved system and access route
Purchase-order mismatch and exception note	Confidential operational data	Use a controlled internal process or a synthetic example for discovery	Who resolves the exception

The point is not to make the coordinator produce this table every time. The point is to let the finance, security and policy owners create it once for the recurring invoice-intake workflow. This is the PathPatron Compass made concrete: the people who own policy decide the normal case and exception; the process puts the check at inbox intake; the approved finance workflow and its technical controls make the safe route usable.

Then the normal route can be simple: use a redacted or synthetic sample for exploration; use the approved finance workflow for live information; send any novel exception to the named owner. The AI can help draft a follow-up or structure a discovery brief, but it does not quietly turn a live invoice into generic prompt context.

Build the AI extension where the work actually happens

If a classification system exists, do not start by rewriting it. Start with a 90-minute working session around one high-frequency workflow such as invoice intake, customer support summaries or proposal preparation. If there is no usable scheme, the same session becomes your sensible first pass — not a substitute for formal policy, but a visible safe default while the right owners refine it.

Bring four things into the room:

the people who do the work and know the real inputs;
the owner of the relevant policy, security or privacy constraint;
the business owner who can decide what a useful outcome is; and
the list of AI tools or connected systems people are already using or considering.

Map the ten most common input types. For each, record the working category, the approved tool route, the allowed purpose, the required settings or redaction, and the owner who decides exceptions. You are not trying to predict every future situation. You are creating a first Data Boundary Card for a recurring piece of work — a PathPatron decision artefact that joins the category to the person, process and power needed to act on it.

The first version can be provisional. What matters is that it has a named owner, a review date and a visible rule for uncertainty: when in doubt, do not upload; ask this role. That is much more useful than waiting for a perfect enterprise taxonomy while staff make irreversible ad-hoc choices.

Encode the decision so people do not have to remember it

Once a route is agreed, make it easy to reuse. A protocol that lives only in a slide deck will not survive a busy Monday morning.

Depending on the tool environment, the reusable form could be:

a short prebuilt “skill” or workspace instruction in the approved AI tool;
a template prompt that asks the user to select the data category and refuses restricted material;
a form, dropdown or intake card before an AI workflow starts;
a documented redaction step and synthetic-example library for discovery work; or
a playbook entry beside the finance, HR or client workflow itself.

For the invoice team, a lightweight assistant instruction might say:

You may help with invoice-intake discovery using only approved synthetic or redacted samples. Do not accept live invoices, payment details, bank information, personal contact details or production email threads. If the user needs to process live material, direct them to the approved finance workflow and name the exception owner.

This is not a substitute for technical controls. It is a behavioural guardrail that makes the right default visible at the moment of use.

Usage should be a three-question Compass check, not a new project

Once the protocol exists, the daily user does not need to rebuild it. They need a fast gate:

What category of material am I about to use?
Is this tool and purpose an approved route for that category?
Is this a normal case, or an exception that needs an owner?

For a normal, green-route task, work can continue quickly. For an amber route, the user may need to redact, use an approved workspace or add the named reviewer. For a red route, the user stops and uses the designated system or escalation path.

In the invoice example, a team member preparing a leadership discovery brief can use a synthetic sample and an approved internal process map. If she wants the tool to inspect a live invoice with bank details, the answer is not “be more careful.” It is “this is outside the normal route; use the finance-approved process or ask the owner.”

That distinction is the difference between a policy people bypass and an operating practice people can follow. It is also the PathPatron promise in miniature: make enough of the decision visible that a non-specialist can take the next right step — and recognise when it belongs with another owner.

Data categories are only one part of control

Data classification alone cannot make a use case trustworthy. The same AI task also has questions about what the system may do, how much evidence is required, who reviews it, whether it connects to other systems and how reversible the outcome is.

That broader portfolio view is the future PathPatron AI Control Map: a way to decide how much control a use case needs across data sensitivity, action authority, evidence standard, external dependency and human oversight. The Data Boundary Protocol is one practical component of that map. It answers the first control question: what is permitted to enter the system, and through which operating route?

Do not wait for the full framework to begin. A single Data Boundary Card for one recurring workflow is already a meaningful improvement.

The second step: evidence policy

This is the first of two connected PathPatron techniques. Start here, with the admission decision. Then move to the companion Evidence Policy for Responsible AI Work for the quality and verification decision:

Data categories and boundaries: May this material enter this system for this purpose?
Evidence policy: Once material is admitted, what sources should the work use, what quality standard applies, and who verifies the important claims?

Together they prevent two different mistakes: putting the wrong information into an AI system, and treating weak or unverified information as decision-ready evidence.

The practical starting point

If you have no protocol at all, pick one recurring workflow this month. Map its common inputs, agree provisional categories with the relevant owners, define one approved route and one clear exception path. Turn that into a reusable instruction or template. Review it after the first few uses.

The ambition is not to make every employee a data-governance specialist. It is to give them enough structure to make a good next decision — and enough clarity to know when the decision belongs elsewhere.

That is responsible AI in practice: not a warning at the edge of a chat window, but a reusable control that lets useful work move with the right boundaries around it.

Evidence Policy for Responsible AI Work — source admission, quality and verification.
The One-Page AI Briefing — decision context, task boundaries and human ownership before prompting.
The forthcoming PathPatron AI Control Map — matching control depth to a use case before it scales.