How to Set a Workplace AI Data Boundary

How to Set a Workplace AI Data Boundary

Work data may enter an AI system only when the organization has authority for the purpose, the exact account and system path are approved, the minimum necessary data is used, access is controlled, retention and secondary use are understood, and the output can be handled under the same or stronger rules.

"Do not paste secrets into AI" is not a complete policy.

flowchart LR
    A["Source and data owner"] --> B["Classification and approved purpose"]
    B --> C["User, device, account, app, and tenant"]
    C --> D["Connector, vendor, model path, and subprocessors"]
    D --> E["Logs, retention, training use, and access"]
    E --> F["Output, export, system of record, and deletion"]
    F --> G["Incident, correction, and decommissioning"]

Begin with authority, not sensitivity alone

Some data is obviously sensitive. Other material becomes restricted because of ownership, contract, license, purpose, combination, or context.

Work data can include personal information, customer records, employee data, contracts, intellectual property, product plans, credentials, security details, regulated information, source code, licensed content, communications, and ordinary records whose combination reveals something confidential.

Ask who owns the data, what purpose authorized its collection, who may use it, which contract or policy applies, and whether the proposed AI use is compatible with that authority.

A worker may be allowed to read a document without being allowed to upload it to another service. Access to the source does not automatically authorize model processing, retention, extraction, or a new output.

Draw the exact system path

Name the device, user, account type, application, tenant, feature, connector, vendor, model provider if known, region, administrators, logs, storage, and output destination.

"We use ChatGPT," "we use Copilot," or "we use an enterprise AI" is not a data-flow record. Products can differ by plan, account, tenant, configuration, connector, contract, model route, and administrator setting.

Do not move the task to a consumer account because the approved enterprise path is unavailable. The convenience of the interface does not create authority.

Record the documentation and contract date. Product behavior and terms can change, and a later review needs to know which state was evaluated.

Classify the data before the prompt

Use the organization's real classification scheme. If none exists, a pilot still needs an interim rule approved by the relevant owner.

An illustrative matrix can separate public material, approved internal material, confidential business material, personal information, regulated or specially protected data, security-sensitive material, credentials, and prohibited combinations. The names and treatment must fit the organization.

For each class, state whether use is allowed, prohibited, or requires specific review for the exact task and system.

Do not assume that redacting a name makes free text anonymous. Job title, location, dates, case facts, writing style, rare events, and combinations of fields can identify a person. De-identification can require qualified privacy review.

Use the minimum data needed

Start a test with synthetic, public, de-identified, or specifically authorized material when that can answer the business question.

Remove fields that do not change the task. Limit the date range, source scope, participants, and connected repositories. A tool should not receive an entire mailbox or shared drive to test whether it can summarize one approved document.

The NIST Privacy Framework is a voluntary tool for managing privacy risk across the data lifecycle and data-processing ecosystem. It supports examining collection, use, sharing, retention, and disposal rather than treating privacy as a prompt warning.

Minimum necessary does not mean merely short. One sentence can contain a credential, diagnosis, customer identifier, acquisition plan, or legally protected detail.

Verify vendor and contract claims

Read the applicable contract, data-processing terms, product documentation, administrator controls, and subprocessor information. Record who verified them.

Ask whether prompts, attachments, outputs, metadata, feedback, and logs are retained; used for training, improvement, safety, or abuse monitoring; accessible to staff or subprocessors; transferred across regions; available through connectors; exportable; and deletable.

The FTC's guidance to AI companies on privacy and confidentiality commitments explains why statements about training, retention, secondary use, and confidentiality can be material.

Vendor commitments are evidence about promised behavior. They do not prove that the organization's configuration, source permissions, contract, use, and law are correct.

Review identity, access, and connectors

Determine who can invoke the feature, which sources it can reach, what role the system uses, which administrators can change scope, and what logs are available.

Permission-aware retrieval still depends on correct permissions. An overshared document remains overshared when AI can find it faster. Repair intended access before treating retrieval behavior as safe.

Use least privilege. Connect only the sources required for the approved task. Separate development, test, and production paths where the organization's risk requires it.

CISA's secure AI system guidance emphasizes ownership, secure design, deployment, and operation. A buyer should translate those principles into identity, access, logging, source scope, incident response, and decommissioning checks.

Treat the output as part of the boundary

Generated text can reproduce, transform, infer, summarize, or combine sensitive material. Apply the source classification or a stronger one when the output increases disclosure risk.

State where the output may be stored, who may receive it, whether it can enter a customer message, public page, personnel file, decision log, source repository, ticket, or codebase, and who must approve it.

Do not let an AI summary become a new unofficial database. Link accepted output to the authoritative record and preserve the provenance needed for correction.

Export and copy controls matter. A protected response inside one tenant can lose its boundary when pasted into email, chat, a personal note, or another model.

Define retention, deletion, and incident handling

Record how long prompts, attachments, outputs, feedback, and logs persist across the organization and vendor. Identify what deletion means, which copies remain, and who can execute it.

Prepare for accidental disclosure, wrong-recipient output, connector overreach, compromised credentials, inappropriate inference, and an output that enters the wrong record. Name the reporting channel, containment owner, notification path, correction method, evidence to preserve, and stop condition.

The FTC's Start with Security guide emphasizes access, service-provider oversight, retention, and security practices through enforcement lessons. It is general business guidance, not a complete AI security standard.

Publish an approved-system matrix

The practical policy should answer a worker's actual question: may I use this data for this task in this system?

The matrix needs a named owner and visible last-reviewed date. It should explain how workers request an exception or report uncertainty without being pushed toward shadow use.

Episode 97's [[AI Workflow Permissions and Third-Party Data Sharing]] expands the connector and workflow boundary. Episode 108's [[What Local-First Means for an AI Meeting Assistant]] explains why a local-processing claim still needs a complete architecture and data-flow record.

The answer to "Can I put this in an AI tool?" is never supplied by the word AI. It comes from authority, purpose, data, system, contract, configuration, control, and current evidence.

This guide was developed with AI assistance from the preserved E019 transcript, the linked data-boundary record, and current NIST, FTC, and CISA sources. Dalton Anderson remains the author. It is not legal, privacy, security, procurement, records, employment, or regulatory advice. Security, privacy, legal, records, procurement, accessibility, domain, vendor, contract, source, and founder review are required before publication. Publication is not authorized.