The first security question about an AI tool is not what it can generate. It is what the product can read, where that information goes and which actions it can take. A small business should answer those questions before connecting an inbox, drive, repository or customer system.

Use this checklist as an operational starting point. It is not a substitute for legal advice or a specialist security review where the risk requires one.

1. Define the use case before buying

  • [ ] Name the exact task the tool will perform.
  • [ ] Identify the owner responsible for the tool.
  • [ ] Define the expected benefit and how it will be measured.
  • [ ] Start with a low-risk process.
  • [ ] Decide what outcome would end the trial.

A broad instruction such as “use AI across marketing” makes risk difficult to control. “Draft non-confidential social variations for human approval” is testable and bounded.

2. Classify the data

  • [ ] List the data users may enter.
  • [ ] Mark personal, confidential, regulated and client-owned information.
  • [ ] Prohibit passwords, API keys and authentication tokens.
  • [ ] Prohibit unpublished financial, legal or strategic material unless specifically approved.
  • [ ] Remove unnecessary identifiers before use.
  • [ ] Confirm whether uploaded files, prompts and outputs are retained.

OWASP identifies sensitive information disclosure as a major risk in LLM applications. Treat both the prompt entering the system and the generated output leaving it as boundaries that need controls.

3. Check the vendor’s data terms

  • [ ] Find the privacy policy and product-specific data documentation.
  • [ ] Determine whether business inputs are used for model training.
  • [ ] Check retention and deletion controls.
  • [ ] Identify subprocessors and relevant data locations.
  • [ ] Confirm how account deletion affects stored data.
  • [ ] Record which plan includes the controls you need.

Do not infer enterprise protections from a consumer product page. Save the version or checked date of important terms because policies can change.

4. Control accounts and access

  • [ ] Use individual accounts rather than shared passwords.
  • [ ] Require multifactor authentication where available.
  • [ ] Use single sign-on when the risk and team size justify it.
  • [ ] Apply least privilege.
  • [ ] Remove access promptly when someone leaves or changes role.
  • [ ] Review administrators and integrations periodically.

The person testing a feature usually does not need permanent administrative access.

5. Treat integrations as separate risk decisions

  • [ ] List every connected inbox, drive, CRM, repository and publishing account.
  • [ ] Review the exact read and write permissions requested.
  • [ ] Avoid connecting production systems during an early trial.
  • [ ] Use a test workspace with limited data where possible.
  • [ ] Know how to revoke the connection.
  • [ ] Monitor actions taken through the integration.

An AI tool connected to an email account or code repository has a different risk profile from the same tool used only as an isolated chat window.

6. Limit agent autonomy

  • [ ] Begin with recommendations, not autonomous actions.
  • [ ] Require approval before sending, publishing, purchasing, deleting or changing permissions.
  • [ ] Set financial and rate limits.
  • [ ] Restrict tools to the minimum necessary set.
  • [ ] Keep a usable activity log.
  • [ ] Provide a fast stop or revocation process.

The UK National Cyber Security Centre’s 2026 joint guidance on agentic AI advises organizations to start small, use agents for low-risk tasks and avoid unrestricted access to sensitive data or critical systems.

7. Plan for prompt injection and untrusted content

  • [ ] Treat websites, emails, documents and user submissions as untrusted input.
  • [ ] Do not assume a system prompt can enforce every security rule.
  • [ ] Separate data retrieval from permission to act.
  • [ ] Validate outputs before passing them to another system.
  • [ ] Restrict tool calls and destinations.
  • [ ] Test how the product handles malicious instructions in retrieved content.

OWASP lists prompt injection as a leading LLM application risk. The problem is especially important when a system reads external content and can also take actions.

8. Require human review for consequential output

  • [ ] Define which outputs always require review.
  • [ ] Check facts and calculations independently.
  • [ ] Do not use generated legal, financial, medical or employment decisions without qualified oversight.
  • [ ] Inspect generated code before execution.
  • [ ] Keep responsibility with a named person.

AI can be an input to a decision. It should not become an invisible decision-maker simply because the interface is convenient.

9. Prepare for incidents and exit

  • [ ] Know how to report a security or privacy issue to the vendor.
  • [ ] Record the internal incident contact.
  • [ ] Know how to revoke tokens and integrations.
  • [ ] Export necessary business data in a usable format.
  • [ ] Define deletion and offboarding steps.
  • [ ] Identify a manual fallback for critical work.

Decide whether the trial is safe enough to start

Approve a trial only when the use case is bounded, the data rules are clear, permissions are limited and a person reviews important outputs. Delay it when the vendor cannot explain data handling, the product requires broad production access for a minor benefit or the team cannot see what an agent does. A smaller test environment is often more useful than a faster production connection.

Sources