checklist
AI tool exception register template for small teams
A practical exception register template for tracking temporary AI tool approvals, owners, risk level, data classes, guardrails, due dates, review evidence, and closure decisions.
Use this exception register when an AI tool or workflow is not fully approved, but the team needs a temporary path with clear limits.
The register is designed for small teams that already have a baseline AI policy, tool inventory, or monthly AI tool access review. If the workflow is new or unclear, run it through the AI Tool Risk Checker first, then copy the decision into the Small Team AI Security Checklist.
Bottom line
An AI exception should never mean “approved forever but undocumented.” It should mean:
- A named owner accepts the business need.
- The data class and tool access are written down.
- Guardrails are active before use.
- The exception expires on a specific date.
- Someone reviews, closes, renews, restricts, or escalates it.
- Evidence is stored without customer records, secrets, source code, or regulated data.
If the owner, guardrails, or expiry date are missing, the exception is not ready.
When to use an exception
| Situation | Use an exception? | Better default |
|---|---|---|
| A team needs a new AI tool for a short pilot. | Yes. | Pilot with limited users, limited data, and a 30-day review. |
| A customer workflow needs AI before formal approval is complete. | Sometimes. | Use the customer data approval form and restrict real customer data until approved. |
| A browser extension needs broad page access for one role. | Yes. | Score it with the AI browser extension risk scoring matrix and limit hosts. |
| A meeting bot needs to record a sensitive call. | Sometimes. | Require notice, storage, retention, and sharing rules first. |
| A developer AI agent needs terminal or repo access. | Yes. | Require command tiers, repo scope, secret controls, and human review. |
| A vendor cannot answer basic security or privacy questions. | No. | Block or escalate until the vendor risk is understood. |
| The workflow touches secrets, private keys, passwords, payroll, legal files, regulated records, or production credentials. | No for lightweight exception. | Escalate outside the small-team exception path. |
Exceptions are useful when they make risk visible and temporary. They are dangerous when they hide permanent drift.
Exception decision table
| Risk level | Example | Approval path | Maximum duration |
|---|---|---|---|
| Low | Public-content AI writing tool with no connector. | Business owner approval. | 90 days. |
| Medium | Managed AI chat tool for internal non-sensitive work. | Business owner plus admin owner. | 60 days. |
| High | Customer data, source code, meeting transcripts, broad browser access, or connector access. | Business owner, admin owner, and data/source-system owner. | 30 days. |
| Critical | Secrets, regulated records, HR/legal/finance records, production actions, or broad automation. | Do not approve through this lightweight path. | Escalate. |
When in doubt, choose the higher risk level and shorten the review window.
Exception register template
Copy this table into your tracker.
| Field | Value |
|---|---|
| Exception ID | AI-EX-YYYY-MM-### |
| Request date | |
| Requested by | |
| Business owner | |
| Admin owner | |
| Data or source-system owner | |
| Tool or workflow | |
| Vendor or product | |
| Account model | Managed workspace / personal account / vendor account / browser extension / API |
| User group | |
| Business need | |
| Data class | Public / internal / customer / source code / transcript / HR / finance / legal / regulated / secrets |
| Systems connected | Email / Drive / Docs / Slack / Teams / GitHub / CRM / helpdesk / calendar / meeting / browser / other |
| Access requested | Read / write / export / record / summarize / send / update / delete / deploy |
| Risk level | Low / Medium / High / Critical |
| Guardrails required | |
| Guardrails verified | |
| Approval decision | Approve temporarily / restrict / pilot / reject / escalate |
| Expiry date | |
| Next review date | |
| Closure decision | Close / renew / convert to standard approval / remove access / escalate |
| Evidence links | |
| Notes |
Do not paste raw customer records, source code, credentials, contracts, medical/payment data, or regulated records into the register.
Required fields
| Field | Why it matters | Reject if missing |
|---|---|---|
| Business owner | Someone must accept the business need and tradeoff. | Yes. |
| Admin owner | Someone must be able to change settings or remove access. | Yes. |
| Data class | The risk depends on what the tool can see or generate. | Yes. |
| Connected systems | Connectors often expose more than the visible prompt. | Yes for connectors. |
| User group | Exceptions should not silently apply to everyone. | Yes. |
| Guardrails | Temporary approval needs limits before use. | Yes. |
| Expiry date | Exceptions decay into permanent access without a date. | Yes. |
| Evidence | The next reviewer needs to know what was checked. | Yes. |
Use shorter records for low-risk public-content tools. Use full records for anything that touches customers, code, transcripts, browser data, or connectors.
Approval workflow
| Step | Action | Output |
|---|---|---|
| 1 | Requester explains the business need and exact workflow. | Request note. |
| 2 | Admin owner identifies account model, users, connectors, extensions, bots, API keys, and settings. | Access summary. |
| 3 | Data owner classifies the data and blocked data types. | Data decision. |
| 4 | Reviewer runs the workflow through the Risk Checker if risk is unclear. | Risk result. |
| 5 | Owners choose approve temporarily, restrict, pilot, reject, or escalate. | Decision record. |
| 6 | Admin owner applies guardrails before use. | Guardrail evidence. |
| 7 | Review owner schedules the expiry and next review. | Calendar or ticket. |
| 8 | Reviewer closes, renews, converts, removes, or escalates before expiry. | Closure decision. |
The exception should not start until guardrails are active.
Guardrails by risk level
| Risk level | Minimum guardrails |
|---|---|
| Low | Named owner, approved users, no sensitive data, human review of outputs, expiry date. |
| Medium | Managed account where practical, MFA, no shared accounts, limited sharing, documented settings, monthly review if new. |
| High | Data owner approval, connector scope review, retention rule, offboarding step, incident path, human review gate, 30-day expiry. |
| Critical | Do not approve through lightweight exception. Escalate to formal legal, security, compliance, engineering, or executive review. |
For ChatGPT connectors, pair the exception with the ChatGPT connector approval template. For developer AI, pair it with the developer AI tool inventory template.
Review cadence
| Exception type | Review cadence |
|---|---|
| Low-risk public-content workflow | Before 90 days. |
| Internal non-sensitive workflow | Before 60 days. |
| Customer data, source code, transcripts, browser page data, or connectors | Before 30 days. |
| Meeting bot recording or transcript exception | After the first sensitive meeting and before 30 days. |
| Browser extension broad host access | Before 30 days and after major extension permission changes. |
| Developer AI terminal, repo, or automation access | Before 30 days and after any incident or permission change. |
| Incident-related exception | Same week. |
The monthly access review should include all open exceptions due in the next 30 days.
Closure checklist
| Check | Close when |
|---|---|
| Business need | The use case is complete, converted to standard approval, or no longer needed. |
| Users | Temporary users, guests, admins, and groups were removed or converted intentionally. |
| Connectors | OAuth apps, integrations, source-system permissions, and tokens were revoked or scoped. |
| Browser extension | Extension install, OAuth access, vendor account, and browser profile were cleaned up. |
| Meeting data | Raw transcript, audio, summary, clips, and CRM sync follow the retention decision. |
| Developer access | Repo access, terminal permissions, API keys, PR bots, and code indexes match the final decision. |
| Evidence | The register shows close, renew, restrict, convert, remove, or escalate. |
| Next owner | Any remaining approved workflow has an owner and next review date. |
Do not mark an exception closed just because the calendar reminder expired.
Escalation triggers
Escalate instead of approving through this lightweight path when the workflow involves:
| Trigger | Why |
|---|---|
| Secrets or credentials | Exposure may require rotation and incident response. |
| Regulated or high-impact records | Lightweight review is not enough for legal or compliance risk. |
| Production changes | AI can create outages, data loss, or irreversible changes. |
| Broad write access | Sending, deleting, updating, merging, deploying, or exporting needs stronger controls. |
| Customer bulk exports | Volume changes the risk even if individual records seem low sensitivity. |
| Unknown vendor behavior | Unclear retention, training, sharing, or subprocessors can invalidate the approval. |
| No owner | No one can remove access or answer questions later. |
| Repeated renewals | The exception is becoming a standard workflow and needs formal approval. |
Escalation is not failure. It is the correct decision when the lightweight path is too small for the risk.
Example entries
| Exception ID | Tool or workflow | Risk | Guardrail | Decision |
|---|---|---|---|---|
| AI-EX-2026-06-001 | Support team uses AI to draft replies from redacted tickets. | Medium | No names, account IDs, or attachments; human review required. | Pilot for 30 days. |
| AI-EX-2026-06-002 | Sales meeting bot records two customer calls. | High | Notice script, internal-only summary, 30-day transcript deletion. | Approve temporarily. |
| AI-EX-2026-06-003 | AI browser extension with all-sites access for one analyst. | High | Only approved host list; OAuth reviewed; extension reviewed after 14 days. | Restrict. |
| AI-EX-2026-06-004 | AI coding agent can run deploy commands. | Critical | Not enough for lightweight exception. | Escalate. |
These examples are patterns, not legal, compliance, or security assurance advice.
Evidence packet
Use this text block for a single exception.
AI tool exception evidence packet
Exception ID:
Review date:
Reviewer:
Business owner:
Admin owner:
Data/source-system owner:
Tool or workflow:
Business need:
Data class:
Connected systems:
Access requested:
Risk level:
Risk Checker result:
Guardrails applied:
Approval decision:
Expiry date:
Next review date:
Closure decision:
Evidence links:
Notes:Store evidence outside the AI tool being reviewed. Avoid storing raw customer data, source code, passwords, API keys, private keys, regulated records, legal files, or private contracts.
Metrics to track
| Metric | What it tells you |
|---|---|
| Open exceptions | Whether temporary approvals are accumulating. |
| Overdue exceptions | Whether the review process is decaying. |
| Exceptions by risk level | Whether high-risk work is using temporary paths too often. |
| Exceptions renewed twice | Which workflows need standard approval or removal. |
| Exceptions closed on time | Whether owners can remove access when promised. |
| Exceptions escalated | Whether the lightweight process is stopping at the right boundary. |
| Incidents tied to exceptions | Whether guardrails are strong enough. |
| Risk Checker completions | Whether approvals use a consistent decision aid. |
If high-risk exceptions keep growing, stop approving new ones until old ones are closed or converted.
Evidence checked
- NIST: AI Risk Management Framework
- NIST: Cybersecurity Framework
- NIST: Privacy Framework
- Cybergiz: AI Tool Risk Checker
- Cybergiz: Small Team AI Security Checklist
- Cybergiz: Monthly AI tool access review checklist
FAQ
Is an exception the same as approval?
No. An exception is a temporary, limited approval with an expiry date. Standard approval should have a stable owner, policy fit, settings record, offboarding path, and review cadence.
Who can approve an AI exception?
At minimum, use a business owner and admin owner. Add a data owner for customer data, an engineering owner for source code or terminal access, and a source-system owner for connectors.
How long should an exception last?
Keep high-risk exceptions to 30 days or less. Medium-risk exceptions can often use 60 days. Low-risk public-content tools can use 90 days if they have no sensitive data or connectors.
What should never be approved through this lightweight path?
Secrets, private keys, passwords, session cookies, regulated records, production deployment actions, broad write access, sensitive HR/legal/finance records, or unclear vendor behavior should be escalated outside this lightweight exception process.
What if the same exception keeps getting renewed?
Convert it to standard approval or remove it. Repeated renewal means the workflow is no longer a temporary exception.
How does this connect to monthly review?
Every monthly AI access review should check open exceptions, overdue exceptions, repeated renewals, and exceptions tied to incidents. The monthly AI tool access review checklist gives the broader review process.