Sensitive Data Handling Checklist for AI Workflows

Create a sensitive data handling checklist for the AI-assisted workflow described below.

Inputs

Workflow description: [Workflow description]
Data inventory: [Data inventory]
Tool, storage, and governance evidence: [Tool, storage, and governance evidence]
Review, approval, escalation, and incident framework: [Review, approval, escalation, and incident framework]

Use of the AI Assistant

Use the AI assistant only to analyze the text and evidence supplied in this conversation, identify risks and gaps, organize proposed controls, and draft the checklist. Do not imply that General AI inspected provider settings, contracts, files, logs, permissions, retention configurations, production systems, or incident records unless their contents were supplied. Do not claim to have changed settings, redacted or deleted data, contacted reviewers, approved the workflow, tested controls, or completed remediation.

Status language

Label each relevant item with one of these states:
- Supplied fact: directly supported by an identified input source.
- Proposed control: recommended but not implemented or approved.
- Reported as executed: the input says an action occurred, but independent verification is absent.
- Verified execution: use only when the supplied evidence identifies the action, result, date or version, and accountable verifier.
- Needs verification: evidence is absent, insufficient, stale, or outside General AI's access.
- Conflict: supplied sources disagree.
- Not applicable: include a short, workflow-specific rationale.

Never convert a proposal, policy statement, vendor claim, screenshot, or user assertion into a verified completion claim without sufficient evidence. Treat provider capabilities, training use, storage, retention, deletion, residency, encryption, access controls, logging, certifications, and contractual protections as Needs verification unless supported by current, attributable evidence.

Input and evidence rules

1. Prefer metadata, field names, data categories, redacted samples, and synthetic examples. Do not request or reproduce credentials, authentication tokens, private keys, full payment details, government identifiers, health records, children's data, confidential contract text, exploitable security details, or other raw restricted data.
2. Assign source IDs such as E1, E2, and E3 to supplied evidence. Cite those IDs beside material findings. Distinguish policy requirements from observed configuration and vendor documentation.
3. If an input is missing, continue only with a clearly limited draft, list the missing input, explain its effect, and mark affected conclusions Needs verification. If safe classification is impossible, apply the more restrictive provisional handling rule.
4. If inputs are ambiguous, state the interpretation used and ask a focused clarification question in the handoff section. If inputs conflict, preserve both claims, cite each source, avoid choosing without a defensible authority rule, and assign an owner to reconcile them.
5. Identify evidence dates and scope where available. Flag evidence that may be stale, applies to a different product tier or workspace, or does not cover the described workflow.
6. Do not invent laws, contractual duties, company policies, reviewers, permissions, approval thresholds, incident deadlines, tool behavior, or test results.

Authority and safeguards

This checklist is an internal planning aid, not legal, privacy, compliance, security, financial, or incident-response advice. Do not authorize processing, approve a tool, waive policy, accept risk, direct a regulatory notification, or make a legal conclusion. Route those decisions to the accountable roles identified in the supplied framework. If no accountable role is supplied, identify the required function without inventing a named person.

Recommend pausing sensitive-data use when the tool is unapproved; storage, training use, access, or retention is unknown; prohibited data may be exposed; required approval is absent; or an incident may be active. For a suspected exposure, propose containment and evidence-preservation steps consistent with the supplied incident process, but do not recommend deleting evidence, investigating beyond authorization, or contacting affected parties or regulators without authorized direction.

Analysis workflow

1. Map the workflow boundary: purpose, users, systems, AI tools, input sources, transformations, outputs, recipients, automated actions, storage locations, reuse, and deletion points. Mark every unsupported element Needs verification.
2. Build a data inventory and classify each category using the organization’s supplied classification scheme.

If no organizational scheme is supplied, use these provisional sensitivity classes:

- public;
- internal;
- confidential;
- restricted.

Record regulated, contract-controlled, policy-controlled, legally privileged, export-controlled, or otherwise specially governed status as separate overlays rather than mutually exclusive sensitivity classes.

Do not infer that data is regulated merely from its subject matter. Cite the supplied legal, contractual, policy, or governance source where such an overlay is asserted. Include synthetic examples only, sensitivity rationale, applicable overlay, source, subjects affected, workflow stage, proposed eligibility, and reviewer requirement.
3. Define input dispositions: allowed, allowed after minimization, approval required, prohibited, synthetic substitute required, or approved-internal-system only. State the controlling evidence or mark the rule Proposed control.
4. Specify minimization measures at field, document, prompt, output, storage, and sharing stages. Include removal, redaction, pseudonymization, aggregation, summarization, truncation, synthetic substitution, and output inspection where relevant. Do not describe anonymization as guaranteed unless evidence supports that conclusion.
5. Review each AI tool and connected storage location for approval status, product or workspace scope, prompt and output storage, provider training use, retention and deletion, residency, access controls, logging, exports, integrations, sharing, contractual terms, and evidence freshness. Unknowns must remain Needs verification.
6. Apply the organization’s supplied risk tiers, approval thresholds, and decision-authority rules where available.

If no organizational taxonomy is supplied, use low, medium, and high only as clearly labelled provisional planning categories. State the factors used, mark the taxonomy Proposed control, and do not imply that the categories reflect existing company policy or legal requirements.

Cover customer-facing, legal, contractual, financial, privacy-sensitive, security-sensitive, employment-related, public, and automated outputs only where relevant. Each gate must identify the trigger, required reviewer function, evidence required, blocking condition, decision record, residual-risk owner, and whether the gate is documented, verified, proposed, or Needs verification.
7. Define escalation triggers for legal, privacy or data protection, security, compliance, finance, HR, leadership, and incident response as applicable. Include immediate safe action, notification owner, required record, and prohibited unilateral action.
8. Draft incident and near-miss readiness steps: recognition, stop or pause criteria, containment within user authority, evidence preservation, notification, logging, assessment handoff, recovery authorization, root-cause review, and recurrence prevention. Reconcile these steps with the supplied incident framework and flag conflicts.
9. Create an implementation register for proposed controls, showing owner function, dependency, priority, required approval, verification method, expected evidence, and current state. Do not state that any control is operating unless verified execution evidence was supplied.
10. Run the acceptance gate and select exactly one readiness result:

- Not ready — use when a blocker exists, prohibited data may be exposed, an active incident may exist, required authority is absent, or a critical tool, storage, retention, deletion, access, training-use, or governance control remains unverified.

- Conditionally ready for authorized limited use — use only when a narrowly defined low-risk scope is supported, prohibited and restricted data are excluded, unresolved conditions have named owner functions and closure actions, and the applicable accountable owners must still authorize the limited use.

- Ready for approval review — use only when the supplied evidence supports every applicable acceptance criterion, no material blocker remains, required decision owners and records are identified, and the workflow is ready to be considered by the accountable human approvers.

None of these outcomes constitutes approval, legal clearance, compliance certification, production authorization, or proof that controls have been implemented.

Output contract: sensitive-data workflow deliverable

Keep the deliverable concise and proportional to the workflow’s actual scope, data sensitivity, and available evidence. Do not repeat the same evidence across multiple sections unnecessarily. For a genuinely irrelevant control area, state Not applicable with a workflow-specific rationale.

Never omit the workflow boundary and evidence register, sensitive-data classification, tool and storage verification, applicable approval gates, acceptance gate, readiness decision, or completion ledger.

## Workflow Boundary and Evidence Register
Provide the workflow map followed by an evidence register with: source ID, source description, issuer or owner if supplied, date or version, scope, supported claim, limitations, and evidence state.

## Sensitive Data Classification Register
Use columns: data category; synthetic example; data subject or business owner; source and destination; workflow stage; classification; rationale; regulatory or policy relevance if supplied; proposed AI-use disposition; minimization requirement; reviewer function; evidence IDs; uncertainty.

## Allowed, Conditional, and Prohibited Input Rules
Separate rules into allowed, allowed after minimization, approval required, prohibited, synthetic substitute required, and approved-internal-system only. For each rule include data category, rationale, control, example using no real sensitive data, authority source, status, and exception path if one is supplied.

## Data Minimization Control Plan
Use columns: workflow stage; exposed element; necessity test; proposed reduction; residual data; output check; owner function; evidence needed; status. Include prompt and external-sharing checks.

## AI Tool, Storage, and Integration Verification Matrix
Use one row per tool, workspace, storage location, or integration and columns: asset; claimed use; approval scope; prompt or output storage; provider training use; retention and deletion; access and workspace controls; logs; sharing or export risk; residency or contractual evidence; evidence IDs and date; finding state; verification owner; verification action; blocking effect. Use Needs verification wherever evidence is insufficient.

## Human Review and Approval Gates
Use columns: risk tier or scenario; trigger; prohibited pending review; reviewer function; checks required; evidence reviewed; decision record; residual-risk owner; current state. Distinguish a proposed gate from a documented or verified gate.

## Escalation and Incident Readiness Matrix
Use columns: scenario; incident or near-miss indicator; immediate action within user authority; action to avoid; notification function; timing only if supplied; evidence to preserve; record required; governing source; conflict or gap; state.

## Workflow Control Implementation Register
Cover approved-tool governance, prompt templates, minimization, permissions, output review, logging, retention, training, periodic review, incident reporting, and any workflow-specific controls. Use columns: control; risk addressed; proposed design; owner function; dependency; priority; approval required; verification method; expected acceptance evidence; current state.

## Acceptance and Reconciliation Gate
Evaluate every check below with Pass, Fail, or Blocked, cite evidence IDs, state the expected observation, record the actual supplied observation, and identify the closure owner:
- Every data category has a classification and disposition.
- Restricted or regulated data has an explicit prohibition or documented approval path.
- Tool approval, storage, training use, access, retention, deletion, logging, exports, and integrations are verified or treated as blockers.
- Proposed minimization can be demonstrated with a redacted or synthetic test case without exposing real sensitive data.
- Required reviewers and decision records are defined for applicable high-risk uses.
- Escalation and incident steps reconcile with the supplied incident process.
- Conflicts, stale evidence, unsupported claims, and missing inputs have owners and closure actions.
- No executed, tested, approved, deleted, or verified claim lacks supporting evidence.

A Pass requires attributable evidence and an observation matching the criterion. A policy statement alone does not prove operational configuration. A proposed test without results is not a Pass. If a safe test has not been executed by an authorized party, specify the test procedure and expected evidence as Proposed control or Needs verification; do not fabricate results.

## Readiness Decision and Authorized Handoff
State one readiness result: Not ready, Conditionally ready for authorized limited use, or Ready for approval review. Give evidence-based reasons, blocking issues, permitted scope if supported, prohibited scope, unresolved questions, required approvers, and next actions. End with a completion ledger separating: analysis produced; controls proposed; actions reported as executed; execution verified by supplied evidence; unavailable work; and outstanding verification. Explicitly repeat that the deliverable is not legal, privacy, compliance, or security advice.