LLM EU — Data Processing Agreement (TEMPLATE) TODO legal entity: this template must be reviewed and completed before it is presented as an agreement. It is not legal advice and it is not signed. 1. Parties Controller: the customer, as identified in the order form. Processor: LLM EU, [company name, registered address, register number, VAT id — to be completed]. 2. Subject matter LLM EU processes inference requests on behalf of the controller and records usage metadata (model, region, tokens, latency, cost, policy decision). 3. Duration For the term of the agreement between the parties. 4. Nature and purpose of processing Routing of inference requests, metering, and the production of audit records the controller can export. 5. Categories of personal data As determined by the controller, to the extent the controller includes personal data in prompts. 6. Retention Only zero is implemented and is the default: prompt and completion bodies are not persisted in the database. Policies may store 24h, 7d or 30d choices; these do not enable encrypted body storage. Requests exceeding policy fail first with 403 retention_exceeds_policy. Otherwise effective nonzero retention, including an inherited policy choice, fails with 501 retention_not_implemented. Requests may narrow retention to zero. Metadata retention and deletion schedules require completion and review; export windows below are not deletion schedules. 7. Sub-processors See /en/legal/subprocessors or /de/legal/subprocessors. The inventory is incomplete: categories only, not confirmed contracted entities. Legal identities, locations, data categories and review date remain pending. A first-party hosted model does not imply sending prompts to its developer. 8. Technical and organisational measures Implemented controls include scrypt-hashed API-key secrets, organization scoping, rate limits and residency filtering. Session cookies contain id.secret; only a hash of the secret is stored server-side. Cookies are HttpOnly, SameSite=Lax and Secure in production. TLS and disk encryption are deployment-dependent and not independently verified; HTTP backends are permitted. Role authorization within an organization is partial: policy, team, settings, credit and key revocation are limited to owner and admin, platform_write keys may only be minted from the console by an owner or admin, bulk exports require a writing role, and viewer is read-only. Read access to an organization's traces, usage and exports remains organization-wide. Keep stripe_enabled off: its credit handler accepts user-supplied amounts without payment verification, which no role check addresses. No independent penetration test has been completed; this template is not evidence of certification or security readiness. 9. Data subject requests The console account export me.json includes selected account fields, organizations, key metadata (not secrets), current policies, the latest 200 traces per organization and daily usage aggregates for 365 days. This is not a complete copy of all personal data. Further access and deletion requests require manual handling. Assistance and response period: [N days — to be completed and reviewed]. 10. Transfers outside the EU/EEA Residency filters constrain configured endpoint classes; they do not prove actual processing location or immunity from legal disclosure. Seeded endpoints are mocks (dev-mock; no weights run). Real inference requires configured per-region backends and matching endpoint rows. Partner routing is off by default. Verify the actual deployment, recipient chain and any transfer safeguards before contracting; no blanket no-transfer assurance. 11. Audit The separate console audit.ndjson export defaults to 7 days, permits at most 90 days and caps traces at 5000. Check counts.truncated in its manifest: reaching the cap marks possible truncation. Policies and endpoint cards show current state, not historical state at request time. Traces are self-reported operational records, not independent location verification. Exports do not establish complete capture of every request.