An AI input box resembles an ordinary search field, but the material pasted into it can contain names, unreleased plans, access tokens, medical details, or another person’s private account. “Never upload anything” is too broad to support useful work, while “the vendor says it is secure” is too vague to support a real decision. A better habit is to classify information by consequence and connect every level to a specific action. The rule should be simple enough to apply during a busy day and strict enough to stop a secret from becoming prompt text.
Classify the content, not the file extension
A document called meeting-notes.docx might contain a public event recap, or it might include a hiring discussion, customer complaints, and an acquisition plan. File type and filename reveal little about the consequences of exposure. Classification should consider the contents, whether a person can be identified, whether the information has been published, contractual duties, and what harm could follow from unauthorized access. Hidden spreadsheet columns, comments, tracked changes, and image metadata belong in that review.
Vendor promises about model training are only one part of the decision. Retention time, administrator access, regional processing, account type, deletion procedures, incident response, and contractual terms also matter. A consumer account and an enterprise account may have different controls even when the interface looks identical. The practical question is not “Is this AI private?” It is “Is this account, configuration, and workflow approved for this specific information?”
A four-level boundary
Level one is public material: published webpages, open reports, and text you have the right to process. It can usually be used for summarization, though copyright and accuracy still apply. Level two is low-sensitivity internal material: blank templates, routine procedures, or working notes without personal or strategic detail. Remove project codes and unnecessary identifiers before use. Level three is sensitive information: customer records, unreleased financial figures, identifiable interviews, private source code, or employee data. It requires an approved organizational tool, appropriate agreement, access controls, and often additional redaction.
Level four is restricted secret material: passwords, API keys, recovery codes, private encryption keys, complete protected records, and information explicitly barred by law or contract. It should not enter a general-purpose model. Classification can change. A press release may move from level two to level one after publication, while several anonymous records can become level three when combined. Review the collection, not only each isolated field.
Applied workflow: editing a customer response
To improve the tone of a customer response, first remove the customer’s name, email, address, order number, phone number, internal ticket link, employee names, and any payment detail. Neutral placeholders and appropriately generalized dates can preserve the grammar problem without preserving direct identifiers. Include the organization’s approved remedy options in the prompt but exclude confidential internal discussion.
After generation, restore necessary details locally and check that the model did not invent a refund promise, admit liability, add an unsupported delivery date, or expose internal language. Send the final message through the normal customer system, not from the AI tool. Redaction does not eliminate risk: rare events, locations, roles, and timelines can re-identify a person. The governing principle is data minimization—the tool receives only what it needs to solve the wording task.
Turn the boundary into a routine
Create a one-page table listing each level, familiar examples, approved tools, required redaction, and who can grant an exception. Before uploading, search for email addresses, phone numbers, identity numbers, credentials, customer IDs, and uncommon names. Inspect hidden columns, document comments, revision history, filenames, and screenshots. If the tool accepts a folder, review every file rather than assuming the selected document is the only input.
For recurring processes, prepare a sanitized template instead of redacting from scratch each time. Review a sample of real tool use every quarter and collect ambiguous cases. If the policy requires ten pages of interpretation, people will route around it. Five concrete examples from the team’s own work are more effective than a banner saying “protect confidential information.” When service terms or settings change, reassess the approved level rather than letting yesterday’s decision become permanent.
Risks, limits, and a usable rule
Redaction is not the same as replacing names. A unique job title, a small town, a rare diagnosis, and a precise date may identify someone together. Automated scanners miss free-form language and often perform unevenly across languages. Local processing can reduce transfer risk but still exposes data through device compromise, logs, backups, or overly broad user permissions. Classification is operational guidance, not a substitute for legal advice or contractual review.
The conclusion can be tested against each prompt: classify by the consequence of exposure, then choose the tool; provide the minimum fields needed; and keep credentials and restricted records out of general models. If you cannot explain a service’s processing rules for the account in use, limit input to public or robustly de-identified material. A good boundary does not ban productive experimentation. It creates a visible point where convenience must yield to responsibility.
REFERENCES
Sources and further reading
External links support verification and further reading; they do not endorse every statement at the destination. Accessed September 2026.