Does Gemini API text include SynthID, and what does that mean for AI-generated-content disclosure?

Establish the status for the exact output you use

The first mistake is asking whether “Gemini” has SynthID as if it were one product. The answer can vary by modality, product surface, model, and release. A statement about a consumer app does not automatically apply to a developer API. A statement about images does not imply the same thing for generated prose.

Google describes SynthID as a family of technologies for marking and identifying Google AI-generated content. For text, it works by adjusting the probabilities of tokens selected during generation, creating a statistical signal that a detector can assess. It is not a visible sentence appended to the answer, and it need not appear as a field in an HTTP response. Google DeepMind SynthID overview Technical overview of SynthID text

That distinction explains why checking a response body, a browser download, or normal API headers is not a test for a text watermark. Lack of a metadata field does not prove that no generation-time signal exists. Conversely, a provider statement that a consumer product uses a watermark does not prove that a given API model, version, streaming route, or tool-call path is covered.

What Google publicly documents by modality

The table is a documentation map, not an audit of Google’s internal implementation. The important outcome is operational: do not state in a privacy notice, product policy, customer contract, or regulator response that “all Gemini API text is watermarked” unless the provider’s current terms or technical documentation specifically covers the exact model and route you run.

If this property matters to your launch, ask Google through a support or contractual channel for a dated answer that names the model identifier, API surface, output types, effective date, whether all supported regions are covered, whether streaming is covered, and how a customer or regulator can verify a disputed output. Preserve the answer with your release records. A forum reply can be useful context for that request, but it is weaker evidence than an updated product document or contract.

Four different controls that are often called a watermark

These controls solve different problems. Treating them as interchangeable produces both technical and compliance mistakes.

For text, SynthID’s documented design works at token selection. Google says detection confidence is strongest with longer and more varied text. It can decline after thorough rewriting or translation, and factual or formulaic writing can be harder to mark or detect. It should therefore be treated as evidence with uncertainty, not as a universal classifier of every copied sentence. Google DeepMind on text watermarking

Google also publishes an open-source SynthID Text toolkit for developers working with their own generative models. That toolkit shows a model-side logits processor and a probabilistic detector with watermarked, not-watermarked, and uncertain outcomes. It does not document a detector endpoint for arbitrary Gemini API text. Google Responsible AI toolkit

In practice, use an explicit uncertainty state. A detector result of uncertain, an output that has been translated, or an output whose model version was not recorded should be represented as unknown, not as “not AI-generated.” Do not make automated enforcement, authorship accusations, or high-stakes eligibility decisions solely from a text-watermark result.

A disclosure architecture that does not depend on a hidden mark

A watermark may be a useful provider-side control when it is documented, but the application should be designed to explain its own use of AI even when a recipient cannot inspect the watermark.

Visual brief

Create a horizontal five-stage diagram with a clear boundary between provider evidence and application evidence:

[Generation service]
     | model, version, modality, documented marking status
     v
[Application record]
     | request ID, timestamp, output hash, transformation history
     v
[Publication decision]
     | approved, edited by accountable person, restricted, or withheld
     v
[Recipient experience]
     | visible AI disclosure, source links, date, correction route
     v
[After publication]
     | monitoring, correction, retention, audit export

Use blue for provider-supplied facts, amber for “unknown or needs confirmation,” and green for controls the application owns. Add a small callout under the first stage: “Watermark status is not the same as a user label.”

The application record is the practical bridge between an API call and a disclosure. Store only what is necessary and secure it appropriately, because prompts and output can contain personal, confidential, or copyrighted material. A useful record normally includes:

• Model name and version returned or configured for the request.
• API product and modality, such as text, image, video, or audio.
• Generation timestamp in UTC and an internal request or job identifier.
• A cryptographic hash of the original returned output and of the published rendition.
• A release or prompt-template version, without storing more prompt content than the retention policy permits.
• Whether a human materially edited, approved, or took responsibility for the item.
• The exact disclosure shown to users, plus its locale and display surface.
• A supplier-documentation reference and status, such as confirmed, unsupported, or unknown.

An output hash is valuable for internal integrity checks, but it is not a watermark. It changes after an edit and only supports a claim when paired with records the operator can produce. Do not describe a hash, a request ID, or a hidden internal flag as an Article 50-compliant machine-readable mark without legal and technical validation.

EU AI Act Article 50 in practical terms

This section is an implementation-oriented reading, not legal advice. The legally authoritative regulation is available on EUR-Lex, while the European Commission’s AI Act Service Desk provides a readable Article 50 page and current implementation guidance. The Service Desk notes that its displayed article text may not yet reflect amendments, so use the current consolidated law and obtain EU counsel for a production classification. Regulation (EU) 2024/1689 on EUR-Lex AI Act Service Desk Article 50

The Commission says the transparency rules apply from 2 August 2026. Its current materials also describe a transitional period until 2 December 2026 for certain generative AI systems placed on the market before 2 August 2026. Dates and transitional scope need confirmation against the applicable consolidated text and the facts of the system. European Commission quick facts Commission transparency code FAQ

Article 50 separates machine-readable marking from a visible disclosure. A provider-side mark may be imperceptible and machine-detectable. A user-facing notice must be clear, distinguishable, accessible, and supplied no later than the first interaction or exposure where the rule applies. The Commission’s fact page and Code of Practice explain this distinction between provider marking measures and deployer labeling measures. European Commission quick facts Code of Practice for AI-generated content

An organization can be both a provider and a deployer in different parts of its offering. For example, a game studio may be an API customer, a deployer of the supplier’s model, and the provider of its own player-facing AI feature. The legal classification depends on the actual control, intended purpose, distribution, audience, modifications, and jurisdiction. It cannot be decided from the API name alone.

There are exceptions and qualifications in Article 50, including some standard editing and editorial-control circumstances. They are fact-specific. Do not turn an exception into a product default, and do not use a visible “AI assisted” badge to imply that all provider marking requirements have been met.

A compliance-oriented release checklist

Use this checklist before representing a feature as SynthID-marked, compliant, or transparently labeled.

1. Inventory the content path. List every model, API endpoint, modality, fallback provider, streaming route, post-processor, translator, editor, and publishing surface. A product that starts with text but creates narrated audio or promotional images has more than one modality.

2. Set an evidence state per path. Use confirmed only when current supplier documentation or an attestation names the relevant model and route. Use unsupported when the supplier says the feature does not apply. Use unknown when public documentation is silent, conflicting, or not model-specific. Unknown should block a marketing claim about watermarking.

3. Decide the user disclosure separately. Put an understandable label near the AI-produced content or interaction when your legal analysis, platform policy, or user-protection standard calls for it. For an AI character, disclose before or at the beginning of the interaction. For public-facing information, pair the label with dates, sources, and a correction route.

4. Keep a minimum viable generation record. Record model configuration, time, internal request identifier, original-output hash, publication hash, transformations, reviewer, and shown label. Apply access controls, retention limits, and data-protection review to the log.

5. Test transformations. For image, audio, and video paths with a documented detector, test the actual crop, transcode, remix, and export steps your product uses. For text, do not infer a pass from a copied phrase, a missing header, or an unverified detector result. Track original and transformed versions separately.

6. Create an exception route. When a model changes, a provider withdraws a claim, detection becomes uncertain, a transformation strips provenance, or a user challenges content, pause the related claim, preserve the evidence, and route the case to the designated owner.

7. Review the legal role and geography. Map each launch country, the intended audience, public-interest use, interaction design, and accountable editor. Obtain qualified legal review before asserting EU AI Act compliance, particularly for regulated information or high-reach publication.

Example for an EU game studio

Hypothetical setup: A studio uses a Gemini API text model to generate optional non-player-character dialogue. It has found an assertion in a public forum that API text is SynthID-marked, but its current supplier documentation does not name its model or show a way to verify a text response. The studio also sometimes publishes an AI-written community update on its public website.

The studio records the model configuration, request time, original response hash, moderation result, editor, and final dialogue version. Its internal status for text watermarking is “unknown pending supplier confirmation,” so it does not tell players or regulators that the dialogue has SynthID. It tells players at the start of the optional chat that responses are generated by AI, gives them a report route, and labels a published AI-written update when its legal and editorial analysis requires it. A named editor reviews any public update about patches, player safety, pricing, eligibility, or other consequential matters before publication.

The takeaway is not that every game line needs the same visible label. It is that a nonverifiable provider watermark cannot carry the entire transparency program. The studio can prove what it controlled, make an understandable disclosure, and avoid an unsupported technical claim while it obtains evidence about the supplier path.

Failure modes and safer alternatives

If an application gives people information about a deadline, benefit, health service, public registration, eligibility, law, or financial decision, content provenance is only one control. Build source verification, update ownership, human escalation, and a clear statement of the official source. A watermark cannot make a generated answer authoritative.

Limits and decision rule

The documentation landscape can change quickly. Google may later publish an API-text commitment, a detector, an output indicator, or model-specific terms. That would improve evidence, but it would not remove the need to decide when users need a visible disclosure or to keep records of how an item was generated and changed.

Until then, use this decision rule: if you cannot show a current source that names your exact API text path and verification method, do not claim SynthID coverage. Use application-controlled disclosure and audit records, and escalate EU role, scope, exceptions, and cross-border requirements to qualified counsel. Similar transparency, consumer-protection, privacy, platform, and sector-specific obligations may apply outside the EU.