fremai Data Processing Agreement

title: fremai Data Processing Agreement author: fremverk date: 2026-08-13 version: “1.0” status: Published v1.0 lang: en #

Last updated: 2026-08-13

Effective Date: 2026-08-13 — Version: 1.0 (see the change log for the effective date of each amendment)

This Data Processing Agreement (“DPA”) is entered into between fremverk ApS and the Customer in connection with the fremai service, pursuant to Article 28 of Regulation (EU) 2016/679 (the “GDPR”). It is fremai’s own DPA — not an extension of the fremforge DPA — and reflects fremai’s distinct sub-processor chain (notably TensorX as the inference sub-processor) and its metadata-only / no-content posture. It supersedes any inconsistent provision in the Terms of Service for matters within its scope.

1. Parties #

Processor: fremverk ApS
CVR: 39150689 · VAT: DK39150689
Ringager 4C, 2. tv, 2605 Brøndby, Denmark
Data-protection contact: privacy@fremai.eu

Controller: the Customer identified in the Terms of Service.

fremai is a product brand of fremverk ApS; fremverk is the sole contracting party. fremverk is not required to designate a Data Protection Officer under GDPR Art. 37; the privacy contact above is the single intake point.

2. Definitions #

Terms defined in the GDPR have the meanings given there. “Service” means the fremai product at fremai.eu as described in Terms §2. “Sub-processor” means any third party engaged by fremverk that processes Customer Personal Data. “Backend” means the third-party EU-sovereign inference provider (TensorX at Annex B) that serves model completions as fremverk’s sub-processor. “Customer Personal Data” means personal data (GDPR Art. 4(1)) processed by fremverk on behalf of the Customer in connection with the Service — see §4.

3. Subject matter, duration, nature, and purpose #

• Subject matter: fremverk’s processing of personal data in connection with providing OpenAI-compatible AI inference to the Customer, as processor on the Customer’s behalf.
• Duration: the term of the Terms of Service, plus the retention periods in §9.
• Nature of processing: transmission and transient in-memory processing of prompt content to route it to the Backend and return the completion; collection, storage, structuring, retrieval, and erasure of Usage Metadata and account/authentication data necessary to provide, meter, secure, and bill the Service.
• Purpose: to provide the Service, meter and bill usage, secure the Service, and comply with fremverk’s legal obligations.

4. Types of personal data and categories of data subjects #

4.1 Types of personal data #

• Account and authentication: names, usernames, email addresses, organisation affiliation; OIDC claims and subject identifiers where a Customer federates its IdP; MFA factors; API-key identifiers; short-lived OAuth access/refresh tokens.
• Prompt and completion content (Customer Content): whatever the Customer or its Users send in a request and receive in a completion, which may contain personal data as determined by the Customer. This content is processed transiently and never persisted at the fremai layer (§5, and Annex A). fremverk cannot read it beyond routing it in memory.
• Usage and technical metadata: token counts (in/out), model id, latency, HTTP status, cost, key id, request timestamp; IP addresses and rate-limit counters; per-tenant audit events (key issue/revoke, login, budget/quota change, admin action, data export).
• Billing and commercial: organisation legal name, billing contact, VAT number, credit-ledger and invoice records. Raw payment-card data is processed by Mollie only; fremverk does not see or store it.
• Support correspondence: whatever the Customer sends to fremai support/abuse/security/privacy addresses, plus attachments.

No special categories of personal data (GDPR Art. 9 / Art. 10) are expected. If the Customer intends to send special-category data in prompts, it notifies fremverk in advance and the parties agree additional safeguards. The Customer is responsible for what it places in prompts, since fremai does not inspect content.

4.2 Categories of data subjects #

• Employees, contractors, and agents of the Customer who use the Service.
• Any natural persons whose personal data the Customer or its Users include in prompts (determined solely by the Customer).
• Billing and administrative contacts of the Customer.

5. No content retention; no training (the metadata-only spine) #

This is a material term and a defining commitment of the Service:

• fremverk does not persist prompt or completion bodies at the fremai layer. They exist only in transient memory for the duration of a request while being routed to and from the Backend.
• fremverk does not use, and does not permit any sub-processor to use, prompts, completions, or operational metadata to train, fine-tune, evaluate, develop, or improve any AI model, for fremverk’s, the sub-processor’s, or any third party’s benefit — regardless of anonymisation.
• Response/semantic caching that would store content is disabled by default.
• fremverk does not inspect or moderate content (no safety classifier, no DLP, no logging of bodies). Abuse enforcement operates on metadata and the AUP. Any content-inspection capability is an explicit, separately-disclosed customer opt-in and never the default path.

The Backend publishes an unconditional commitment that prompts and completions are processed in ephemeral execution and never stored, and that customer data is never used to train, fine-tune or improve models — a commitment that covers all of its customers and therefore the fremai path. fremverk is additionally securing the equivalent clause in the executed reseller agreement, because a contractual term is the enforceable form of a published one; that is an outstanding action and is recorded as such rather than presented as complete.

6. Processor obligations #

fremverk shall:

• Process Customer Personal Data only on the Customer’s documented instructions (these ToS/DPA and the Customer’s use of the Service being the instructions), including as to transfers, unless required by EU or Danish law — in which case fremverk informs the Customer unless legally prohibited.
• Ensure persons authorised to process the data are bound by confidentiality.
• Implement the technical and organisational measures in Annex A (GDPR Art. 32).
• Respect the conditions for engaging sub-processors (§10) and international transfers (§11).
• Assist the Customer, taking account of the nature of processing, in fulfilling data-subject requests (§7) and its Art. 32–36 obligations (§8).
• At the Customer’s choice, delete or return Customer Personal Data at the end of provision (§9).
• Make available information necessary to demonstrate compliance and allow for and contribute to audits (§12).

7. Data-subject requests #

Because fremai retains no content, most data-subject requests concern account/metadata rather than prompt content. fremverk will, taking account of the nature of processing, assist the Customer by appropriate technical and organisational measures to respond to requests to exercise data-subject rights (access, rectification, erasure, restriction, portability, objection). Where fremverk receives a request directly from a data subject relating to Customer Personal Data, it refers the data subject to the Customer and does not respond substantively except on the Customer’s instruction or where legally required.

8. Security-breach assistance and notification #

• Processor → Controller. fremverk notifies the Customer without undue delay and in any event within 24 hours of becoming aware of a Personal Data Breach affecting Customer Personal Data, with the information the Customer reasonably needs for its own Art. 33/34 obligations, supplemented as it becomes available.
• Controller-side incidents. Where a breach affects processing for which fremverk is itself the controller (e.g. the fremai key store, the OAuth refresh-token store, metering-data integrity, or a Backend/sub-processor compromise where fremverk is the affected controller), fremverk operates its own Art. 33 (72-hour supervisory-authority) and Art. 34 (data-subject) notification path. The runbook and breach classes are in controller-incident-response.md.
• fremverk assists the Customer with data-protection impact assessments and prior consultations (Art. 35–36) to the extent the information is within fremverk’s control.

9. Return and deletion; retention #

• On termination, API Keys are deactivated. Because prompts and completions are never persisted, there is no content corpus to return or delete — the no-content posture (§5) means the largest data class simply never exists at rest.
• Account, authentication, and Usage Metadata are deleted or anonymised after the retention periods in Annex A, subject to fremverk’s own legal-retention duties (notably Danish bookkeeping law for billing records).
• Retention summary (detail in Annex A): no content, ever; audit metadata — 3 years WORM; billing-relevant usage aggregates — 5 years (Bogføringsloven); raw per-request metadata short hot-tier 90 days; OAuth refresh tokens short-lived and rotated.

10. Sub-processors #

10.1 Authorised sub-processors #

The Customer authorises fremverk to engage the sub-processors listed in Annex B to process Customer Personal Data for the purposes stated there.

10.2 Changes to sub-processors #

fremverk may engage additional or replacement sub-processors. fremverk notifies the Customer of any intended change at least 30 days in advance by (a) direct email to the tenant’s billing contact of record and (b) a public posting on the trust center at www.fremai.eu/trust. The Customer may, within 15 calendar days of notice, object in writing on reasonable data-protection grounds; the parties work in good faith for a further 15 days, and failing resolution the Customer may instruct fremverk not to use the new sub-processor (fremverk may then decline the affected portion of the Service and refund prepaid unused Fees pro rata) or terminate the affected Service with a pro-rata refund.

10.3 Emergency sub-processor onboarding #

Where a security or operational emergency requires onboarding a new sub-processor faster than the 30-day notice (for example, replacing a sub-processor that is itself the source of an incident — the Backend being the obvious case given the Phase-1 single-backend posture), fremverk may onboard immediately, provided it: (a) notifies Customers within 24 hours via the same dual channel; (b) states the emergency justification; (c) confirms the new sub-processor is bound by equivalent data-protection terms; and (d) extends the objection window to 30 days post-onboarding with the same termination / pro-rata-refund right.

10.4 Sub-processor obligations #

fremverk imposes on each sub-processor contractual data-protection obligations no less protective than those in this DPA and remains fully liable to the Customer for its sub-processors’ acts and omissions.

11. International transfers and residency #

fremverk processes Customer Personal Data exclusively inside the EU/EEA, at the sub-processors in Annex B. No international transfer outside the EU/EEA occurs on any fremai processing path and no Article 46 safeguard is required.

This is a statement about where processing happens. It is not a claim that every entity in the chain is European-owned — see the CLOUD Act posture below, which addresses ownership separately and precisely.

• Inference path. The inference data plane (api.fremai.eu/v1) terminates TLS inside the T Cloud Public tenant (region eu-de, Germany) and routes to the Backend. No CDN sits in the inference path — prompts never transit a third-party edge. The Backend’s API endpoint terminates in France (Scaleway SAS, a French-owned host) and inference executes on dedicated GPUs in Dublin, Ireland and Helsinki, Finland. Every hop is inside the EU. The Backend serves inference from ephemeral, zero-retention execution.
• Non-inference path. Public www / docs / console (app.fremai.eu) assets are fronted by Bunny CDN at EU points of presence only; Bunny sees only public assets and TLS-terminated console UI, never the inference/prompt path.

CLOUD Act posture. fremverk is a Danish entity. On the inference path, the entities that hold or could access Customer Personal Data are European: fremverk (Denmark), T Systems / Deutsche Telekom (Germany), TensorX Ltd (Ireland, company no. 796387), and its French and Finnish hosting (Scaleway SAS, France; Verda, Finland). None of these is subject to the US CLOUD Act, FISA, or Executive Order 12333.

One entity on the inference path has a US parent, and fremverk states it plainly rather than claim otherwise. The Dublin facility housing the Backend’s dedicated GPUs is operated by Digital Realty Trust, Inc., a US-incorporated colocation provider. Its role is space, power, cooling and physical security. It has no logical access to Customer Personal Data, holds no encryption key, and prompts and completions exist only transiently in memory and are never written to storage in that facility. The CLOUD Act reaches data within a US entity’s possession, custody or control; a colocation provider in this position has none of the three with respect to Customer Personal Data, so it creates no practical exposure. Customers assessing this for themselves should weigh physical-access risk, which fremverk does not claim is zero, against the absence of any persisted data to obtain.

Outside the inference path, the Backend’s own corporate suppliers — payments, email, support and CRM — include US-incorporated companies. They handle the Backend’s business operations, not fremai Customer Personal Data, and no prompt or completion reaches them. Mollie’s card-network chain likewise retains US-parented networks (Visa / Mastercard) for card payments, which SEPA avoids.

Ownership positions above were verified against the Backend’s published trust and sub-processor disclosures and by direct measurement of its API endpoint’s hosting, on 2026-08-13. The Backend’s published sub-processor list did not at that date name its French API host; fremverk has raised this in partner due diligence, and Annex B below records what fremverk has verified rather than only what the Backend lists.

12. Audit #

The Customer may audit fremverk’s compliance with this DPA once per calendar year on at least 30 days' notice, during business hours, at its own cost, with reasonable confidentiality limits and no access to other customers’ data. The parties may agree that an audit is satisfied by existing third-party audit reports where available.

13. Certifications and compliance posture #

fremai inherits fremverk’s compliance posture (same legal entity). fremverk does not itself hold standalone ISO 27001 / SOC 2 / BSI C5 certifications as of the effective date; its posture rests on (i) the inherited certifications of the sub-processors in Annex B, (ii) the measures in Annex A, and (iii) its security-testing programme. fremverk targets commencing ISO 27001 Stage 1 within 18 months and SOC 2 Type II readiness within 24 months. Backend certifications are recorded in Annex B as verified, including where a certification is in progress rather than held.

14. Order of precedence; changes #

In case of conflict on a data-protection matter, this DPA prevails over the Terms. Material changes follow the notice procedure in Terms §8; sub-processor changes follow §10 above.

Annex A — Security Measures #

fremverk implements and maintains the following technical and organisational measures (GDPR Art. 32). These reflect fremai’s metadata-only posture and its deployment on T Cloud Public in Germany, in a dedicated fremai-prd namespace isolated by network policy.

A.1 The metadata-only / no-content control #

• Prompt and completion bodies are never written to disk, database, or logs. The inference proxy (LiteLLM) is configured with request/response body logging disabled; only Usage Metadata (token counts, model, latency, status, cost, key id, timestamp) is persisted. Response/semantic caching is off. This is verified so that no body field lands in the metering database or the log pipeline.
• This is a non-disableable platform floor, not a per-tenant setting.

A.2 Data residency and infrastructure #

• All fremai processing is inside the EU/EEA. Compute, database (PostgreSQL), cache (Redis), key management, and observability run on T Cloud Public (eu-de, Germany), operated by Deutsche Telekom AG / T-Systems under ISO 27001, ISO 27017, ISO 27018, BSI C5 Type 2, and TISAX.
• Inference TLS terminates in-tenant; the Backend runs in the EU (Dublin/EU). No CDN in the inference path.

A.3 Encryption #

• In transit: TLS across all external and inter-service hops (customer → api.fremai.eu/v1, proxy → Backend, and all console/API traffic).
• At rest: the metering/account database, cache, and object storage are encrypted with fremverk-managed keys in T Cloud Public DEW KMS (per-domain keys, annual rotation). API-key material and OAuth refresh tokens are stored encrypted.

A.4 Access control and identity #

• Customer identity is managed in the self-hosted Zitadel identity layer (native accounts plus optional per-tenant OIDC federation); MFA/passkeys supported. Operator access to fremai systems uses fremverk’s separate workforce IdP with MFA and least-privilege roles.
• RBAC: fremverk-operator (metadata-only, audited) / tenant-admin / billing-admin / developer.
• Tenant isolation is logical: LiteLLM organisation/team/user/key scoping plus control-plane row-level security on a shared fremai database (not a per-tenant database).

A.5 Key and credential lifecycle #

• Customer inference keys (sk-fremai-…) are individually revocable with per-key budgets, rate limits, model subsets, and expiry. Leaked-key auto-revoke is enrolled via secret-scanning partner notifications on the sk-fremai-… prefix.
• OAuth refresh tokens are short-lived and rotated (design default: 12-hour key TTL, 30-day sliding refresh), stored encrypted, so a removed federated user loses access within the TTL.

A.6 Rate-limiting, budgets, and abuse controls (metadata-based) #

• Per-key / user / team / tenant RPM/TPM, concurrency, and budget limits; a global egress ceiling toward the Backend; and a spend-velocity anomaly breaker that auto-throttles a runaway or compromised key and alerts the developer and tenant-admin. Budget thresholds alert at 50/80/100%.

A.7 Audit logging and integrity #

• Security-relevant events (key issue/revoke, login, budget/quota change, admin action, data export) are written to a tamper-evident, per-tenant SHA-256 hash-chained audit log, WORM-anchored to object storage with 3-year retention, and customer-verifiable via export. No prompt/completion content is in the audit log (there is none to log).

A.8 Retention schedule #

A.9 Availability and recovery #

• Stateless proxy scales horizontally; database and cache use T Cloud Public managed redundancy. Backups are encrypted with DEW-managed keys. Phase-1 accepts a single-backend SPOF (see SLA §2); the routing layer is kept fallback-ready so a second EU backend is a configuration change.

A.10 Security testing #

• fremverk runs a security-testing programme; third-party penetration-test reports, when commissioned, are available to Customers under NDA on written request. A vulnerability-disclosure channel is published at security@fremai.eu.

Annex B — Sub-processor Register #

As of the date of this DPA, fremverk engages the following sub-processors to process Customer Personal Data for the fremai service. Customer-chosen identity providers that a Customer federates to fremai (its own Entra, Okta, Google Workspace, etc.) are the Customer’s processors, not fremverk’s sub-processors, and are not listed here.

Source of truth. The authoritative, canonical sub-processor list for fremverk and all its products is the shared machine-readable register at fremverk’s internal supplier register. The table below is the customer-facing view derived from that register — the register is the source of truth, and this Annex B reflects the fremai-relevant subset of it. Entries are reviewed on a quarterly cadence per the review runbook in fremverk’s supplier-review procedure; each supplier carries a next_review_due date in the register, and any addition, removal, or material change is propagated to this Annex B and notified under §10. (TensorX is shown below pending the executed partner agreement; its entry lands in fremverk’s shared register when that agreement is signed. The row below records what fremverk has independently verified, with the verification date, rather than waiting on the register.)

Bunny is confined to the non-inference surfaces by design (see §11). It never sees prompts or completions.

Mollie’s card-processing chain includes Visa and Mastercard network entities with US ultimate parents, governed by Mollie’s own sub-processor register. Customers preferring zero US-parent exposure on the payment path may pay by SEPA Direct Debit.

B.1 Self-hosted components (not sub-processors) #

fremverk self-hosts the following on its T Cloud Public infrastructure under its own control; they introduce no additional sub-processor: the LiteLLM inference proxy, the fremai control plane (signup, console, key management, credit ledger, metering), and the Zitadel identity layer (customer authentication and IdP brokering). These run inside fremai-prd and are covered by the Deutsche Telekom (T Cloud Public) infrastructure row above.

B.2 Carve-outs disclosed for transparency (not sub-processors) #

• EU Commission VIES — VAT-number validation at signup; a public-sector lookup receiving only the VAT identifier, not an Art. 28 sub-processor.
• Customer-federated identity providers — the Customer’s own processors, per the header note above.
• External uptime monitoring — probes only public health endpoints; captures URL, status, latency, TLS metadata; no Customer Personal Data. Provided by updown.io and fremverk’s self-hosted Uptime-Kuma, the same probe methodology fremverk uses across its products.

Change log #