Version: draft-2026-08-25 · Status: ⚠️ DRAFT — not reviewed by a lawyer
Forms part of the Terms of Service where the customer is a business processing personal data through the service.
Controller: the customer · Processor: {{LEGAL_ENTITY}}
| Subject matter | Generating advertising media from customer material |
| Duration | For as long as the account exists, plus the retention periods in §7 |
| Nature and purpose | Storage, transformation, and transmission to AI providers for generation |
| Types of personal data | Account contact details; any personal data in uploaded images, reference video or prompts — including images of identifiable people where the customer uploads them |
| Categories of data subject | The customer's staff who use the service; people appearing in or identified by uploaded material |
| Special categories | Not intended. The customer must not upload health, biometric, or similarly sensitive data. Uploading a photograph of a person may create biometric data depending on jurisdiction — see §9 |
We will:
the instruction, and there is no other purpose;
already in the product;
no more than once a year with 30 days' notice, or after a personal data breach.
We will not use customer content to train any model, ours or a sub-processor's.
The customer warrants that it has a lawful basis for everything it uploads, and specifically that any identifiable person appearing in uploaded material has consented to that use in advertising.
This is the practical crux of the whole document. The service cannot know whether the person in a photograph agreed to be in an advertisement; only the customer can.
The customer authorises the following. We give 30 days' notice before adding one, and the customer may object and terminate if the objection cannot be resolved.
| Sub-processor | Purpose | Location | Transfer basis |
|---|---|---|---|
| fal.ai | Model inference | {{FAL_REGION}} | {{FAL_BASIS}} |
| OpenRouter | Language model for the scripting agent | {{OR_REGION}} | {{OR_BASIS}} |
| Stripe | Payment | EU / US | SCCs |
{{HOSTING_PROVIDER}} | Compute and database | {{DATA_REGION}} | — |
{{STORAGE_PROVIDER}} | Object storage | {{DATA_REGION}} | — |
{{MAIL_PROVIDER}} | Transactional email | {{MAIL_REGION}} | {{MAIL_BASIS}} |
{{ERROR_TRACKING}} | Error reports (no bodies, no headers) | {{ERR_REGION}} | {{ERR_BASIS}} |
Each is bound by terms no less protective than these.
This table must be filled in and kept accurate. A DPA naming a sub-processor that is no longer used, or omitting one that is, is worse than none: it is a written statement that is false.
Not a generic list — these are the controls that exist:
database. The API connects as a role that cannot bypass it, so an application bug that forgets a WHERE clause returns nothing rather than another tenant's rows.
encrypted before they leave the cluster with a key held off-cluster.
refresh tokens hashed and rotated on every use, with reuse revoking every session.
database.
roles and are recorded in an append-only audit log.
filesystem, no Kubernetes token mounted, and network policy between tiers.
We will notify the customer without undue delay and within 72 hours of becoming aware, with what we know: what happened, which categories and roughly how many records, the likely consequences, and what we are doing.
If we do not have all of it within 72 hours, we send what we have and follow up rather than waiting.
On termination the customer can export everything for 30 days. After that, content is deleted and personal data anonymised.
Kept longer, because the law requires it:
| Period | Why | |
|---|---|---|
| Invoices, credit and cost ledgers | 10 years | Tax |
| Moderation decisions | 2 years | Demonstrating enforcement |
| Administrative audit log | 3 years | Accountability |
These are anonymised where they can be — the record of what happened is kept; the identity attached to it is not, unless the law requires that too.
Where a sub-processor is outside {{DATA_REGION}}, transfers rely on Standard Contractual Clauses or an adequacy decision, as recorded in §4.
For Turkish customers, KVKK Art. 9 applies to transfers abroad and requires its own basis — explicit consent, a commitment letter approved by the Board, or an adequacy decision. This needs legal confirmation before launch; it is the item most likely to be wrong in this document.
Generating from a photograph of an identifiable person may constitute processing of biometric data in some jurisdictions, which is a special category under both GDPR Art. 9 and KVKK Art. 6.
The service does not perform facial recognition and does not build a face database. It does transmit the image to a model provider.
The customer is responsible for establishing a lawful basis before uploading a photograph of a person. A lawyer should decide whether this section is sufficient or whether such uploads should be refused outright.
If this addendum conflicts with the Terms of Service, this addendum prevails for anything concerning personal data.
{{LEGAL_ENTITY}} · {{DATA_REGION}} · {{FAL_REGION}} · {{FAL_BASIS}} · {{OR_REGION}} · {{OR_BASIS}} · {{HOSTING_PROVIDER}} · {{STORAGE_PROVIDER}} · {{MAIL_PROVIDER}} · {{MAIL_REGION}} · {{MAIL_BASIS}} · {{ERROR_TRACKING}} · {{ERR_REGION}} · {{ERR_BASIS}}
permit us to make the commitments in §2?
biometric data"? If so, is explicit consent workable in an advertising product?
rather than a physical audit?