What You Actually Own When an AI Consultation Ends

The artifacts that should be yours

A finished engagement should leave physical things behind, not just a changed state of affairs. If you cannot point at them, you rented an outcome rather than bought an asset.

• The running automations themselves, in accounts you own and can log into.
• The prompts and their version history — these are the actual logic and they get tuned over time.
• Integration credentials and API connections registered to your organisation, not the consultant's.
• The data the system produced and consumed, exportable in a standard format.
• Documentation of what each piece does, why it was built that way, and what breaks it.
• The baseline measurements taken before the work started, so the result stays provable.

Accounts are the one that quietly goes wrong

This is the most common ownership failure and it rarely comes from bad intent — it comes from convenience. It is faster for the consultant to build inside their own automation platform account, their own API keys, their own workspace. Everything works. The system runs. Then the relationship ends and you discover the thing your operations depend on lives somewhere you cannot reach.

The fix is to specify it up front and it costs nothing at the start: every account is created under your billing and your domain, and the consultant is added as a user. If that is agreed at kickoff it is a non-issue. Raised in month four, it becomes a migration project.

Ownership and handover are settled at the scoping stage, which is part of an AI consultation rather than an afterthought at the end of a build.

The walk-away test

Ask this directly during the sales conversation: if we ended this tomorrow, what specifically stops working, and what would we need to do to keep it running?

A good answer is concrete and slightly uncomfortable. It names the pieces that need maintenance, the accounts you would need to take over billing on, and the tasks that currently only they know how to do. A bad answer is reassurance without specifics. The point is not to catch anyone out — it is that a consultant who has thought about the handover has usually built differently from one who has not.

Documentation that is usable versus documentation that exists

Almost every engagement produces a deck. Very few produce documentation someone could actually operate from. The difference is whether it was written for the person approving the invoice or for the person who will get the alert at 7am when something fails.

The test is simple and you should apply it before final payment: hand the documentation to someone on your team who was not in the meetings, and ask them to make a small change — adjust a rule, add a field, change who gets notified. If they can, it is documentation. If they need a call, it is a deck.

Who owns the logic

Consultants reuse patterns. That is not a problem — it is why hiring one is faster than working it out yourself, and you should be suspicious of anyone claiming every engagement is invented from nothing. What matters is the distinction between their general method and your specific implementation.

The reasonable position, and the one worth writing down: they keep their frameworks and general approach; you own the configured system, the prompts written for your processes, your data, and the documentation. Anything more aggressive in either direction is a warning sign. A consultant demanding ownership of your configuration is holding your operations hostage; one who signs away their entire methodology has probably not thought about it.

Red flags

Any one of these is worth a direct conversation before signing.

• Systems that only they can log into, described as "managed for you".
• No export path for the data the system accumulates.
• Prompts treated as proprietary and not shown to you.
• Documentation promised at the end rather than produced as the work goes.
• A monthly fee whose scope is never defined beyond "support".
• Reluctance to answer the walk-away question with specifics.

Ownership does not mean going it alone

None of this argues against an ongoing relationship. Systems need tuning, models change, and processes evolve. The distinction is whether you continue because it is worth it or because you have no alternative. Those produce very different incentives on both sides.

An engagement that ends with you genuinely able to walk away, and choosing not to, is the healthy version. That is the arrangement worth asking for.