Elena has found a promising project: use AI to draft replies about service fees and booking. Now she is about to upload a folder called “Customer Examples.”
The folder contains useful questions. It also contains home addresses, personal stories, an old invoice, and a password someone once pasted into a support email.
The task needs the questions and the approved service policy. It does not need everything that happened to be in the folder.
Elena and Mesa Equipment Service are fictional. This example illustrates an avoidable information-handling problem.
Your result from this chapter: an approved list of inputs, accounts, users, and actions for your first project.
Begin with what the task actually needs
Ask what information is necessary to produce and check the output. Work from that answer, rather than giving the tool every record it might find useful.
For Mesa's pilot, the assistant needs the inspection-fee policy and the customer's question. It does not need the customer's full account history to draft a general explanation of the fee.
If the question concerns a particular order, Elena can supply the relevant permitted facts after checking them. That does not require uploading the whole customer database.
This habit makes the task easier to review as well as reducing unnecessary exposure.
Sort information into practical groups
Use a simple classification for the pilot. Adapt it to your organization's existing rules; it is a working aid, not a substitute for them.
| Group | Examples | Starting rule for the pilot |
|---|---|---|
| Public | Published opening hours, public product descriptions, an approved public policy | Use when relevant; verify that the material is current and you have the right to use it |
| Internal | Draft procedures, unpublished plans, internal instructions | Use only in an account and workflow approved for that material |
| Confidential or personal | Customer details, employee information, supplier terms, donor records | Limit to a specifically approved purpose, audience, and configuration; remove unnecessary fields |
| Restricted for this pilot | Passwords, API keys, full payment-card data, sensitive case files | Keep out of the pilot; use an appropriate controlled process instead |
Public availability does not remove copyright or other obligations. An internal label does not make a document harmless. A spreadsheet may contain several groups of information at once.
For a nonprofit, a public volunteer description may be suitable for drafting. A case note about someone receiving help is a very different input. For a shop, a public product specification and a customer's payment information are different inputs even when they appear in the same system.
Check the account, not just the brand name
“We use ChatGPT,” “we use Claude,” or “we use Copilot” does not fully describe a data arrangement. Consumer, business, enterprise, and API offerings may have different terms, settings, and controls.
The following examples were checked on September 8, 2026. They illustrate why plan-specific verification matters; they are not a ranking of vendors.
| Product scope | What the official source says | What you still need to check |
|---|---|---|
| OpenAI business products and API | Organization inputs and outputs are not used for model training by default | Your actual plan, retention, optional sharing, connectors, and available controls. Official business-data information |
| Anthropic commercial products | Commercial inputs and outputs are not used for training by default; voluntarily provided feedback or other opt-in sharing can create exceptions | Whether the account is commercial or consumer, feedback practices, and applicable retention. Commercial training-use policy |
| Microsoft 365 Copilot | Prompts, responses, and Microsoft Graph data are not used to train foundation models; access operates within the user's permissions | Whether existing file permissions are too broad and which features or external services are enabled. Microsoft privacy documentation |
| Generative AI in Google Workspace | Workspace privacy commitments describe protection of customer data and limits on training use without permission | The supported service, account, administrator settings, and any use outside the covered Workspace experience. Workspace privacy hub |
“Not used for training” does not mean “never stored.” Retention, deletion, logging, access, processing location, and model training are separate questions. Write down the answer that applies to your actual workflow.
Connections can widen access
A connection to a drive, inbox, or customer system may make the assistant more useful. It may also expose much more information than a single uploaded document.
Check what the connection can read and whether it can change records. Look for shared folders with outdated access, unnecessary administrators, and broad “anyone with the link” sharing.
An assistant that respects a user's permissions can still reveal information the user should not have been able to access in the first place. Correct the underlying sharing problem.
For a first pilot, a small approved reference pack is often easier to inspect than a connection to a large document collection. This is a recommended starting practice, not a claim that file uploads are always safer than properly managed connections.
Removing a name may not remove identity
Suppose a message describes the only employee who works a particular shift, names a small location, and gives an exact date. Removing the employee's name may leave the person easy to identify.
Review the combination of details, including free text, attachments, screenshots, hidden spreadsheet tabs, comments, and document metadata. When learning the workflow, fictional examples can avoid the need to process real personal records at all.
For Mesa's first test, Elena writes:
“A customer asks what an inspection costs and whether tomorrow morning is available.”
That is enough to test the core drafting behavior. Later tests can include appropriately approved real examples when needed to evaluate the full task.
Decide who can do what
Name the person who approves source documents, the people who may use the workspace, and the person who reviews outputs. Decide whether the tool may only draft or may also act.
For Mesa, the owner approves the policy. Elena and a trained backup may use the reference pack. Elena reviews customer drafts. The assistant has no permission to send messages or change bookings.
Keep credentials in the proper credential-management system. Do not put passwords or API keys into prompts, shared procedure documents, or example screenshots. Remove access when someone leaves or changes roles.
Record these choices somewhere staff can find them. A rule known only to the owner is difficult to follow consistently.
Have a response for mistakes
If someone uploads the wrong material, stop further use of that material and notify the designated owner. Record what was shared, with which service and account, who could access it, and what actions followed.
Use the service's available deletion and access controls, and check whether the information was copied elsewhere. Do not assume deleting a visible conversation instantly removes every retained copy. If a credential was exposed, revoke or rotate it through the appropriate system.
Follow the organization's incident process to determine any further response, including contractual or legal obligations. The exact requirements depend on the information and circumstances.
Complete the data-use record
Pilot name:
Business purpose:
Approved product and account/plan:
Person who checked the terms/settings:
Date checked and official source links:
Permitted input categories:
Specific approved source documents:
Information excluded from this pilot:
People allowed to use the workspace:
Connections enabled and their permissions:
Retention/deletion settings and known limits:
Allowed actions:
Actions requiring separate approval:
Incident contact and first response:
Next review date or trigger:
Your goal is a record a colleague can follow. If the answer to an important data question is unknown, resolve that question or use a simpler input before testing.
Your next step: assemble only the approved material in Chapter 4.