checklist

AI tool pilot exit checklist for small teams

A practical checklist for ending an AI tool pilot with evidence, owner decisions, risk review, access cleanup, data retention checks, incident review, and approve/restrict/remove outcomes.

Use this checklist when an AI tool pilot reaches its review date.

The hard part of AI governance is not starting pilots. It is ending them cleanly. A pilot should finish with an explicit decision: approve, restrict, extend once, remove, or escalate. If you do not have the original request, start with the AI tool request intake form and run the tool through the AI Tool Risk Checker before making the exit decision.

Bottom line

An AI tool pilot should not become permanent by default. Before the pilot closes, answer:

1. Did the tool solve the business problem?
2. Did users follow the allowed data and workflow rules?
3. Did the tool access new data, connectors, browser pages, meeting transcripts, source code, or automation paths?
4. Were there incidents, near misses, bad outputs, or support questions?
5. Can the team offboard the tool completely?
6. Does the evidence support standard approval, restriction, removal, or escalation?
7. Who owns the next review date?

If no owner can answer those questions, remove or restrict the pilot until the review is complete.

Pilot exit outcomes

Outcome	Use when	Next action
Approve	The use case worked, guardrails were followed, and risk stayed within the approved scope.	Convert to standard tool approval and add to the operating register.
Restrict	The tool is useful but the user group, data class, connector, extension, or automation scope was too broad.	Narrow scope and set a near-term review date.
Extend once	Evidence is incomplete but risk stayed low or medium.	Extend for a fixed period with missing evidence listed.
Remove	The tool did not solve the problem, created risk, or cannot be governed.	Offboard users, revoke connectors, delete retained data where appropriate.
Escalate	The workflow touches critical data, production actions, regulated records, broad automation, or unclear vendor behavior.	Move outside the lightweight pilot path.

Avoid “keep testing” as a decision. It usually means the pilot has no owner.

Exit decision table

Review area	Approve if	Do not approve if
Business value	The tool saved time, improved quality, or reduced risk for the approved workflow.	Benefits are vague, anecdotal, or unrelated to the original request.
User scope	Only approved users used the tool.	New teams, guests, admins, or personal accounts appeared.
Data scope	Data stayed within the approved classes.	Customer data, source code, transcripts, browser data, or regulated records appeared unexpectedly.
Connector scope	Connected systems matched the approval record.	Email, Drive, Slack, GitHub, CRM, helpdesk, calendar, meeting, or browser access expanded.
Output control	Human review happened before customer, code, record, or public impact.	AI output changed records, code, or customer messages without review.
Incident history	Issues were reported, contained, and corrected.	Incidents were hidden, repeated, or unresolved.
Offboarding	The admin owner can remove users, connectors, data, extensions, bots, and keys.	The team cannot fully remove access.

Use the stricter side of the table when evidence is missing.

Pilot exit checklist

Step	Check	Owner	Evidence
1	Confirm the original request, approved users, data classes, systems, guardrails, and review date.	Review owner	Intake form.
2	Compare actual usage with approved usage.	Business owner	Pilot notes or user feedback.
3	Review users, guests, admins, personal accounts, shared accounts, and API keys.	Admin owner	User/access list.
4	Review connected systems and OAuth apps.	Source-system owner	Connector register.
5	Review browser extension permissions and hosts if the tool used an extension.	IT owner	Extension record.
6	Review meeting recording, transcript, CRM sync, retention, and sharing if a bot was used.	Meeting owner	Bot settings notes.
7	Review repo, terminal, PR, CI/CD, code search, and secret exposure if developer AI was used.	Engineering owner	Developer AI register.
8	Review customer data and redaction records if customer workflows were involved.	Data owner	Approval form.
9	Review incidents, near misses, bad outputs, employee questions, and support tickets.	Incident owner	Incident log.
10	Decide approve, restrict, extend once, remove, or escalate.	Business owner	Decision record.
11	Apply cleanup or standard approval steps before closing the pilot.	Admin owner	Closure evidence.
12	Schedule the next review if the tool remains in use.	Review owner	Calendar or ticket.

Do not let the tool remain live while the decision is “pending” unless there is a temporary exception with an expiry date.

Usage review

Question	Evidence to request
Who used the tool during the pilot?	User list, group membership, or admin export.
Which workflows used the tool?	Request notes, user feedback, tickets, or pilot summary.
Which data classes appeared?	Data owner notes, redaction records, or approval form.
Which systems were connected?	OAuth app list, connector settings, source-system notes.
Which outputs were used externally or operationally?	Customer reply samples, PR references, CRM notes, or publishing review.
Which guardrails were violated?	Incident log, exception register, or manager notes.
Which users want continued access?	Business owner decision, not only user preference.

Collect evidence about the process, not raw sensitive data.

Data and retention review

Data or artifact	Exit check
Public content	Confirm outputs were reviewed before publication.
Internal notes	Confirm sharing stayed within the approved team.
Customer records	Confirm redaction, approval, retention, and downstream sharing.
Source code	Confirm repo scope, secret scanning, PR review, and production boundary.
Meeting transcripts	Confirm notice, storage, retention, deletion, and CRM sync.
Browser page data	Confirm host access and OAuth scopes stayed within approval.
Prompts and files	Confirm retained prompts, files, memories, and projects match the approved policy.
Exports	Confirm exports were approved, stored safely, or deleted.
Secrets or regulated records	Treat as incident or escalation, not normal pilot closure.

For customer workflows, pair this review with the customer data approval form.

Connector and integration review

Integration	Exit check
Email	Mailboxes, labels, attachments, history, and external messages stayed in scope.
Drive or Docs	Folders, shared drives, files, comments, and external sharing stayed in scope.
Slack or Teams	Channels, DMs, files, and history stayed in scope.
GitHub or GitLab	Repos, issues, PRs, actions, and write permissions stayed in scope.
CRM or helpdesk	Customer records, tickets, notes, contracts, and exports stayed in scope.
Calendar or meeting platform	Meeting titles, attendees, recordings, transcripts, summaries, and CRM sync stayed in scope.
Browser extension	Extension ID, hosts, permissions, and OAuth scopes stayed in scope.
API or automation	Keys, scopes, logs, rate limits, and rollback paths are documented.

If any integration expanded during the pilot, decide whether to restrict or escalate before approval.

Incident and output review

Review item	Question
Bad output	Did AI produce inaccurate, unsafe, confidential, biased, or unsupported output?
Human review	Did a person review output before customer, code, record, or public impact?
Accidental paste	Did users paste secrets, customer data, source code, transcripts, or regulated records outside scope?
Connector exposure	Did a connector reveal broader data than expected?
Extension behavior	Did browser permissions or host access change?
Meeting bot mistake	Was a meeting recorded, summarized, synced, or shared incorrectly?
Developer incident	Did AI-assisted code cause a defect, secret exposure, or production issue?
Employee confusion	Did users ask questions that show the policy is unclear?

Every issue should produce either a guardrail change, a restriction, or a removal decision.

Approval conversion checklist

If the tool is approved after the pilot, complete this before calling it standard.

Item	Required state
Owner	Business owner, admin owner, and backup owner are named.
Tool register	Tool is added to the approved/restricted/pilot/blocked register.
Data rule	Allowed, approval-required, and prohibited data classes are clear.
User group	Approved users or groups are explicit.
Settings	Retention, sharing, export, training, connector, and guest settings are recorded.
Offboarding	User, connector, extension, bot, API key, and account removal steps are known.
Incident path	Accidental paste, upload, recording, connector, or secret exposure has an owner.
Review cadence	Next review date is scheduled.
Evidence	Decision evidence is stored outside the AI tool.

Add the final decision to the Small Team AI Security Checklist so it is visible during monthly review.

Removal checklist

If the pilot is removed, close every access path.

Access path	Removal step
Users and admins	Remove users, guests, admins, shared accounts, and personal accounts used for work.
Connectors	Revoke OAuth apps and source-system integrations.
Browser extension	Remove extension install, OAuth app, vendor account, and browser profile access.
Meeting bot	Stop recording, remove calendar app, review transcripts, and apply retention/deletion rules.
Developer AI	Remove repo access, PR bot access, terminal permissions, API keys, and code indexes where practical.
Files and prompts	Delete retained files, projects, memories, exports, or prompt records according to policy.
Automations	Disable scheduled jobs, webhooks, agents, workflow rules, and record-update permissions.
Evidence	Record what was removed and what could not be removed.

If cleanup cannot be completed, keep an exception record open until the remaining risk is resolved.

Decision record

Copy this into the pilot ticket.

AI tool pilot exit decision
Pilot ID:
Tool or workflow:
Review date:
Reviewer:
Business owner:
Admin owner:
Data/source-system owner:
Pilot users:
Approved use case:
Actual use case:
Data classes observed:
Connected systems:
Incidents or near misses:
Benefits observed:
Risks observed:
Decision:
Restrictions:
Cleanup actions:
Standard approval actions:
Next review date:
Evidence links:
Notes:

Do not store raw customer records, source code, passwords, API keys, private keys, regulated records, payroll data, legal files, or private contracts in this record.

Metrics to track

Metric	Why it matters
Pilots started	Shows AI demand.
Pilots closed on time	Shows whether governance has follow-through.
Pilots approved	Shows which workflows deserve standard operating docs.
Pilots restricted	Shows where scope was too broad.
Pilots removed	Shows which requests were not worth the risk or effort.
Pilots escalated	Shows where lightweight review boundaries are working.
Incidents during pilot	Shows whether guardrails need improvement.
Exceptions created from pilots	Shows whether temporary access is becoming normal.
Median time to exit decision	Shows whether pilots are lingering.

If pilots rarely close, stop starting new ones until old decisions are finished.

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: AI tool request intake form template
• Cybergiz: AI tool exception register template
• Cybergiz: Monthly AI tool access review checklist

FAQ

When should an AI tool pilot end?

End it on the review date from the intake form or exception register. For high-risk workflows, use 30 days or less. Medium-risk pilots can often use 60 days. Low-risk public-content pilots can use up to 90 days.

Who makes the exit decision?

The business owner should decide whether the tool is useful enough to keep. The admin owner verifies settings and cleanup. Add the data owner for customer data, the engineering owner for developer AI, and the source-system owner for connectors.

Can we extend a pilot?

Yes, once, if risk stayed within scope and the missing evidence is specific. The extension needs a new expiry date and a short list of questions to answer. Repeated extensions mean the pilot needs standard approval or removal.

What should trigger removal?

Remove the tool if it did not solve the business need, expanded access without approval, exposed sensitive data, caused repeated confusion, cannot be offboarded, or has unclear vendor behavior for the workflow.

What if users strongly prefer keeping the tool?

User preference is useful evidence, but it is not approval. The exit decision also needs data scope, access scope, incident history, offboarding ability, and owner accountability.

How does this connect to monthly review?

Approved, restricted, extended, removed, and escalated pilots should feed the monthly AI tool access review checklist. The monthly review checks whether pilot decisions remain accurate after real usage starts.