When a team launches an AI agent, most of the attention goes to quality and cost. A quieter question usually stays open: whose is the work the agent produces, and what are we allowed to give it in the first place? The answer affects what you can publish, what you can reuse, what you can promise customers and what you must be able to delete.
This article is not legal advice, and it does not tell you what the law says in your country. Rules differ by jurisdiction and change over time. What it offers is an operating checklist: the things a company can decide, write down and check without waiting for a dispute. Where a point needs a professional opinion, it is phrased as a question for your lawyer.
Start with the two directions
There are two separate flows, and mixing them up is the most common source of confusion.
- Inputs are what goes into the agent: prompts, uploaded documents, customer messages, internal data, third-party material.
- Outputs are what comes out: answers, drafts, summaries, images, code, records written into your systems.
Each direction raises different questions. Inputs are mostly about confidentiality, personal data and permission to use material. Outputs are mostly about ownership, reuse and responsibility for what is in them. Give each its own section in your internal rules.
What the vendor contract should say
Your contract with the AI vendor, and with any platform the agent runs on, is the first place to look. Read it with four questions, and mark every answer as clear, vague or missing.
- Who may use your inputs? Can the vendor keep them, review them, or use them to improve its own models? Is that the default, or something you can switch off? Does the answer differ between consumer and business plans?
- Who holds rights in the outputs? Some contracts assign output rights to the customer, some grant a licence, some say nothing. "Say nothing" is a finding.
- What happens when you leave? Can you export your configuration, your instructions, your conversation records and your knowledge base in a usable form? Is your data deleted, and can you get confirmation?
- Who answers if an output infringes someone else's rights? Some vendors offer protection under conditions, such as using only approved settings. Others exclude it entirely. Check the conditions, because they are often operational: a switched-off filter or an unapproved plug-in can void the cover.
If you are also comparing vendors, these questions fit naturally next to the ones in questions to ask an AI agent vendor before signing and the wider look at vendor contracts, SLA, liability and exit.
Outputs: ownership is not the only question
Companies tend to ask "do we own it?" and stop there. In practice, four questions matter.
Can we use it freely? Even with a favourable contract, an output may resemble existing material. For text that is merely functional, such as an internal summary, the risk is low. For anything you publish under your brand, such as marketing copy, images or code you distribute, the risk and the consequences are higher.
Can we stop others copying it? Whether and how protection applies to material generated largely by a machine is an open and jurisdiction-specific question. If exclusivity matters to you, for example for a logo, a product design or a key piece of software, do not assume it. Ask your lawyer, and consider keeping a record of the human contribution: who wrote the brief, who selected, edited and approved.
Who is responsible for the content? Whatever the contract says about ownership, your company is the one that sends the answer to the customer. An agent that quotes a wrong price or repeats a claim it cannot support is your problem, not the vendor's. Responsibility stays with a named human owner.
Can we prove where it came from? Keep enough records to show that a piece of content was produced by the agent, with which instructions and sources, and who approved it. This helps in disputes and also in simple internal questions such as "why did the agent say that?"
What must not go into the agent
Write one list that everyone can read in a minute. Three groups work well.
- Allowed. Public information, your own published material, and generic work that contains nothing sensitive.
- Allowed only in a protected setup. Internal documents, customer records and personal data, but only in an agent configured for that purpose, with access limits, retention rules and a vendor contract that covers it. See data handling and retention for customer data for the controls behind this.
- Never. Passwords and keys, special categories of personal data unless there is a specific, approved reason, material covered by a confidentiality agreement that does not permit this use, trade secrets you could not afford to lose, and anything you are not entitled to share.
Two points deserve emphasis. First, confidentiality obligations to your own customers and partners often limit what you may pass to a third-party tool, even when the tool is secure. Check the agreements, not just the tool. Second, a personal or free account is not a protected setup. If employees can paste company material into one, the list needs to say so plainly, which is the same discipline described in a one-page acceptable use policy for employees.
Licences for the sources the agent reads
An agent that answers from a knowledge base is only as clean as that base. Before a document goes in, you should know whether you may use it this way.
Build a simple source register with five columns: the document, its owner, where it came from, its licence or permission status, and the date it was last reviewed. Typical trouble spots are:
- Material bought or subscribed to, such as standards, research reports or paid databases, whose licence may restrict copying or machine use.
- Content supplied by customers or partners under an agreement that limits the purpose.
- Material scraped from websites, whose terms may not allow it.
- Old internal documents written by contractors, where it is unclear who holds the rights.
If a source's status is unknown, leave it out until someone finds out. This also helps quality, because documents without an owner are often the ones that are outdated, as covered in preparing company documents for an AI agent.
Who decides, and what to write down
Rules without an approver drift. Name one person responsible for the policy, and decide who must agree to each kind of change.
- Adding a new source or data type: the source owner and the person responsible for data protection.
- Changing the vendor, plan or settings: the agent owner and whoever handles contracts.
- Publishing agent output externally: the content owner, with a review step proportionate to the risk.
- Exceptions to the never-list: a written approval, with a reason and an end date.
Put the result in the rules in plain language: the allowed, protected and never lists; the ownership position you have agreed with the vendor; the source register; the approver for each change; and how an employee reports a doubt. Review the whole page when the vendor changes its terms, when you add a new use, and at least once a year.
Questions to bring to your lawyer
You will get more value from a short, specific brief than from a request for a general opinion. Here are questions that tend to be worth the time:
- Does our contract give us the output rights we need for the uses we plan, and are the conditions realistic for us to keep?
- For the outputs we care most about, what protection, if any, can we expect, and what should we record to support it?
- Which of our customer and partner agreements limit passing material to an AI tool?
- Are the licences for our paid or third-party sources compatible with using them in an agent?
- What notices do we owe customers or employees about how the agent uses their information?
- If an output turns out to infringe someone's rights, how does responsibility fall between us and the vendor?
For the related point about what to tell people using the agent, see legal questions to settle before launching an AI agent.
A short checklist
- The vendor contract is read for input use, output rights, exit and infringement cover, and gaps are marked.
- Inputs and outputs have separate rules.
- One page lists what is allowed, what needs a protected setup, and what is never allowed.
- A source register records owner, origin, licence status and review date.
- Published outputs have a named human owner and an approval step.
- One approver is named for each type of change, and exceptions are written down with an end date.
- A short list of questions has gone to your lawyer, and the answers are in the rules.
Ownership questions are easy to postpone because nothing goes wrong on the day of launch. They tend to surface later, when a customer asks, a partner objects or the vendor changes its terms. An hour spent writing this down now is cheap compared with reconstructing it then.
