# AI Usage Policy — Editable Business Template

Prepared by 48 AI. Version 1.0, October 11, 2026.
General operational draft; not legal advice or a compliance guarantee.
Replace every bracketed field and review before adoption. No tool is approved merely because it appears as an example.

## 1. Ownership and scope

Organization: [name]
Policy owner: [name / role]
IT or security reviewer: [name / role]
Effective date: [date]
Next review: [date]
Applies to: [employees / contractors / teams]
Questions and incident reporting: [approved contact / channel]

This policy covers AI used for business work, including personal accounts and AI features inside existing applications. Only the services, accounts, workflows, and information categories recorded as approved below may be used. Existing confidentiality and security policies continue to apply.

## 2. Approved services and use cases

Maintain this register with one row per approved workflow. Identify the specific service and account arrangement rather than approving an entire vendor brand.

| Service and account type | Workflow | Approved users | Permitted information | Output reviewer | Owner / approval date | Review date |
|---|---|---|---|---|---|---|
| [service, configuration] | [task] | [group] | [categories] | [role] | [owner, date] | [date] |

Employees must use [company-managed access method]. Personal accounts are [prohibited / explicitly permitted for specified synthetic or public-only tasks]. Record the actual decision before issuing this policy.

## 3. Information boundaries

Permitted: [specify approved public, synthetic, or other assessed categories].
Requires separate approval: [specify categories and owner].

Do not submit passwords, access tokens, authentication codes, private keys, or other credentials. Do not submit customer records, personnel records, sensitive personal information, nonpublic financial data, confidential agreements, or other restricted information unless the particular service and workflow have been explicitly assessed and approved for that category.

Do not assume removing a name makes a record safe. Review indirect identifiers, context, and confidential business details. Input checks cover [describe actual tested coverage]; they do not replace employee judgment or detect every disclosure.

Allowed example: [invented, approved example].
Approval-required example: [invented example without real sensitive information].

## 4. Human review and output use

The assigned reviewer checks factual accuracy, completeness, confidential information, and suitability before output is used or shared. Verify factual claims against appropriate sources. Employees remain responsible for business decisions and final communications.

Prohibited or separately assessed decisions: [list relevant higher-impact workflows]. AI output alone must not be treated as verified evidence or final authority.

## 5. Access, costs, and changes

Access approver: [role]. Removal / suspension owner: [role].
Joiner, role-change, and leaver procedure: [reference].
Spending owner and allowance: [owner, amount, period].
Behavior at the limit: [tested behavior].
Exceptions require [approver], a documented reason, defined scope, expiry date, and review. New providers, models, input categories, uploads, connectors, or autonomous actions require reassessment before use.

## 6. Oversight and privacy

Activity recorded: [list actual metadata].
Authorized reviewers: [roles].
Retention and deletion rules: [approved values / procedure].
Monitoring coverage: [actual devices, networks, or workspace]. Do not claim visibility into traffic outside that boundary. Routine review should collect only necessary information; do not log detected credentials or routinely expose full employee conversations unless separately justified and approved.

## 7. Accidental submissions and incidents

Stop the affected workflow and report through [channel]. Include service, account type, time, broad information category, and the responsible owner. Do not repeat the sensitive input or secret in an email or ticket. Follow [incident procedure] for containment, investigation, provider follow-up, and any required notifications. Do not delete potential evidence without the incident owner's direction.

## 8. Training and review

Before access, provide the approved-use examples, output-review expectations, and reporting instructions. Review after meaningful changes and by the next scheduled date. Collect questions and correct unclear instructions. Validate that the policy reflects actual service terms and configured controls.

## First-pilot checklist

- [ ] Named business owner and reviewer.
- [ ] Specific service and account arrangement assessed.
- [ ] Narrow workflow and approved users recorded.
- [ ] Permitted and prohibited information documented.
- [ ] Synthetic examples prepared.
- [ ] Access removal and applicable controls tested.
- [ ] Spending envelope and stop process defined.
- [ ] Actual oversight and retention described.
- [ ] Incident route communicated.
- [ ] Review date and continue / revise / stop decision assigned.

## Approval record

Business owner: [name / date]
IT or security reviewer: [name / date]
Other required reviewer: [name / date]
Open issues and conditions: [record]

Further reading: https://48ai.io/shadow-ai/ and https://48ai.io/insights/business-ai-governance/