Preamble: governing law and forum

Ambroot is a Belgian company. This Privacy Policy is governed by the laws of Belgium and incorporates the General Data Protection Regulation (Regulation (EU) 2016/679, the GDPR) and its Belgian implementation, the Belgian Data Protection Act of 30 July 2018. For business creators contracting with Ambroot on a professional basis (B2B), Belgian law applies and any disputes are submitted to the courts of Brussels. For consumer creators (B2C), the mandatory protections of the creator's country of habitual residence apply under Article 6 of Regulation (EC) No 593/2008 (Rome I), and the consumer creator may bring proceedings in the courts of their habitual residence under Article 18 of Regulation (EU) No 1215/2012 (Brussels Ia).

Ambroot is a Digital Content and Digital Service provider within the meaning of Directive (EU) 2019/770 (the Digital Content Directive). Material modifications to the Service follow Article 19 notice rules as operationalised in sections 3.7 and 8.2 below.

0. Who we are and how to contact us

‘Ambroot BV’ (hereafter 'Ambroot', 'we', 'us', or 'our') is a besloten vennootschap incorporated under the laws of Belgium. Ambroot operates a Software-as-a-Service platform that ingests creator-account, content-metadata, and audience-engagement data from YouTube, TikTok, Instagram, and Facebook on the creator's instruction, presents that data on a unified dashboard, and generates customised insights through a Large Language Model operated by Anthropic. The Service is described in further detail in the Ambroot Terms of Service. Ambroot is established in the European Union; the designation of an Article 27 GDPR representative is therefore not required.

• Legal name: Ambroot (the legal entity is currently being incorporated as Ambroot BV; KBO and VAT numbers will be published here upon registration).

• Registered office: Elfenstraat 8, 2800, Mechelen, Belgium

• Enterprise number (KBO/BCE):

• VAT number (BTW/TVA):

• RPR/RPM: RPR Antwerpen, afdeling Mechelen

Ambroot is the controller of personal data within the meaning of Article 4(7) GDPR, except where this Privacy Policy expressly states that Ambroot acts as a processor on behalf of a creator (see section 2.2) or as a joint controller under Article 26 GDPR.

0.1 Contact channels

• Primary privacy contact: privacy@ambroot.com

• General contact: info@ambroot.com

Ambroot acknowledges receipt of any privacy enquiry within 5 working days and responds within one month of receipt, in line with Article 12(3) GDPR. Ambroot may extend the response window by up to two additional months for complex or numerous requests, with notice to the requester within the first month, stating the reasons for the extension.

0.2 Language regime

This Privacy Policy is published in English only at v1 launch. The English version is the authoritative legal text for all creators. For B2C consumer creators, the mandatory consumer-protection rules of the country of habitual residence continue to apply by operation of Article 6 of Regulation (EC) No 593/2008 (Rome I), as stated in the Preamble; where those mandatory rules require communication in the consumer creator’s official language, Ambroot will provide a translation of the relevant sections of this Privacy Policy on individual request via privacy@ambroot.com within the Article 12(3) response window. Ambroot may publish translations post-launch; until then, no translation is offered as standard and the English text governs.

0.3 Data Protection Officer

Ambroot has assessed its processing operations against Article 37(1) GDPR and concluded that the designation of a Data Protection Officer is not mandatory: Ambroot is not a public authority, its core activities do not involve large-scale regular and systematic monitoring of data subjects, and it does not process special categories of personal data on a large scale. The assessment is documented in Ambroot's internal Record of Processing (section 9) and is reviewed at least annually and on every material change to a processing operation.

1. Scope of Processing

Ambroot processes creator account data, content metadata, and audience-engagement data ingested from YouTube, TikTok, Instagram, and Facebook. Processing serves two distinct purposes: (a) Layer 1 ingestion and presentation (the creator dashboard showing per-platform metrics with per-platform attribution preserved) and (b) Layer 2 LLM analysis (the creator receives customised insights and benchmarks computed by Anthropic's LLM on the creator's own ingested data and on anonymised aggregate pools).

Each platform's data flow is governed by that platform's own developer terms in addition to GDPR. The four platform-specific compliance frameworks are integrated below.

Ambroot maintains a clear separation between Layer 1 raw-data presentation and Layer 2 LLM-derived analytics so that creators can opt out of Layer 2 without losing Layer 1. The opt-out moves the creator to a Layer-1-only mode in which platform metrics remain visible but no LLM insights are generated.

2. Lawful basis per layer (GDPR Article 6, Article 28)

2.1 Creator-account data

Categories: YouTube creator ID, TikTok creator ID, Instagram username, Facebook page ID, account email, account-creation date, and subscriber or follower counts per platform.

Lawful basis: GDPR Article 6(1)(b) (performance of contract).

Where processing is necessary for the security, integrity, or improvement of the Service beyond strict contract performance, Ambroot relies on GDPR Article 6(1)(f) (legitimate interest), with a Legitimate Interest Assessment available on request.

Ambroot acts as controller for this data.

This Privacy Policy discloses: data categories, retention period per platform, purposes (service delivery, creator dashboard), and the creator's rights (access, erasure, portability).

2.2 Content metadata

Categories: per-platform video and post metadata, captions, view counts, upload dates, sound or effect usage on TikTok, post engagement.

Lawful basis: GDPR Article 6(1)(b) (performance of contract).

Controller-vs-processor framing: Ambroot is processor on behalf of the creator (creator equals controller of own content) when processing only per the creator's documented instructions. Ambroot becomes joint controller under Article 26 for any downstream uses of creator content (product analytics, model improvement, brand reporting) where such uses are not strictly necessary for contract performance.

Downstream-use position: as of the effective date of this Privacy Policy, Ambroot does not operate model-improvement or brand-reporting flows that fall under joint-controller framing. Ambroot operates consent-gated product analytics in the signed-in application via PostHog (see section 10.4); that processing covers product-usage telemetry (page views and feature-interaction events) tied to the creator's account identifier and account email, and does not process creator content, audience-engagement data, or platform-sourced data. It runs only on the creator's explicit opt-in consent under Article 6(1)(a); Ambroot is controller and PostHog is processor under an Article 28 arrangement, so the flow does not attract joint-controller framing under Article 26. Vercel Web Analytics on the marketing site operates cookielessly and processes no creator personal data (see section 10.4). Anthropic is contractually prohibited from training models on Customer Content under the Anthropic Commercial Terms of Service (see section 3.4); Ambroot operates no internal model-training or offline LLM-evaluation pipeline that retains creator prompts or responses. The brand-visibility flow described in section 8.1 operates under Article 6(1)(a) creator consent with a logged consent record, not under joint-controller framing. If any future flow would attract joint-controller framing under Article 26 GDPR, it will be added to the Record of Processing (section 9), surfaced to creators in advance per the material-change procedure in section 3.7, and made the subject of a separate Article 26 joint-controller arrangement with the creator where required. Ambroot does not rely on Article 6(1)(f) legitimate interest as an undocumented downstream basis.

Operational discipline on LLM inputs: Ambroot's processing pipeline does not persist creator prompts or LLM responses to disk; only operational metadata (token counts, cache hit rates, character lengths) is logged. The Anthropic SDK's prompt-caching mechanism may retain prompts ephemerally at Anthropic's edge for up to five minutes to serve cache hits; this is a vendor-side operational cache and is subject to the Anthropic Data Processing Addendum described in section 3.4.

2.3 Audience-engagement data

Categories: aggregated audience numbers (viewer counts, demographic distributions where exposed by platform APIs in non-identifiable form). Ambroot does not ingest individual viewer records.

Lawful basis: GDPR Article 6(1)(b) (performance of contract). No Article 6(1)(f) legitimate-interest path is asserted because audience data is non-identifiable; no profiling of individual audience members occurs.

Audience-member transparency: Ambroot does not directly notify audience members because the data is non-identifiable; each platform's own audience-information notices apply at the source.

Data-subject-rights position: where audience-engagement data has been irreversibly aggregated and Ambroot has no means (alone or combined with another party) to re-identify individual audience members, that data falls outside the GDPR's personal-data scope and Articles 15 to 22 do not apply to it. If a creator or audience member presents evidence that identification is possible, Ambroot will assess the request on a case-by-case basis and apply the rights accordingly.

3. Layer 2 LLM analysis with Anthropic: lawful basis, Article 22 safeguards, vendor relationship

3.1 Processing operation

Ambroot feeds ingested platform data (YouTube, TikTok, Instagram, Facebook) into an LLM operated by Anthropic that returns customised insights and feedback to the creator. Layer 2 LLM analysis includes:

• Per-creator insights computed from the creator's own platform data (engagement trends, content suggestions, audience profile summaries).

• Comparative and benchmark insights computed against aggregated, non-identifiable data pools across the Ambroot creator population. The LLM does not rank individual creators against named other creators and does not expose individual creator identities in benchmark outputs.

3.2 Lawful basis

GDPR Article 6(1)(b) (performance of contract) is the primary basis for delivering insights to the creator.

Ambroot relies on Article 6(1)(f) (legitimate interest) for the use of fully anonymised aggregate insights to improve Ambroot's own product, with a documented Legitimate Interest Assessment made available to creators on request. Ambroot does not use creator data to train or fine-tune Anthropic's models or any other model under this basis; that scope would require separate Article 6(1)(a) consent (see Annex A).

3.3 Article 22 framing (automated decision-making)

Ambroot's Layer 2 LLM outputs are advisory insights only; no automated decision is taken based on the LLM output alone. A human reviewer (Ambroot or the creator) is required before any decision affecting the creator's account, ranking, or visibility is taken. Article 22 protections (right not to be subject to a solely automated decision, right to human intervention, right to express views, right to contest) are not strictly applicable to advisory insights but are surfaced as transparency measures in section 6.6 of this Privacy Policy. See section 6.6 for the operational mechanics of these rights.

If Ambroot's product roadmap introduces automated decision effects (auto-ranking for brand deals, auto-matching, auto-suspension), Article 22 becomes mandatory and this section requires re-drafting. See Annex A.3.

3.4 Controller-to-processor relationship with Anthropic

Where Ambroot uses Anthropic's Claude API and related commercial services to operate features of the Service, Ambroot is the controller and Anthropic Ireland, Limited (the EEA-established Anthropic entity that contracts with EEA customers under Anthropic's Commercial Terms of Service) acts as processor. Onward processing within the Anthropic group, including any transfer to Anthropic, PBC (United States), is governed by the Standard Contractual Clauses incorporated into the Anthropic Data Processing Addendum.

The processing relationship is governed by the Anthropic Data Processing Addendum (effective 24 February 2025), incorporated by reference into the Anthropic Commercial Terms of Service (effective 17 June 2025) and accepted by Ambroot. The DPA operationalises Article 28(3) GDPR as follows:

• Documented-instructions-only processing (DPA Section B.2).

• Duty of confidentiality on authorised personnel (DPA Section B.7).

• Article 32 technical and organisational security measures set out in DPA Schedule 2 (DPA Section E.1).

• General written authorisation for sub-processors listed in DPA Schedule 4 and at https://www.anthropic.com/subprocessors, with reasonable advance notice for new sub-processors and a 15-day Ambroot objection window (DPA Sections C.1 and C.3).

• Assistance with data-subject rights, including forwarding of any Data Subject Request received directly by Anthropic (DPA Section D).

• Assistance with security obligations, DPIAs, and supervisory-authority consultation (DPA Sections B.6 and G).

• Personal Data Breach notification by Anthropic without undue delay and in any event within 48 hours of becoming aware (DPA Section G.1), giving Ambroot a 24-hour buffer against the GDPR Article 33 72-hour deadline for notifying the Belgian Gegevensbeschermingsautoriteit.

• Return or deletion of Customer Data within 30 days of termination, subject to mandatory legal-retention exceptions (DPA Section H.1).

• Audit rights via annual external audits (for example SOC 2 reports) on written request, and a customer-cost direct-audit right (DPA Sections F.1 and F.2). Anthropic's current certifications are listed at https://trust.anthropic.com/.

Transfers of Personal Data from the EEA to third countries within the Anthropic group are governed by the Standard Contractual Clauses (Module Two controller-to-processor, and Module Three processor-to-processor where applicable) approved by European Commission Implementing Decision (EU) 2021/914, with governing law of the Republic of Ireland. The technical and organisational measures set out in DPA Schedule 2 and the transfer-impact-assessment-cooperation duty in DPA Section C.4 operate together as the supplementary protection layer for the Schrems II framework.

Retention by Anthropic on the commercial Anthropic API:

• Default 30 days for inputs and outputs after receipt or generation.

• Up to 2 years for inputs and outputs, and up to 7 years for the trust-and-safety classification scores, where content is flagged by Anthropic's classifiers as violating Anthropic's Usage Policy.

• 5 years where Ambroot submits product feedback to Anthropic. Ambroot does not submit feedback containing creator personal data.

• Longer where the Anthropic Files API is used 'under the customer's control'. Ambroot does not use the Anthropic Files API for creator personal data.

• Longer where applicable law requires.

Anthropic is contractually prohibited from training models on Customer Content under Anthropic Commercial Terms of Service Section B, which states that Anthropic may not train models on Customer Content from the Services. This commercial-contract prohibition is stronger than a privacy-policy-level commitment.

Ambroot will pursue a Zero Data Retention arrangement with Anthropic where commercially feasible. ZDR, if granted, suppresses input-and-output retention but preserves Trust-and-Safety classifier results retention by Anthropic. ZDR availability is enterprise-tier and subject to Anthropic approval.

The Anthropic DPA and its SCCs are governed by the law of the Republic of Ireland. Anthropic's liability under the Commercial Terms is capped at fees paid in the prior 12 months and excludes consequential damages; Ambroot's commitments to creators in this Privacy Policy are Ambroot's own obligations and do not flow contractually from Anthropic.

3.5 LLM data retention

• LLM inputs deleted from Ambroot's processing pipeline within 24 hours of analysis completion.

• LLM prompts retained alongside outputs for reproducibility.

• LLM outputs retained for the creator's access for 24 months from generation, then deleted or anonymised.

• Anonymised aggregate insights are retained for as long as they remain useful for Ambroot product analytics, subject to an annual review against EDPB anonymisation guidance (irreversibility, no singling-out, no linkability, no inference). Aggregates failing this review are deleted or further aggregated to restore irreversibility.

3.6 Privacy Policy disclosure

This Privacy Policy names Anthropic as the LLM vendor and explains that Anthropic receives the creator's platform data to generate insights, subject to Anthropic's published Privacy Policy and DPA terms. Ambroot publishes Anthropic's current Privacy Policy URL and DPA URL on its Trust page, refreshed whenever Anthropic publishes a material update. The creator may opt out of Layer 2 LLM analysis and receive Layer 1 raw-data presentation only; the opt-out mechanism is described in section 6.6.

3.7 Sub-processor change notification

When Ambroot adds, removes, or substitutes a sub-processor (including the LLM vendor Anthropic), the creator is notified by email at least 30 days in advance of implementation. Ambroot also publishes its current sub-processor list at a stable URL on the Ambroot Trust page; the page is updated at the same time as the email notice.

The creator may object within those 30 days on reasonable grounds relating to compliance with applicable data protection laws, by emailing privacy@ambroot.com. During the objection window Ambroot may, at its discretion, suspend the affected service component pending resolution. If the objection is not resolved within the 30-day window, Ambroot either:

• (a) maintains the existing sub-processor for that creator's account where technically feasible, or

• (b) terminates the affected service component for that creator with a pro-rated refund of unused fees.

This mechanism aligns with GDPR Article 28(2) and (4) and the Belgian implementation thereof under Article 28 WVV (Wetboek van Vennootschappen en Verenigingen). The corresponding contractual mechanic lives in the Ambroot Terms of Service sub-processor change clause; in the event of any inconsistency between this Privacy Policy and the Terms of Service, the Terms of Service govern.

Anthropic carve-out: Anthropic's own Data Processing Addendum (see section 3.4) provides Ambroot with 'reasonable notice' of any new Anthropic sub-processor rather than a fixed-period commitment. Where Anthropic provides notice shorter than 30 days, Ambroot forwards the full notice to creators as soon as Ambroot receives it and provides the longest objection window that the residual notice period allows. In every other respect (objection grounds, suspension permission, maintain-or-refund remedy), the section 3.7 mechanism applies to Anthropic-side sub-processor changes.

3.8 How the LLM analysis works (Article 13(2)(f))

The Layer 2 LLM operated by Anthropic receives, as input, the creator's platform data (engagement metrics, content metadata), and a prompt prepared by Ambroot describing the analytical task (for example, evaluating a brand-deal offer, summarising audience composition, or suggesting a counter-offer range). The LLM produces a natural-language output that is presented to the creator as an advisory insight. The LLM does not access external sources beyond the data Ambroot supplies in the prompt, does not retain creator data beyond the windows set out in section 3.4, and does not make any decision affecting the creator's account, ranking, visibility, or eligibility for any feature of the Service. The creator may at any time disable Layer 2 LLM analysis and continue to use Ambroot in Layer 1 raw-data mode (section 3.6).

4. International transfers (Articles 44 to 46, Schrems II)

4.1 Per-platform routing

Where a recipient of EU personal data is DPF-certified on the date of verification (Ambroot verifies before each onboarding and at renewal), Ambroot relies on the EU-U.S. Data Privacy Framework as the primary transfer mechanism, with Standard Contractual Clauses as a fallback. Per-platform posture as of capture date 2026-05-16:

• YouTube data: ingested from Google (US-headquartered, DPF-certified). Primary mechanism: DPF; fallback: Google Cloud SCCs. Onward routing from Google API to Ambroot platform requires an additional Article 46 transfer mechanism.

• TikTok data: ingested from TikTok per TikTok's API and data-residency policy. SCCs plus Schrems II supplementary measures apply if TikTok-routed data lands in a non-EEA Ambroot platform.

• Instagram and Facebook data: ingested from Meta (US-headquartered, DPF-certified). Primary mechanism: DPF; fallback: Meta SCCs.

• Anthropic LLM processing: Anthropic is US-headquartered and is not certified under the EU-U.S. Data Privacy Framework as of capture date 2026-05-16 (verified 2026-05-17 against Anthropic's Privacy Center compliance listing dated 2026-03-16, which enumerates HIPAA-ready, ISO/IEC 27001:2022, ISO/IEC 42001:2023, and SOC 2 Type I and II as Anthropic's current certifications and does not include the EU-U.S. DPF). Ambroot relies on the Standard Contractual Clauses incorporated into Anthropic's published DPA plus Schrems II supplementary measures, as set out in section 3.4.

4.2 Ambroot platform hosting

Ambroot platform is hosted in the EEA. The frontend runs on Vercel; the backend runs on Railway in the EU West region. No additional transfer mechanism beyond the platform-API and Anthropic SCCs (see section 4.1) is required for Ambroot's own hosting layer. Vercel and Railway are listed as Ambroot sub-processors and are covered by the sub-processor change notification mechanism in section 3.7.

5. Retention by platform and data category

This section sets out Ambroot's retention policy by data category. The matrix in section 5.2 lists every category of personal data Ambroot processes, the lawful basis for retaining it, the storage location, the active and post-account-closure retention periods, the driver that determines those periods, and how Ambroot handles an Article 17 right-to-erasure request against each category. The platform-specific cache durations in section 5.1 are an upper bound on how long source-platform data sits in Ambroot's cache layer and apply alongside the matrix. Subsequent updates to the matrix are version-tracked on the Ambroot Trust page.

Retention principles

• Article 5(1)(e) GDPR storage-limitation drives the minimum retention for every category.

• Article 17(3) GDPR carve-outs preserve data strictly necessary for the establishment, exercise, or defence of legal claims, for compliance with a legal obligation, or for other Article 17(3) grounds. Each carve-out is named per category in the matrix.

• Belgian Code of Economic Law Article III.86, BTW-Wetboek Article 60, and Belgian Income Tax Code Article 315 impose a 7-year minimum on accounting, VAT, and direct-tax records. Where a category overlaps with these obligations, the post-account-closure retention is the longer of the matrix default and the statutory 7-year floor for the slice that is itself a statutory record.

• Hard-deleted means destroyed beyond practical recovery in production systems; backup-tape rotation completes deletion within 30 days aligned to Ambroot's backup policy.

• Anonymised means processed to a state that satisfies the EDPB anonymisation four-test (irreversibility, no singling-out, no linkability, no inference). Once anonymised, the data falls outside GDPR scope and is retained for as long as the test continues to hold under annual review.

5.1 Platform-specific cache durations (operational layer)

• YouTube channel statistics refreshed at least every 24 hours; video-level metrics refreshed per the YouTube Data API Developer Policies III.E.4 tiers; Authorized Data is subject to the 30-day re-authorisation check described below — Ambroot verifies the creator's OAuth grant remains valid via a daily background job, and Authorized Data is deleted within 30 days of a verified revocation; Analytics API and Reporting API data may be stored longer subject to the same re-authorisation check.

• TikTok cached metadata is capped at 30 days as Ambroot's operational commitment; the Display API access-token refresh cycle is documented at approximately every 12 hours per the TikTok Display API Get Started documentation, and Ambroot's background-job cadence is aligned to that cycle. Authorised data is cached for the active session only. The underlying retention rule is governed by the TikTok Developer Terms of Service (https://www.tiktok.com/legal/page/global/tik-tok-developer-terms-of-service/en); Ambroot re-verifies that rule on the schedule set in section 3.7 and tightens its operational cap below 30 days if the platform publishes a stricter rule.

• Meta Insights data is refreshed on a sliding cadence — typically within 24 hours for fresh content, scaling out to weekly for older content — in line with Meta's Platform Terms §3.d obligation to delete Platform Data when no longer necessary; Meta account data is refreshed at least every 7 to 30 days depending on the data category; Meta Stories are tracked per story lifecycle.

5.2 Per-category retention matrix

The matrix below lists eighteen categories of data Ambroot processes. Each category is described with its lawful basis, storage location, active retention period (while the account is active), post-account-closure retention, the driver behind the retention period, and the erasure-handling rule that applies when a creator makes an Article 17 request.

1. Creator-account data

Description: YouTube creator ID, TikTok creator ID, Instagram username, Facebook page ID, account email, account-creation date, subscriber and follower counts per platform. Lawful basis: Article 6(1)(b) (contract) and Article 6(1)(f) (service security and integrity) with LIA on request. Storage location: Ambroot Railway EU West. Active retention: duration of the account. Post-account-closure retention: 24 months, then hard-deleted. Driver: Article 5(1)(e) storage-limitation; lawful-claims preservation under Article 17(3)(e) for the limitation periods applicable to claims arising from the contract. Erasure handling on Article 17 request: hard-deleted within 30 days, except (a) the identifiers needed to honour the erasure-request audit (category 11), retained 7 years, and (b) any slice tied to an outstanding invoice (category 13), retained 7 years.

2. Content metadata

Description: per-platform video and post metadata, captions, view counts, upload dates, sound or effect usage on TikTok, post engagement. Lawful basis: Article 6(1)(b) (contract); Ambroot acts as processor on the creator's instructions per section 2.2. Storage location: Ambroot Railway EU West cache, bounded by the section 5.1 platform cache windows. Active retention: the section 5.1 platform cache windows (up to 30 days for most Authorized Data; longer for YouTube Analytics and Reporting subject to the 30-day re-authorisation check). Post-account-closure retention: cache flushed within 30 days of account closure; no post-closure retention beyond the cache. Driver: source-platform Developer Policies cache obligations (YouTube III.E.4, TikTok Display API, Meta Platform Terms section 3.d); Article 5(1)(e). Erasure handling on Article 17 request: hard-deleted within 30 days; no carve-out for legal-claims because Ambroot is processor not controller for this category.

3. Audience-engagement data

Description: aggregated audience numbers, demographic distributions where exposed by platform APIs in non-identifiable form. Lawful basis: Article 6(1)(b) (contract); the data falls outside GDPR personal-data scope where irreversibly aggregated (see section 2.3). Storage location: Ambroot Railway EU West cache. Active retention: the section 5.1 platform cache windows. Post-account-closure retention: none beyond the cache. Driver: source-platform cache obligations; non-personal-data status where aggregation is irreversible. Erasure handling on Article 17 request: not applicable to non-personal-data slices; identifiable slices, if any are ever exposed by a platform API, are treated per category 1.

4. LLM inputs

Description: data passed to Anthropic for inference (platform metrics and content metadata fed to the LLM prompt). Lawful basis: Article 6(1)(b) (contract); Anthropic is processor under the Article 28 DPA. Storage location: Ambroot processing pipeline (transient); Anthropic per the Anthropic DPA. Active retention: deleted from the Ambroot pipeline within 24 hours of analysis completion (per section 3.5); Anthropic retention per the Anthropic DPA terms (up to 30 days default, lower under zero-data-retention if negotiated, per section 3.4). Post-account-closure retention: none at Ambroot beyond the 24-hour pipeline window; Anthropic per the Anthropic DPA. Driver: Article 5(1)(e); Ambroot's transient-processing design; Anthropic's published vendor retention. Erasure handling on Article 17 request: hard-deleted from Ambroot within 24 hours of analysis completion as standing practice; Anthropic instructed to delete within 30 days per section 6.2.

5. LLM prompts

Description: the prompt text alongside the LLM inputs in category 4. Lawful basis: Article 6(1)(b) (contract) and Article 6(1)(f) (reproducibility and audit of advisory insights). Storage location: Ambroot Railway EU West. Active retention: retained alongside outputs for reproducibility (per section 3.5). Post-account-closure retention: aligned with LLM outputs (category 6): 24 months from generation, then deleted or anonymised. Driver: Article 5(1)(e); audit-trail necessity for the Article 22(3) right-to-explanation surfaced as best practice in section 6.6. Erasure handling on Article 17 request: hard-deleted within 30 days; an audit-trail copy is preserved per category 11 for 7 years, redacted to remove the content payload.

6. LLM outputs

Description: insights returned to the creator (per-creator engagement trends, content suggestions, audience profile summaries). Lawful basis: Article 6(1)(b) (contract); insights are personal data of the creator. Storage location: Ambroot Railway EU West. Active retention: 24 months from generation, accessible to the creator per section 3.5. Post-account-closure retention: 24 months from generation OR 24 months post-account-closure, whichever is shorter. Driver: Article 5(1)(e); creator-side utility window. Erasure handling on Article 17 request: hard-deleted within 30 days; a portability export under section 6.4 is offered before deletion.

7. LLM-derived insights (per-creator, stored separately from raw)

Description: Ambroot-generated observations about the creator's account, audience, and content, stored in an insights store separate from the raw cache. Lawful basis: Article 6(1)(b) (contract) where the insight is creator-personal-data; Article 6(1)(f) where the insight is a product-analytics signal with LIA on request. Storage location: Ambroot Railway EU West (insights store separated from raw cache). Active retention: 24 months from generation. Post-account-closure retention: 24 months post-account-closure or 24 months from generation, whichever is shorter. Driver: Article 5(1)(e); separation of the personal-data slice from the product-analytics slice. Erasure handling on Article 17 request: the creator-personal-data slice is hard-deleted within 30 days; the product-analytics slice is anonymised to category 8 if retention is otherwise justified. Until the operational pipeline can reliably split the two slices, Ambroot's safer default is to hard-delete the entire category 7 record on request.

8. Anonymised aggregate insights

Description: cross-creator data pools used for benchmarks, subject to the minimum cohort floor of 5 creators per section 8.2. Lawful basis: outside GDPR scope where the anonymisation test holds; Article 6(1)(f) as a safety fallback while the annual irreversibility review is in progress. Storage location: Ambroot Railway EU West. Active retention: retained for as long as the EDPB anonymisation four-test holds (annual review per section 3.5). Post-account-closure retention: same as active (anonymisation persists past account closure). Driver: anonymisation status (irreversibility, no singling-out, no linkability, no inference); EDPB Opinion 05/2014 and the WP29 anonymisation guidance. Erasure handling on Article 17 request: not subject to Article 17 where the anonymisation test holds; if the test fails on review, the aggregate is either further aggregated to restore irreversibility or deleted.

9. Consent records

Description: Article 7 evidence (cookie consent, brand-side sharing consent per section 8.1, opt-in to Layer 2 LLM, any future training opt-in). Lawful basis: Article 6(1)(c) (legal obligation under Article 7(1) GDPR to demonstrate consent); accountability under Article 5(2). Storage location: Ambroot Railway EU West. Active retention: duration of the consent plus a statute-of-limitations buffer. Post-account-closure retention: 5 years post-withdrawal or post-account-closure, whichever is later. Driver: Article 5(2) accountability; the civil-law limitation period under Belgian Civil Code Article 2262bis (10 years for contractual; 5 years for extra-contractual); the 5-year value is chosen as proportionate to the consent-evidence purpose. Erasure handling on Article 17 request: carve-out under Article 17(3)(b) (compliance with legal obligation under Article 7(1)) and Article 17(3)(e) (lawful claims); the record is retained with the content payload redacted to identifier, timestamp, and consent-version.

10. Authentication and session data

Description: OAuth tokens for YouTube, TikTok, Instagram, and Facebook; session cookies; refresh tokens. Lawful basis: Article 6(1)(b) (contract) and Article 6(1)(f) (session integrity, fraud prevention). Storage location: Ambroot Railway EU West (tokens encrypted at rest); session cookies in browser. Active retention: duration of the active session for session cookies; OAuth refresh tokens valid per the source-platform-issued lifetime. Post-account-closure retention: revoked and deleted within 24 hours of account closure. Driver: source-platform Developer Policies on token handling; Article 5(1)(e); security best practice (tokens are secrets). Erasure handling on Article 17 request: revoked at the source platform and hard-deleted from Ambroot within 24 hours; the revocation acknowledgement is logged per category 11.

11. Audit logs

Description: access logs, admin actions, security events, DSAR-receipt records, erasure-request audit, the sub-processor-change notification log per section 3.7. Lawful basis: Article 6(1)(c) (legal obligation under Article 5(2) accountability, Article 30 ROPA, Article 33 breach notification) and Article 6(1)(f) (security). Storage location: Ambroot Railway EU West (append-only). Active retention: duration of the account plus 7 years. Post-account-closure retention: 7 years post-account-closure or post-event, whichever is later. Driver: Article 5(2) accountability; Belgian Code of Economic Law Article III.86 7-year floor for business-records overlap; NIS2 and security-audit norms. Erasure handling on Article 17 request: carve-out under Article 17(3)(b); records are retained, with the identifier of the erased creator pseudonymised where compatible with audit utility.

12. Support correspondence

Description: privacy@ambroot.com, hello@ambroot.com inbound emails; ticket history. Lawful basis: Article 6(1)(b) (contract) for support tickets tied to active accounts; Article 6(1)(c) for DSAR correspondence (mirrors the Article 12 records); Article 6(1)(f) for service-quality analysis. Storage location: Ambroot Railway EU West; Support handled via email: privacy@ambroot.com. Active retention: duration of the account plus 3 years. Post-account-closure retention: 3 years post-account-closure, then hard-deleted. Driver: Article 5(1)(e); the civil-law extra-contractual limitation period (5 years under Belgian Civil Code Article 2262bis) is the upper bound; 3 years is chosen as proportionate to support-ticket utility. Erasure handling on Article 17 request: hard-deleted within 30 days, except the DSAR correspondence which is carved out under Article 17(3)(b) and retained as part of category 11 audit log.

13. Payment data (invoices and payment metadata)

Description: Ambroot-issued invoices, billing ledger, Stripe-payment metadata such as the payment-intent ID and last-4 of the card. Ambroot never stores the full PAN; cardholder data is tokenised at Stripe. Lawful basis: Article 6(1)(b) (contract) and Article 6(1)(c) for accounting (Belgian Code of Economic Law, BTW-Wetboek, Belgian Income Tax Code). Storage location: Ambroot Railway EU West (invoice records); Stripe (payment-method tokens and transaction records; see category 14). Active retention: duration of the account. Post-account-closure retention: 7 years post-account-closure (statutory minimum). Driver: Article 6(1)(c) and the Belgian commercial-law overlay: Article III.86 Code of Economic Law (7 years for accounting records); Article 60 BTW-Wetboek (7 years for VAT records); Article 315 Income Tax Code (7 years for direct-tax records). Erasure handling on Article 17 request: carve-out under Article 17(3)(b); records are retained for the statutory 7 years; the creator is notified of the carve-out in the Article 17 response.

14. Stripe-side payment data

Description: payment-method tokens, transaction records, dispute and chargeback records stored at Stripe as independent controller for fraud prevention, regulatory compliance, and Stripe's own operational and legal obligations, in line with Stripe's published Privacy Policy and Data Processing Addendum. Lawful basis: Article 6(1)(b) (contract); Article 6(1)(c) for fraud-prevention obligations imposed on Stripe by acquirers and card networks. Stripe acts under its own Privacy Policy and DPA terms. Storage location: Stripe (United States, DPF-certified; SCCs fallback per the Stripe DPA). Active retention: per Stripe's published retention terms; Active retention: for the duration of the business relationship between Ambroot and Stripe. Post-account-closure retention: per Stripe's published Privacy Center (https://stripe.com/legal/privacy-center), Stripe generally retains Personal Data obtained from Business Users for a period of five or more years from the end of the business relationship, with longer retention possible where mandated by anti-money laundering, anti-terrorism, tax, accounting, financial reporting, or other applicable legal obligations, or where required by Stripe's agreements with its financial partners. Post-account-closure retention: per Stripe's published retention terms; conservatively assumed to be 7 years for transaction records aligned to PCI-DSS and card-network rules. Driver: Stripe's published retention; PCI-DSS card-network norms. Ambroot has no control over Stripe-side retention beyond the Stripe DPA. Erasure handling on Article 17 request: the erasure instruction is passed through to Stripe per section 6.2; Stripe retention carve-outs are disclosed to the creator; Ambroot is not the controller of the Stripe-side slice for any data Stripe processes as independent controller.

15. Accounting and tax records

Description: general ledger, accounting books, VAT returns, direct-tax filings, supporting documentation distinct from the invoices in category 13. Lawful basis: Article 6(1)(c) (Belgian commercial and tax law). Storage location: Ambroot Railway EU West; [PLACEHOLDER: accounting-software vendor to be confirmed]. Active retention: duration of the fiscal year plus 7 years. Post-account-closure retention: 7 years from the close of the fiscal year, regardless of account-closure status. Driver: Belgian Code of Economic Law Article III.86, BTW-Wetboek Article 60, Belgian Income Tax Code Article 315; uniformly 7 years. Erasure handling on Article 17 request: carve-out under Article 17(3)(b); records are retained for the statutory 7 years from the relevant fiscal-year close.

16. Marketing and sign-up data

Description: waitlist emails, newsletter subscriptions, marketing consent records. Lawful basis: Article 6(1)(a) (consent under Article 7) for marketing communications; Article 6(1)(b) (pre-contract steps under Article 6(1)(b) second branch) for sign-up records. Storage location: Ambroot Railway EU West; [PLACEHOLDER: email-marketing vendor to be confirmed]. Active retention: duration of the subscription. Post-account-closure retention: 24 months from withdrawal of consent or last engagement, whichever is earlier; sign-up records that did not convert to an account are hard-deleted at 24 months from sign-up. Driver: Article 5(1)(e); Belgian Data Protection Authority guidance on marketing-list hygiene (the last-engagement test); consent revocability under Article 7(3). Erasure handling on Article 17 request: hard-deleted within 30 days; the consent-withdrawal record is retained per category 9.

17. Sub-processor change notifications

Description: the section 3.7 audit trail of which creators were notified of which sub-processor change and when, including objection responses. Lawful basis: Article 6(1)(c) (Article 28(2) GDPR notification-and-objection obligation; Article 30 ROPA). Storage location: Ambroot Railway EU West (subset of the audit log). Active retention: duration of the account plus 7 years. Post-account-closure retention: 7 years post-account-closure or post-event, whichever is later. Driver: Article 28 GDPR; Article 5(2) accountability; aligned to category 11 audit-log retention. Erasure handling on Article 17 request: carve-out under Article 17(3)(b); records are retained in the audit log.

18. Supervisory-authority correspondence

Description: correspondence with the Belgian Gegevensbeschermingsautoriteit and other EEA supervisory authorities; DPIA records per any future Annex; internal Article 37(1) DPO Necessity Assessment memo and any later re-evaluations. Lawful basis: Article 6(1)(c) (Article 35 DPIA records where applicable; Article 5(2) accountability). Storage location: Ambroot Railway EU West (restricted access; founder-only at v1, transitioning to DPO-only if and when one is designated). Active retention: duration of the matter plus 10 years. Post-account-closure retention: 10 years from close of the matter, regardless of account-closure status. Driver: Article 5(2) accountability; Belgian Civil Code Article 2262bis 10-year contractual-claim limitation as the conservative upper bound; DPIA records retained for the lifetime of the processing operation per EDPB guidance. Erasure handling on Article 17 request: carve-out under Article 17(3)(b) and (e); records are retained, with the identifier of the data subject pseudonymised where utility permits.

5.3 Erasure mechanics

When a creator exercises the right to erasure under Article 17 GDPR, Ambroot operationalises the request as follows. Within 30 days of receipt (extendable by two months under Article 12(3) for complex or numerous requests, with notice and reasons given within the initial month), Ambroot hard-deletes the data slices in categories 1, 2, 3, 4, 5, 6, 7 (creator-personal-data portion), 10, 12 (non-DSAR portion), 14 (where Ambroot is the controller), and 16. Ambroot instructs Anthropic to delete LLM inputs, prompts, and outputs within the same window, subject to the limit described in section 6.2.

The product-analytics slice of category 7 and the anonymised aggregates in category 8 are not deleted where the EDPB anonymisation four-test continues to hold; the creator is notified that those slices fall outside GDPR scope. Article 17(3) carve-outs preserve category 9 (consent evidence under Article 17(3)(b)), category 11 (audit logs under Article 17(3)(b) and (e)), category 12 DSAR correspondence portion (under Article 17(3)(b)), categories 13 and 15 (Belgian accounting and tax overlay under Article 17(3)(b)), category 14 (Stripe-side under PCI-DSS and card-network obligations), category 17 (sub-processor notification log under Article 17(3)(b)), and category 18 (supervisory-authority correspondence under Article 17(3)(b) and (e)).

Ambroot surfaces each carve-out to the creator in the Article 17 response, naming the category, the legal basis for retention, and the date on which the carve-out expires. Where Ambroot cannot delete a data slice in production systems because it has been written to backup-tape rotation, Ambroot isolates the slice from further processing until the next 30-day backup-rotation cycle completes deletion.

6. Data-subject rights across platforms (Articles 15 to 22)

6.1 Right to access (Article 15)

Ambroot confirms within 30 days the personal data processed, source platform, and purposes. Provided in CSV or JSON. Ambroot may extend the response window by up to two additional months for complex requests, with notice to the data subject within the initial 30 days, per Article 12(3).

6.2 Right to erasure (Article 17)

Ambroot deletes the creator's account data and content metadata from all four platform-sourced caches within 30 days of request, and instructs Anthropic to delete LLM inputs, prompts and outputs within the same window. Ambroot retains an audit record of the erasure request and may retain limited data where required for legal claims, regulatory obligations, or freedom of expression (Article 17(3)).

6.3 Right to rectification (Article 16)

The creator may request a refresh from the source platform API; Ambroot completes within 30 days.

6.4 Right to portability (Article 20)

Machine-readable export (CSV, JSON, or Parquet) of all creator-account data and content metadata. Where LLM-derived insights are personal data of the creator (readable observations about the creator's account, audience, or content), they are included in the portability export by default. Insights that constitute Ambroot proprietary analytics methodology (Ambroot's internal benchmark scores) may be excluded under the IP carve-out, with the creator notified of the exclusion.

6.5 Right to restriction of processing (Article 18)

The creator may request that Ambroot restrict the processing of their personal data where: (a) the accuracy of the data is contested, for a period enabling Ambroot to verify accuracy; (b) the processing is unlawful and the creator opposes erasure and requests restriction instead; (c) Ambroot no longer needs the data but the creator requires it for the establishment, exercise, or defence of legal claims; or (d) the creator has objected to processing under Article 21 pending verification whether Ambroot's legitimate grounds override those of the creator. Ambroot implements the restriction within 30 days and notifies the creator before any restriction is lifted.

6.6 Right to object (Article 21)

The creator can object to any processing based on Article 6(1)(f). Ambroot ceases that processing within 30 days unless a compelling overriding interest is documented and disclosed to the creator.

6.7 Article 22 best-practice safeguards (Layer 2 LLM)

• Right to explanation of any insight that informs an Ambroot decision affecting the creator.

• Right to human review.

• Right to object and receive Layer 1 raw data only.

Annex A.3 describes how this framing changes if Ambroot ever introduces automated decisions affecting creators.

6.8 Right to lodge a complaint with a supervisory authority

Without prejudice to any other administrative or judicial remedy available to you under Belgian or EU law, you have the right under Article 77 GDPR to lodge a complaint with a supervisory authority, in particular in the Member State of your habitual residence, place of work, or place of the alleged infringement.

In Belgium, the competent supervisory authority is the Gegevensbeschermingsautoriteit / Autorité de protection des données (the Belgian Data Protection Authority):

• Address: Drukpersstraat 35 / Rue de la Presse 35, 1000 Brussels, Belgium

• Telephone: +32 2 274 48 00

• Email: contact@apd-gba.be

• Website: https://www.dataprotectionauthority.be (EN), https://www.gegevensbeschermingsautoriteit.be (NL), https://www.autoriteprotectiondonnees.be (FR)

• Complaint form: https://www.dataprotectionauthority.be/citizen/actions/lodge-a-complaint

If you reside in another Member State of the European Economic Area, or in the United Kingdom or Switzerland, you may instead lodge a complaint with your local supervisory authority. The European Data Protection Board maintains a directory of national supervisory authorities at https://www.edpb.europa.eu/about-edpb/about-edpb/members_en.

Ambroot encourages you to contact us first at privacy@ambroot.com so we can attempt to resolve your concern directly, but this is not a precondition to exercising your right under Article 77 GDPR.

7. Platform-specific Privacy Policy disclosures

7.1 YouTube-required disclosures

Ambroot's YouTube integration uses YouTube API Services and is governed by the YouTube API Services Terms of Service and the Google Privacy Policy. This section is written to be read on its own and sets out, for Google's OAuth verification review, what Google user data Ambroot accesses, how it is used, how it is shared, how it is stored and protected, and how it is retained and deleted.

Data accessed (OAuth scopes). Ambroot requests only the read-only scopes needed to generate the connecting creator's own insights, and maps each scope to the data it grants:

• https://www.googleapis.com/auth/youtube.readonly: channel metadata, video metadata, and public statistics for the connected channel.

• https://www.googleapis.com/auth/yt-analytics.readonly: the creator's own YouTube Analytics reports, such as views, watch time, engagement, and aggregate audience demographics.

How the data is used. Ambroot accesses, collects, and stores this YouTube API Data and uses it, including through machine-learning inference, to generate insights for the creator who authorised the connection. Storage durations are set out in the retention and deletion rules below. YouTube-derived data is not combined with data from TikTok, Instagram, or Facebook for any purpose, including model training. This is a standing commitment driven by YouTube Developer Policies III.E.2, which prohibits aggregating YouTube API Data across content owners. Ambroot's Layer 2 LLM analysis is inference-only and is described in section 3.1. If Ambroot ever introduces cross-platform training, the change would require a fresh Privacy Policy update, a fresh creator consent moment under Article 6(1)(a), and a written approval request to Google's API team per Annex A.9.

Limited Use. Ambroot's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

Data sharing. Google user data is shared only with Anthropic, acting as processor solely to generate the creator's own insights and analysis (section 3), and with Ambroot's EEA hosting sub-processors (section 4.2). Google user data is never sold, is never used for advertising, and is never transferred to any other third party except with the creator's consent or where legally required. The brand-side visibility setting described in section 8.1 is account-level, OFF by default, and requires the creator's explicit logged consent; absent that consent Ambroot never shares Google user data with a brand, and when enabled, sharing covers only the data categories set out in section 8.1.

Storage and protection. Google user data is stored encrypted at rest on EEA infrastructure (Railway, EU West region) and is encrypted in transit via TLS, as described in section 14.

Attribution. Any insight referencing YouTube data is presented with a YouTube Brand Feature (the YouTube logo or icon selected per the YouTube Branding Guidelines) linking to YouTube content or a YouTube component, and is accompanied by the text 'via YouTube' or equivalent. A separate persistent link to Google's Privacy Policy is provided in this Privacy Policy and in the Ambroot footer.

Retention and deletion. YouTube data caching follows the Developer Policies III.E.4 tiers: channel statistics retrieved via the YouTube Data API are refreshed at least every 24 hours; other Authorized Data is refreshed or deleted within 30 calendar days; Authorized Data retrieved via the YouTube Analytics API or Reporting API may be stored longer subject to the 30-day re-authorisation check. Detailed cache windows are in section 5.1. Creators may request deletion of all Google user data at any time by emailing privacy@ambroot.com or by deleting their account, and Ambroot completes the deletion within 30 days. Revoking Ambroot's OAuth access triggers deletion of the associated Authorized Data within 30 days, mirroring the revocation rule in section 5.1. Creators may revoke Ambroot's access to their YouTube data at any time via https://myaccount.google.com/connections.

7.2 TikTok-required disclosures

Ambroot integrates with TikTok APIs (Display API, Login Kit) using the user.info.basic and video.list OAuth scopes (per the TikTok Display API getting-started documentation, captured 2026-05-16) to fetch creator metadata, video metrics, and account statistics with explicit OAuth permission. Public video metadata is cached for no longer than 30 days as Ambroot's operational commitment, with background-job refresh cadence aligned to the Display API access-token rotation cycle of approximately every 12 hours; authorised data is cached for the active session only. The underlying TikTok retention rule is governed by the TikTok Developer Terms of Service; Ambroot re-verifies the rule on the schedule set in section 3.7 and tightens its operational cap below 30 days if a stricter platform rule is published.

LLM-derived insights are stored separately from raw TikTok data and retained for the creator's access in accordance with the LLM retention schedule in section 3.5 (currently 24 months from generation, or until the creator requests deletion, whichever is shorter). The underlying TikTok-sourced raw data is retained only within the cache windows disclosed above.

Ambroot does not train any LLM on creator TikTok data; insights are inference-only. Aggregated benchmarks use anonymised data pools across the Ambroot creator population, not individual creator data; see section 8.2 for the minimum cohort size and ranking-prohibition guardrails that satisfy the TikTok Developer Policies competitive-analysis prohibition.

Ambroot does not sell, license, sublicense, syndicate, rent, lend, distribute, or otherwise transfer any TikTok-derived data, LLM-generated insights, or benchmarks to third parties, except where the creator has explicitly enabled brand-side sharing under section 8.1 with the disclaimer flow specified there.

TikTok attribution: any metric or content sourced from TikTok is displayed with the TikTok logo, 'via TikTok' text, and a link back to TikTok, in accordance with the TikTok Developer Terms of Service Section II.2 and Brand and Use Guidelines. Ambroot does not superimpose Ambroot branding on TikTok creator content (TikTok Developer ToS Section III(t)).

7.3 Meta-required disclosures

7.3.1 Data access and authorization

Ambroot accesses Instagram and Facebook data on the creator's behalf through Meta's Graph API. Ambroot requests only the minimum OAuth scopes necessary for each feature (for example, instagram_insights for reach and impressions, pages_show_list for page selection). The creator may revoke Ambroot's access at any time via the creator's Meta account settings; on revocation Ambroot immediately stops API calls and deletes all cached Meta-derived data. Aggregated, obscured, or de-identified data that cannot be associated with the creator, as well as data Ambroot is legally required to retain, may remain in line with Meta Platform Terms §3.d.i.2.d.

7.3.2 Graph API access tiers

Ambroot operates under Meta's standard production access tier (as defined by Meta's App Review framework). The standard tier provides access to insights endpoints (reach, impressions, engagement, audience demographics, account metadata). Any future upgrade to an upgraded access tier would require separate Meta app review and the creator's explicit re-authorisation, disclosed as a separate feature launch.

7.3.3 Data caching and refresh windows

Ambroot's internal cache policy keeps Insights data for no more than 24 to 48 hours and account data (username, bio, profile picture, follower count) for no more than 7 to 30 days. Follower count is refreshed within 24 to 48 hours. Media and Story data are cached in alignment with content lifecycle. These windows are Ambroot's operational commitments aligned to Meta's Platform Terms §3.d obligation to delete Platform Data when no longer necessary.

7.3.4 Attribution requirements

All Meta-sourced data displayed on Ambroot includes visible attribution to Instagram or Facebook (for example, 'Data from Instagram Insights' or 'Facebook insights powered by Meta'), positioned near the metric display. A last-refresh timestamp accompanies every displayed metric. A staleness warning appears if cached data exceeds half the recommended refresh window. Logo lock-ups, colour, and trademark presentation follow the Meta Brand Resource and Permissions Center and the Logos and Trademarks requirements. Ambroot does not present Meta-sourced metrics as Ambroot-measured data.

7.3.5 Branded Content disclosure compliance

Where Ambroot provides features to help the creator manage Branded Content deals, Ambroot's role is to surface Meta's native Branded Content tool and the 'Paid partnership' label at the moment of publication. Ambroot does not provide an alternative or simplified labelling mechanism, and does not replace Meta's tool with an Ambroot-rendered label. Ambroot warns the creator if they attempt to publish without applying the label. The creator's manual caption disclosure (for example '#ad' or '#sponsored' at the start of the caption) remains required for FTC and equivalent regulatory compliance and is not a substitute for the native label. The creator remains responsible for FTC, Instagram, and equivalent compliance on Branded Content disclosure.

7.3.6 Creator and brand obligations for Branded Content

By using Ambroot's Branded Content features, the creator agrees to apply the Branded Content label before posting, include explicit disclosure language in the caption, and not remove or obscure the label after publishing. Brands working with the creator through Ambroot may not request label removal, may not penalise the creator for disclosing, and may not provide contradictory instructions. These obligations are reflected in Ambroot's Terms of Service and the Brand-side Terms; this Privacy Policy section is informational.

7.3.7 Instagram and Facebook differences

Instagram uses the native Branded Content label positioned in the publishing flow before the post goes live. Facebook's Branded Content disclosure operates under the same Meta Branded Content Policies; detailed Facebook-specific UI variations are tracked internally and applied by Ambroot's product in line with Meta's then-current published guidance. This Privacy Policy is updated when material differences emerge.

8. Cross-platform data combination discipline

Ambroot displays creator metrics from all four platforms on a unified creator dashboard with per-platform attribution preserved (see sections 7.1, 7.2, and 7.3.4 for the attribution mechanics that apply per platform). Each platform's metrics are sourced from that platform's APIs and attributed to that platform. Ambroot does not combine YouTube API Data, TikTok API data, or Meta Graph API data at any stage of processing (ingestion, storage, inference, or display), per YouTube Developer Policies III.E.2 and the equivalent TikTok and Meta restrictions.

The Layer 2 LLM may generate cross-platform derived insights and aggregated benchmarks. These are Ambroot-generated outputs computed against anonymised data pools across the Ambroot creator population. The Layer 2 LLM does not train on cross-platform data. Aggregated, anonymised benchmarks are an internal product feature only; Ambroot does not sell, license, or share benchmarks externally (YouTube Developer Policies III.G.1.b and III.G.1.d; TikTok Developer Terms of Service Section II.1, which limits use of TikTok Information to 'developing, maintaining, and supporting your Applications', and the TikTok Developer Policies competitive-analysis prohibition; Meta Platform Terms §3, Permitted and Restricted Uses of Platform Data). Ambroot has not received written approval from any platform to monetise platform-derived aggregates and therefore commits not to monetise them.

The reuse of consumer-generated data implied by aggregated benchmarks is consistent with Article 16(3)(b) of the Digital Content Directive (Directive (EU) 2019/770). The no-monetisation commitment is reflected as a binding warranty in the Ambroot Terms of Service and is not framed as an unfair contract term within the meaning of Directive 93/13/EEC (the Unfair Contract Terms Directive).

8.1 Brand-side data sharing flow

Brand-side sharing of platform-sourced data is creator-controlled through a single account-level setting. Default state for every creator account: brand-side sharing is OFF. The creator must explicitly enable the setting from their dashboard (not through Terms of Service acceptance), and the creator's consent is logged at the time of enabling. When the setting is enabled, brand-side sharing covers the creator's connected platforms, including YouTube.

On enable, the creator is shown a disclaimer modal (not a buried Terms link) that names:

• What data is shared, by category (engagement metrics, audience demographics, account statistics).

• With whom the data is shared (the brand counterparty, named).

• Under what platform-Terms-of-Service constraints. For YouTube, attribution rules and the prohibition on the brand re-using the data outside YouTube's permitted scope. For TikTok, the use-only-for-authorised-purposes restriction in TikTok Developer Terms of Service Section II.1, which limits brand-side display of creator data to the documented purposes the creator opted in to. For Meta, the Meta Platform Terms §3 restrictions on third-party display.

• The creator's right to revoke at any time with immediate effect (revocation must be as easy as giving consent, per Article 7(3) GDPR), and the consequences of revocation: the brand stops receiving updated metrics; previously shared data may remain in the brand's records under the brand's own retention obligations. From the moment of revocation, the brand is an independent controller for any previously shared data the brand has retained, not Ambroot's processor.

Creator consent is logged with timestamp and version of the disclaimer for evidence under GDPR Article 7 (consent proof). At v1 launch, the disclaimer modal is presented in English. Ambroot plans to add per-member-state localisation of the modal text post-launch in line with Rome I Article 6 (mandatory consumer-protection rules of the creator's country of habitual residence); until that localisation is in place, B2C creators retain the mandatory protections of their habitual residence by operation of law regardless of the modal language. Any consumer-protection claim relating to brand-side sharing may be brought in the courts of the creator's habitual residence under Brussels Ia Article 18.

Per platform-specialist analysis, this opt-in flow does not require an OAuth scope expansion at any of the four platforms (existing scopes already cover the API read; the consent moment is for third-party display). The corresponding brand-side contractual commitments and brand-liability allocation live in the Ambroot Terms of Service brand-side clauses; this Privacy Policy describes the data-flow disclosure only.

8.2 Comparative and ranking-based insights

Ambroot's Layer 2 LLM analysis includes comparative and benchmark insights computed against aggregated, non-identifiable data pools across the Ambroot creator population. The LLM does not rank individual creators against named other creators and does not expose individual creator identities in benchmark outputs.

Architectural commitments that satisfy the platform-Terms-of-Service competitive-analysis prohibitions:

• Aggregation pools include a binding minimum threshold of creators per cohort set by Ambroot's operations team and published on the Ambroot Trust page; the threshold is never below five creators per cohort.

• Ambroot does not expose individual creator names, channel IDs, or identifiable characteristics in benchmark outputs.

• Ambroot does not market the benchmark feature as a competing analytics product to the platforms' own analytics tools.

• Ambroot does not sell, license, or share aggregated benchmarks with brands, market-research firms, or competitors. This commitment is reflected as a binding contractual warranty in the Ambroot Terms of Service.

• Benchmarks are an internal Ambroot product feature consumed only by Ambroot creators within the Ambroot UI.

Any future reduction of the cohort floor (for example from ten to five) is a material modification under Article 19 of the Digital Content Directive and follows the same 30-day notice, objection right, and pro-rated-refund mechanism as section 3.7.

9. ROPA (Record of Processing) summary

Ambroot maintains an internal Record of Processing per Article 30 covering each platform-specific data flow (YouTube, TikTok, Instagram, Facebook), the Layer 2 LLM processing layer with Anthropic as named processor, and the brand-side data sharing flow. The ROPA is reviewed at least annually and on every material change to a processing operation (new sub-processor, new processing purpose, new lawful basis). Ambroot provides the relevant ROPA extracts to a supervisory authority on lawful request and to creators on a reasonable-need basis, redacted where third-party confidentiality applies.

10. Cookies and similar technologies

Ambroot uses a minimal set of cookies and similar client-side storage to operate the Service. All items listed below qualify as strictly necessary under Article 5(3) of the ePrivacy Directive 2002/58/EC, as transposed in Belgium by Article 129 of the Electronic Communications Act of 13 June 2005, because each is either essential to deliver the Service or stores a preference explicitly chosen by the creator. No consent banner is presented because Ambroot does not use non-essential cookies, marketing pixels, advertising cookies, or third-party tracking technologies.

10.1 Authentication and session

Auth0 sets session and transaction cookies (including a session cookie and a short-lived OAuth-transaction cookie) to maintain the creator's logged-in session and to secure the login flow against cross-site request forgery. These cookies are required for the Service to function. Retention: session duration; the transaction cookie is short-lived (typically minutes) and the session cookie persists until logout or expiry, typically up to 24 hours.

10.2 Payment flow

When a creator interacts with payment pages, Stripe sets cookies on those pages to maintain checkout state and prevent fraud (for example __stripe_mid, __stripe_sid). Stripe is the controller for these cookies; their lifecycle is governed by Stripe's published cookie notice at https://stripe.com/cookies-policy/legal. Ambroot has no control over Stripe-side cookie retention.

10.3 User-set preferences (client-side storage)

Ambroot stores a small number of preferences in the browser's localStorage and sessionStorage when, and only when, the creator has explicitly set them. These are not analytics or tracking; each entry exists solely to honor the creator's explicit request that the relevant preference be remembered between sessions. Current preferences:

• ambroot:theme — the creator's chosen interface theme (light or dark), set when the creator clicks the theme toggle. Retention: until the creator changes it or clears their browser storage.

• Sidebar layout state — whether the navigation sidebar is collapsed or expanded, set when the creator interacts with the sidebar. Retention: same as above.

• Login intro animation flag — a sessionStorage entry that records whether the login-screen intro animation has already played in the current browser session, so that the animation does not replay on every page refresh. Retention: cleared automatically when the browser session ends.

• Offer analysis fallback cache — a transitional localStorage entry used for legacy offers analyzed before server-side snapshot storage existed; this fallback is read-only for legacy data and is phased out as offers are migrated. Retention: until the creator clears their browser storage or the legacy offer is replaced by a server-side snapshot.

Because each of these entries is created in response to the creator's own explicit action and exists to fulfil the creator's request that the preference be remembered, Ambroot relies on the strictly-necessary exemption in Article 5(3) ePrivacy.

10.4 Analytics

Ambroot operates analytics on two separate surfaces with different consent postures.

Marketing site (cookieless, no consent required): the Ambroot marketing site uses Vercel Web Analytics, a cookieless analytics product. No cookies are set, no persistent identifiers are stored on the visitor's device, and visitor identification is performed via a request-derived hash that is automatically discarded within 24 hours. Because no information is stored on the visitor's device for analytics purposes, Article 5(3) ePrivacy does not apply to this processing and no consent is required.

Signed-in application (PostHog, consent-gated opt-in): within the signed-in Ambroot application, Ambroot uses PostHog, a product-analytics service provided by PostHog, Inc., hosted in PostHog's EU cloud region, to understand product usage and improve the Service. This is a non-essential technology. PostHog is initialised in an opted-out state: it captures nothing and writes nothing to the creator's device — no analytics cookie and no analytics identifier in browser storage — until the creator gives explicit opt-in consent through the in-app consent prompt. Lawful basis: Article 6(1)(a) consent for the analytics processing, and the storing of or access to information on the creator's device under Article 5(3) ePrivacy proceeds only on that same consent. Once consent is given, PostHog collects product-usage events and page views within the application and associates them with the creator's Ambroot account identifier and account email; it does not capture contract or document content, analysis outputs, payment-card data, or platform-sourced creator data (YouTube, TikTok, Instagram, Facebook). The creator may decline at the prompt, in which case nothing is captured or stored, and may withdraw a previously given consent by contacting privacy@ambroot.com, after which capture stops (events already collected age out under PostHog's configured retention). Consent decisions are recorded per ROPA category 9. Ambroot is controller for this processing and PostHog is processor under an Article 28 arrangement; the recipient entry and transfer posture are set out in section 13.

10.5 Non-essential technologies and consent

Ambroot does not use advertising cookies, advertising pixels, social-media tracking pixels, or third-party advertising networks. The only non-essential technology Ambroot operates is the consent-gated PostHog product analytics in the signed-in application described in section 10.4, which runs solely on the creator's explicit opt-in consent and stores nothing on the creator's device before that consent is given. The creator can decline at the consent prompt and can withdraw consent at any time, as described in section 10.4. If Ambroot introduces any further non-essential cookie or similar storage technology, the addition of the relevant processor is treated as a material change, notified at least 30 days in advance per sections 3.7 and 12.2, and consent is obtained before any such technology is activated.

11. Eligibility and minimum age

11.1 Minimum age for creator accounts

The Ambroot service is intended for adult creators operating a creator business. The minimum age to create an Ambroot account is eighteen (18).

The Belgian Data Protection Act of 30 July 2018 (Article 7) sets the Article 8 GDPR consent age for information society services at 13. Ambroot has set a higher account-eligibility age because: (a) the Ambroot service is a paid SaaS subscription requiring full contractual capacity under Belgian civil law; (b) Ambroot's brand-deal and monetisation features (section 8.1) are designed for the adult creator population; and (c) the four source platforms' monetisation programmes (YouTube Partner Program, TikTok Creator Marketplace, Meta Branded Content) themselves require the creator to be 18 or older.

11.2 Discovery of an underage account

Ambroot does not knowingly collect or process personal data of individuals under 18. If Ambroot becomes aware that an account has been created in breach of this minimum-age requirement, Ambroot will: (i) suspend the account immediately, (ii) attempt to contact the holder at the registered email and require evidence of age or parental authorisation within 30 days, (iii) in the absence of resolution, delete the account and all associated personal data within a further 30 days under Article 17(1)(c) and (f) GDPR, and (iv) document the deletion in Ambroot's internal Record of Processing. Any person may report a suspected underage account at privacy@ambroot.com.

11.3 Audience-side data

Audience members of YouTube, TikTok, Instagram, and Facebook may be of any age, including minors. Ambroot does not ingest individual audience-member records (see section 2.3) and processes only aggregated, non-identifiable audience-engagement data exposed by each platform's APIs. Per-platform compliance with children's privacy obligations (COPPA-equivalent rules each platform implements at the source) is the responsibility of each platform under its own published policies. Ambroot does not present audience-engagement data to brands in a manner that could re-identify minors.

12. Effective date and changes to this Privacy Policy

12.1 Effective date

This Privacy Policy (version 1.2) is effective from 7 July 2026 and is the direct successor to version 1.0. Version 1.0 was effective from 18 May 2026 and remains accessible from the version history. The 'last updated' date appears at the top of this Privacy Policy and is incremented whenever any change, material or non-material, is published.

12.2 Material changes

Ambroot considers a change to this Privacy Policy to be material if it falls within one of the following categories:

• A change to the lawful basis on which Ambroot processes a category of creator personal data.

• A change to the retention period applicable to a category of creator personal data.

• The addition, removal, or substitution of a sub-processor (including the LLM vendor), per section 3.7.

• A change to the international transfer mechanism (section 4) or to the geographic location of the platform's hosting layer.

• A change to the operationalisation of data-subject rights (section 6), including response windows, formats, or limitations.

• The introduction of automated decision-making with legal or similarly significant effects (triggering Article 22 GDPR; see Annex A.3).

• A change to the minimum age (section 11.1) or to the children's-data handling rules.

Where a change is material, Ambroot notifies all active creators by email at least thirty (30) days in advance of the change becoming effective, consistent with section 3.7. The notice describes the change, the rationale, and the effective date, and points to the updated Privacy Policy. Creators who object on reasonable grounds relating to compliance with applicable data protection laws may notify Ambroot at privacy@ambroot.com within the 30-day window; section 3.7 governs the resolution mechanic.

12.3 Non-material changes

Non-material changes (typographical corrections, clarifications that do not alter substance, adjustments to internal section numbering) are reflected immediately on publication and are recorded in the public version log without a separate email notice.

12.4 Version history

A publicly accessible version log is maintained on the Ambroot Trust page, later versions will be published there. The link for this page can be found on subsequent privacy policy versions. The log records, for each version: the version number, the date of publication, the categorisation (material or non-material), and a short description of the change. Previous versions remain accessible from the same page.

13. Recipients of personal data

This section consolidates the recipients or categories of recipients of creator personal data, as required by Article 13(1)(e) GDPR. Onward transfers from non-EEA recipients are governed by section 4 (International transfers). Sub-processor additions, substitutions, and removals follow the change-notice mechanic in section 3.7 and are reflected in this list within the same notice cycle.

• Anthropic Ireland Ltd, processor (with onward transfer to Anthropic PBC, United States): LLM analysis (Layer 2) per section 3. Transfer mechanism: SCCs in the Anthropic DPA plus Schrems II supplementary measures (section 4.1).

• Auth0 by Okta (Okta EMEA Limited, Ireland), processor, EU region: authentication and identity management. EEA-hosted at ambroot.eu.auth0.com; no third-country transfer of personal data in the ordinary course beyond standard Okta sub-processor flows governed by the Okta Data Processing Addendum.

• Vercel Inc.: front-end application hosting in the EEA (EU West region) and Vercel Web Analytics (cookieless, no persistent identifiers stored on the creator's device, visitor identification via short-lived request-derived hash discarded within 24 hours). EEA-hosted; no third-country transfer of personal data in the ordinary course.

• PostHog, Inc., processor, EU cloud region: consent-gated product analytics for the signed-in Ambroot application (product-usage events and page views tied to the creator's account identifier and account email), per sections 10.4 and 10.5. Hosted on PostHog's EU Cloud; processed under an Article 28 data processing arrangement, on the basis of the creator's Article 6(1)(a) opt-in consent. No analytics data is captured or transmitted before that consent is given.

• Railway Corp.: back-end application hosting in the EEA (EU West region). EEA-hosted; no third-country transfer of personal data in the ordinary course.

• Stripe Payments Europe Ltd, Ireland (with onward transfer to Stripe, Inc., United States): payment processing and fraud prevention. Stripe acts as independent controller for the controller-side activities described in ROPA category 14. Transfer mechanism: Stripe DPF certification plus Stripe SCCs.

• Google LLC, United States, as source platform for YouTube data ingestion: controller of platform data. Transfer mechanism: DPF plus Google Cloud SCCs (section 4.1).

• TikTok Technology Ltd and affiliated TikTok / ByteDance entities (Ireland, United Kingdom, United States), as source platform for TikTok data ingestion: controller of platform data. Transfer mechanism: SCCs plus Schrems II supplementary measures (section 4.1).

• Meta Platforms Ireland Ltd (with onward transfer to Meta Platforms, Inc., United States), as source platform for Instagram and Facebook data ingestion: controller of platform data. Transfer mechanism: DPF plus Meta SCCs (section 4.1).

• Belgian Gegevensbeschermingsautoriteit / Autorité de protection des données, supervisory authority, Belgium: GDPR supervision and complaints handling per section 6.7. Statutory.

• Federal Public Service Finance (FOD Financiën / SPF Finances), public authority, Belgium: VAT and corporate-tax filings. Statutory.

• Belgian and EEA payment-system banks involved in SEPA flows, independent controllers, EEA: payment settlement. Statutory and contractual.

The current list is provided in section 13 of this Privacy Policy and updated per the material-change procedure in section 3.7. Material additions and substitutions trigger creator notification at least 30 days before they take effect, per section 3.7.

14. Security measures (Article 32)

Ambroot implements technical and organisational measures appropriate to the risks presented by the processing operations described in this Privacy Policy, in line with Article 32 GDPR. The current measures are summarised below; the full set of technical and organisational measures is maintained internally and is available to creators and supervisory authorities on reasonable request under section 6.7.

• Encryption in transit: all data transmitted between the creator and Ambroot, between Ambroot and source platforms, and between Ambroot and Anthropic is encrypted with TLS 1.2 or higher.

• Encryption at rest: creator personal data persisted on Ambroot Railway EU West (back-end) and Vercel EU West (front-end) is encrypted at rest using the provider default encryption (AES-256 or provider-equivalent).

• Access controls: production-data access is role-based, follows the principle of least privilege, and is limited to authorised Ambroot personnel. All administrative access to production systems requires multi-factor authentication.

• Key management: cryptographic keys for Ambroot data are managed via the platform key-management services of Ambroot hosting providers (Railway, Vercel). LLM-side cryptography is managed by Anthropic under DPA Schedule 2.

• Logging and monitoring: application logs are emitted via the .NET logging pipeline and captured by Ambroot's hosting provider (Railway) for the platform-default retention window. Access, processing, and administrative-action logs are retained per ROPA category 11 (audit log) and are used for incident detection and post-incident review. Ambroot does not currently operate a dedicated third-party log aggregator or SIEM.

• Vulnerability management: Ambroot conducts periodic vulnerability assessments on its application surface, applies security patches to dependencies on a defined cadence, and reviews sub-processor security posture annually against each sub-processor's published certifications (SOC 2 Type II, ISO/IEC 27001, ISO/IEC 42001 where applicable).

• Incident response: Ambroot maintains a written Personal Data Breach response plan that operationalises the Article 33 supervisory-authority notification deadline and the section 21 creator-notification mechanism.

15. Personal Data Breach notification (Articles 33 and 34)

A Personal Data Breach has the meaning set out in Article 4(12) GDPR: a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored, or otherwise processed.

15.1 Supervisory-authority notification (Article 33)

Where a Personal Data Breach has occurred at Ambroot and is likely to result in a risk to the rights and freedoms of natural persons, Ambroot notifies the Belgian Gegevensbeschermingsautoriteit without undue delay and, where feasible, within 72 hours of becoming aware of the breach. Where the 72-hour deadline cannot be met, the notification is accompanied by reasons for the delay, in line with Article 33(1) GDPR. Where Anthropic notifies Ambroot of a breach affecting LLM inputs or outputs, the 48-hour Anthropic relay obligation set out in section 3.4 starts Ambroot's own Article 33 clock and preserves a 24-hour internal buffer.

15.2 Data-subject notification (Article 34)

Where a Personal Data Breach is likely to result in a high risk to the rights and freedoms of natural persons, Ambroot communicates the breach to the affected creators without undue delay. The communication is provided by email to the creator's account email on file and by an in-dashboard notice, in clear and plain language, and includes: the nature of the breach; the contact point for further information; the likely consequences of the breach; and the measures Ambroot has taken or proposes to take to mitigate the breach and its possible adverse effects, in line with Article 34(2) GDPR.

15.3 Article 34(3) exceptions

Ambroot may forgo direct creator notification under Article 34(3) GDPR where: (a) the affected personal data was protected by encryption or another technical measure that rendered it unintelligible to unauthorised persons; (b) subsequent measures by Ambroot have ensured that the high risk to creator rights is no longer likely to materialise; or (c) direct notification would involve disproportionate effort, in which case a public communication or equivalent measure is made instead.

15.4 Breach register (Article 33(5))

All Personal Data Breaches, including those that do not trigger Article 33 or Article 34 notification, are documented in Ambroot's internal breach register under Article 33(5) GDPR. The register records the facts, effects, and remedial actions taken in relation to each breach and is retained per ROPA category 18 (supervisory-authority correspondence).

16. Source of personal data (Article 14)

Ambroot does not collect creator personal data exclusively through direct creator input. The categories of creator personal data set out in section 2 are also obtained from the four source platforms (YouTube, TikTok, Instagram, Facebook) under the OAuth permissions the creator grants on first connection of each platform account. This section sets out the Article 14(2)(f) source-of-data disclosures.

16.1 YouTube

Source: YouTube Data API operated by Google LLC. Categories of data obtained: per section 2.1 (creator-account data including channel ID, channel email, subscriber counts) and section 2.2 (content metadata including video metadata, view counts, upload dates, post engagement). Whether obtained from publicly accessible sources: mixed; channel-level metadata is publicly visible on the YouTube platform; engagement metrics tiered under YouTube Developer Policies III.E.4 are obtained from the Authorized Data surface and are not publicly accessible.

16.2 TikTok

Source: TikTok Display API and Login Kit operated by TikTok Technology Ltd and affiliated TikTok / ByteDance entities. Categories of data obtained: per section 2.1 (creator ID, follower counts) and section 2.2 (video metadata, captions, view counts, sound or effect usage). Whether obtained from publicly accessible sources: mixed; public video metadata is visible on the TikTok platform; account-level data accessed via the OAuth scopes user.info.basic and video.list is not publicly accessible.

16.3 Instagram

Source: Instagram Graph API operated by Meta Platforms Ireland Ltd. Categories of data obtained: per section 2.1 (Instagram username, follower count) and section 2.2 (post metadata, captions, view counts, post engagement). Whether obtained from publicly accessible sources: mixed; public profile data is visible on Instagram; metrics accessed via the Insights endpoint are not publicly accessible.

16.4 Facebook

Source: Facebook Graph API operated by Meta Platforms Ireland Ltd. Categories of data obtained: per section 2.1 (page ID, page-level account data) and section 2.2 (post metadata, captions, view counts, post engagement). Whether obtained from publicly accessible sources: mixed; public page data is visible on Facebook; Page Insights metrics are not publicly accessible.

16.5 Article 14(3) timing

Where new categories of creator personal data are obtained from a source platform following a creator OAuth re-authorisation (for example, the addition of a new scope), the disclosures in this section are updated and the change is treated as a material modification of the Service per sections 3.7 and 12.2.

16.6 Article 14(5) posture

The Article 14(5)(b) exception (data already in the data subject's possession or disproportionate-effort exception) is considered but is not relied on by Ambroot; the source-of-data disclosures in this section apply in full to all creator personal data obtained from the four source platforms. Audience-engagement data continues to be processed in non-identifiable form per section 2.3 and falls outside the GDPR scope to which Article 14 attaches.

17. Version history

v1.2 (7 July 2026). Material. Direct successor to version 1.0. This version bundles two sets of changes relative to v1.0. First, consent-gated PostHog product analytics for the signed-in application: updated the analytics sections (10.4 and 10.5) and the recipients list (section 13) to reflect EU-hosted, opt-in PostHog analytics that store nothing on the creator's device before consent, added PostHog, Inc. as a sub-processor, and updated the section 2.2 downstream-use position accordingly. Second, expanded YouTube and Google data disclosures in section 7.1 so they self-containedly satisfy Google's OAuth verification requirements: named the exact OAuth scopes (youtube.readonly and yt-analytics.readonly) and mapped each to the data it grants; added the Google API Services User Data Policy Limited Use affirmation with a hyperlink; stated the data-sharing position (Google user data shared only with Anthropic as processor and with Ambroot's EEA hosting sub-processors, never sold, never used for advertising, no other third-party transfers absent creator consent or legal requirement) and clarified that the section 8.1 brand-side visibility setting is account-level, OFF by default, and requires the creator's explicit logged consent before any Google user data is shared with a brand; cross-referenced the section 14 encryption-at-rest and in-transit measures; and set out the Google-user-data deletion and OAuth-revocation path (deletion on request or account closure within 30 days; deletion of Authorized Data within 30 days of OAuth revocation).

v1.0 — 18 May 2026. Initial publication. Material — first version of the Privacy Policy made public.

Annex A: Implications if cross-platform LLM training were enabled

This annex is descriptive only. The Privacy Policy commits to inference-only LLM analysis with no cross-platform training (per section 3.1). If Simon ever reverses that decision, the following sections of this Annex describe the regulatory and contractual surface that re-opens.

A.1 Lawful basis re-evaluation (Article 6)

Training represents a distinct purpose beyond contract performance. The current Article 6(1)(b) basis would no longer suffice; either Article 6(1)(a) (separate explicit creator consent for training) or Article 6(1)(f) (legitimate interest with a documented LIA per Article 6(3)) would be required. Each creator would need to re-consent. Given the Garante's December 2024 OpenAI ruling on the inadequacy of generic legitimate-interest claims for AI training, Ambroot's strong preference would be Article 6(1)(a) explicit opt-in consent per platform-data-category, not 6(1)(f).

A.2 DPIA mandatory trigger (Article 35)

Cross-platform training on creator and audience data triggers Article 35(3)(b) (large-scale processing) and Article 35(3)(c) (systematic monitoring) criteria per EDPB WP248 nine-criteria test. A formal DPIA would be required before training begins; Article 36 prior consultation with the Belgian Gegevensbeschermingsautoriteit may also be required.

A.3 Article 22 implications

If trained models then feed automated decisions affecting creators (auto-ranking, auto-matching, auto-suspension), Article 22 protections become mandatory: right not to be subject to a solely automated decision producing legal effects or similarly significant effects, right to human intervention, right to express views, right to contest. Section 3.3 of this Privacy Policy would require re-drafting from advisory framing to operational Article 22 framing.

A.4 Transfer-mechanism re-evaluation (Article 46, Schrems II)

Cross-platform training increases the volume of creator data sent to Anthropic and other potential vendors. A formal transfer impact assessment per Schrems II becomes critical; supplementary measures may need strengthening. Where commercially feasible, Ambroot will seek zero-data-retention (ZDR) arrangements with LLM vendors as a Schrems II supplementary measure.

A.5 Retention re-evaluation (Article 5(1)(e))

Source data, training data, model snapshots, and trained weights all require separate retention determinations. Creator erasure becomes complex: deleting source data does not necessarily delete the trained model contribution. Where data has already contributed to a model's trained weights, opt-out and erasure are forward-looking only; prior training contributions are typically not reversible without model retraining or deprecation.

A.6 Transparency re-evaluation (Articles 13 and 14)

This Privacy Policy would need to disclose: (a) that creator data feeds model training; (b) the categories of data used in training; (c) the purposes (product improvement, general model performance, etc); (d) the retention of training data and trained model snapshots; (e) the data-subject rights against the trained model.

A.7 Data-subject rights against trained models

Right to access against a trained model is technically complex (can the creator's contribution to model weights be enumerated). Right to erasure against trained models requires either model retraining or deprecation. Right to object to training must be operationalised as a separate consent moment under A.1.

A.8 Platform-Terms-of-Service implications

YouTube's developer surface restricts ML training in two layers: Developer Policies III.E.2 prohibits combining YouTube API Data across content owners, and III.E.4.h prohibits using API Data to create new or derived data or metrics. Separately, YouTube's creator-side third-party AI training setting (default OFF) controls whether a creator's audiovisual content may be used by approved third parties for AI training. Cross-platform training using YouTube API Data would require written approval from Google's API team (see A.9) AND, for any audiovisual-content training, also requires the creator's third-party AI training setting to be opt-in.

The TikTok Developer Policies competitive-analysis prohibition (captured 2026-05-05, pending re-capture) restricts use of TikTok Information to the purposes of developing, maintaining, and supporting your application (TikTok Developer Terms of Service Section II.1). Cross-platform training using TikTok Information falls outside that purpose envelope absent platform approval.

Meta Platform Terms §3 (Permitted and Restricted Uses of Platform Data) and the Meta Developer Policies restrict ML training on Meta-sourced data. Cross-platform training using Meta data would require separate analysis under Meta's developer terms, and would not be assumed permitted absent explicit Meta approval.

A.9 Per-platform approval pathways

YouTube approval pathway: developers requiring prior written approval from YouTube file the request via the Google API approval form, per YouTube Developer Policies III.G.1 (the 'Prohibited Actions' subsection).

TikTok approval pathway: developers submit through the TikTok Developer Portal with a documented use case, demo accounts, and audit-cooperation commitments under TikTok Developer Terms of Service Section II.4. Industry-reported timelines are 2 to 6 weeks for typical creator-tool integrations and longer where scope elevation or new feature surfaces are requested.

Meta approval pathway: Meta App Review is required for any expanded data use beyond the initially-approved app scope. Approval timelines are determined by Meta and not committed to by Meta in published documentation; the Annex assumes a conservative, multi-month process for planning purposes.