Does the Company Really Own What AI Creates?

AI can generate a piece of code, a set of illustrations, or a research report in minutes. But generating something does not mean that a company has obtained clear, complete, and commercially usable rights to it.

In Brief

• Permission to use AI-assisted output does not necessarily give a company complete or exclusive rights in it.
• Important assets should retain records of their input sources, human contributions, relevant platform terms, and approved uses.
• Employee-created work, supplier deliverables, and third-party materials require separate analysis rather than a single assumption about ownership.
• A material change in use may require reassessment, particularly when an asset moves from internal experimentation to publication, customer delivery, or licensing.
• A context-aware agent can help connect facts and evidence, but it cannot replace legal judgment.

Scope note: This article provides a general framework for operational and legal risk identification. It does not constitute legal advice in any jurisdiction. Laws and legal standards vary, and material matters should be reviewed by qualified professionals based on the relevant facts and applicable law.

Consider a hypothetical example.

A fictional startup uses AI-assisted tools to develop a brand character that later becomes unexpectedly popular. The team begins with a character brief and uses an image model to explore different visual directions. A designer reviews hundreds of outputs, selects a promising concept, and redraws its silhouette, colors, expressions, and details. The character is eventually turned into website animations, social-media stickers, and physical merchandise.

Several months later, a partner wants to license the character commercially.

At that point, the question is no longer whether the character looks good. The questions are:

• Who created the character?
• Which elements were designed by people, and which were generated by a model?
• Were any external reference images used?
• Do the model provider’s terms permit the intended commercial use?
• Were the designer’s revisions and source files preserved?
• Does the company own a defensible set of rights, or does it merely possess an image file?
• Does the company have enough authority to license the character to someone else?

The scenario is illustrative and does not describe the creation process, rights position, internal structure, or practices of any specific company or brand.

As AI-assisted creation becomes routine, more companies will face questions like these.

AI can generate code, illustrations, videos, research reports, and product copy in minutes. But “generated” does not mean “owned.” Permission to use an output on a company’s own website does not necessarily mean that the company may deliver it to a customer, sublicense it to a partner, or prevent others from creating something similar.

AI has dramatically reduced the cost of creation. It has not automatically removed uncertainty about where rights come from.

Traditional intellectual-property management often begins with the final asset: preserve source files, apply to register relevant trademarks, and use employment, development, assignment, or licensing agreements to address the applicable rights.

When people and AI create together, companies must look further upstream. They need to understand how an asset was produced, what materials were used, who made identifiable contributions, what the relevant contracts and platform terms permit, and which risks still require human judgment.

In this article, chain of rights is an operational shorthand for the records connecting provenance, authorization, contribution, review, and approved use from prompt to product. It is not a single statutory concept with the same legal meaning in every jurisdiction.

The examples are illustrative and do not describe the internal arrangements or practices of any particular company. Rules concerning the protectability of AI-assisted work, ownership in employment or commissioned-work relationships, trade secrets, privacy, and data use differ across jurisdictions. Outcomes may also depend on the creative process, contract language, and intended use.

1. Who Owns the Image?

Consider a simple scenario.

A marketing team needs an image for a campaign. Someone enters the following prompt:

“A mechanical fox wearing flight goggles crossing a desert, warm cinematic light, geometric illustration style.”

The model generates an image, and the team posts it on social media.

If the image is used only for a temporary post, a basic review may be enough.

But suppose the post performs well, and the company decides to:

• adopt the image as a long-term branded character;
• apply to register related signs as trademarks;
• produce stickers and merchandise;
• incorporate the character into a paid product;
• license it to commercial partners;
• restrict unauthorized uses of the relevant expression or signs where the law permits.

The legal and operational questions change immediately. Copyright, trademark, patent, trade-secret, and contractual rights protect different subject matter, arise under different conditions, and offer different remedies. A trademark application or registration does not by itself give the company exclusive control over every expressive aspect of a character.

The team may now need to determine:

1. What commercial uses does the model provider permit?
2. Were external reference images used as inputs?
3. Is the result substantially similar to an existing character, work, or brand?
4. What creative contributions did people make to the final design?
5. Did the company preserve drafts, revision history, and editable source files?
6. What agreements govern the relationship between the designer and the company?
7. Are the company’s rights sufficient to support licensing to third parties?

One distinction is especially important:

The ability to use an asset is not the same as the ability to control it exclusively.

A platform’s permission to use outputs commercially generally addresses the contractual relationship between the user and the platform. It does not necessarily mean that:

• the output qualifies for enforceable intellectual-property protection;
• the output cannot implicate third-party rights;
• the user can prevent other people from producing similar results;
• the user can safely give customers an absolute non-infringement warranty.

The fact that an image can be downloaded does not mean that it has become a company asset with clearly defined rights.

2. AI Turns “Who Is the Author?” into a Series of Questions

In conventional creative work, we can often identify a specific person:

• an article was written by an author;
• an illustration was drawn by a designer;
• a program was written by an engineer.

When people and AI create together, the final result may emerge from a chain of contributions:

• a product manager defines the objective;
• a researcher prepares source material;
• an employee writes the prompt;
• a model generates the first draft;
• an agent invokes other tools to process the result;
• a designer selects, combines, and redraws elements;
• an editor substantially rewrites the text;
• an engineer reimplements critical logic;
• an authorized reviewer approves the final version.

“Who is the author?” can no longer be answered simply by identifying who pressed the Generate button.

More useful questions include:

• Who determined the final expression?
• Who made specific choices about structure, style, composition, or logic?
• Who modified the model’s output?
• Were those changes merely mechanical, or were they creative?
• Which parts of the final asset reflect independent human contribution?
• Which parts came from external tools or source materials?
• Who had authority to approve the asset for use in a product?

The legal treatment of AI-assisted and autonomously generated content differs across jurisdictions. In copyright analysis, human creative contribution is an important consideration in many jurisdictions, but the relevant standard, protected subject matter, and scope of protection are not uniform. Human involvement does not necessarily make the entire output protectable.

If a company expects to assert copyright or other rights in an important asset, it should identify the relevant human contributions and preserve records explaining the creative process and legal basis. Those records can support a factual account, but they do not by themselves guarantee that rights exist.

Relevant evidence may include:

• the original brief;
• key prompts and parameters;
• reference-material lists;
• intermediate outputs;
• records of human selection;
• editable source files;
• revision history;
• source-control history;
• review comments;
• final approval records.

This does not mean that every temporary illustration needs a complete legal dossier.

A stronger process may be appropriate for assets that enter products, acquire long-term brand value, become part of customer deliverables, or are intended for external licensing. The scope of recordkeeping should remain necessary and proportionate, taking account of privacy, confidentiality, security, and retention obligations.

3. The Company Paid for It. Why Might the Rights Still Be Incomplete?

Consider another hypothetical scenario.

A company hires an external studio to create a collection of brand animations. The agreement contains only one sentence about ownership:

“Upon full payment, all project deliverables shall belong to the client.”

The sentence looks direct, but it may leave many questions unanswered.

What exactly counts as a “project deliverable”?

• exported GIFs and videos;
• editable project files;
• original illustrations;
• storyboards;
• custom fonts;
• music and sound effects;
• prompts;
• workflows;
• automation scripts;
• the studio’s reusable tools;
• third-party materials used in the project.

What does “belong to the client” mean?

• Is it an assignment of intellectual-property rights or a license?
• Does it concern copyright, patent rights, trademark interests, trade secrets, or another category of rights?
• May the client reproduce, modify, distribute, communicate, display, or otherwise exploit the material?
• May it use the material in other products or sublicense it to partners?
• May it manufacture physical merchandise?
• What territories, terms, media, and fields of use are covered?
• When does the assignment or license become effective?
• If a right is non-transferable or has not yet arisen under applicable law, what license and cooperation obligations apply instead?
• Does the supplier represent that it has authority to deliver, license, or assign the relevant material?

If the supplier uses AI tools, the company may also need the supplier to disclose:

• which models, platforms, or generation tools were used;
• whether third-party references were incorporated;
• whether open-source components were included;
• whether the supplier’s pre-existing assets were used;
• whether the relevant tool terms allow the planned commercial delivery;
• whether confidential client material was submitted to an external service;
• whether the supplier retains the inputs or outputs;
• whether sufficient source files and process records will be delivered.

A single sentence about ownership therefore needs to be developed in light of the relevant right, governing law, and commercial objective, and should usually distinguish at least four categories:

1. Custom work created specifically for the project
2. Pre-existing tools and materials owned by the supplier
3. Licensed third-party materials and open-source components
4. Content generated or processed with AI tools

Without these distinctions, the company may discover at the end of the project that:

• it received the image but not the editable source file;
• it received application code but not critical deployment scripts;
• it may use the output internally but cannot lawfully deliver it to customers;
• the supplier promised to transfer material it did not own;
• the product depends on the supplier’s pre-existing tool, but the company has no continuing license to use it.

Payment can complete a transaction. It cannot automatically repair a broken chain of rights.

4. Is “Commercial Use Permitted” a Simple Answer or a Set of Boundaries?

Generative AI providers are frequently asked:

Can the output be used commercially?

The question sounds as though it should have a yes-or-no answer. In practice, it often needs to be divided into several layers.

Layer 1: The relationship between the platform and the user

The provider’s terms may explain whether the user may use the output, how the provider and user allocate any contractual interests they may have, and whether commercial use is allowed. A contract cannot create an intellectual-property right that does not otherwise exist under applicable law, nor does it automatically bind third parties who are not parties to that contract.

Layer 2: The relationship between the user and the input material

Even when the platform permits commercial use, the user may still be responsible for ensuring that it has the necessary rights to submit the input materials.

Those materials might include:

• an unpublished customer proposal;
• a paid industry report;
• proprietary source code;
• employee or customer information;
• a third-party design;
• a protected character or brand image.

A company’s lawful possession of material does not necessarily mean that it may submit that material to an external model.

Layer 3: The relationship between the output and third parties

An output may raise issues involving:

• substantial similarity to an existing work;
• trademarks or brand identifiers;
• a person’s likeness;
• open-source code;
• restricted datasets;
• other third-party rights.

Permission from the platform does not prevent a third party from making a separate claim.

Layer 4: The company’s intended use

Risk also changes with the intended use.

Using an image in an internal brainstorm is different from registering it as a trademark, selling it as merchandise, or licensing it to a third party.

The better question is therefore not simply:

Can this be used commercially?

It is:

How does the company intend to use this output, and what review or authorization is required for that specific use?

5. Lawful Access Does Not Mean Unrestricted Permission to Upload

Intellectual-property risk does not arise only from AI outputs. It also arises from input.

A company may lawfully possess:

• customer contracts;
• proprietary source code;
• user behavior data;
• paid research reports;
• employee information;
• unreleased product plans;
• supplier quotations;
• internal investigation materials.

But lawful possession does not necessarily permit submission to any external AI service.

Before uploading material, a company may need to consider:

• whether the original purpose of use covers AI processing;
• whether a customer or supplier agreement permits third-party processing;
• whether submission would violate confidentiality obligations;
• whether personal or sensitive information is involved;
• whether the material can be anonymized or minimized;
• whether the service retains the input;
• whether the input may be used for training or product improvement;
• where the data is processed and stored;
• who may access conversations or logs;
• whether the data can be deleted after the task is complete.

Publicly accessible material is not necessarily rights-free either.

Public websites, articles, images, and code may still be governed by:

• copyright and related rights;
• open-source licenses or other contractual conditions;
• platform terms;
• sui generis database rights in some jurisdictions;
• trademark and other source-identifying rights;
• rights relating to likeness, name, voice, personality, or publicity;
• privacy and data-protection rules;
• unfair-competition and other applicable laws.

Before submitting material to a model, a company can ask seven questions:

1. Why are we entitled to access this material?
2. Does the existing permission cover AI processing?
3. Must we provide the complete original content?
4. Can we anonymize, summarize, or reduce the input?
5. Should we use an approved enterprise tool instead of a personal account?
6. What is the intended use of the output?
7. Where should the source and authorization evidence be preserved?

AI changes how information is processed. It does not automatically expand the company’s underlying rights to use that information.

6. AI-Generated Code May Be Harder to Explain Than Ordinary Copy and Paste

AI-assisted programming often feels highly controlled.

An engineer describes the requirement, an assistant produces code, tests pass, and the change is merged into the repository. Because the process takes place within a development environment, it may appear easier to trace than generated images or marketing copy.

But generated code can create a different set of questions:

• Is the code substantially similar to an identifiable open-source implementation?
• Has it introduced undocumented dependencies?
• Are the applicable licenses compatible with the product’s business model?
• Was proprietary code submitted to an unapproved external service?
• Does the code contain copyright notices copied from a public repository?
• Does it conflict with customer requirements concerning code provenance?
• Can the company responsibly provide a non-infringement warranty?

Code review should therefore examine more than whether the feature works.

Depending on the importance of the code, review may include:

• dependency and license scanning;
• provenance and similarity checks;
• security testing;
• architecture review;
• records of how the code was generated;
• substantive human refactoring;
• approval by an accountable engineer.

There is also a broader operational question:

If the engineer cannot explain why a critical piece of code was designed in a particular way, does the company genuinely possess the capability to maintain it?

From an operational perspective, code that cannot be understood or maintained may not yet be a mature company asset, even if no immediate infringement issue has been identified.

7. What Kind of Asset Is a Prompt, Workflow, or Skill?

In an AI-native company, the most valuable asset may not be a single output. It may be the method that reliably produces useful results.

Examples include:

• a contract-review workflow;
• a set of customer-support instructions;
• a product-research agent;
• a data-cleaning process;
• a brand-generation skill;
• a collection of evaluation rules and negative examples.

Can these capabilities be protected like code, trademarks, or designs?

The answer is rarely a simple yes or no, because they may contain several different kinds of material.

Prompts

A short, highly functional prompt may be difficult to protect through stable exclusive rights, although the result depends on its expression, arrangement, applicable law, and surrounding facts.

A sophisticated collection of instructions may contain original expression, structured selection, code, or configuration that could receive protection. Even then, protection generally does not extend to the underlying idea, function, or method itself, and another party may be able to achieve a similar result through different wording or implementation.

The commercial value of a prompt should therefore not depend entirely on copyright. Contractual restrictions, confidentiality measures, access controls, and technical safeguards may also matter.

Workflows

A workflow may include an abstract method, business logic, documentation, code, node configurations, tests, and data structures.

An abstract idea, method, or function must be distinguished from its concrete expression and implementation. Copyright generally does not protect the abstract idea or method itself, while code, documentation, or visual configuration may be protected as particular expressions. Some technical implementations may also implicate patent rights, trade secrets, or contractual interests, depending on the legal requirements and facts.

Skills and agent configurations

A mature skill may contain:

• instructions;
• program code;
• examples;
• tool connections;
• evaluation standards;
• domain rules;
• permission settings;
• exception-handling procedures;
• curated cases.

It is better understood as a combination of rights, data, and operational knowledge than as a single work.

Trade secrets

For prompts, workflows, evaluation standards, and internal operating rules, trade-secret protection may be more practical than relying solely on copyright.

But information does not become a trade secret merely because a company labels the file “Confidential.” Although the legal elements differ across jurisdictions, analysis commonly considers whether the information is not generally known, has actual or potential commercial value because of its secrecy, and is subject to reasonable protective measures proportionate to its value and risk. Such measures may include:

• restricting access on a need-to-know basis;
• assigning confidentiality classifications;
• using confidentiality and invention-assignment agreements;
• logging access, downloads, and exports;
• requiring approval before external sharing;
• revoking access when a person leaves or a project ends;
• prohibiting unauthorized use in external projects;
• separating critical rules and datasets.

A valuable AI capability may require a combination of copyright, contract, trade-secret protection, source-control practices, and access restrictions.

8. Not Every AI Output Needs the Same Legal Process

If every AI interaction requires a complex legal form, people will quickly stop following the policy.

The more practical approach is to classify AI-assisted work by intended use and potential impact.

Lower-risk uses

Examples may include:

• internal brainstorming;
• temporary summaries;
• personal productivity tools that contain no sensitive information;
• placeholder material that will not be published.

These uses may require only compliance with basic tool and data policies.

Medium-risk uses

Examples may include:

• external marketing content;
• visual assets intended for ongoing use;
• customer-support templates;
• internal decision reports;
• product prototype code.

These may require records of sources, tools, human review, and permitted use.

Higher-risk uses

Examples may include:

• core product code;
• formal customer deliverables;
• content intended for external licensing;
• training, fine-tuning, or evaluation datasets;
• workflows that process customer or personal information;
• long-term brand characters and visual systems;
• analysis that directly informs material company decisions.

These uses may require a more complete chain of rights and, where appropriate, professional review.

Factors that may affect the risk classification include:

• whether the output enters a product;
• whether it will be seen by customers;
• whether it will be licensed externally;
• whether it contains sensitive data;
• whether it depends on third-party material;
• whether it would be difficult to replace;
• the potential impact of a dispute;
• whether the company expects to assert exclusive rights.

The mere use of AI does not automatically make an activity high risk. Nor does limited AI involvement necessarily make an activity low risk.

The appropriate level of governance depends primarily on what the output will be used for and what could happen if the underlying assumptions are wrong.

9. Companies Need a “Chain-of-Rights Card”

A company does not necessarily need a lengthy legal report for every important AI-assisted asset.

A structured chain-of-rights card may answer many of the foundational questions.

Note: The card below is intended to organize information and identify questions for further review. Completing it does not constitute legal review, establish ownership, confirm non-infringement, or provide compliance certification.

The card can also be presented on a website as a copyable Markdown block, a one-page PDF, a workspace template, or a simple self-assessment checklist. Whatever the format, the same limitation should remain visible: it is an information-organization and risk-identification tool, not a legal opinion or compliance certificate.

The purpose of the card is not to declare an asset “absolutely safe.”

It can help the company organize and, where supported by the evidence, demonstrate:

• how the asset was created;
• who contributed to it;
• how the company acquired relevant permissions;
• which restrictions remain;
• who reviewed and accepted the residual risk.

10. Changes in Use Are an Overlooked Source of Risk

An asset that is appropriate for one purpose may not be appropriate for every later purpose.

Common changes include:

• an image from an internal report is reused in a public advertisement;
• prototype code moves into production;
• a workflow designed for one customer is reused for others;
• an internal dataset is repurposed for model training;
• a brand character is licensed to a commercial partner;
• internal research conclusions are used in public marketing;
• a personal productivity tool becomes a critical team workflow.

A new use may trigger new questions:

• Does the original permission cover public release?
• Are modification and sublicensing allowed?
• Does the new audience or territory introduce additional requirements?
• Must the facts and sources be verified again?
• Does the new use exceed the purpose to which a customer originally agreed?
• Do the relevant platform terms still apply?
• Is new security, brand, privacy, or legal review required?

A company should therefore record not only that an asset was “approved,” but also:

Approved for what purpose?

When the purpose changes materially, the original conclusion may need to be reassessed.

11. Rejected Versions May Become Important Evidence

Teams typically preserve the final work and discard the unsuccessful drafts.

When people and AI create together, intermediate versions may show:

• that people did not mechanically accept the first output;
• that a designer made substantive creative choices;
• that an engineer reimplemented critical logic;
• that an editor changed the structure, reasoning, and expression;
• that reviewers identified and removed third-party risks;
• how the final expression developed through human intervention.

A designer may review hundreds of generated concepts and then redraw the character’s silhouette, expressions, colors, and animation. An engineer may treat generated code as a prototype and rewrite the core module. An editor may substantially reorganize and rewrite a model-generated article.

Representative process records can support:

• quality review;
• a factual account of human contribution and the creative process;
• an explanation of the approval process;
• future maintenance;
• factual reconstruction in the event of a dispute.

Intermediate versions do not by themselves prove that copyright exists or that the company owns it. Their evidentiary value must be assessed together with the content, contractual relationships, timing, and other evidence.

This does not mean that every prompt and rejected result must be retained indefinitely.

The company can establish proportionate retention practices based on the importance of the asset, preserving materials such as:

• key intermediate versions;
• major revision records;
• rejected alternatives and the reasons for rejection;
• final approval evidence.

Retention practices should also reflect data minimization, confidentiality obligations, third-party platform terms, storage security, and established deletion periods. Provenance should not become a reason to preserve every input and generation log indefinitely.

A defensible chain of rights needs evidence, but evidence management should remain proportionate.

12. What Could a Context-Aware Agent Do?

Intellectual-property reviews often begin too late.

When an asset is about to be published, delivered, licensed, or examined during due diligence, someone starts searching for the relevant records. The problem is often not that those records never existed. It is that the context is fragmented across agreements, files, design tools, code history, review comments, and approval messages.

Where users choose to provide the relevant context and permissions, an agent could help connect those records as the work develops.

At the beginning of a project

It could help identify:

• the intended deliverable;
• the internal and external materials expected to be used;
• whether sensitive information may be involved;
• whether the proposed tools have been approved;
• whether the output may later enter a product, reach a customer, or be licensed externally.

As the work changes

It could help preserve:

• significant human revisions;
• the reasons certain outputs were rejected;
• newly introduced third-party materials;
• unresolved questions requiring specialist review;
• changes to the asset’s intended use.

Before publication or delivery

It could prepare a structured review:

• Are the sources identifiable?
• Is there evidence of meaningful human contribution?
• Do the relevant platform terms cover the intended use?
• Are the necessary employee or supplier agreements available?
• Are there potential trademark, likeness, open-source, confidentiality, or data issues?
• Who has authority to approve the final use?

When the intended use changes

The agent could bring the original approval context back into view:

This asset was previously reviewed for limited internal use. The proposed external publication or licensing arrangement is materially different and may require reassessment.

A context-aware agent should not declare that an asset is “completely safe” or “non-infringing.” It should not independently decide whether copyright exists, whether a statutory exception applies, or whether a company can provide an unconditional legal warranty.

Its more appropriate role is to preserve facts, connect evidence, identify gaps, and bring questions requiring genuine legal judgment to people before the asset is released.

Over time, recurring issues could be translated into reusable review practices, organizational guidance, and carefully scoped agent assistance.

More broadly, one direction worth discussing is whether context-aware agents could help preserve continuous operational context where users deliberately provide the relevant materials and permissions—not by replacing legal judgment, but by keeping important facts and evidence available when that judgment is needed.

13. Perhaps Every Important Asset Will Eventually Have Its Own Biography

Today, companies usually manage assets through folders.

In the future, an important AI-assisted asset may have a continuously updated digital biography.

Select a piece of product code, and the company could see:

• the requirement that led to it;
• the people and agents involved;
• the tools and libraries used;
• which parts were substantially rewritten;
• who completed the testing and review;
• which product features depend on it;
• which license conditions apply.

Select a visual asset intended for long-term use, and the company could see:

• the original design brief;
• the models and reference materials used;
• the designer’s key revisions;
• the editable source files;
• approved uses;
• relevant applications, registrations, agreements, and licensing records;
• existing partner permissions;
• the next date or event requiring review.

Trademark registration, copyright registration, and other administrative records have different legal effects. None of them, by itself, necessarily proves that the company owns complete and exclusive rights in an entire AI-assisted asset.

Select a workflow, and the company could see:

• the original problem it was designed to solve;
• the internal materials it uses;
• the third-party services that process information;
• who may access it;
• which judgments must remain human;
• whether it may be used for other customers or contexts;
• which historical failures have become formal rules.

The purpose would not be to burden every creative act with procedural overhead.

It would mean that, as an asset becomes more important, the company would not need to reconstruct from scratch why it has the right to use it.

Conclusion: Possessing a File Is Not the Same as Owning an Asset

AI can help companies produce code, designs, content, and research at unprecedented speed.

But the faster creation becomes, the easier it is to overlook a fundamental question:

Has the company obtained a downloadable file, or has it built an asset that it can control, maintain, deliver, and commercialize?

The difference lies in a defensible chain of rights:

• where the input materials came from;
• what human contributions were made;
• how employee and supplier rights were allocated;
• what the model provider permits;
• whether third-party rights are involved;
• who completed the necessary reviews;
• what use was approved;
• whether a change in use triggered reassessment;
• what evidence the company can produce if challenged.

Not every AI conversation needs to enter a formal intellectual-property process.

But when an output enters a product, reaches a customer, acquires long-term brand value, or becomes a repeatable core capability, the company should preserve more than the final version.

Between a prompt and a product, there should be a chain of rights that can be explained, reviewed, and demonstrated.

This is also a direction worth exploring for context-aware agents.

The potential value of this kind of agent may extend beyond helping people create faster. With the user’s knowledge, deliberate provision of context, and appropriate permissions, it could help work retain its sources, revisions, and decisions. It should not manufacture false legal certainty; it should bring unresolved questions to authorized decision-makers and qualified advisers while there is still time to address them.

AI will not make intellectual-property questions disappear.

But it may help a company understand—earlier and more clearly—what it has created, what it can control, and which boundaries still require careful confirmation.