Who Owns the AI System a Consultant Builds? Code, Prompts, Evals and Accounts

Why AI systems have more to own than code

A statement of work for an AI project usually names the code as the deliverable, the way it would for any software project. A working AI system is rarely just code, though — the list below shows what else is easy to leave off.

• Code and configuration — the application logic, integration glue, and settings.
• Prompts and eval sets — the instructions given to the model and the test cases used to check its output before and after changes.
• Data and fine-tunes — any reference or training data your organization supplied, and any model weights or adapters tuned on it.
• Accounts and keys — the cloud, model-provider, and billing accounts the system runs under, and the credentials that authenticate to them.
• Runbooks and documentation — the operating instructions a new team would need to run the system without the consultant.

Check whether your contract template names the AI-specific assets above, not just code. The matrix below is a way to confirm every one of them has a named owner before you sign, not after the consultant has moved on to the next engagement.

The ownership matrix

Use this with whoever drafts or reviews the statement of work: for each asset, decide who should hold it, and copy the wording idea into the contract.

Treat every row as a position to negotiate into the contract, not an assumption to leave unwritten. A consultant may push back — a fine-tune trained partly on their own base recipe, for instance — so have that negotiation before signing, not after.

Accounts, keys and billing

The fastest way for a consultant to start work is to use accounts they already have: their own cloud account, their own model-provider organization, their own API keys. It's also the arrangement most likely to leave you dependent on them, because the account holder controls billing, access, and who gets a key.

AWS's own security guidance tells account holders to protect root credentials: ^[1] "When you create an AWS account, you establish root user credentials to sign in to the AWS Management Console. Safeguard your root user credentials the same way you would protect other sensitive personal information." If that account belongs to the consultant, you don't control it.

• Open cloud and model-provider accounts in your organization's name before the engagement starts, not after it ends.
• Add the consultant's staff as members with a scoped role, rather than working under their personal or company account.
• Keep a named internal owner who can see billing, membership, and key inventories at any time, not only at handover.

OpenAI's platform documentation separates roles too: it describes the Owner role as able to ^[2] "modify billing information" and "manage members within the organization" — permissions your organization should hold, with the consultant's staff added as members. The same guidance suggests separate projects for staging and production so you can ^[2] "limit user access to your production project, and set custom rate and spend limits per project" — worth requiring regardless of provider.

Anthropic's Admin API documentation describes a similar split: ^[3] "Organization owners and primary owners have all admin permissions and can also manage admins." That role belongs to a named person inside your organization, not the consultant.

Prompts, eval sets and data

Treat prompts and eval sets as deliverables by naming them in the contract, the same way you'd name code. They're easy to leave off a list because they don't look like a deliverable: a prompt often lives in a chat history or config file, and an eval set can sit inside a tool the consultant already had a license to.

• Every production prompt and system instruction, exported in a plain-text or version-controlled format you can read without the consultant's tooling.
• The evaluation set itself — inputs, expected outputs or scoring rubric, and the method used to run it — in a format you can re-run independently.
• A short data-lineage note for any reference data or fine-tune: what was supplied, what was derived, and what stays with the vendor, if anything does.

Fine-tuned models and adapters follow the same logic: name the artifact, the base model, and the training method, and say who holds the weights. A fine-tune trained on your process is hard to maintain or retrain if only the consultant can reproduce it.

What to put in the statement of work

A statement of work that only lists "the AI system" as a deliverable leaves every asset in the matrix open to interpretation. The clauses below turn the matrix into wording to adapt for your statement of work.

1. List every asset from the ownership matrix by name in the deliverables section — code, prompts, eval sets, data notes, fine-tunes, and documentation — not one line covering "the system."
2. State when ownership or license rights transfer: on delivery, on acceptance testing, or on final payment, and make that trigger explicit.
3. Require that cloud and model-provider accounts are provisioned under your organization's own name, with the consultant added as a member for the engagement's duration.
4. Require that API keys and other secrets are created inside those client-owned accounts, never reused from the consultant's personal or company accounts.
5. Set a documentation deliverable — runbooks, architecture notes, and known limitations — due before final sign-off, not promised for "later."
6. Add a post-engagement clause: the consultant's access is removed and keys rotated within an agreed window after handover is confirmed, not left open indefinitely.

See how AI agent implementation handles scope, acceptance and handover.

Checking ownership at handover

A signed contract states intent; handover is where you confirm it matches reality. Work through the matrix again at handover, this time checking access rather than wording, and resolve anything a consultant could still gate.

1. 01
   Confirm account ownership

   Log into the cloud and model-provider accounts yourself, as an owner or admin, not through a shared or delegated session.

2. 02
   Audit membership

   List every member and role on each account and workspace; remove any access the consultant's staff no longer need.

3. 03
   Rotate every key

   Issue new API keys and secrets from inside the client-owned account, and revoke any key created under the consultant's own account or personal login.

4. 04
   Export prompts and eval sets

   Pull the current production prompts and the evaluation set into a format you can open and re-run without the consultant's tooling.

5. 05
   Check the fine-tune or adapter

   If one exists, confirm you hold the artifact itself, not just access to run it through the consultant's account.

6. 06
   Read the runbook end to end

   Have someone who wasn't on the build team follow it to perform one routine task, to confirm it's usable without the people who wrote it.

7. 07
   Confirm nothing is single-threaded through the consultant

   Check for any login, key, or account that only the consultant's staff can access — that's the clearest sign of vendor lock-in left over from the build.

That last step is the practical answer to avoiding AI vendor lock-in: it isn't a clause you write once, it's a check you repeat until nothing in the system depends on credentials only the consultant holds.

When this checklist doesn't apply

• You're subscribing to a vendor's hosted product, not commissioning a custom build — ownership terms live in the vendor's standard agreement, not this matrix.
• The engagement is a short, throwaway prototype with no production go-live planned — negotiate ownership before the system goes into production, not for a prototype you'll discard.
• You're contributing to or adopting an open-source project as-is — review its license separately; this matrix is for commissioned work.
• Your organization already has a standard master services agreement that names these assets — check it against the matrix instead of renegotiating from scratch.

Frequently asked questions

Related reading

• Vetting a firm before you sign at all: questions to ask an AI consulting firm.
• How a build like this is scoped and staged with a deliverables list from the start: AI agent implementation.
• Building the internal capacity to run what you now own: AI operations and enablement.
• Scoping the pilot that precedes a build like this: how to scope an AI automation pilot.
• What the system costs to run once you own it: what an AI agent really costs.

Sources

1. Amazon Web Services, "Security best practices in IAM" (retrieved 2026-09-29) (accessed 2026-09-29)
2. OpenAI, "Production best practices" (retrieved 2026-09-29) (accessed 2026-09-29)
3. Anthropic, "Admin API" (retrieved 2026-09-29) (accessed 2026-09-29)