checklist
AI chatbot service owner handover checklist for small teams
A practical handover checklist for customer-facing AI chatbots, covering ownership, access, sources, prompts, connectors, tool actions, monitoring, incidents, vendors, pause and fallback, first-week checks, and sign-off.
Use this checklist when responsibility for a customer-facing AI chatbot moves from one person or team to another. It is designed for a small team that needs a usable handover record, not a long architecture document.
Bottom line
A chatbot handover is complete only when the incoming owner can explain the approved use case, data boundary, source and prompt versions, connector and tool permissions, monitoring route, incident path, vendor contacts, pause control, fallback route, and next review date. The incoming owner must be able to change, limit, pause, and recover the service without depending on the outgoing owner.
Run the AI Tool Risk Checker before accepting the handover when the chatbot handles customer data, can call tools, connects to a source system, or has changed scope. Use the Small Team AI Security Checklist for baseline access, data, vendor, and incident controls. This page complements the AI chatbot quarterly governance review scorecard and the AI chatbot access recertification checklist.
Do not put passwords, API keys, private keys, raw customer records, unredacted transcripts, regulated files, private invoices, or dashboard URLs containing tokens into the handover packet. Link to protected systems instead.
When to use this checklist
| Trigger | Handover depth | Required decision |
|---|---|---|
| Service owner leaves or changes role | Full | Transfer service, security, data, and recovery ownership. |
| Chatbot moves from pilot to production | Full | Reconfirm scope, owners, evidence, and launch gates. |
| Vendor, model, or hosting provider changes | Full | Compare the approved baseline with the new service boundary. |
| New connector, tool action, or customer channel is added | Full | Review permissions, downstream authorization, notice, and rollback. |
| Support team takes over an engineering-owned route | Full | Confirm on-call, escalation, and safe change rights. |
| Only a backup owner is added | Light | Test emergency access and record the deputy. |
| Chatbot is being retired | Usually no | Use the AI chatbot retirement decision checklist instead. |
If the incoming owner cannot verify a high-impact control, mark the handover as pending and limit or pause the affected route. Do not turn an unknown into an assumed approval.
Handover intake form
Copy this form into a protected internal record before the meeting.
AI chatbot service owner handover intake
Chatbot and environment:
Business purpose:
Customer channels:
Handover date:
Reason for handover:
Outgoing service owner:
Incoming service owner:
Backup owner:
Technical owner:
Support and escalation owner:
Security or privacy reviewer:
Vendor and support route:
Approved use case:
Out-of-scope requests:
Allowed data classes:
Prohibited data classes:
Approved sources:
Model and prompt versions:
Connectors and tool actions:
Human approval points:
Monitoring and log location:
Incident route:
Pause owner:
Fallback route:
Next review date:
Open incidents:
Open exceptions:
Open changes:
Missing evidence:
Handover decision:
Approver:Before sharing the record, replace private values with protected record links or internal reference IDs.
Ownership map
| Responsibility | Outgoing owner confirms | Incoming owner accepts |
|---|---|---|
| Business purpose | Intended users, value, limits, and prohibited uses. | The purpose and risk tolerance. |
| Service operation | Deployment, configuration, on-call, and support path. | The ability to operate, change, and recover the service. |
| Customer experience | Notice, human handoff, correction, and complaint path. | The route for customer impact decisions. |
| Data and privacy | Allowed data, retention, deletion, exports, and requests. | The data boundary and review responsibility. |
| Sources and prompts | Approved sources, versions, owners, and update rules. | The ability to review and roll back source or prompt changes. |
| Connectors and tools | Effective scopes, downstream roles, approvals, and failures. | The ability to revoke, limit, and test each capability. |
| Monitoring | Signals, samples, alerts, log access, and review cadence. | The monitoring and evidence workflow. |
| Incidents and exceptions | Open records, severity, expiry, and actions. | Follow-up ownership and decision dates. |
| Vendor and billing | Contract owner, support route, renewal, and exit plan. | Vendor review and continuity responsibility. |
| Pause and fallback | Trigger, approver, runbook, and customer message. | The ability to stop safely and restore service. |
- Every row has a named primary owner and backup owner.
- The incoming owner has decision rights, not only read access.
- A separate reviewer can approve high-impact actions or residual risk.
- The outgoing owner has no continuing access unless it is documented and time-bound.
- The team has recorded who can pause the service outside normal business hours.
Service boundary and dependency map
Record the chatbot as a route through systems, not just as a vendor name.
| Boundary | Questions to answer | Evidence to retain |
|---|---|---|
| User and channel | Who can reach it, from which channels, and under which identity? | Channel list and access decision. |
| Model service | Which provider, model family, version, region, and account boundary are used? | Current vendor documentation and approved configuration note. |
| Prompt and policy | Which system instructions, safety rules, and escalation rules are active? | Protected version reference and change record. |
| Knowledge sources | Which data stores, fields, documents, and tenants can retrieval reach? | Source inventory and permission review. |
| Connectors | Which OAuth apps, APIs, webhooks, or extensions are connected? | Scope list, owner, expiry, and revocation path. |
| Tool actions | Can it read, create, update, delete, send, charge, or change account state? | Action inventory and downstream authorization. |
| Logs and exports | What is logged, where is it stored, and who can export it? | Log map and retention decision. |
| Human route | How does a customer reach a person and how is context transferred? | Handoff test and support route. |
| Fallback | What serves customers when the bot is paused or unavailable? | Fallback test and customer-safe message. |
- Draw the request path from customer channel to model, source, connector, action, and response.
- Mark every data store and downstream system that can receive content.
- Separate read, write, delete, export, send, and account-changing capabilities.
- Identify dependencies that the incoming owner cannot currently pause or replace.
- Record the last verified date for each boundary.
Access transfer checklist
| Check | Done | Evidence |
|---|---|---|
| Add the incoming owner through the approved identity provider. | ||
| Add and test a backup owner. | ||
| Confirm MFA and least-privilege roles for owners and admins. | ||
| Review groups, guests, contractors, service accounts, and break-glass identities. | ||
| Remove outgoing owner access when the transition is complete. | ||
| Rotate or reissue secrets through the approved secret manager when required. | ||
| Review source-system grants and downstream roles. | ||
| Verify audit-log and monitoring access. | ||
| Test the incoming owner’s ability to change, pause, and recover the route. | ||
| Run a negative test for removed or expired access. |
Do not copy credentials into this record. A handover is not complete when access has merely been granted; it is complete when the new owner can perform the required control actions and the old access has been verified as removed or justified.
Source, model, and prompt inventory
| Item | Record | Acceptance question |
|---|---|---|
| Model and provider | Version, account boundary, region or deployment, and documented limitations. | Does the current service match the approved route? |
| System prompt | Protected version reference, owner, and last approved change. | Can the team compare and roll back the active prompt? |
| Safety and refusal rules | High-impact topics, refusal behavior, and escalation rules. | Are sensitive requests routed to a person? |
| Knowledge source | Source name, owner, fields, tenant, freshness, and access boundary. | Is retrieval limited to approved content? |
| Evaluation set | Normal, refusal, sensitive, handoff, abuse, and action tests. | Were tests run after the latest material change? |
| Change history | Model, prompt, policy, source, connector, channel, and tool changes. | Does each change have an owner and result? |
| Known limits | Unsupported claims, stale-source conditions, languages, and channel limits. | Can support explain when the bot should not be trusted? |
- Save the current versions as protected references, not raw secrets or customer content.
- Confirm the fixed test set has an owner and a repeatable result format.
- Test source freshness and source conflict handling.
- Test that the bot does not disclose hidden instructions or unrelated source content.
- Record unknowns as handover gaps with an owner and due date.
Connector and tool action inventory
OWASP LLM06:2025 describes excessive agency as excessive functionality, permissions, or autonomy. Treat every connector and action as a separate approval boundary.
| Capability | Minimum evidence | Handover stop condition |
|---|---|---|
| Read source | Source, fields, tenant, identity, scope, and revocation path. | Read access is broader than the approved use case. |
| Create or update | Input fields, downstream policy, confirmation, and result reconciliation. | The model can change records without independent authorization. |
| Delete | Exact object scope, confirmation, recovery, and audit event. | Delete is bundled into a broad extension or cannot be reversed. |
| Export or send | Destination, content review, user authorization, and rate limit. | Raw data can leave without an approval or destination check. |
| Billing or account action | Allowed state changes, approver, and rollback. | A prompt alone can trigger a high-impact state change. |
| Webhook or automation | Retry behavior, duplicate handling, timeout path, and owner. | Unknown results can repeat a side effect. |
| Admin setting | Change owner, independent review, and audit evidence. | One person can change and self-approve a risky capability. |
- Remove unused tools and extension functions before accepting the handover.
- Use the narrowest downstream identity and scope that supports the approved workflow.
- Enforce authorization in the downstream system, not only in the prompt.
- Require a human approval step for high-impact actions.
- Test denied, expired, malformed, retried, and unknown action results.
- Confirm logs include actor context, action, target class, result, and correlation reference.
Monitoring, logs, and incident routing
| Signal | Minimum review | Route if failed |
|---|---|---|
| Access and admin changes | Review new owners, roles, groups, guests, and service identities. | Access owner and security reviewer. |
| Source and retrieval drift | Sample stale, conflicting, denied, and cross-boundary retrieval. | Knowledge owner and service owner. |
| Output quality | Sample normal, refusal, sensitive, correction, and handoff outcomes. | Product, support, and incident owner. |
| Tool actions | Review allowed, denied, retried, failed, and unknown results. | Technical owner and action approver. |
| Data handling | Review retention, export, deletion, redaction, and sharing events. | Privacy or data owner. |
| Abuse and prompt injection | Review attempts to override policy or reach unauthorized actions. | Security owner and incident route. |
| Availability | Review latency, error rate, fallback use, and pause events. | On-call owner and vendor support. |
- The incoming owner can find the logs without receiving raw secrets.
- Log retention and access are documented for the relevant data classes.
- Alerts have a human owner, severity, response target, and escalation route.
- Incident records link to protected evidence and preserve the decision timeline.
- A sample alert was routed to the new owner during the handover.
Vendor and support contacts
| Contact purpose | Record in protected system | Verify during handover |
|---|---|---|
| Product support | Vendor support route and account owner. | The incoming owner can open and track a case. |
| Security notice | Security advisory or incident notification route. | Notifications reach the current owner and backup. |
| Data request | Deletion, export, correction, and privacy request path. | The team knows what evidence and authorization are required. |
| Subprocessor change | Current vendor documentation and review owner. | Changes trigger a route and data-boundary review. |
| Billing and renewal | Procurement owner, renewal date, and cancellation authority. | The service will not renew without an accountable decision. |
| Exit and migration | Export, replacement, and termination contacts. | The team can preserve continuity without extending unsafe access. |
The FTC vendor-security guidance recommends written security expectations, verification, and updates as threats and vendor practices change. For businesses covered by the FTC Safeguards Rule, the rule also addresses qualified oversight, risk assessment, access reviews, monitoring, service providers, change management, incident response, and periodic program updates. The Safeguards Rule applies to covered financial institutions; it is not a universal checklist for every small business.
Pause and fallback readiness
| Trigger | Immediate action | Fallback |
|---|---|---|
| High-impact action cannot be independently authorized | Disable the action, keep read-only or route to a person. | Human queue or manual workflow. |
| Unauthorized data access is suspected | Revoke the affected grant and preserve evidence. | Data-minimized support route. |
| Source poisoning or stale critical content | Disable the source or retrieval path. | Approved static guidance and human escalation. |
| Repeated unsafe or materially wrong answers | Pause the affected use case and notify support. | Human review with a customer-safe message. |
| Vendor outage or security event | Follow incident route and vendor escalation. | Documented alternate channel or manual process. |
| Owner or access transition fails | Stop the transfer and keep the old route time-bound. | Backup owner or controlled maintenance window. |
- Pause authority is assigned to a role that is reachable during the service window.
- Pause steps do not require the model to cooperate.
- Tool actions, connectors, and outbound sends can be disabled separately.
- The fallback gives customers a clear human or delayed-response path.
- A safe pause drill has been run and recorded.
- Restart requires evidence, owner approval, and a limited verification window.
First-week verification
Run these checks after the incoming owner takes responsibility.
| Day | Verification | Pass condition |
|---|---|---|
| 1 | Sign in, find configuration, and locate logs. | Incoming and backup owners can perform the core tasks. |
| 2 | Review users, admins, service identities, and grants. | Unneeded access is removed or tracked with an expiry. |
| 3 | Run source, prompt, refusal, handoff, and sensitive-data tests. | Results match the approved baseline or have an owner. |
| 4 | Review connector and tool actions. | Effective scopes and downstream approvals are understood. |
| 5 | Test monitoring, alert routing, and incident intake. | A test signal reaches the right responder. |
| 6 | Exercise pause and fallback. | The route can stop without model cooperation. |
| 7 | Review gaps and sign off. | Decision, owners, dates, and next review are recorded. |
Do not close the handover because the chatbot remained available for seven days. Close it only when the evidence shows the incoming owner can operate, constrain, monitor, and recover the service.
Handover decision table
| Result | Use when | Required follow-up |
|---|---|---|
| Accepted | Owners, boundary, evidence, and recovery are verified. | Set the next review date. |
| Accepted with follow-up | Gaps are bounded, owned, and time-limited. | Track actions and expiry dates. |
| Restricted | A data, channel, connector, or action boundary is not ready. | Reduce scope and retest. |
| Pending | Evidence or access is missing but service can remain safely limited. | Collect missing evidence before expansion. |
| Paused | A high-impact control failed or cannot be verified. | Use fallback and complete incident or remediation review. |
| Escalated | Risk or impact exceeds the incoming owner’s authority. | Obtain an accountable decision from the designated approver. |
| Rejected | The route cannot meet the approved boundary or recovery requirement. | Replace, redesign, or retire the service. |
The handover decision is an operating control, not a judgment about the outgoing owner. Record the reason and evidence for every result.
Sign-off record
AI chatbot service owner handover record
Chatbot and environment:
Handover date:
Outgoing owner:
Incoming owner:
Backup owner:
Technical owner:
Support owner:
Data or privacy owner:
Security reviewer:
Approved use case:
Current data boundary:
Current sources and prompt versions:
Connectors and tool actions reviewed:
Monitoring and incident route tested:
Pause and fallback tested:
Open incidents:
Open exceptions:
Open remediation actions:
Next review date:
Decision: accepted / accepted with follow-up / restricted / pending / paused / escalated / rejected
Approver:
Evidence location:Action tracker
| Finding or action | Risk | Owner | Due date | Evidence | Status |
|---|---|---|---|---|---|
| High / Medium / Low | Open / In progress / Done | ||||
| High / Medium / Low | Open / In progress / Done | ||||
| High / Medium / Low | Open / In progress / Done |
- Every action has one accountable owner.
- High-risk actions have a shorter due date or a documented temporary control.
- Actions that change scope, data, permissions, or tools are linked to a change record.
- Exceptions have an expiry and renewal decision.
- Closure evidence is specific enough for another reviewer to reproduce.
Final handover checklist
- Business purpose, users, channels, and prohibited use are current.
- Primary and backup owners have the required decision rights.
- Outgoing access is removed or explicitly time-bound.
- Sources, prompts, models, and fixed tests are inventoried.
- Connectors and tool actions use minimum necessary scope.
- High-impact actions have downstream authorization and human approval.
- Data, retention, export, deletion, and sharing rules are documented.
- Monitoring, logs, alerts, and incident routing are tested.
- Vendor support, security notice, renewal, and exit paths are current.
- Pause and fallback controls work without model cooperation.
- First-week verification has an owner and completion date.
- Decision, evidence location, open actions, and next review are recorded.
Metrics to track
| Metric | Why it matters |
|---|---|
| Chatbots with named primary and backup owners | Shows whether responsibility survives turnover. |
| Handover records completed on time | Shows whether ownership changes are controlled. |
| Handover records with unknown boundaries | Shows where inventory and evidence are weak. |
| Connectors or actions removed during handover | Shows hidden excess capability. |
| Access grants removed or recertified | Shows whether effective access was reviewed. |
| First-week verification completion | Shows whether transfer was tested in operation. |
| Pause and fallback drill success rate | Shows whether the team can contain failure. |
| Open handover actions past due | Shows whether ownership changed without closing gaps. |
Track trends by route and risk level. A high completion rate does not prove that the chatbot is safe if the team is not testing the data boundary, authorization, and recovery path.
Evidence checked
- NIST AI RMF Core describes govern, map, measure, and manage functions, including documented roles, inventory, periodic review, monitoring, incident response, recovery, and deactivation responsibilities.
- NIST AI RMF Manage Playbook provides implementation-oriented guidance for prioritizing risk, documenting residual risk, monitoring third-party components, and assigning responsibilities for disengaging or deactivating systems.
- FTC Safeguards Rule guidance describes requirements for covered financial institutions, including qualified oversight, risk assessment, access reviews, inventories, MFA, monitoring, service-provider oversight, change management, and written incident response.
- FTC vendor security guidance recommends written vendor expectations, verification, and updates as threats and vendor practices change.
- OWASP LLM06:2025 Excessive Agency recommends minimizing extensions, functionality, permissions, and autonomy; enforcing downstream authorization; requiring approval for high-impact actions; and logging and rate limiting activity.
These sources support the control principles. They do not certify a specific chatbot, vendor, or business as compliant.
FAQ
Is a chatbot handover the same as an admin transfer?
No. An admin transfer covers access to a console. A service handover also covers business purpose, customer impact, data boundary, prompts, sources, connectors, tool actions, monitoring, incident response, vendor support, pause, fallback, and decision rights.
Should the outgoing owner keep access for continuity?
Only when there is a documented business need, least-privilege role, named approver, and expiry or review date. Otherwise remove the access and verify removal. Keeping a former owner as an informal backup is not a recovery plan.
What if the new owner cannot understand a connector?
Do not accept the connector as-is. Disable or restrict it when safe, record the gap as an exception or remediation action, and require a source, scope, identity, downstream authorization, and revocation path before expansion.
Does a human approval step make a tool action safe?
No. It is one control. The downstream system still needs authorization, minimum scope, input validation, logging, and a recovery path. The approval should be tied to the actual user, action, target, and data boundary.
How much evidence should a small team collect?
Collect enough to reproduce the decision without copying sensitive content: redacted test results, configuration references, access review results, action scopes, monitoring evidence, incident and exception IDs, vendor answers, and the signed decision record.
Does the FTC Safeguards Rule apply to every company using a chatbot?
No. The FTC guidance describes the rule for covered financial institutions under its jurisdiction. Other businesses may still use the same risk-management ideas, but they should determine which laws, contracts, and sector rules actually apply to them.
When should the team pause the chatbot?
Pause the affected route when a high-impact action lacks independent authorization, a sensitive data boundary is uncertain, access cannot be revoked, monitoring is unavailable during a known incident, or the fallback cannot protect customers. Record the reason and use a human or data-minimized fallback.
What should happen after the handover is signed?
Run the first-week verification, close or assign every gap, update the tool inventory and review calendar, and schedule the next review. A signed record without operational verification is only an acknowledgement, not a completed handover.