11.4 Image Rights, Personal Data, and Copyright

The AI Act gets the headlines. The three layers in this chapter produce the lawsuits.

They are separate regimes with separate remedies, and none of them cares that you disclosed. A perfect Article 50(4) disclosure does not make it lawful to build a persona on someone's face, does not give you a basis to process fan data, and does not settle who owns what you generated. Chapter 11.1 described what the AI Act does not cover. This chapter is what it does not cover.

Chapter 11.7 covers the Polish and EU text for each of these — the Civil Code provisions, RODO mechanics, and the retention schedule. This chapter covers the doctrine, which is the same everywhere in outline and different in detail.

Where the face comes from: three tiers of risk

Almost all of the legal risk in a persona is decided at one moment: the moment you decide what the face is made of. There are three paths, and they are not close to each other in cost or in exposure.

Tier 1 — Invented. A face generated from a text description with no reference to any real individual. This is the lowest-risk path and the one this book recommends. Two checks keep it there:

• Run a reverse image search on the generated face, and on your three strongest identity references, before you commit. Image models trained on celebrity-heavy data sometimes produce a face that is close to a real person's. If it matches, regenerate. Getting a Cease and Desist on your launch week because your persona resembles an actor is an expensive way to learn this.
• Do not name real people in prompts. "In the style of [living actress]" or "[name]'s face" turns an invented face into evidence of intent. It also violates most vendors' terms.

Tier 2 — Composite. Built from a licensed stock model, several reference images, or a purchased face set. Here you need rights in every input, and the licenses are where people get caught:

• A model release for any human whose face or body appears in a reference.
• A stock license that permits your specific use. Read the derivative clause and the AI clause. Some libraries permit commercial video but prohibit training models on their assets, which covers exactly what you are doing when you train a LoRA on them.
• A purchased face from a synthetic-face vendor is the cleanest version of this tier, provided the vendor's terms transfer the rights you need, including the right to train on it and the right to commercialize derivatives.

Tier 3 — Derived from a real person. You are using somebody's likeness as the basis of the character. This requires a legal basis for the likeness itself: an assignment or a license, drawn in writing, with scope. Territory, term, media, exclusivity, the right to train a model on the likeness, and what happens on termination. If the person is a performer, the synthetic performer statutes from 11.3 sit on top of that. If the person is deceased, post-mortem publicity rights apply in a growing set of jurisdictions, and they outlive the person by decades.

The bright line: do not train on a real person's likeness without a legal basis. Scraping somebody's Instagram and training a LoRA on it is the case that ends up in a complaint, and the platform's terms allowing you to view the images has nothing to do with your right to build a model from them.

Public figures are not an exception. There is a public-interest carve-out for news, commentary, and satire in most legal systems. Commercial use of a persona built on someone's face is not news. It is also the exact pattern TikTok bans outright, as chapter 11.2 describes.

What you own, and what the terms actually say

This is where operators discover, usually after paying for a year of infrastructure, that they do not own the thing they built the business on.

"Commercial rights to output" is not ownership of the character. Every major vendor grants something in that shape. It means you may sell or publish the images and video the service generates. It does not mean you own the model, the weights, the training pipeline, the style, or an exclusive right to the character's look. Read the sentence in the terms that grants the rights, and read the sentence immediately after it that reserves the vendor's rights.

The LoRA is the artifact you actually control — if the base model permits it. A LoRA trained on your own hardware on a permissive base model is yours to keep, move, back up, and reuse across vendors, which is exactly why chapter 4.7 insists on it as the identity artifact. But the base model's license governs the derivative:

• Apache-2.0 and similarly permissive bases: commercial use of trained derivatives is generally permitted.
• Research-only or non-commercial bases: a LoRA trained on them inherits the restriction. Selling output from it is a license breach, and hosted training services enforce this in their own terms rather than warning you at the checkout.
• Hosted training services: the terms of the service can be stricter than the terms of the base model. Check both, and check them for the specific base model you selected. [AS OF 2026-10]

That is a real cost trap. Two operators with identical pipelines can have different rights in their own identity artifact because one chose FLUX-dev-class weights and the other chose a permissive base, and neither noticed at the time.

What you can actually own and defend: the accumulated identity consistency, the name as a trademark (register it in the classes you sell in), the content library, the audience and the conversation history, and the contracts. Those are worth more than the weights, and they survive switching vendors — which is the whole point of the portability rule in chapter 7.5.

Copyright in the output is thinner than people assume. In the US, purely machine-generated output may not be protectable for lack of human authorship. In the EU, protection depends on originality, which is an open question for generated material. The practical consequence for you is not "you have no rights." It is that copyright is a weak tool for stopping someone from copying your images. What works instead: trademark on the name, contract terms in brand deals, platform reporting mechanisms, and the one asset a copier cannot clone — an audience that recognizes the character and follows the original.

Personal data in the chat

The conversation layer is the most valuable part of the business and the one where you are processing the most personal data you will ever touch. Fans disclose health information, sexual preferences, relationship details, and financial situations to a persona. That is not a side-effect of the product. It is the product.

Four obligations follow, in every serious privacy regime:

A lawful basis. For a direct-to-fan chat product, the basis is normally performance of a contract or consent. Consent has to be specific and freely given, which means it cannot be buried in terms of service. Chapter 11.7 covers the RODO mechanics; the Washington My Health My Data Act and similar US state laws add separate consent requirements for health-adjacent data.

An information duty. You must tell users what you collect, why, how long you keep it, who processes it, and how to exercise their rights. That notice belongs where the user can see it before the conversation starts, not in a footer.

Retention limits. "Keep everything forever because it might be useful" is a compliance finding and a liability. Define a retention period per data class, and implement deletion. Chapter 12.3 covers the operational side.

Processor agreements. Every vendor in the chat path — the model provider, the hosting provider, the analytics tool — is a processor acting on your instructions. You need a data processing agreement with each, and you need to know whether the vendor trains on your data by default and how to turn it off. Ask the question in writing and keep the answer.

Two details that get missed:

• The chat vendor's training default is a decision you have already made if you never checked it. Verify it per vendor, and re-verify when the vendor changes its terms.
• Reference photos of real people are personal data. A consented model's photographs in your training set are biometric-adjacent personal data, not assets. They need a basis, a retention rule, and deletion on request.

The compliance register

Everything above becomes defensible only if it is written down. One file per persona, versioned, and it answers questions you will not be asked until the day they matter.

The retention column is a working default, not legal advice. The principle behind it: keep records for at least as long as a claim could be brought. In the EU, personality-rights claims and contract claims have multi-year limitation periods, and five years is a safe working floor. Chapter 11.7 refines it for Polish and EU practice.

Two rules make the register useful rather than decorative:

• Write to it at creation, not after. A provenance record reconstructed six months later is a story you are telling, not evidence.
• Store it outside the tool that could be turned off. The register outlives your vendors. Chapter 12.4 covers the continuity plan for exactly this reason.

Where this goes wrong

Assuming disclosure makes the likeness lawful. Different regimes, different remedies. Disclosure is transparency; likeness is permission.

Training on a real person because their profile is public. Public visibility is not a license.

Reading "commercial rights" as ownership. It is a permission to sell output, not a transfer of the character.

Choosing a base model whose license forbids exactly the commercial use you planned. Check the base model license and the hosted service terms before you train, not after.

Treating fan chat as data you own. It is other people's personal data that you process on a basis you must be able to name.

Building the register after the first complaint. By then the useful records are gone — unless the vendor kept them, in which case they are the vendor's records, not yours.

The gate

1. Which tier is your face, and what is the document that proves it?
2. Did you reverse-image-search the final face before committing?
3. What license governs the base model your LoRA was trained on, and does it permit commercial output?
4. What is your lawful basis for processing DM conversations, and where is the notice?
5. Where is the register, who updates it, and what is the retention rule?

What you leave with

Three tiers for the face and the documents each one requires, a clear-eyed reading of what the vendor terms grant and what they reserve, the four personal-data obligations in the chat layer, and the register table you fill in as you build rather than after. Chapter 11.7 gives the Polish and EU text for every one of them.