Article 50 transparency, Article 27 risk assessments, opt-out for AI features. What the AI Act asks of a creator platform — and what Linkette ships in response.
The EU AI Act has been law since 2024 and its substantive provisions have been phasing in across 2025 and 2026. By the time you read this, the obligations that touch a creator SaaS like Linkette — transparency, opt-out, processor disclosure, content marking — are no longer theoretical. They are enforceable. A regulator at the CNIL or one of its sister authorities can, today, ask a creator platform to demonstrate how its AI surface complies, and the platform must answer.
I want to walk through, in plain terms, what the Act asks of a platform like Linkette, and what Linkette has shipped in response. Not because I think the Act is the most exciting subject anyone could write about — I do not — but because I have spoken to a half-dozen other European SaaS founders in the last six weeks who are uncertain about what concretely needs to be in the product, and a worked example may be useful.
I am not a lawyer. The framings here are my best reading of the regulation as a builder, informed by the CNIL-aligned audit Linkette completed in week seven of development. Anything that follows that touches your specific compliance posture, get a real lawyer.
Article 50: marking AI-generated content
Article 50 of the AI Act establishes a transparency obligation for AI-generated or AI-modified content. When a system generates content, or substantially modifies content, the resulting artifact must be identifiable as such — by humans, and in a machine-readable way where practicable.
The Act is more demanding for deepfakes than for, say, a writing assistant that helps a creator polish a bio. But the underlying principle is consistent: the user should not be deceived about the provenance of what they are reading. If an AI wrote it, the surface should say so.
Linkette's answer is a small symbol. Every text surface in the product that contains AI-generated or AI-modified content carries the character ✦ — a small four-pointed star — adjacent to the generated text. When the editor's ghost-text feature proposes a phrase, the proposal carries ✦ until the creator accepts it. When the onboarding agent proposes a bio, the bio carries ✦ until the creator edits or confirms. When the weekly brief lands in a creator's email, the AI-summarized sections carry ✦. The mark is unobtrusive but consistent.
We chose a symbol rather than a phrase ("generated by AI" and its variants) because creators redistribute Linkette content — bios get pasted into other platforms, briefs get screenshotted, copy gets reused. The symbol travels. The phrase often gets edited out.
Article 27 and risk assessments
Article 27 of the Act requires deployers of high-risk AI systems to perform a fundamental rights impact assessment before putting the system into operation. The list of high-risk systems is finite — it covers things like biometric identification, employment decisions, credit scoring, and certain critical infrastructure applications. A link-in-bio editor is not, by any reading I have seen, a high-risk system.
But the Act invites — and a thoughtful regulator will look favorably on — the deployer who has documented the case. We have written an internal memo that walks through each high-risk category in Annex III of the Act and explains, in plain prose, why Linkette's AI surface does not fall under it. Writing assistant: no. Onboarding conversation: no. Link enrichment: no. Page suggestion: no. The memo is short. It exists. If a regulator ever asks, we can hand it over.
This is the kind of small documentation work that costs almost nothing to produce in advance and is impossible to produce convincingly under deadline. I recommend every creator SaaS founder do it.
The opt-out toggle, and what it covers
Article 21 of the GDPR establishes a general right to object to processing. The AI Act extends and reinforces this for AI-touching processing in specific contexts. The clean way to honor both is to give the user a single, plain-language toggle that disables every AI-touching feature in one click.
In Linkette this is the ai_weekly_brief_enabled setting in a creator's account preferences. The name suggests a single feature, but the toggle is more comprehensive than the label implies — when it is off, the Mistral-powered weekly brief is disabled, and the ghost-text completions in the editor are disabled, and the onboarding agent's AI proposals are suppressed in favor of a blank-state flow, and the URL-paste enrichment falls back to non-AI metadata fetching. Every AI surface in the product is gated by that one setting.
I will probably rename the toggle in a future version to make its scope more obvious. The product naming is imperfect. The mechanism is clean.
When the toggle is off, no Mistral API call is made on behalf of that creator. The setting is checked at the boundary of lib/ai, which, as I have written elsewhere, is the only module in the codebase that imports the AI SDK. The check is at the model-call layer, not at the UI layer, which means the protection holds even if a future UI bug accidentally exposes an AI-touching control to a user who has opted out.
Foundation model retraining: opt-in, not opt-out
The most important commercial term in choosing a foundation model provider for a European SaaS is, in my opinion, the retraining policy.
Mistral La Plateforme commits, in its standard terms, that customer prompts and completions are not used to train foundation models without explicit opt-in. This is the position a European founder should expect from a European AI provider, and Mistral honors it.
OpenAI's standard API terms have moved through several positions over the last three years; the present default for API customers is closer to opt-out than opt-in, with various enterprise-tier nuances. The exact language has changed often enough that any specific summary I give you here will be wrong by the time you read it. The structural difference between the two providers, however, has been stable: Mistral defaults to we do not use your data; OpenAI defaults to we do not use your data unless you allow it / and even then with caveats / and the policy has exceptions / please consult the latest version of the terms.
For a creator SaaS, this is the difference between being able to look a user in the eye and say the words you typed into the editor will never train a future model and having to qualify the sentence into uselessness.
Linkette routes every AI call to Mistral. We can make the unqualified statement. Our privacy page makes it.
What ends up in the privacy page
The privacy page at linkette.eu/privacy lists Mistral La Plateforme as a sub-processor, by name, with the country (France), the purpose (AI inference for the editor's writing assistant, the onboarding agent, the link enrichment, and the weekly brief), and a link to Mistral's own terms. We do the same for every other sub-processor: Supabase (Paris, primary database), Scaleway (France, hosting), BunnyCDN (Slovenia, CDN), Brevo (France, transactional email), Plausible (Estonia, analytics), Mollie (Netherlands, payments).
This is not a regulatory requirement at the granularity we use — the GDPR allows for somewhat more abstract disclosure, naming categories rather than vendors. We name vendors because the creator on the receiving end of our processing is entitled, in our view, to know which company is processing what. The auditor in week seven called this over-disclosure in a useful direction.
The AI usage table
Internally, Linkette tracks every Mistral call in a table called ai_usage. Each row records: the creator id, the task type (onboarding, bio_assist, link_enrich, weekly_brief), the model used, the input and output token counts, the cost in euros, the timestamp, and a Langfuse trace id that points to the full prompt and completion in our observability layer.
The table serves three purposes. It powers per-creator quota enforcement. It feeds internal cost accounting — at any moment I can tell you how much AI compute a given creator has consumed and what fraction of revenue that represents. And it provides an audit trail: if a creator ever asks what AI calls did you make on my behalf this month, we can produce a complete list, with task types and timestamps, in a single query.
I am not aware of any creator SaaS today that exposes this level of AI accounting to the user. I would like to, eventually — a show me my AI history surface in the account settings, where a creator can see exactly which features have used the model on their behalf and revisit specific outputs. The schema is there. The UI is not yet built. It is on the list.
Why this is good for creators
A creator on a transparent AI platform can answer their audience honestly. If a fan asks did you write that bio yourself, the answer is I edited what the assistant proposed, and the creator can point to the ✦ convention as the visible mark of that workflow. The relationship is not corrupted by uncertainty about provenance.
A creator can also leave the platform, taking their content with them, knowing exactly what processing was applied to it during their tenure. The data export endpoint includes the AI usage history alongside the page content.
Why this is good for builders
A creator SaaS that has documented its AI Act compliance posture, that ships the transparency markings, that runs on a European foundation-model provider with strong default terms, has a defensible legal position. When a regulator asks, the answers are short and prepared. When a journalist asks, the framing is clean. When a competitor's data practices come under scrutiny in the press, the contrast is your benefit.
The cost of getting there, if you start from the first commit, is small. The cost of retrofitting it onto a year-old platform with US dependencies is, I am told by several founders who are presently doing it, substantial.
I would rather be on the early end of that work than the late end.
If you are building a creator SaaS in Europe and you'd like to compare notes on AI Act implementation — the marking convention, the opt-out architecture, the sub-processor disclosure — write to me at founder@linkette.eu. I am gradually compiling a small reference document for European founders and would welcome additions.