← All Field Notes

Data ownership

Who owns the data and knowledge in an AI implementation?

The practical architecture, access, contract and handover choices that help a business retain control of its data, workflows and operating knowledge.

The short answer

The client business should retain control of its source data, client-specific workflows, prompts, rules, documentation and derived operating knowledge. That outcome is not automatic: it must be established through contracts, account ownership, access controls, exportability, retention rules and a documented handover. Vendor platform terms still need to be checked separately.

The valuable asset is more than raw data

An implementation learns how the business actually works: its terminology, exception rules, decision thresholds, customer patterns and the relationships between systems. That connected context is operating knowledge. It can become a genuine advantage because generic software does not arrive with it.

If the knowledge only exists inside an agency account or a black-box workflow, the business has funded an asset it cannot properly control. Ownership needs to cover the configuration and documentation around the data, not only the original records.

Make control concrete

‘You own your data’ is too vague on its own. A robust implementation specifies where information is stored, who administers each account, which people and services can access it, how long temporary copies remain, what can be exported and what happens when the engagement ends.

  • Use client-controlled production accounts wherever practical.
  • Grant the implementation team the minimum access required and record when it is removed.
  • Separate reusable agency components from client-specific data, rules and configurations.
  • Document retention, deletion, backups and incident responsibilities.
  • Provide exports, operating documentation and credentials through a formal handover.
  • Check each platform’s terms for data use, model training and portability.

Use temporary infrastructure deliberately

During diagnosis, it may be useful to create a temporary connected data plane or dashboard. Temporary should be the default unless the business chooses to retain it or proceed into implementation. The purpose, access, retention period and deletion date should be agreed before data is connected.

Treat the handover as part of the build

A handover is not a final meeting. It is a tested operating state: the business has administrative access, the workflow can be monitored, exceptions reach the right person, key decisions are documented and a new provider could understand the system without reverse-engineering it. Ongoing support can remain available without becoming structural dependency.

Working principle

The business should finish with more usable knowledge and control than it had before—not a new dependency disguised as automation.