Тайвань MODA: три шари маркування AI-зображень — post-BIAIG checklist для Bubble-каталогів

Навіщо це Bubble-розробнику після BIAIG

Я масово генерую або підвантажую AI-зображення товарів у Bubble і віддаю фід на маркетплейс. Один раз зламався pipeline — і compliance довелося добивати руками на тисячах PDP. З того моменту я тримаю в даних те, що downstream платформам потрібно для Layer 1–3, щоб не ганяти bulk знову.

У звітності 25 жовтня 2026 (CNA, Taipei Times, Taiwan News) Міністерство цифрового розвитку Тайваню (MODA, 數位發展部) описало три шари для великих соцплатформ: активне розкриття при завантаженні, автоматичне маркування за вбудованими/прихованими сигналами або ознаками генерації, і канали повідомлень/оскаржень з подальшим маркуванням або видаленням. MODA наголосила на помітності мітки і навела YouTube (мітка в розгорнутому описі) як недостатній приклад. У цих джерелах це ризик-орієнтоване governance щодо deepfake і публічної плутанини — не опублікований технічний стандарт і не те саме, що обов’язкове маркування кожного AI product shot у каталозі продавця.

Окремо від жовтневих новин: обов’язкові правила 網路廣告資訊揭露基準及作業辦法 (чинні з 30 листопада 2024) стосуються регульованих мережевих рекламних платформ — розкриття, коли реклама використовує deepfake або AI-generated personal imagery (人工智慧生成之個人影像); платформи мають вимагати розкриття від рекламодавця при поданні, зазвичай на поверхні оголошення (посилання — лише за обмеженого місця). Джерела з packet не підтверджують, що тришаровий соціальний план MODA поширюється на всі PDP e-commerce; industry-блоги про «немає мандату для всіх product images» — не норма, лише контекст.

Не змішуйте шари: SynthID Detector, OpenAI content_provenance_checks, Google Merchant 2027 / IPTC — інші юрисдикції, актори (platform vs merchant) і шляхи enforcement. MODA тут — platform-compliance framing для того, що ви зберігаєте в Bubble, щоб downstream платформи могли виконати Layer 1–3 без повторного bulk.

Матриця: генерація → ingest у Bubble → експорт

Етап	Що відбувається	Що зберегти (мінімум)
1. Генерація (BIAIG / зовнішній API)	Створення зображення, опційне розкриття merchant	ai_disclosed_by_creator (boolean), ai_disclosure_at, generation_tool, generation_model, biaig_job_id, source_prompt_hash (без PII у логах, якщо не потрібно)
2. Ingest у Bubble	Завантаження, ресайз, CDN, прив’язка до Product	asset_url, ingest_at, metadata_intact_after_processing (boolean), embedded_provenance_detected (boolean/null), detection_run_at, detection_outcome (enum: disclosed / auto_flag / clean / unknown), не перекодовувати без need — Layer 2 на платформах покладається на читабельні вбудовані маркери
3. Експорт на маркетплейс	Фід, API, ручний sync	export_channel, export_at, marketplace_sku, visible_label_required (boolean — ваш policy + platform rules), ad_surface_disclosure (boolean — якщо asset іде в мережеву рекламу з personal imagery), last_pdp_hash для idempotent re-export

BIAIG job log (рекомендовані поля)

Один job — один рядок (абo nested thing), щоб bulk-run можна було переграти або оновити Product без повторної генерації:

• Identity: job_id, product_id, variant_id, batch_id, operator_user_id
• Layer 1 (creator disclosure): merchant_ai_disclosure, disclosure_method (checkbox / API flag / import column), disclosed_at
• Layer 2 (technical): generator_id, model_version, output_has_c2pa_or_watermark (as reported by tool), post_process_stripped_metadata (yes/no), automated_scan_id, scan_label_applied (platform-side — nullable until sync feedback)
• Layer 3 (moderation): report_source, external_case_id, status (open / relabeled / removed / appealed / closed), resolution_at, notes

У Bubble я тримаю історію job log окремо від поточного Product image URL: після bulk змінюється лише pointer + audit trail. Про це окремо: ChatGPT virtual try-on і shopping.

Product type (каталог)

На Product (або ProductImage child type):

• primary_image_ai_status — enum: undisclosed | merchant_disclosed | system_labeled | disputed | not_ai
• ai_provenance_summary — короткий text для internal ops (не замінює visible label на PDP, якщо платформа вимагає UI)
• taiwan_ad_personal_imagery — boolean + ad_disclosure_supplied_at лише якщо цей asset реально йде в Taiwan-regulated network ads з personal imagery (під Nov 2024 rules — не автоматично для всіх packshots)
• marketplace_export_ready — boolean; false, якщо metadata_intact_after_processing = no і channel вимагає Layer 2
• linked_biaig_job_id — зв’язок one-to-many через log

Workflow: після bulk-run один scheduled workflow «reconcile export flags» по batch_id, не N окремих API calls на PDP.

Post-BIAIG checklist (15 хвилин на batch)

1. Розділити planned vs binding: жовтень 2026 — 擬推 / planned push до Meta, Google, LINE; не описуйте клієнту це як чинний catalog law без primary instrument (див. open questions у packet).
2. Layer 1: чи в BIAIG/API є явний merchant disclosure для batch? Якщо ні — зафіксуйте merchant_ai_disclosure = false і policy «не експортувати на TW social без review».
3. Layer 2: перевірте pipeline ingest — чи JPEG/WebP re-encode знімає embedded provenance? Якщо так — post_process_stripped_metadata = yes і не обіцяйте auto-label downstream.
4. Layer 3: чи є поле для external_case_id після скарги на маркетплейсі? Bulk-update ai_provenance_summary + primary_image_ai_status, не замінюйте файл без audit.
5. Реклама vs каталог: asset у network ad з AI personal imagery — окремий шлях disclosure на ad surface; звичайний product render ≠ автоматично «personal imagery» (сіра зона — legal review).
6. Помітність: metadata в Bubble не замінює visible label на платформі; MODA вимагає «明顯» без фіксованого UI spec у news — плануйте channel-specific display окремо від job log.
7. Не дублюйте інші compliance-треки: IPTC/Google Merchant 2027 — parallel fields або mapping table, не перезапис одним boolean «compliant_globally». Про це окремо: Sync, async і batch для.

Крок	Навіщо / перевірка	Не робити / якщо ні
Planned vs binding	Жовтень 2026 — 擬推 / planned push до Meta, Google, LINE	Не описувати клієнту як чинний catalog law без primary instrument (open questions у packet)
Layer 1	Чи в BIAIG/API є явний merchant disclosure для batch?	Якщо ні — merchant_ai_disclosure = false; policy «не експортувати на TW social без review»
Layer 2	Pipeline ingest: чи JPEG/WebP re-encode знімає embedded provenance?	Якщо так — post_process_stripped_metadata = yes; не обіцяти auto-label downstream
Layer 3	Чи є поле external_case_id після скарги на маркетплейсі?	Bulk-update ai_provenance_summary + primary_image_ai_status; не замінювати файл без audit
Реклама + помітність	Network ad з AI personal imagery — окремий disclosure на ad surface; product render ≠ автоматично «personal imagery»	Metadata в Bubble не замінює visible label; MODA «明顯» — channel-specific display окремо від job log (сіра зона — legal review)
Інші compliance-треки	IPTC / Google Merchant 2027	Parallel fields або mapping table; не один boolean compliant_globally

Чесні межі (з Scout packet)

• Немає в packet primary MODA document, що кодує Oct 2026 mechanism з датами enforcement для e-commerce catalog operators.
• Industry статті про «no mandate for all AI product images» — verify перед normative claims; опирайтесь на MODA law pages для реклами.
• March 2026 MODA timeline (stakeholder guidance до кінця року) — окремий процес від жовтневого three-layer reporting.

Джерела (лише з packet)

CNA 2026-10-25; Taipei Times; Taiwan News; TechNews 2026-03-13; law.moda.gov.tw EngLawContent id=79; MODA press 14562, 12666, 12648; Lexology commentary; Trustpass industry blog (обережно).

---

Стаття для внутрішньої методології Bubble-розробника; не юридична порада і не публікація назовні.