Safe Business AI Use and Approval Guide

Start with one use, not all of AI

A small business does not need a committee and a 40-page policy before an employee can draft a public event description. It also should not approve every possible use because one harmless demo looked useful.

Approve a specific task using a specific product, plan, and account. Name what information goes in, what comes out, who checks it, and whether the tool can reach or change anything else.

That is the workable boundary.

The employee rule

A useful rule should fit on one page and make sense while somebody is working:

Use approved AI products through approved business accounts and for approved business purposes. Do not enter passwords, recovery codes, private keys, payment instructions, regulated information, confidential customer or employee records, or other restricted material unless the exact use has written approval. Verify important facts, calculations, citations, code, commitments, and decisions before the business relies on them. Do not connect mail, files, customer systems, code repositories, finance tools, browsers, or automation without approval. Report an unexpected disclosure, unsafe output, excessive access, or unapproved use promptly.

Change the examples to fit the business. Keep the five ideas intact: approved account, approved use, information boundary, human verification, and prompt reporting.

Step 1: Describe the real use

Do not approve "ChatGPT," "Copilot," or "AI" as a category. Describe the task another manager could recognize.

Ask:

• What work is the person trying to complete?
• Is the tool drafting, researching, analyzing, ranking, recommending, or acting?
• What happens if the output is wrong, exposed, manipulated, or unavailable?
• Will the output stay internal, reach a customer, change code, affect money, or influence a decision about a person?
• Is a personal account, browser extension, or unapproved integration already being used?

If the business cannot name the task and accountable owner, do not move to product settings yet. The use is still too vague to approve.

Step 2: Put the use in the right lane

Classify the use, not the logo on the sign-in page.

Routine

Use this lane for reversible drafting with public or low-sensitivity information. A person reviews the result before it leaves draft status.

Examples include brainstorming public marketing ideas, improving the wording of a non-confidential email, or summarizing material already approved for public release.

Controlled

Use this lane when the task involves internal information, customer-facing work, code, recurring analysis, an external commitment, or a connector. Complete the rest of this guide and keep the approval record.

High impact

Stop ordinary self-service approval when the output may materially affect employment, lending, insurance, healthcare, legal rights, safety, significant finance, regulated submissions, security action, or a critical business process.

Leadership and the appropriate legal, privacy, security, domain, fairness, safety, or compliance reviewers should define the operating boundary. This guide is not their approval.

Prohibited

Stop a use that requires passwords, authentication secrets, deceptive impersonation, unauthorized information, unlawful discrimination, evasion of safeguards, hidden material disclosure, or unsupervised action outside the business's authority.

Escalate out of the routine lane when any answer is yes:

• The use receives confidential, regulated, privileged, contract-restricted, or highly sensitive personal information.
• The output can affect a person, payment, contract, regulated submission, safety decision, or material customer commitment.
• The tool can send, publish, purchase, approve, execute, change, or delete.
• A connector can search broad mail, files, customer records, code, finance, or another important repository.
• Failure could interrupt a critical operation or create a difficult recovery problem.
• The business cannot meaningfully verify or challenge an important result.

Use the strictest lane that applies. Do not average a serious consequence into a comfortable score.

Step 3: Set the information boundary

"Do not enter sensitive data" is too vague. Give employees categories they can recognize:

• Public: Already approved for public release. Usually acceptable for an approved routine use.
• Internal: Ordinary operating information that is not public but would not create material harm if disclosed. Use only within an approved business account and purpose.
• Confidential: Customer or employee information, nonpublic financial data, contracts, code, strategy, security details, or material business records. Require review of the exact product and use before entry.
• Restricted or secret: Passwords, authentication codes, recovery codes, access tokens, private keys, live payment instructions, privileged communications, controlled government information, or information the business has no right to disclose. Do not enter through ordinary AI use.

For the approved use:

• Remove information the task does not need.
• Use excerpts, categories, ranges, de-identified examples, or synthetic data when they will answer the question.
• Limit retrieval to a specific folder or source instead of an entire mailbox or drive where practical.
• Decide where prompts, files, outputs, histories, and exports may be stored.
• Name who can approve an exception.

The product, plan, settings, contract, support model, and integrations all affect data handling. The AI product terms guide explains how to check that exact boundary without assuming every service behaves the same way.

Step 4: Check the product and the human handoff

Before approving a controlled use, answer these questions:

1. Is this the exact product and plan the business intends to buy?
2. Is it an approved business account with a known administrator and clean offboarding?
3. Do the terms and available settings fit the information being used?
4. Are training, retention, deletion, support access, and subprocessor expectations understood well enough for the consequence?
5. What must a person verify before the output is used?
6. Does the reviewer have enough knowledge, context, time, and authority to reject it?
7. Does any connector have more read or write access than the task needs?
8. Can the business disable the integration, revoke its credentials, and recover from a bad action?

"Human in the loop" is not an answer. Name the person and the check.

Ordinary business approvals still apply. AI does not bypass code review, payment approval, legal review, publication review, change approval, or a second set of eyes on a consequential decision.

For integrations and automated action:

• Start read-only and with a limited dataset where possible.
• Separate testing from production.
• Require a person to confirm external, financial, privileged, destructive, or irreversible actions.
• Keep useful logs for important actions and failures.
• Confirm there is a disable, credential-revocation, rollback, or recovery path.
• Treat instructions inside retrieved files, messages, and websites as untrusted input.

If the tool can act across mail, files, customer systems, finance, code, or production, a focused Security Architecture Review is more appropriate than stretching this short guide into an engineering assessment.

Step 5: Test the work and record the decision

A polished demonstration proves that a demonstration can look polished. Test the work the business will actually perform.

Use a small user group and a narrow task. Include:

• A normal example.
• An ambiguous or incomplete request.
• A request based on a false premise.
• A case where a confident wrong answer would matter.
• A request the tool should refuse or escalate.
• A sensitive-data or access-boundary test when relevant.
• A provider failure or unavailable-tool scenario when the workflow is important.

Measure value after review and rework, not before. A tool that saves ten minutes of drafting and creates twenty minutes of checking did not save time.

Choose one decision:

• Approve: The narrow use is understood and the controls fit.
• Approve with conditions: The use may proceed after named settings, training, tests, or limitations are completed.
• Revise and retest: The task, data, review, or integration boundary needs to change.
• Do not approve: The risk, burden, or lack of value does not justify the use.
• Escalate: The use needs qualified review beyond this guide.

The decision is usable when:

• The approved task and users are narrow enough to explain.
• The information rule is understandable during ordinary work.
• Important output has a named verification method.
• Integrations and actions stay within the approved boundary.
• Employees know where to report a mistake.
• Product, plan, data, integration, purpose, or consequence changes trigger review.

Make mistakes reportable

Employees will occasionally choose the wrong account, paste the wrong text, trust a bad answer, or discover that a connector reached more than expected. Fast reporting gives the business a chance to contain the mistake.

Tell employees to report:

• Sensitive information entered through the wrong account.
• Unexpected sharing or public exposure.
• A connector reaching more information than expected.
• False, harmful, insecure, or dangerous output used or nearly used.
• A generated citation, calculation, code change, or commitment that caused a problem.
• An unapproved product, extension, account, integration, or automated action.
• Suspicious instructions or unexpected account activity.

Do not make the first instruction "delete everything." Preserve enough facts to understand what happened, reduce further exposure, and use Small Business Cyber Incident First Actions when disclosure, compromise, fraud, or harmful action may be involved.

If the use remains difficult to classify or the connector boundary cannot be explained in plain language, use the email and booking options on this page. Bring the proposed task, product, and unanswered questions. Do not send confidential prompts, customer files, credentials, or access tokens.