Privacy Policy

Draft — last revised Jul 16, 2026

Draft pending legal review

This policy is a working draft prepared from how the platform handles data. It has not yet been reviewed by legal counsel, and some details — contact, jurisdiction, retention periods — are still to be completed. Do not rely on it until it is finalised.

On this page

Fygo Labs operates the Tempera platform. This policy explains how we collect, use, disclose, and protect personal data when you use the Tempera web application, mobile application (iOS and Android), and application programming interfaces (APIs) (together, the "Services").

Tempera is a business-to-business platform used by creative agencies and their teams. It is not directed at consumers or children. Where the Services are made available to you through your employer or an agency (a "Customer"), that Customer determines who may use the Services and configures much of how data is handled; see Section 13.

This policy is principles-based and jurisdiction-neutral. Terms such as "personal data", "controller", "processor", "data subject", and "processing" are used in their ordinary data-protection sense and should be read as the nearest equivalent under the law applicable to your deployment (see [[APPLICABLE LAW / GOVERNING JURISDICTION]]).

1. Who we are and how to contact us

Fygo Labs ([[FYGO LABS — FULL LEGAL ENTITY NAME]]) operates the Tempera platform. For any question about this policy or how your personal data is handled, or to exercise your rights (Section 11), contact:

  • Privacy contact: [[PRIVACY CONTACT EMAIL]]
  • Postal address: [[REGISTERED ADDRESS]]
  • Data protection officer / representative (if appointed): [[DPO OR REPRESENTATIVE CONTACT]]

If you use Tempera through an agency or employer (a Customer), you may also contact that organisation directly; it is responsible for the data it uploads and for the choices it makes when configuring the Services (Section 13).

2. Scope, and our role

What this covers. This policy covers the Tempera web application, the Tempera mobile application, and the Tempera API. Where a practice applies to only one surface, we say so (for example, browser cookies apply to the web app; the device camera applies to the mobile app).

Our role. Depending on the arrangement under which the Services are provided, Fygo Labs may act as a controller (deciding the purposes and means of processing — for example, for account administration and platform security) or as a processor acting on a Customer's instructions (for example, when processing the client materials a Customer uploads). Where Fygo Labs acts as a processor, the relevant Customer is the controller and its own privacy notice governs.

"Bring your own keys" (BYOK). Tempera is designed so that key external services — AI model providers, file storage, and outbound email — run on credentials that the operator or Customer supplies and controls. In those cases the data flows directly to the provider chosen and configured for that deployment, under that provider's own terms. The specific recipients listed in this policy therefore depend on how a given deployment is configured (Section 7).

3. The personal data we collect

We collect only what the Services need to function.

3.1 Account and profile data

  • Email address (used as your sign-in identifier).
  • Your name — as given name, family name, and/or a display name, and a display-name style preference.
  • Profile picture / avatar, if you or your identity provider supplies one.
  • Your language (locale) and time-zone preferences.
  • Your role and the set of clients you are permitted to access (used for access control), and account-status flags (for example, whether an account is disabled or suspended).

3.2 Authentication and security data

  • Passwords. If you sign in with a password, we store only a one-way cryptographic hash of it (using scrypt), never the password itself. We also keep hashes of a limited number of previous passwords to prevent reuse.
  • Single sign-on. If you sign in with Google, we receive from Google — after verifying the sign-in token — your email address, name, profile picture, and a stable account identifier. We request only basic sign-in scopes (openid email profile). We do not receive or store Google passwords, and we do not store Google access or refresh tokens.
  • Two-factor authentication (2FA). If you enable 2FA, we store your time-based one-time-password secret in encrypted form and store one-way hashes of your recovery codes.
  • Sessions. When you sign in we issue a session token; we store only a one-way hash of that token, together with technical metadata such as the client type (web or mobile) and timestamps used to expire and rotate the session.
  • Password reset, email change, and mobile pairing. These flows use short-lived, single-use tokens, of which we store only a one-way hash. A mobile-pairing record also stores the originating IP address for the duration of the short pairing window.

3.3 Content and materials you provide

When you use the Services you and your team create and upload working materials. These may contain personal data — including personal data about third parties (for example, names or contact details appearing in correspondence or brief documents). This content includes context files you upload to train an agent (such as brand guidelines, previously approved or rejected work, and correspondence); briefs; generated outputs and the review decisions, ratings, and feedback notes recorded against them; guided intake conversations; and reusable "skills". Uploaded file bytes are never stored in the platform database — the database keeps only a reference, and the bytes live in the storage location configured for the deployment (Section 7).

3.4 AI generation data

To generate work, the platform assembles a prompt from your brief and the relevant client, brand, campaign, and activity context (including text extracted from context files, and images such as brand logos or uploaded images) and sends it to the configured AI model provider(s). See Section 6.

3.5 Usage, audit, and technical data

  • Audit log. For security and accountability, we record certain administrative and sensitive actions. Each entry records the action, the affected item, a short summary, the acting user's email address and IP address, and a timestamp.
  • Usage metering. We record AI usage events (such as the model used and token/cost counts) associated with the requesting user, to meter and report usage.
  • API request logs. For the public API, we log the request method, the request path (never the query string), and the response status against the API key used.
  • Server logs. Our servers emit structured operational logs (for example HTTP method, path, status code, response time, and a correlation identifier). Logs pass through automatic redaction that removes credentials, tokens, and API-key-shaped strings before they are written.

3.6 Device and mobile application data

  • On-device storage. The mobile app stores your session token in the operating system's secure keystore (iOS Keychain / Android Keystore) and keeps small non-sensitive preferences (such as your chosen language and theme) in local device storage.
  • Camera. The mobile app uses the device camera solely to scan a pairing QR code when you sign in. Camera imagery is processed on the device and is not transmitted to us or retained.
  • Biometric app lock. If you enable the optional biometric app lock, verification is performed by your device's operating system. Biometric data never leaves your device and is never sent to or stored by us.
  • At runtime, the mobile app communicates only with the workspace API you have paired it to and, if you use Google sign-in, with Google for authentication.

3.7 Cookies and local storage (web)

The web application uses a single strictly-necessary session cookie to keep you signed in. It is set as httpOnly (not readable by page scripts) and is scoped to the application's own origin. We do not use advertising, analytics, or tracking cookies, and we do not build advertising or cross-site profiles.

3.8 What we do not collect or do

To be explicit, the platform does not integrate any of the following: no third-party product-analytics or usage-tracking (for example, no Google Analytics, Segment, Mixpanel, Amplitude, or PostHog); no third-party advertising, ad networks, or cross-site tracking; no third-party crash-reporting or error-tracking; no mobile push-notification tracking and no over-the-air update telemetry; and no selling or sharing of personal data for advertising.

4. How and why we use personal data

We use personal data to provide the Services (authenticate you, maintain your account and preferences, run the Client → Brand → Campaign → Activity workflow, generate and store work, and record review decisions); to secure the Services (authenticate and authorise access, apply role- and client-based access controls, prevent abuse, and maintain the audit log); to operate and support (provide support, meter usage, keep the Services reliable); to communicate with you (necessary service messages such as password-reset and account emails); and to comply with law.

We follow these principles: we process personal data lawfully, fairly, and transparently; we collect it for specified purposes and do not use it in incompatible ways; we minimise what we collect; we keep it accurate; we retain it no longer than necessary (Section 9); and we protect it with appropriate security (Section 10).

5. Lawful basis for processing

Where the law applicable to your deployment requires a lawful basis, we rely on the basis appropriate to each purpose: performance of a contract (to provide the Services); legitimate interests (to secure and improve the Services, prevent abuse, and maintain records, balanced against your rights); consent (where we ask for it, which you may withdraw at any time); and legal obligation. These map to the equivalent lawful bases under [[APPLICABLE LAW]]. Where Fygo Labs acts as a processor for a Customer, the Customer is responsible for ensuring a lawful basis for the content it uploads.

6. AI model providers and how your content is processed

Tempera is model-agnostic. To generate work, it sends the assembled prompt and context to one or more AI model providers.

  • The provider is chosen and configured for your deployment. Providers are enabled using API credentials supplied by the operator or Customer (BYOK). Claude (Anthropic), OpenAI, and Google are the primary providers; a deployment may additionally enable other supported providers. A provider that has not been configured receives no data.
  • What is sent. The system prompt and your brief; the relevant client, brand, campaign, and activity context; text extracted from context files; and images (such as brand logos and uploaded images). During refinement or regeneration, previously generated outputs may also be sent.
  • Credentials are protected. Provider API keys are encrypted at rest and used only on the server; they are never placed into a prompt or exposed to the model.
  • The provider's terms apply. Content sent to a provider is processed by that provider under its own terms. Where a provider offers controls to limit data retention or to exclude data from model training, the operator/Customer is responsible for enabling them (see [[AI PROVIDER DATA-HANDLING SETTINGS]]).
  • Mock mode. When no usable provider key is configured, the platform produces clearly-marked sample output locally, with no external transmission.

7. Sub-processors and other recipients

We share personal data only as needed to run the Services, and only with the categories of recipient below. Because of the BYOK design (Section 2), several of these are configured per deployment; the definitive, deployment-specific list is maintained by the operator ([[SUB-PROCESSOR REGISTER]]).

  • AI model providers (e.g. Anthropic, OpenAI, Google; others if enabled) — to generate creative work. Receives prompts, briefs, client/brand context, extracted text, images, and prior outputs. Only enabled providers receive data.
  • Cloud hosting / infrastructure ([[HOSTING PROVIDER & REGION]]) — to run the Services and store the database. Handles all data processed by the Services.
  • File-storage backend — to store uploaded files and generated outputs. The default is local storage; cloud or remote storage (for example Amazon S3, Google Cloud Storage, SFTP, FTP, or Google Drive) is optional and operator-configured.
  • Email provider — to send account and service emails. Receives the recipient's email address and display name, entity/task/client names, and a link — never brief or output content. Optional; if unconfigured, email is not sent.
  • Google (Identity) — optional Google single sign-on (scopes openid email profile).
  • Google (Drive) — optional native Google Docs / Slides delivery and shared-drive storage; where enabled, team member email addresses are shared with Google to manage access permissions.
  • App stores and build service (Apple App Store, Google Play, Expo/EAS) — to distribute and update the mobile app. Build- and release-time only, not runtime user data.

We may also disclose personal data where required by law, to protect our rights or the safety of others, or in connection with a corporate transaction (in which case we will require the recipient to honour this policy).

8. International data transfers

Personal data may be processed in countries other than your own, depending on where the operator, the Customer, and the configured providers (Section 7) are located. Where personal data is transferred across borders, we and/or the relevant Customer put in place safeguards recognised under [[APPLICABLE LAW]] (for example, standard contractual clauses or an equivalent mechanism). The hosting region for your deployment is [[HOSTING REGION]].

9. How long we keep data

We keep personal data only as long as necessary for the purposes in this policy, then delete or de-identify it. Specific retention periods for your deployment are set out in [[RETENTION SCHEDULE]].

  • Account and content data is retained while your account or the relevant client engagement is active. Client, brand, campaign, activity, and agent records are first soft-deleted — hidden from use but recoverable for a period — before any permanent removal.
  • Audit, review-decision, and usage-metering records can be automatically de-identified and later permanently deleted on a schedule the operator sets. If no schedule is configured, these records are retained until deleted manually.
  • Deletion on request. We do not currently provide self-service permanent account deletion. On a verified request (Section 11), we will delete or de-identify the relevant personal data within [[RESPONSE WINDOW, e.g. 30 days]], except where we must retain it to meet a legal obligation, resolve disputes, or enforce our agreements.
  • Backups. Database backups may retain data for a limited period after deletion from the live system; such data is expired on the backup cycle described in [[BACKUP RETENTION]].

10. Information security

We use technical and organisational measures appropriate to the risk, including:

  • Encryption in transit. Traffic to the Services is protected with TLS.
  • Encryption at rest for secrets. Sensitive credentials and secrets — AI-provider keys, storage and email credentials, and 2FA secrets — are encrypted at rest using AES-256-GCM. Database and file-storage encryption at rest additionally depends on the hosting and storage providers configured for the deployment.
  • Password and token protection. Passwords are hashed with scrypt; session, reset, pairing, and recovery tokens are stored only as one-way hashes.
  • Access control. Access is governed by role-based capabilities and client-level data scoping, so users see only the clients and actions they are permitted to; sensitive actions apply a maker/checker separation.
  • Human review gate. AI-generated work passes through a human review and approval step before it is treated as client-ready (Section 12).
  • Tenant isolation. Each agency's data is isolated and every data access is scoped to the requesting agency.
  • Log hygiene. Operational logs are automatically scrubbed of credentials and token-shaped values.

No method of transmission or storage is completely secure; we cannot guarantee absolute security. If we become aware of a personal-data breach, we will act in line with our legal obligations and notify affected parties and authorities as required.

11. Your rights and choices

Subject to and to the extent provided by [[APPLICABLE LAW]], you may have the right to access the personal data we hold about you; rectify inaccurate or incomplete data (you can update much of your profile in the app directly); erase your personal data; restrict or object to certain processing; receive certain data in a portable format (data portability); withdraw consent where processing is based on it; and lodge a complaint with the relevant supervisory authority ([[SUPERVISORY AUTHORITY]]).

To exercise these rights, contact us at [[PRIVACY CONTACT EMAIL]]. We may need to verify your identity, and we will respond within [[RESPONSE WINDOW]]. If you use Tempera through a Customer and we act as its processor, we will refer your request to that Customer (the controller) and support its response.

12. Automated processing and human oversight

Tempera uses AI to draft creative work. It does not make solely-automated decisions that produce legal or similarly significant effects about you. Generated work is presented as options and is subject to a human review-and-approval gate before it is treated as client-ready; a person remains accountable for each piece of work.

13. Responsibilities of operators and Customers

Where an agency or employer makes Tempera available to you and uploads materials, that Customer is responsible for having a lawful basis and appropriate notices for the personal data it uploads — including personal data about third parties that may appear in correspondence, briefs, or reference materials. That Customer configures the AI, storage, and email providers used, and manages its own users' access; your employer may be able to access and administer your account and the work within its workspace. If you have questions about how a particular Customer uses your data, please contact that organisation.

14. Children's data

The Services are intended for business use by adults and are not directed to children. We do not knowingly collect personal data from children. If you believe a child has provided us personal data, contact us and we will take appropriate steps to delete it.

15. Changes to this policy

We may update this policy from time to time. When we make material changes, we will update the effective date and, where appropriate, notify you through the Services or by other reasonable means. Continued use of the Services after an update means the updated policy applies to the extent permitted by law.

16. How to contact us

Questions, requests, or complaints about this policy or your personal data: email [[PRIVACY CONTACT EMAIL]] or write to [[REGISTERED ADDRESS]]. You also have the right to complain to a supervisory authority ([[SUPERVISORY AUTHORITY AND CONTACT DETAILS]]).