How we made this product Article 50 compliant

Step 1: inventory and classification

We listed every feature that calls a model and classified each one. The scoring diagnostic, the rewriter, and three email-assistant features (drafting, summarizing, folder suggestions) — all built on a third-party model API, which makes us a downstream provider of each. Then the negative checks: nothing we run is a prohibited practice, and nothing is high-risk by intended purpose — a style scorer evaluates text, not people. To keep it that way we wrote the intended purpose down publicly: our limitations page states the tool is not for grading students or screening candidates. That sentence is doing legal work — under Article 25, anyone who repurposes the tool for evaluating people becomes the provider of that new system themselves.

Step 2: disclosure at every AI touchpoint

Article 50(1) wants users told they're dealing with AI at first interaction — and the "obvious from context" exception is read too restrictively to lean on for a consumer product. So we stopped relying on context: the paste box says scoring uses an AI model and names the vendor; the rewriter labels its output as written by the model; every email-assistant action carries an "(AI)" label in all three languages; the consent screens for voice samples name the model that processes them. None of this needed engineering — it's copy, reviewed once per locale.

Step 3: machine-readable marking where feasible

Article 50(2) is where a small product needs judgment. For AI-drafted email we added a real machine-readable marker: every message whose draft originated from the assistant goes out with an X-AI-Assisted mail header naming the model and provider — cheap, robust, exactly what the norm asks for. For rewritten text copied to a clipboard, watermarking simply isn't available to us: our model API exposes none, and no post-hoc scheme survives a copy-paste of short text reliably. The guidelines anticipate this — you aren't obliged to use technology that isn't on the market — but the position only holds if you can show your work. So we wrote a feasibility assessment: what we evaluated, why it's infeasible today, the visible attribution we show instead, and a quarterly trigger to adopt upstream marking the moment our model provider ships it.

Step 4: one compliance file

Everything above lives in a single document in the repository: the system inventory, the classification reasoning, the Article 50(1) measures, the 50(2) feasibility assessment, the Article 4 AI-literacy note, and an open-items list with dates. If a market surveillance authority ever asks, that file is the answer. It also forced the decisions we'd been deferring — like concluding we should notsign the transparency code of practice yet, because its text-watermarking commitment is one we currently can't implement, and a documented non-signatory position beats a signed commitment you can't keep.

What it cost

One focused day: an afternoon of legal reading, a few hours of copy changes across three locales, one small feature (the email header), and the documentation. No lawyers, no consultants, no architectural changes. That's the honest headline for small products: the transparency wave of the AI Act is mostly a discipline problem, not an engineering problem — provided someone has already mapped the terrain.

What's still open

Two things, both flagged with review dates in the compliance file: adopting model-level text watermarking when it exists (and then signing the code of practice), and tracking how national enforcement practice develops for downstream API providers — a question nobody can answer definitively today. If you want this done for your own product, that's exactly what our consulting covers — or start with the free self-check.