Adding AI to your app? Add these three disclosures to your privacy policy.

The pull request was forty lines. An API key in the environment, a prompt template, one fetch call, and a button in the sidebar that says Summarise. It shipped on a Thursday afternoon and nobody wrote a ticket for it, because it was the smallest thing anyone shipped that month.

From that afternoon on, your product sends your users' text to a company you have never named in public, running it in a location nobody on your team picked. Your privacy policy still describes the product you had on Wednesday.

Most people arrive at this worried about the EU AI Act, and that worry is not misplaced: Article 50 started applying on 2 August 2026, and I come to it below. But what reaches a normal SaaS feature first is ordinary GDPR transparency, in force since 2018, and that is what a customer's procurement team checks.

So: if you have shipped a feature that calls a model, you need to open that pull request and answer five questions about it, or the privacy policy published under your company name is describing a product you stopped shipping the day it merged.

What does one LLM call add to your privacy policy?

Three items on a list you already published. Where you collect personal data from a person, GDPR Article 13 makes you give them a set list of information at the time you obtain it, and adding a model call changes three entries on that list 1:

• The recipient line, Article 13(1)(e): "the recipients or categories of recipients of the personal data, if any".
• The transfer line, Article 13(1)(f): whether you intend to send the data outside the EEA, and what makes that lawful.
• The automated-decision line, Article 13(2)(f): "the existence of automated decision-making, including profiling, referred to in Article 22(1) and (4)" and, in those cases, meaningful information about the logic involved.

Those are the three disclosures in the title, and all three are edits to a document. The AI Act then adds two more duties, and those are code changes rather than policy edits. I come to them after the three above.

Why is the model vendor a recipient even though you signed a DPA?

Because the GDPR defines a recipient without caring whether they work for you. Article 4(9) says a recipient is a person or body "to which the personal data are disclosed, whether a third party or not" 1. Your processors are recipients. A data processing agreement governs what the vendor may do with the prompt; it does not remove them from the recipient line you publish.

That catches more companies than people expect, because a prompt rarely travels to one place. If you call a cloud's hosted inference rather than the model company directly, the cloud receives it and the model company may not be in the path at all. Then there is everything you bolted on afterwards: the gateway, the evaluation tool, the prompt-logging service you added during a debugging week and left running. Those are the easiest to miss, because nobody negotiated a contract for them. Somebody added an environment variable.

So read the request path rather than your memory of it: follow one prompt from the browser to the model and write down every company that receives it.

There is a fair objection here. The recipient line lets you publish "recipients or categories of recipients", so a policy already disclosing a category such as hosting and infrastructure providers may cover a new model vendor without a word changing 1. Sometimes that is right. It stops being right when the model vendor belongs to no category you disclosed, and "analytics providers" does not cover sending the text your users typed to a company that generates text back. You also still need the real names on file, because a user exercising their right of access can ask who specifically received their data.

Where does the prompt go, and what does the transfer line have to say about it?

Wherever your vendor is configured to run it. The answer lives in a region setting in a console, plus whichever of the vendor's legal entities your contract names. Two companies using the same model vendor can end up with genuinely different answers, so the sentence in your privacy policy is really a claim about how your own account is set up. Open the console and look, because nobody remembers choosing a region.

The answer also moves without anyone editing the policy. Vendors add regions, you switch to a cheaper endpoint, a fallback provider gets wired in during an outage and stays.

What you then have to publish is short. Either the Commission has ruled that the destination protects personal data well enough, which is what an adequacy decision is, or you name the safeguard you are relying on instead, usually a set of standard contractual clauses, and say how a user can get a copy of it 1.

When does the automated-decision line apply to an LLM output?

When the output alone determines something that matters to the person, and no human genuinely decides. Article 22(1), which the automated-decision line points at, covers decisions "based solely on automated processing" producing "legal effects" or similarly significant ones 1.

A summary in the sidebar is not that, and neither is a suggested reply a person reads before sending, so do not disclose a decision you are not making. Automatically declining a signup, cancelling an account, rejecting a listing, ranking a job applicant or setting one customer's price plausibly is, so do not skip it because the feature felt like plumbing when you built it.

Two things make this wider than it looks. The first is how much counts as a decision. In 2023 the Court of Justice of the EU, which decides what the GDPR's words mean for every member state, held that a credit bureau producing a score was itself making the automated decision, because the lender receiving it "draws strongly on" that score 2. That case turns on two separate companies, so it does not carry over wholesale to a feature inside one product. The lesson that does carry: a court will not accept "the model only recommends, a person decides" when the recommendation is what drives the outcome.

The second is what counts as the human, and here there is guidance written for exactly this question. The European Data Protection Board, the body that issues joint guidance for the EU's national privacy regulators, has endorsed guidelines on automated decision-making that say a decision is not solely automated where a person reviews the recommendation and takes other factors into account 5. So a review step genuinely can settle it. The same guidelines are blunt about the other case: oversight has to be "meaningful, rather than just a token gesture", by someone "who has the authority and competence to change the decision", and where somebody routinely applies a generated output "without any actual influence on the result" the decision is still solely automated 5. So if your support tool drafts rejections and an agent approves four hundred a day without reading them, the human in the loop is a fact about your org chart rather than about the decision.

What does AI Act Article 50 add on top of all this?

Two duties, both on the product rather than on the policy page, and both live since 2 August 2026 3. Which one you get depends on what your feature does.

Article 50(1) covers systems "intended to interact directly with natural persons": those people have to be informed they are interacting with an AI system, unless that is obvious to a "reasonably well-informed, observant and circumspect" person 3. Article 50(5) sets the timing, "at the latest at the time of the first interaction", and requires it to be clear and distinguishable 3. A support chat widget is squarely in this. The Summarise button I opened with is probably not, because nobody is conversing with it.

Article 50(2) catches the Summarise button, and it needs engineering rather than copy. Providers of systems "generating synthetic audio, image, video or text content" have to mark the outputs "in a machine-readable format and detectable as artificially generated or manipulated", as far as that is technically feasible 3. There is an exception for systems performing "an assistive function for standard editing" or not substantially altering the input, which is where many summarisers will argue they sit. If your feature drafts text a user then sends as their own, do not assume the exception carries you. There is one piece of timing relief, and the test is a single date: if your feature was live before 2 August 2026, you have until 2 December 2026 to comply with this one 4. If you shipped it after, you do not.

Both duties fall on the provider, and if you wrote the feature and shipped it under your own brand, that is you, whoever trained the model 3. The exception is narrow: embed somebody else's AI product wholesale under their branding and you are a deployer instead, with much less to do here.

Where do you start?

Open the pull request that added the model call. Five questions, all answerable from that diff plus your vendor console, and none of them requiring a lawyer:

1. The recipient line. Which companies receive the prompt: the model vendor, whichever cloud runs the inference, and every gateway, evaluation and logging tool in the path.
2. The transfer line. Which region processes it, which vendor entity you contracted with, what makes the transfer lawful, and how a user gets a copy of those safeguards.
3. The automated-decision line. Whether the output decides something that matters to a person, and whether anyone with the authority to overrule it reads it before it lands.
4. The "you are talking to a model" notice. Whether a user meeting this feature is told so, at the first interaction (AI Act Article 50(1)).
5. The generated-output marking. Whether the feature produces text, audio, image or video that leaves your product unmarked (Article 50(2)).

The first three are edits to a document you already publish. The last two are work in the product. None of it is hard once the answers exist, and the harder problem is the next forty-line pull request, and the one after that.

Lawcel is what we built for that second problem. It keeps a company's legal documents matching the product it ships: it watches where product change shows up, mostly pull requests and issue trackers, works out whether a change has made a published document wrong, and shows you the specific sentence with replacement text to approve or reject. Behind the documents it keeps a profile of the facts they rest on, and that profile has a section for each of the things above: the third parties that receive data, the transfers out of the EEA, the automated decision-making, and where the product uses AI. So when somebody adds a model vendor on a Thursday afternoon, there is something specific for that pull request to contradict, while the change is still in review rather than the week your first enterprise customer reads the document.

If you shipped an AI feature this year, the five questions above are worth an hour today. If you would rather the next one raised them by itself, connect your repository to Lawcel and let it ask.