An AI tool should not receive real business data merely because its demonstration looked useful. Before adoption, define what information will enter the system, who can access it, what the provider may retain, which actions the tool can perform, and how the organization will respond when something goes wrong.
Privacy and security are not one checkbox. Privacy asks whether data processing is appropriate, understandable, and limited to a justified purpose. Security asks whether the system protects data and operations from unauthorized access, manipulation, disclosure, and loss. A tool may have strong encryption and still collect more information than the workflow needs. It may publish a detailed privacy policy and still be unsafe when connected to broad permissions or untrusted documents.
This checklist is for teams, independent professionals, and small organizations evaluating AI services for ordinary work. It is not a substitute for legal advice, a formal security assessment, or sector-specific compliance review.
1. Define the workflow before reviewing the vendor
Start with the exact job, not the product name. Record the input, transformation, output, human reviewer, storage destination, and consequence of failure. A vague proposal such as “use AI for customer work” cannot be assessed because it hides multiple data flows and decisions.
A useful workflow statement is specific: “Create a first draft from approved, de-identified support notes; a staff member verifies every factual claim; the approved version is stored in the existing document system.” This exposes where data enters, where human judgment remains, and which systems become connected.
Document what the AI must never decide. Employment, access approval, financial authorization, medical advice, legal conclusions, security changes, and public statements usually require stronger controls than low-impact drafting or formatting.
Decision questions
- What exact input, operation, output, reviewer, and destination define the workflow?
- What harm could occur if the output is wrong, delayed, disclosed, or manipulated?
- Which decisions and approvals remain exclusively human?
2. Classify data before anyone uploads it
Create a small data classification that people can actually use. At minimum, distinguish public information, internal information, confidential business information, personal data, regulated or highly sensitive data, credentials, and security material.
Then map each class to an action: allowed, allowed only after de-identification, allowed only under an approved enterprise configuration, or prohibited. Do not depend on employees remembering a long policy during a fast conversation. Put the rule beside the tool, in onboarding material, and in the workflow itself.
Secrets deserve a separate prohibition. Passwords, API keys, session cookies, recovery codes, private keys, database credentials, and production configuration should not be pasted into a general AI interface. Redaction also requires care: removing a name may not anonymize a record if dates, locations, rare events, or identifiers still reveal the person.
Decision questions
- Which data classes may enter the tool, and under which account or configuration?
- Can realistic tests use synthetic or de-identified material instead of production data?
- Which fields remain identifying when names and obvious identifiers are removed?
3. Verify the provider contract and active settings
Marketing summaries are not enough. Review the terms, privacy notice, data processing terms, security documentation, retention policy, subprocessors, deletion controls, and the settings that apply to the exact plan and region you will use.
Separate contractual commitments from optional controls. A provider may offer a training-data opt-out, shorter retention, regional processing, administrator logs, single sign-on, or restricted sharing only on certain plans. Confirm the active state in the actual account rather than assuming the feature exists because it appears in documentation.
Record unsettled questions. If the documentation does not clarify human review, deletion timing, backup retention, or cross-border processing, mark the item unresolved. Silence is not a favorable answer.
Decision questions
- Are inputs, outputs, metadata, and feedback retained or used to improve services?
- Which plan, region, and account settings control those practices?
- Can administrators verify deletion, sharing, and access configuration rather than relying on user memory?
4. Apply least privilege to people, integrations, and agents
Give the tool the smallest permissions needed for the defined job. A writing assistant does not need access to every drive folder. A meeting summarizer does not need the ability to send email. A search tool does not need write permission. Start with read-only access to a narrow test dataset and expand only when evidence shows a need.
Review permissions at three levels: the individual user, the connected service account, and any autonomous agent or tool-calling function. A limited user account can still create broad risk if the integration token can read an entire workspace or execute actions without confirmation.
For consequential actions, separate preparation from execution. The system may draft a message, query, or change plan, while a person reviews and performs the final action. Require explicit confirmation for external communication, purchases, deletion, permission changes, code execution, and production operations.
Decision questions
- What is the minimum read and write scope required for this workflow?
- Can preparation and execution use separate permissions and separate approval steps?
- How quickly can access be revoked when a user, integration, or provider changes?
5. Treat prompts, files, web pages, and retrieved text as untrusted input
Prompt injection occurs when instructions hidden in user content, documents, web pages, messages, or retrieved knowledge alter the model's behavior. The risk is not limited to a person typing “ignore previous instructions.” A document can contain text designed to request secrets, change the task, trigger a tool, or mislead the reviewer.
Do not assume that a model can reliably distinguish trusted instructions from untrusted content. Keep system rules outside retrieved text, limit tool permissions, validate requested actions, and present the source of external instructions to the reviewer. Sensitive data should not be available to a component that processes arbitrary external content unless the workflow has a strong isolation boundary.
Test adversarial examples before adoption. Include documents that request credential disclosure, hidden instructions that conflict with the task, links to unapproved destinations, and content that attempts to authorize an action. The expected result should be refusal, isolation, or a visible request for human review.
Decision questions
- Which inputs can be controlled by customers, websites, attachments, or third parties?
- Can untrusted content influence tool calls, data access, or external actions?
- What evidence shows that hostile instructions are blocked or surfaced for review?
6. Validate outputs before they reach another system
AI output is untrusted data. Do not pass generated text directly into a command shell, database query, browser renderer, workflow engine, access policy, or production API without validation appropriate to that destination.
Use allowlists, typed schemas, parameterized interfaces, length limits, destination restrictions, and escaping. Check generated links before following them. If the output selects recipients, files, amounts, permissions, or commands, compare each value with the approved request and show the final action to a person.
Content safety and factual review are separate from technical output handling. A statement can be factually correct but dangerous as a command, while a harmless paragraph can contain a false claim. Validate both the meaning and the execution context.
Decision questions
- Which downstream system will interpret the output, and what inputs can it safely accept?
- Are generated actions constrained by schema, allowlist, and human approval?
- Can output be stored as a draft instead of being executed automatically?
7. Plan retention, export, deletion, and exit
Decide how long source material, prompts, outputs, logs, feedback, and audit records should remain. Retention should follow the workflow's purpose rather than the provider's maximum default. Keeping everything indefinitely increases exposure and makes later deletion harder.
Test deletion and export before dependence grows. Determine whether deleting a conversation removes associated files, embeddings, derived data, shared links, and copies visible to administrators. Ask how backups and legal holds affect timing. Exported data should use formats that another approved system can read without reconstructing the entire history manually.
Keep important approved outputs in the organization's own system of record. The AI service should not become the only place where essential decisions, evidence, or final documents exist.
Decision questions
- What retention period is justified for each data type in the workflow?
- Does deletion cover files, derived data, shares, logs, and backups?
- Can the organization leave the service without losing required records or context?
8. Prepare monitoring and incident response before launch
Define what will be logged and who will review it. Useful records may include account changes, integration permissions, large exports, sharing events, tool calls, failed authorization, policy overrides, and publication actions. Avoid creating a new privacy problem by logging full sensitive prompts when event metadata would be sufficient.
Write a short response plan for accidental data submission, suspected account compromise, malicious prompt injection, unauthorized action, provider incident, and incorrect public output. The plan should identify the person who can disable integrations, revoke credentials, preserve evidence, contact the provider, notify affected parties when required, and approve restoration.
Run a rehearsal with synthetic data. A plan that has never been exercised may depend on unavailable credentials, unclear ownership, or controls that do not exist on the selected plan.
Decision questions
- Which events indicate misuse, leakage, excessive access, or unexpected agency?
- Who can disable the workflow and revoke every connected credential?
- Has the team rehearsed containment, evidence preservation, correction, and recovery?
Adoption decision matrix
| Area | Evidence required | Stop condition |
|---|---|---|
| Workflow | Defined input, output, reviewer, and consequence | Purpose or owner remains unclear |
| Data | Approved classification and minimization rules | Prohibited data is required for routine use |
| Provider | Applicable terms, retention, controls, and settings | Critical processing practice is unresolved |
| Access | Least-privilege account and integration scopes | Broad write or workspace access is unavoidable |
| Injection | Adversarial document and prompt tests | Untrusted content can trigger sensitive actions |
| Output | Schema, allowlist, destination checks, approval | Output is executed without validation |
| Lifecycle | Tested export and deletion | Required records cannot be recovered or removed |
| Response | Named owner, logs, revocation, rehearsal | No practical containment path exists |
Who should not adopt yet
Delay adoption when the workflow requires highly sensitive data but the applicable contract and controls are unclear; when the tool needs broad write access to essential systems; when users cannot distinguish drafts from approved outputs; when no person owns incident response; or when the service cannot provide a usable export and deletion path.
A limited pilot may still be appropriate. Use synthetic information, disable external actions, restrict access to a small group, and define a fixed end date. The objective of a pilot is to produce evidence for a decision, not to create an unofficial permanent system.
Short pre-adoption checklist
- Is the workflow specific, limited, and owned by a named reviewer?
- Are allowed and prohibited data classes written down?
- Have the applicable contract, plan, region, and active settings been checked?
- Are user, integration, and agent permissions limited to the minimum scope?
- Have prompt injection and hostile document cases been tested?
- Is every downstream action validated and approved?
- Have export, deletion, retention, and provider exit been tested?
- Can the organization detect, contain, correct, and recover from an incident?
For evaluating usefulness, cost, portability, and long-term fit, combine this checklist with 7 Criteria to Check Before Choosing an AI Tool. For checking factual output after adoption, use How to Verify AI Answers, Sources, and Factual Claims.
Sources reviewed
- NIST Privacy Framework (opens in a new window)
- NIST AI Risk Management Framework 1.0 (opens in a new window)
- NIST Generative AI Profile (opens in a new window)
- OWASP Top 10 for LLM and Generative AI Applications (opens in a new window)
- OWASP LLM01:2025 Prompt Injection (opens in a new window)
Sources checked: 2026-07-19