Who Owns Your AI Prompts, Memory and Data? A Company Guide

A company should own the instructions it writes, the business knowledge its agent accumulates, the records of what the agent did, and the configuration that connects it to company systems. The underlying AI model normally stays with its provider, and the contract decides everything else. Ownership only counts if you can export these assets in a form someone else can read and reuse, so test the exit before you need it.

Key takeaways

• Ownership on paper is different from control in practice. Ask what you can export, in what format, and how long it takes.
• Prompts, memory, logs, integrations and configuration are separate assets, and each needs its own answer in the contract.
• Memory deserves the closest attention because it grows over time and can hold both business knowledge and personal data.
• Accounts, credentials and permissions should sit in the company's name, so the company can revoke or move them without asking anyone.
• Run an export test early and repeat it at every review. An export nobody has tried is an assumption.

What does it mean to own part of an AI setup?

An AI setup is not one object. There is a model, supplied by a provider. Around it sits a working layer that holds instructions, memory, tool connections, permissions and approval rules. On top of that sit the records the system produces as it works. Each layer can have a different owner, and each can be locked in or portable.

It helps to separate three tests. The first is the legal right: who is entitled to the material under the contract. The second is possession: who holds a working copy today. The third is usability: could another competent team pick it up and run it? A company that holds the legal right to a pile of files it cannot read has weak ownership. A company that has a clean, readable copy but no clear right to use it has a different problem.

The practical goal is simple. If you changed vendors, or brought operations in house, you should lose the vendor's service but keep the knowledge, the rules and the history of your own agent.

Prompts and instructions: who owns the wording?

Instructions are the written description of how your company wants work done: tone, definitions, what to do when information is missing, when to stop and ask a person. That is company knowledge, even if a vendor helped phrase it. You should expect to own it, receive it as plain text, and see its change history.

There is a fair distinction to make. A vendor may reuse general scaffolding across customers, such as a template for handling tool errors. What belongs to you is the content that describes your business: your policies, your terms, your escalation rules, your customer categories. Ask the vendor to separate the two in writing, so you know which parts are yours.

Two habits keep instructions truly yours. First, store them in a place your team can read without a vendor login. Second, write them so that a new person can maintain them, which is the subject of How to keep AI agent instructions maintainable. Instructions buried in a single long block, with no owner and no history, are technically exportable and practically useless.

Memory: the asset that grows quietly

Memory is where ownership questions get hardest, because nobody decides to create it in one moment. It accumulates. Preferences, past decisions, customer facts and working notes build up as the agent runs. AI memory vs chat history explains why memory should be a curated record and not a pile of old conversations.

For ownership, ask these questions about memory:

• Can your team read every entry, in plain language?
• Can you edit or delete a single entry, and does deletion reach backups and indexes?
• Does each entry record where it came from, so you can judge whether to trust it?
• Is memory separated by client, team or role, so one group's knowledge does not leak into another's?
• Can you export the original text and its metadata, not only a processed version?

The last point matters more than it looks. Many systems turn text into numerical representations (embeddings) so it can be searched. Those representations are tied to the model that produced them, so they are not a portable copy of your knowledge. The source text is. Make sure the contract and the export cover source text, structure and metadata.

Memory also touches data protection. If it contains personal data, deletion requests, access requests and retention limits apply to it as they would to any other store. In Brazil, the national authority is the [ANPD](https://www.gov.br/anpd/pt-br), and other jurisdictions have their own regulators. Have counsel confirm the obligations for your case, and make sure your vendor can actually carry out a deletion in memory. For multi-client setups, Client data isolation for AI agents: a practical checklist covers the separation side.

Logs, integrations and configuration: the assets people forget

Logs are the record of what the agent received, which tools it called, what it proposed, what a person approved and what actually happened. You need them for audits, for disputes, for debugging and for evaluating whether the agent is improving. Observability practice distinguishes signals such as logs, traces and metrics, as described in the [OpenTelemetry observability primer](https://opentelemetry.io/docs/concepts/observability-primer/). Ask which of these you receive, how long they are retained, whether sensitive fields are redacted, and whether they can be exported in an open, documented format.

Integrations are the connections to your email, calendar, CRM, messaging channels and internal tools. The ownership question is whose account holds the connection. When access is granted through a standard authorization flow such as [OAuth 2.0](https://developers.google.com/identity/protocols/oauth2), the grant is tied to an account and to specific permissions. If the grant sits under the vendor's account, leaving means rebuilding every connection and re-approving every permission. If it sits under yours, you can revoke it in one place and reissue it to someone else.

Tool definitions matter too: the description of what each tool does, what it accepts and what it returns. Open approaches such as the [Model Context Protocol](https://modelcontextprotocol.io/docs/getting-started/intro) describe a common way to connect AI applications to tools and data, which can make those definitions easier to carry from one setup to another. Whether a given vendor uses it is something to ask, not assume.

Configuration is everything else that shapes behavior: permission levels, approval rules, schedules, routing, channel settings, which actions are drafts and which are sends. It is often undocumented because it lives in settings screens. It should exist as a readable description that someone could follow to rebuild the setup.

A checklist to use before you sign or renew

This list turns the sections above into questions you can put to a vendor, or to your own team if you built the setup. For a wider set of contract questions, see Questions to Ask an AI Agent Vendor Before You Sign the Contract.

• Instructions: Do we own the company-specific content? Do we receive it as plain text with version history?
• Memory: Can we read, correct, delete and export entries, including source text and metadata?
• Logs: What is recorded, how long is it kept, and in what format can we export it?
• Integrations: Are connections made under accounts we own? Can we revoke each one ourselves?
• Credentials: Who holds secrets and tokens, and how are they rotated or removed at exit?
• Configuration: Is there a readable description of permissions, approval rules and schedules?
• Personal data: Who is responsible for access and deletion requests, and how fast can they be carried out?
• Exit: What is delivered when the engagement ends, in what form, by when, and what is deleted on the vendor side afterward?
• Test: Have we performed a trial export and had someone outside the vendor read it?

The final item is the one that turns a promise into evidence. Pick a modest sample, such as one workflow's instructions, a slice of memory and a week of logs, and ask a person who did not build the system to confirm they can understand it.

Illustrative scenario: changing providers

This scenario is illustrative, not a description of a real engagement. A small services firm runs an agent that prepares customer follow-up drafts. After some time, the firm decides to move operations to a different provider.

In the first version of this story, the instructions live inside the vendor's dashboard, memory is stored only as processed search data, connections run under the vendor's accounts, and the only logs are a short on-screen history. The firm can leave, but it starts almost from nothing. It has to rewrite the instructions from recollection, rediscover customer preferences, and re-authorize every tool.

In the second version, the firm holds a plain-text copy of the instructions with history, a readable memory export with sources, logs in a documented format, and connections under its own accounts. The new provider reads the material, rebuilds the tool connections, runs the old test cases against the new setup and compares results. Some behavior will still differ, since models differ, but the company's knowledge and rules travel with it. A golden test set is what makes that comparison possible, which is one more reason to keep it as a company asset.

How Be Human handles ownership

Be Human designs the setup so that its important parts are readable documents the company can receive: the role definition, instructions, memory content with its sources, tool descriptions, permission levels and approval boundaries. Connections are intended to be made through the company's own accounts, with the smallest permissions the role needs, so the company can review or revoke them. Managed operations include monitoring, recurring evaluations, permission review and controlled changes, and each change is recorded so the company can see how the setup evolved. Export terms, retention and deletion are agreed as part of the engagement scope instead of being left to the end.

Frequently asked questions

Do we own what the AI model generates for us? This depends on the provider's terms and on the law where you operate, and both are changing, so confirm it with counsel and in the contract. In practice, ask the vendor to state in writing that outputs produced for your workflows are yours to use, and keep the records that show where each output came from.

Can a vendor keep using our data to improve its own products? It can only do so if the contract allows it, so look for explicit language on training, reuse and retention. Ask separately about prompts, memory content and logs, because vendors sometimes treat them differently. If the answer is unclear, treat it as not permitted until it is written down.

Is it enough to export a copy of the chat history? No. Chat history shows what was said, but it does not capture the rules the agent follows, the curated memory it relies on, the permissions it holds or the connections it uses. A useful export lets another team reproduce the behavior, not only read the conversation.

What should we do if we built the setup ourselves? The same questions apply to your own team. Store instructions and configuration in a shared, versioned place, keep connections under company accounts, and document who can change what. Ownership also fails when the knowledge lives only in one person's head, and Build, Buy or Managed AI Agents: A Decision Framework can help you decide how much of the upkeep to keep in house.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.