SynthID Detector і Bubble після BIAIG: семплінг, квота ~10/день, pass/fail/retry

Контекст

7 жовтня 2026 Google відкрив SynthID Detector для всіх на synthid.com (англійський UI). Завантажуєш зображення, відео або аудіо — інструмент каже, чи є SynthID watermark від підтримуваних партнерів. Це не відповідь на питання «згенеровано ШІ чи ні» взагалі. Партнери з боку Google: Google, OpenAI, NVIDIA, Kakao; Apple — «скоро». Цифри масштабу розгортання watermark у матеріалах Google (180B+ images/videos, 240k years audio) не означають, що кожен asset у вашому каталозі можна верифікувати.

У мене Bubble-каталоги після bulk BIAIG — і synthid.com я бачу як додатковий шар QA, а не заміну OpenAI content_provenance_checks. Через API я автоматизую сигнали OpenAI (C2PA + SynthID на images; SynthID на audio). На synthid.com лишаю ручний семплінг, коли постачальники ширші за OpenAI-only, або C2PA могли зірватися при експорті/thumbnail, а watermark ще може бути. Про це окремо: FLUX 3 Image −50% до. Про це окремо: FLUX 3 Image −50% до.

Що означають результати (не переплутати)

Офіційний FAQ synthid.com:

Watermark detected — ймовірно контент з SynthID-enabled generation/editing у scope партнерів.
Watermark not detected — немає впевненого сигналу; це не доказ «людського» походження і не виключає AI з моделей поза SynthID.

На відео/аудіо можуть бути сегменти з watermark. Стиснення, редагування, низька якість експорту погіршують сигнал; рідкі false positives Google визнає. Потрібен sign-in (Google, Apple або OpenAI — за вторинними джерелами).

Квота: Gemini Help документує ~10 перевірок на модальність / 24 год (rolling window) з лімітами розміру/тривалості; преса (Ars Technica, з посиланням на Google) описує подібну ~10-check/day квоту на synthid.com і можливе швидше спрацювання лімітів на near-duplicate uploads (anti–watermark-removal логіка, за словами інженерів журналістам). Публічний UI простіший за pro-версію (без region-level highlighting — Ars).

API: у первинних матеріалах Google для synthid.com self-serve HTTP API не знайдено — batch у Bubble через офіційний Google endpoint я не планую; OpenAI API лишається програмним шляхом для OpenAI-origin assets. Схожий розбір: Bubble.io і bubble.io price: який. Схожий розбір: Bubble.io і bubble.io price: який.

Post-batch QA workflow у Bubble

1. Розділіть автомат і ручний семпл

Шлях	Коли	Що перевіряє
OpenAI `POST /v1/content_provenance_checks`	Генерація/редагування через OpenAI у вашому BIAIG pipeline	OpenAI signals; `not_detected` — inconclusive (як у доках)
synthid.com (ручно)	Multi-vendor SynthID, spot QA, підозра на stripped C2PA	Partner SynthID only

Gemini in-app verification (доки наголошують Google-only scope) я не змішую з multi-partner synthid.com.

2. Які SKU rows семплити після BIAIG

При ~10 checks/account/day exhaustive row verification неможливий — це editorial/ops вибір, не вимога вендора. Мій практичний мінімум:

Перший рядок кожного нового SKU (hero image + primary video/audio, якщо є).
Variant rows після зміни prompt/model/post-processing (новий batch chunk).
Ad-variant export candidates — 100% семпл у межах денної квоти або пріоритетні SKU за revenue/risk.
Після агресивного compression для catalog thumbnail — retry на найвищій якості source file (Google рекомендує highest-quality uploads).
Mixed workflows (людина + AI edit): я не блокую автоматично лише через detected — можливі false positives; ставлю human review flag.

Тримаю internal mapping: який model/export pipeline для рядка — очікуваний SynthID, C2PA-only, чи нічого (open question з packet; без внутрішньої схеми coverage % не вигадую).

3. Запис у Bubble: pass / fail / retry

Додаю до catalog row (або QA subtable) поля:

provenance_openai_status — enum з API (detected / not_detected / error / skipped_not_openai).
synthid_spot_status — pass_detected | fail_not_detected_inconclusive | retry_quality | retry_quota | manual_review | not_sampled.
synthid_checked_at, synthid_checker_account_id (ops), synthid_source_file_url (master, не thumbnail).
synthid_notes (segment timestamps для A/V).

Семантика gates:

not_detected / fail_not_detected — не auto-pass для publish; inconclusive за дизайном Google і OpenAI.
retry_quality — re-export без додаткового стиснення; повторна перевірка на master.
retry_quota — черга на наступне 24h вікно або інший verifier account лише з ops policy (multi-account може суперечити anti-abuse intent — risk note).

4. Коли блокувати publish до catalog або ad-variant export

Блокую (hard stop або workflow «Needs review»):

OpenAI API error на обов’язковому OpenAI-origin рядку без fallback policy.
Політика бренду/compliance вимагає provenance, а рядок not_sampled у high-risk cohort.
Повторний inconclusive після retry_quality на master.

Не блокую автоматично лише через:

watermark detected на mixed/legitimate pipeline (false positive risk).
not_detected як «доказ без AI» — небезпечно (coverage gap).

Ad-variant export: тримаю gate «останній spot-check ≤ N днів» для sampled cohort; для несемплованих — або defer export, або приймаю documented risk.

Ризики (коротко)

Багато AI-систем без SynthID — negative result не очищає рядок.
synthiddetector.com (third-party Inspect API) ≠ Google synthid.com — endpoints не плутаю.
Retry loops не використовую як adversarial watermark probing (Google rationale для rate limits, за пресою).
Detector не доводить human origin; не замінює licensing, consent, brand QA.

Підсумок

Після BIAIG bulk: автоматизую OpenAI там, де stack OpenAI; statistical synthid.com sampling для multi-vendor і C2PA-stripped сценаріїв; у Bubble — чесні статуси pass/fail/retry з inconclusive negatives; publish/export блокую за policy + repeated inconclusive, а не за illusory «AI-free» not_detected. Поруч із цим: OpenAI Decisions API (preview): класифікація. Поруч із цим: Після 8.10: FLUX 3 Image.

Джерела (digest + Scout): Google blog 2026-10-07, synthid.com, DeepMind SynthID, Gemini Help quotas, OpenAI Content Provenance, Ars Technica.