AI and Copyright: Training, Outputs and Practical Risk

Copyright questions around AI remain unsettled in several respects, which makes practical risk reduction more useful than waiting for a definitive answer. Three areas are live: training provenance, output similarity, and ownership. This guide covers each, drawing on FISTA Solutions' AI enablement work. This article is general guidance, not legal advice.

Where does copyright risk actually sit?

In three distinct places, with different mitigations for each.

Area	Practical mitigation
Training data used by a provider	Supplier due diligence, indemnity terms
Data you supply for fine-tuning	Provenance records and rights checks
Output similarity to protected works	Testing, prompt constraints, review
Ownership of generated material	Document human contribution
Licensed content in retrieval	Licence terms cover AI use
Attribution obligations	Preserved through the pipeline

What about training data?

For models you use rather than train, this is a supplier question: what the provider says about training data, what indemnities are offered, and on what conditions.

For data you supply for fine-tuning, it is yours to get right. Records of where the material came from and what rights you hold are cheap to keep at the time and impossible to reconstruct afterwards, and they are the first thing asked for if a question arises.

What is output similarity risk?

The risk that generated output reproduces protected expression closely enough to infringe.

It is more likely with distinctive styles, well-known works, and prompts that explicitly ask for imitation of a named creator. The practical mitigations are constraining those prompts, testing outputs for close similarity where the volume justifies it, and reviewing anything published at scale. Prompts asking for work 'in the style of' a living creator are the highest-risk pattern and the easiest to prohibit.

Who owns AI-generated material?

It varies by jurisdiction, and several require human authorship for copyright protection.

That can leave purely machine-generated output unprotected, which matters if the material is a commercial asset you expect to defend. Material with substantial human authorship is generally treated differently, so documenting the human contribution is worth doing where ownership matters. See what is content provenance.

What evidence do you need?

Records of which models were used under what terms, provenance information for any data you supplied for training or fine-tuning, output review evidence for material you publish, and records of human contribution where ownership matters.

If that evidence exists as a by-product of how systems are built and operated, you are in good shape. If it exists only as documents written for a review, you are not, and the difference is visible to anyone who looks carefully.

How does this change engineering practice?

It pushes provenance recording and prompt constraints into the pipeline. Recording which model produced which asset, from what prompt, with what human editing, is cheap during generation and impossible later.

For retrieval systems, licence terms for the indexed content matter: a licence permitting internal reference may not permit indexing into a system that generates derived text, and that is worth checking before the corpus is built.

How does it interact with other regimes?

Usually more than expected. The same system can attract questions from a data protection authority, a sector supervisor, and a general AI regulator, each starting from a different premise and arriving at overlapping requirements.

One evidence base mapped to several requirements answers all of them. Separate programmes produce separate documents describing the same systems, and inconsistencies between them are themselves a finding.

What does compliance cost?

Mostly the cost of good engineering practice: evaluation, documentation, logging, and oversight design. Built into a project, the incremental cost is modest and much of it is work the system needed anyway.

Retrofitted onto a live system it becomes a project, performed under a deadline you did not choose, on something people already depend on. See AI compliance audit cost.

What are the common mistakes?

Assuming a provider indemnity covers everything without reading its conditions. Fine-tuning on material with unclear rights. Allowing 'in the style of' prompts naming living creators. And indexing licensed content without checking whether the licence permits it.

Who owns this internally?

The function that owns the systems, with legal and compliance support. Ownership by compliance alone produces documents describing systems nobody changed; ownership by engineering alone produces good practice with no one accountable for the interpretation.

Name a person per system rather than a committee. Committees review; people decide.

What should you ask a supplier?

What documentation they provide about capabilities and limitations, what evaluation evidence they share, how they handle personal data, where processing happens, and what happens to your prompts and outputs.

Suppliers who have prepared answer those quickly. Suppliers who have not take weeks, and that delay is itself information about how the relationship will run.

How do you keep this current?

Assign someone to watch the sources that actually bind you rather than general commentary. Record what was checked and when, so the next review starts from a known point.

Rules in this area change, and a position taken eighteen months ago and never revisited is a risk in itself.

How should teams handle the uncertainty?

By documenting decisions and keeping options open. Record which models were used, on what terms, for what material, so that if the position changes you know what is affected.

Organisations that cannot say which assets were machine-generated, from which model, will struggle to respond to any development in this area. Those that can will treat it as a scoped question.

What should you do first?

Check whether you can identify which published assets were AI-generated, by which model, and what human editing followed. If you cannot, start recording it now.

How FISTA Solutions helps

FISTA Solutions builds AI systems so the evidence exists when it is needed: generation provenance recorded per asset including model, prompt, and human editing, prompt constraints preventing the highest-risk imitation patterns, evaluation results dated and versioned, oversight designed structurally rather than asserted in policy, and documentation produced during the build rather than reconstructed afterwards. Delivery runs through AI enablement, AI agents, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries.

To align a system with these requirements, message FISTA on WhatsApp, or read what is content provenance.