Your business should know who legally owns the deliverables, who controls each account and data source, who may edit the workflow, and who will keep it running after the consultant leaves. Paying an invoice does not automatically answer every intellectual-property, licensing or access question. The signed agreement and third-party platform terms matter.

Practical guide: Use the examples and templates below as starting points. Adjust them to your client, industry, risk and contractual obligations.

The short answer: ownership must be explicit

Your business should know who legally owns the deliverables, who controls each account and data source, who may edit the workflow, and who will keep it running after the consultant leaves. Paying an invoice does not automatically answer every intellectual-property, licensing or access question. The signed agreement and third-party platform terms matter.

Ownership is not one switch. Separate legal rights in custom work, access to platform accounts, custody of data, rights to reusable templates, and operational responsibility. A business can own its data while still depending on a vendor’s proprietary software. Clarify these distinctions before work begins, not during an emergency handover.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—the short answer: ownership must be explicit—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

1. Accounts and subscriptions

List every AI provider, automation platform, cloud service, integration, database and monitoring tool used in the solution. For each, record the account owner, billing entity, administrative users, renewal date, plan restrictions and support contact. Wherever practical, the business should create and control its own production accounts and grant the consultant appropriately limited access.

If a workflow is running under the consultant’s personal subscription, ask how it will be transferred and what breaks when that subscription ends. Some services do not permit simple transfers. Test the exit process before relying on it. Never exchange passwords in ordinary email as a substitute for proper account administration.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—1. accounts and subscriptions—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

2. Data and records

Identify where customer information, uploaded files, prompts, outputs, logs, embeddings and backups reside. Document retention and deletion rules, export formats and whether third-party providers can access or reuse the data under the chosen plan. Confirm which records the business can retrieve and which it cannot.

A successful handover includes a data inventory and access verification. The consultant should not retain customer datasets or unrestricted copies after the engagement unless there is a clear, lawful and documented reason. Privacy obligations depend on jurisdiction, industry and contracts, so seek qualified advice when necessary.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—2. data and records—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

3. Workflows, code and reusable components

Ask what exactly is being transferred: diagrams, prompts, scripts, integration configurations, test cases, documentation and deployment files. Distinguish bespoke client work from the consultant’s pre-existing tools, licensed templates, open-source dependencies and third-party software. A contract should specify rights to use, modify, reproduce and maintain each category.

A business may not need exclusive ownership of every reusable component. It does need sufficient rights and practical access to operate and maintain the solution. If the consultant reserves rights to an underlying framework, document the license and what happens if the relationship ends.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—3. workflows, code and reusable components—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

4. Administrative access and secrets

Maintain a role-and-permission matrix. Record who can change prompts, connectors, deployment settings, billing and data exports. Use organization-managed identities, least privilege and separate service accounts where supported. Store secrets in an appropriate secrets manager rather than in documents or source code.

At handover, review every external collaborator, API key, webhook secret and token. Rotate or revoke access no longer needed, and verify the automation still runs. Avoid immediately disabling an unknown account without understanding dependencies; plan the transition, test and then remove privileges.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—4. administrative access and secrets—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

5. Documentation that a replacement can use

Require a plain-English architecture diagram, workflow purpose, trigger conditions, inputs and outputs, dependencies, exception handling, monitoring instructions, test procedures, change history and rollback steps. Include the exact location of editable files and configuration settings. A video walkthrough can help but should not replace written instructions.

Ask a staff member who was not involved in the build to follow the runbook in a safe test environment. If they cannot explain how to pause the workflow or identify a failed job, the handover is incomplete. Documentation quality is part of delivery, not an optional courtesy.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—5. documentation that a replacement can use—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

6. Maintenance and incident responsibility

An automation needs someone to monitor failures, update integrations, evaluate model changes, review costs and respond to security incidents. Name the business owner and technical maintainer. Agree on response expectations and whether post-project support is included, separately billed or not offered.

A system can fail when an API changes, a connected account loses permission, a model’s behavior shifts or the source data format changes. A realistic maintenance plan covers these ordinary events. If the business cannot maintain the system, consider a support contract or a simpler workflow.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—6. maintenance and incident responsibility—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

7. Vendor lock-in and exit costs

Some integrations can be recreated easily; others depend on proprietary connectors, stored embeddings, specialized prompt orchestration or vendor-specific automation formats. Ask what can be exported, in what format and at what cost. Identify which parts would require rebuilding on another platform.

Avoid treating all vendor dependence as unacceptable. The question is whether the dependence is understood, priced and appropriate for the business. A low-cost tool with a clear manual fallback may be sensible; a mission-critical workflow with no export route deserves closer scrutiny.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—7. vendor lock-in and exit costs—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

8. A handover acceptance test

Run through the workflow using business-owned accounts. Confirm an authorized employee can view logs, change approved settings, pause execution, restore manual operation and contact vendor support. Test at least one ordinary exception and one failure scenario. Confirm subscription billing and renewal notices reach the right person.

Use a checklist with evidence links and sign-off. An unchecked box should identify a specific outstanding task, owner and due date. Do not sign off solely because the consultant sent a ZIP of code or a diagram; operational control must be demonstrated.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—8. a handover acceptance test—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

Worked example: fictional small business

Fictional example: Meadowbrook Design Studio hires a consultant to automate lead intake and draft appointment confirmations. During handover, the owner discovers the workflow is hosted in the consultant’s personal automation account and uses an API key charged to the consultant’s credit card. The solution works, but the business does not yet control it.

The parties create organization-owned accounts, rebuild or transfer the workflow as platform terms allow, rotate credentials, document dependencies and test the process end to end. Only then does the studio accept final delivery. This example illustrates a preventable operational dependency; it does not describe a real customer or legal dispute.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—worked example: fictional small business—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

Contract questions to ask before signing

Who owns custom code and written deliverables? Which pre-existing components remain licensed? Who is the customer of record for software subscriptions? Where is data stored and how is it deleted? Who controls admin access? What documentation is required? What support is included? How are security incidents reported? What happens if the consultant is unavailable? What export or transition assistance is included and at what rate?

Put answers in the statement of work and relevant legal agreements. Avoid vague promises such as “full ownership of the AI.” Ownership of a workflow, underlying model, output, data and platform are different questions. Contract language should match the actual technical architecture.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—contract questions to ask before signing—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

Reusable exit checklist and sources

Before final payment: [ ] inventory every account and integration; [ ] confirm business-owned billing; [ ] transfer editable files; [ ] verify data exports and retention; [ ] document licenses; [ ] test administrator access; [ ] rotate or revoke consultant credentials; [ ] run an exception test; [ ] rehearse pause and rollback; [ ] assign monitoring and maintenance; [ ] confirm support and renewal contacts; [ ] record written acceptance.

Use NIST’s Cybersecurity Framework for governance and access concepts, and CISA’s practical security guidance for account security basics. For related decisions see our AI consultant hiring guide, proposal template and deliverables guide.

Apply this in practice

Before moving on, write down how this applies to the specific workflow you are evaluating. Identify the person who can verify your assumptions, the evidence you would ask them to provide, and the decision that evidence would support. Keep a record of what you know, what you have only estimated, and what remains unresolved. For this step—reusable exit checklist and sources—make sure the next action is concrete enough that another person could complete it without guessing what you meant.

For additional guidance, see the AI Consulting Resource Library, AI consulting services and small-business AI governance guides.