On this page
What OpenAI announced
On 5 October 2026 OpenAI said it will start watermarking eligible text from ChatGPT and Codex for users in the EU over the coming weeks, to comply with the EU AI Act. API customers can turn text watermarking on for select models worldwide today. The announcement extends the image and audio provenance work OpenAI already ships.
What stood out was how plainly OpenAI described the limits. In its own words, a text watermark helps answer one question: was this likely generated by an OpenAI model? It works by embedding an invisible statistical pattern in the choice of words. Short passages are often undetectable. Rewriting or translating the text can remove the mark entirely. And for now, only approved researchers get access to the detector.
That is an honest description of the technology, and it is worth reading twice. A watermark is a probabilistic signal, placed by the model provider, read only by the model provider, and lost the moment someone edits the text. It is the right tool for the question the regulation asks of OpenAI. It is the wrong tool for the question a regulator, a court, or an enterprise customer asks of you.
Why the EU AI Act asks for a watermark
Article 50 of the EU AI Act places a transparency duty on providers of generative models: synthetic text, audio, image and video must be marked in a machine-readable way so that it can be detected as artificially generated. Those obligations apply from 2 August 2026, which is why watermarking announcements are arriving now.
Read the duty carefully. It sits on the model provider, and it is about the content itself: can a reader or a platform tell that this paragraph came from a machine? It says nothing about which organisation deployed the model, what prompt produced the output, when it was produced, or whether the text in front of you is the text the model actually returned.
Those are the questions that matter when an AI output is challenged. They are not provenance-of-the-medium questions. They are evidence questions, and the same Act puts them on a different party: Article 12 and Article 26 require deployers of high-risk systems to keep the automatically generated logs of the system under their control. A watermark does not help you with that obligation at all.
What a text watermark cannot tell you
Take the limits OpenAI listed and ask what each one means for an organisation relying on the watermark as its record.
It cannot survive editing. A contract clause drafted by a model and lightly reworded by a lawyer loses the mark. So does a customer email that a human tidied up, a summary pasted into a different document, or any output run through a translation step. In practice the texts most likely to be disputed are exactly the texts that were edited before use.
It cannot be checked by you. The detector is held by OpenAI and shared with approved researchers. If a counterparty claims a document was machine generated and you need to confirm or deny it, you cannot run the check yourself, and neither can a court. Verification that depends on asking the vendor is not independent verification.
It cannot identify the deployer. The mark says an OpenAI model was likely involved. It does not say which of OpenAI's millions of customers sent the prompt, under which account, in which application. For accountability that is the whole question.
It cannot bind input to output. A watermark lives in the output alone. It carries no information about the prompt, the system instructions, the retrieved context, or the user who triggered the call. You cannot reconstruct a decision from it.
It cannot fix a time. There is no timestamp in a statistical pattern. Whether the text was generated last week or last year is not something a watermark encodes.
It is probabilistic. The detector returns a likelihood, not a fact. In an evidentiary setting, a likelihood from a vendor-held tool that fails on short and edited text is a weak foundation. OpenAI knows this, which is why it described the limits itself.
What proof looks like instead
A cryptographic attestation approaches the problem from the other side. Instead of hiding a signal inside the text and hoping it survives, it records the text, the input, the model, and the time at the moment of generation, and signs that record with a key that belongs to the organisation that made the call.
With Invoance, your application makes one API call after each model response. Invoance computes a SHA-256 hash of the input and a SHA-256 hash of the output, canonicalises the record together with the model provider, model name, model version and any subject context you attach, and signs it with your tenant's Ed25519 key. The record is written to an append-only ledger with a timestamp and returned to you with an attestation id, the hashes, the signature, and your public key.
Each of the watermark's gaps closes. Editing the text afterwards does not weaken anything, because the proof is about what the model returned, and a later edit simply fails to match the recorded hash, which is itself useful information. Verification is public: anyone holding the record and the text can recompute the hash and check the signature against your published key, with no Invoance account and no call to the model vendor. The signature identifies you as the deployer, not merely the model family. Input and output are bound together in one record. The time is fixed when the record is written, not inferred afterwards. And the answer is binary: the record verifies or it does not.
import { InvoanceClient } from "invoance";
// Reads INVOANCE_API_KEY from the environment.
const client = new InvoanceClient();
const att = await client.attestations.ingest({
type: "output",
input: promptSentToModel,
output: modelResponse,
modelProvider: "openai",
modelName: "gpt-4.1",
modelVersion: "2026-04-14",
subject: { userId: user.id, sessionId: conversationId },
});
// Store these next to your own record of the interaction.
console.log(att.attestation_id, att.output_hash, att.signature, att.public_key);
Watermark and proof side by side
The two mechanisms are not competitors. They answer different questions for different people, and a serious AI deployment in the EU will end up with both: the provider's watermark because the Act requires it of the provider, and the deployer's signed record because the Act and every auditor require it of the deployer.
Who places it: the model provider places the watermark. You place the attestation.
What it covers: the watermark covers the output text. The attestation covers input, output, model identity, subject and time.
Who can check it: the watermark is checked by the provider's detector, currently limited to approved researchers. The attestation is checked by anyone with the record, the text and your public key.
What editing does: editing removes the watermark. Editing makes the text fail verification against the attestation, which proves the text changed.
What it says about you: the watermark says nothing about the deployer. The attestation is signed by the deployer's own key.
What the answer looks like: the watermark gives a likelihood. The attestation gives a verified or failed result.
Where it lives: the watermark lives inside the text and travels with it. The attestation lives in a ledger and is referenced by id.
A worked example: a disputed AI-drafted response
A lender uses a model to draft the explanation that accompanies a declined credit application. Eight months later the applicant complains that the explanation they received does not match the reasons on file, and the regulator asks the lender to show what the model actually produced.
With a watermark alone, the lender can say that the letter probably contains model-generated text. It cannot show the prompt, cannot show whether an adviser edited the draft, cannot show when the draft was produced, and cannot run the detector itself.
With an attestation, the lender pulls the record by the attestation id stored against the application. The record carries the hash of the prompt, the hash of the model's draft, the model version, the adviser's user id as subject, and the timestamp. The lender hashes the letter the applicant received and compares. If it matches, the applicant received the model's draft unchanged. If it does not, the lender can show exactly that a human changed the draft after generation, and the application's own audit events show who. Either way the regulator gets a verifiable answer rather than an assertion.
Verifying without trusting anyone
Independence is the property that makes a record useful under challenge. An Invoance attestation can be verified three ways, and none of them requires believing Invoance or the model vendor.
Through the API, by posting the text to the attestation's verify endpoint, which recomputes the hashes and checks the signature. Through the public verification page, which an auditor can open in a browser with no account. Or fully offline, in any of the eight SDKs, which check the Ed25519 signature against the public key locally, with no network call.
The public key is published per tenant and is the same for every record you sign. The signature algorithm is Ed25519. The hash is SHA-256. Nothing proprietary stands between the record and the person checking it, which is the opposite of a detector you have to apply to use.
curl -X POST https://api.invoance.com/v1/ai/attestations/ATTESTATION_ID/verify \
-H "Content-Type: application/json" \
-d '{"input":"<the prompt>","output":"<the text you were handed>"}'
What to do this quarter
If you deploy OpenAI models to EU users, the watermark will arrive on its own. Leave it on. It costs you nothing and it helps the public ecosystem.
Separately, decide which of your model outputs could be challenged: anything that reaches a customer, informs a decision about a person, or ends up in a document someone else relies on. Add one attestation call after each of those generations. Store the attestation id with your own record. Publish your verification key to the people who might need it.
Then, when the first dispute, audit, or regulatory inquiry arrives, you will not be explaining the statistical limits of a watermark. You will be handing over a record that anyone in the room can check.