Choose a route before choosing an AI tool
Write down the task and its intended output first. A request for issue counts may need only a category and count; a customer update may need a few approved incident facts. NIST's guidance on personally identifiable information calls for protection proportionate to the information and its context. Government AI data-security guidance recommends classification and access controls for sensitive and proprietary data.
| Check | What to establish | If you cannot establish it |
|---|---|---|
| Authority | The data owner or applicable policy permits this data class, purpose, AI service, workspace, and recipient. | Stop. Ask the named owner or security, legal, or privacy contact. |
| Content | Every surviving fact is needed for the output, including dates, rare events, free text, and combinations that might identify someone. | Minimize locally. Try an aggregate, synthetic example, or smaller excerpt. |
| Container and access | The whole file, image, archive, or connector scope has been checked, not just the visible paragraph or selected sheet. | Do not attach or connect it. Make a smaller copy or narrow the access. |
| Release | A person is responsible for checking the AI output and approving its destination. | Keep the draft internal and unapproved. |
Proceed only when the use is permitted, the workspace controls are known, and the reviewed input contains no unnecessary restricted detail. Sanitize locally when an authorized task can be completed with a smaller substitute; review that substitute again before transfer. Stop when permission is missing, a live credential is present, the tool or connector scope is unknown, or the task needs restricted information not approved for that environment. Record who made the decision and what input was allowed. If an owner approves a different environment, repeat the content and container checks there.
When you need an owner's decision, ask about a bounded task rather than requesting blanket permission to “use AI.” A short request can specify: the data class and owner; the exact outcome; the proposed service, account, and workspace; whether a file, pasted excerpt, or connector will be used; the fields that will cross the boundary; and the intended output recipient. Ask who will review the result and how long the service or workspace may retain the input. An approval for one workspace or purpose does not silently extend to another.
Keep the answer with the task record. If the owner permits only an aggregate, do not send pseudonymized rows. If they permit an internal model but not an external service, changing the prompt does not solve the access problem. If they cannot identify the permitted recipient or connector scope, the task remains stopped until those details are settled.
Apply the checks to different kinds of work
Use the situation closest to your task to decide what to check first. A fact published in a product manual may still be confidential in an unreleased incident report.
| Situation | Practical route | Check before transfer |
|---|---|---|
| Published manual or public product page | Use the relevant excerpt if the task and usage rights allow it. | A downloaded copy may contain private notes or an unpublished appendix. |
| Your own health note, tax form, or family photo | Start with a short summary or invented example. Share the original only if the task needs its details and you accept the service's storage and sharing rules. | Look for other people's names, faces, addresses, and financial details. Remove them or get permission before sharing. |
| Customer-support export for issue counts | If authorized, produce category counts locally and send the aggregate when counts are enough. | Free-text notes, rare groups, exact dates, and small counts can still reveal a customer. Row tokens remain linkable. |
| Work-held employee, patient, student, or financial records | Stop for the applicable owner and approved processing route. Use synthetic examples while the decision is pending. | Confirm purpose, policy, access, retention, and whether even a redacted extract is permitted. |
| Code or logs with a token, cookie, private endpoint, or customer value | Keep the original local. If a live secret may have been exposed, follow the incident process and revoke or rotate it. Build a small synthetic reproduction for AI help. | Inspect config files, headers, stack traces, history, and generated attachments. |
| Unreleased contract, deal, board note, or incident update | Obtain purpose-specific owner approval for the tool and workspace. A short approved fact summary may be possible. | Even a timestamp, codename, workaround, or promise can be confidential in context. |
| Connected drive, repository, mailbox, or meeting transcript | Check the connection's permissions and reachable scope before enabling it. Use a narrower approved source when possible. | The tool may see adjacent material that was never intended for this task. |
For hidden parts of spreadsheets, documents, images, logs, and archives, use the artifact inspection guide. For row-level data, the local anonymization and pseudonymization workflow explains why removing names alone does not establish anonymity. First decide whether this particular AI use is authorized.
Build a minimum input locally
- Define the deliverable. Write the question the AI must answer and the facts it needs. Mark unknown facts so they cannot silently become guesses.
- Inventory the source without uploading it. Inspect visible text and adjacent content: comments, revisions, hidden sheets, filenames, metadata, screenshots, embedded objects, links, and connected-folder scope. Never paste a live secret to ask an AI whether it is sensitive.
- Make a separate input. Copy only approved facts into a new document. Remove unneeded identifiers and confidential context locally; aggregate when individual records are unnecessary. Keep a private redaction ledger so a reviewer can tell what changed.
- Review it as a fresh disclosure. Search for known restricted values and likely patterns, then read for unusual combinations the scan misses. Check what a recipient could infer from remaining dates, roles, rare events, and wording. Zero pattern matches do not prove anonymity or authorization.
- Set the output boundary. Tell the AI to use only the reviewed facts, mark unknowns, and leave approval or publication to the responsible person. Inspect the generated output before sharing it.
If even the minimum input reveals an unapproved secret, person, or confidential event, do not send it. Ask for an approved environment or complete the work without that AI service.
Test whether the minimized input still supports the work. A table of issue counts can support a trend summary but cannot support a named customer response; a synthetic code sample can demonstrate a bug but cannot prove a patch works in production. When the required output depends on facts removed for safety, either narrow the deliverable or seek an approved processing route. Do not let the AI fill the missing facts from plausible context.
Check the exact product and workspace controls
Account settings affect handling, not disclosure authority. OpenAI's current Temporary Chat guidance says an unsaved temporary chat stays out of history, is not used for model improvement while temporary, creates no new memories, and may be kept for up to 30 days for safety. A personalized temporary chat can use existing memories, custom instructions, and plugins; saving it converts it to a regular chat. If a GPT action sends data to a third party, that recipient's policy applies. OpenAI's Library guidance says files uploaded in a temporary chat are not saved to Library while it remains temporary, but eligible files may be saved if the chat is saved.
Before using any service, verify the current settings of the actual account or workspace, its file and retention rules, enabled connectors or actions, and who can access the result. Do not infer enterprise controls from a personal account or assume that turning off training removes a file already sent. If these details cannot be confirmed, stop until the owner or administrator answers.
Walk through a synthetic incident update
The downloadable practice source is fictional. It contains a name, reserved-domain email address, test IDs, a secret-like test token, an internal-invalid hostname, confidential project context, and four operational facts. The original file and restricted values were never submitted to ChatGPT. The example shows how to prepare a draft for review; it does not authorize real customer or incident data.
Classify without sending values
Describe field types when asking for classification: direct identifiers, ticket ID, credential, internal host, project name, unreleased date, operational facts, and unknown cause and restoration time. Do not include actual values. In the documented test, the credential class stopped, identifying and confidential fields were marked for local removal, and minimum facts remained candidates for review.
Record what is allowed and prepare the input
The boundary card records who can authorize the task, which facts may be used, and what the tool can access. In this example the source file stays local, and the result still needs owner review. For a real task, record the data owner, permitted purpose, exact service and workspace, allowed and prohibited fields, destination, and reviewer. Do not transfer anything while those decisions are unknown.
In the example, nine restricted values were removed locally. The 13-row ledger records what was removed and retained. The reviewed input contains four operational facts: an export timed out at 09:20 UTC, dashboard viewing remained available, a previous scheduled export was a temporary workaround, and engineering had not confirmed cause or restoration time. These facts are allowed only within this fictional exercise; a real incident owner must decide whether the same detail is permitted.
Draft, challenge, and correct
Ask for four sections: Verified facts, Current workaround, Unknowns, and Owner review. Treat the first response as a draft that still needs a human check for leaked or invented details. In the documented test, the draft kept the known time and workaround without supplying a root cause or restoration estimate.
Before sharing a draft, compare every identifier, date, host, cause, ETA, promise, and approval statement with the reviewed input. In a deliberate test, the editor inserted placeholder identifiers and an internal host, an invented credential-expiry explanation, a 14:00 UTC promise, and an “approved and sent” claim. Four of six candidate sentences failed the audit. The passing statements described only the available dashboard and previous-export workaround. This tests the review step; it does not show that the model catches every kind of leak.
The corrected update contains only reviewed facts and preserves unknowns. The release record shows that nobody established permission for real data, an owner still needs to review the result, and nothing was published. A clean draft is not permission to send it.
Check the practice files with the optional script
Download the complete synthetic review kit, extract it into one folder, and run the bundled script there:
python3 sensitive-data-evidence-gate.pyThe script checks that nine exact restricted values appear in the practice source but not the reviewed input or final update, that the required facts remain, and that the final file matches the reviewed example. An unexpected added line fails. This check works for the bundled files; it cannot find every paraphrased leak, identify a person from outside information, interpret a real contract or law, or grant permission. Read the input and output yourself and obtain the required owner review. The recorded result applies only to these practice files.
If information has already crossed the boundary
Stop further prompts, attachments, sharing, and connector actions involving that material. Record what was sent, when, through which account or workspace, to which service or action, and who can access the chat or output. Notify the organization contact specified by its incident policy so they can decide on containment, notices, and retention requests. Revoke or rotate exposed live credentials through that process. Do not assume deleting a chat erases every copy: OpenAI documents separate chat, file, and workspace retention rules. Preserve the facts needed for the response team without repeating sensitive values in another AI prompt.
