The easiest version of AI content disclosure is a line in the privacy policy and a hope that nobody checks. We did not want the easiest version. EU AI Act Article 50 transparency duties apply from August 2 — we spent early June mapping our obligation surface and determining we are a provider, not just a deployer, for our AI-powered features. The first surface to ship disclosure is this blog: every AI-generated post now carries a machine-readable stamp, and a CI guard makes sure it cannot silently disappear.
Article 50(2) of the EU AI Act requires providers of AI systems that generate synthetic text to mark outputs as machine-readable and detectable as artificial — effective, interoperable, robust, reliable, and technically feasible. The Act is realistic about the limits of text watermarking: short outputs, copy-paste, paraphrase — none of these can be reliably watermarked at the content layer. What the regulation asks for is a genuine attempt at disclosure, not a pixel-deep footnote and not a terms-of-service clause nobody encounters until something goes wrong. The obligation date is August 2, 2026. The EU AI Office is simultaneously shaping a voluntary Code of Practice to define what robust and interoperable look like in practice — but the obligation does not wait for the Code.
The reflex when you integrate a third-party model is to treat compliance as the model vendor's problem. The Act's value-chain logic does not work that way. Anthropic is the provider of the foundation model. Dekimu is the provider of the AI systems — Builder, Reply Assistant, ecosystem AI answers — that ship under Dekimu's name to business customers. The system-level marking obligation sits at the Dekimu boundary regardless of whether the upstream model emits its own mark. We verified the provider determination against the live regulation text, confirmed that we cannot fully offload 50(2) to Anthropic, and decided to plan marking at our own boundary rather than assume it flows down from the API.
The provider-versus-deployer line is where most integrators will find they have more obligation than they assumed. Reading the regulation before August is the version of this problem you want.
The clearest surface is this blog. We run an autonomous cron that generates and publishes posts several times a week — AI-written, reviewed by a structural gate, auto-merged when they pass. Every cron-generated post now carries an aiGenerated field in its metadata, machine-readable by any tool that ingests the page. A CI parity guard runs weekly to verify that no cron post has slipped through without it. We started here because it is the simplest, most auditable case, and because compliance infrastructure that stays honest under automation has to be wired in from the start — not added as a layer on top.
The broader Hub AI surfaces each carry a different marking question, because what survives depends on the carrier. A Builder draft published to a public dekimu.site page can carry a signed provenance record — a cryptographic attestation that the page was AI-assisted, verifiable independently of the text itself, and the approach we think holds up best against the Act's robustness criterion. A reply draft the user copies into their own email client cannot carry anything once the text leaves the application boundary. The Act's 'as far as technically feasible' qualifier is load-bearing for exactly these cases. We are working through each surface in priority order, led by published-page cases where a detached, tamper-evident provenance receipt is realistic. The goal in each case is the same one we keep coming back to: disclosure as a property of the infrastructure, not a claim in the documentation.
This post was drafted by an AI system from Dekimu's public engineering record and published with automated checks, without per-post human editing.
← Back to blog