Data location Germany

All client data is processed and stored in a datacenter in Frankfurt am Main. There is no data flow to third countries — neither for storage nor for processing nor for AI inference. Daily backups stay in the EU region Frankfurt.

We name our infrastructure components functionally rather than by vendor. Independence also means not being uncancelably tied to a single cloud provider or model vendor. The architecture is built so that storage and inference platform remain swappable as long as they sit in the EU.

GDPR architecture

LEGALinhouse is not "made GDPR-compatible" — it is designed as an architecture for GDPR requirements. Specifically:

  • Personal data does not leave the EU — neither for storage nor for processing nor in reports.
  • Purpose binding in the data model — every data category is held in the schema with purpose and legal basis; reports and exports preserve this binding.
  • Erasure concept — retention periods per data category configurable, with soft-delete and automatic hard-delete stage.
  • DPA for every customer — not a generic "T&C DPA annex" but structured data processing agreements.

Features that support the customer's own compliance management (their own record of processing, DPIA workflows, their own incident management, data subject rights tracking) are being developed as an optional add-on module — see DPMS · Data Protection Management. The module is currently in planning and not yet included in beta access.

AI data protection — the 3-phase anonymization

Before any client text touches an AI, it runs through a 3-phase pipeline: pseudonymization of 15 entity types on our own servers in Germany → AI processing on an inference platform in the EU region Frankfurt → re-personalization of the response. The language model sees no identifying data.

Consequence

Even in a hypothetical breach of the inference platform, no client data would be affected — the model never saw it. Full explanation of the pipeline with all entity types under Concept · AI Architecture.

EU AI Act — high-risk compliance

The EU AI Act classifies legal AI applications as high-risk systems. This imposes requirements on logging, human oversight, explainability and transparency that LEGALinhouse meets by design:

  • Full logging of every AI operation — which specialist, which sources, which inputs, which model.
  • Mandatory human approval for every AI-generated result. No auto-send.
  • Draft marking — AI output is visibly marked as AI draft until an employee approves it.
  • Explainability — for every AI answer, knowledge graph sources and specialist can be traced.

RDG compliance

LEGALinhouse is a productivity tool, not a legal service under the German Legal Services Act (RDG). We build the tool with which legally trained employees accelerate their work — we make no legal decisions and give no legal recommendations.

The architecture holds this line consistently: AI output is always draft, always human-in-the-loop, always marked as AI-generated. More under Concept · RDG and Limits.

Encryption & infrastructure

  • In-transit: TLS for all connections — browser ↔ application, application ↔ storage, application ↔ inference platform.
  • At-rest: Encryption of all client data on storage systems per current state of the art.
  • Tenant isolation: Strict tenant separation in the data model and the application layer. One tenant's data is technically not retrievable from another tenant.
  • Sub-processors: List of all engaged sub-processors (datacenter, inference platform) accompanies every DPA; changes are reflected with notification obligation and right to object.

Access & permissions

Permissions follow a role model per tenant. Employees see what their role allows — no more. External staff (lawyers, tax advisors, other advisors) receive default-deny access: they see nothing until they are explicitly granted access to a matter or document. This lets you bring in external advisors without giving them full access.

  • Role-based access control (RBAC) per tenant
  • External staff with explicit per-object approval
  • Audit log of all write accesses plus document downloads
  • Session management with auto-logout

Audit trail

Every change in every module is logged: who, when, what, previous and new value. This includes AI operations. On compliance audits or internal investigations, the system delivers the full evidence at the press of a button — without after-the-fact Excel work.

  • Append-only audit trail with access protection
  • Filtering by employee, module, tenant, period
  • Export for external audits

DPA with customers

Every customer receives a data processing agreement (DPA) under Art. 28 GDPR. The DPA describes subject and duration of processing, nature and purpose of processing, categories of data subjects and data, technical and organizational measures (TOMs) and sub-processors.

We name infrastructure providers internally by name, transparently in the DPA, and functionally in external communication — because the agreement with the customer must be clear, while the marketing should not live off vendor logos.

Backup & recovery

Client data is backed up regularly; backups stay within the EU. Recovery times are dimensioned so that a customer should experience a full day's outage no more than once over a multi-year period. We perform backup tests internally at intervals.

Existing customers also have the option to export data, so customers can pull a copy of their own data at any time.

Incident response

Data protection incidents are reportable within 72 hours. For our own infrastructure we operate an incident response process with structured intake, logging and clear escalation paths — on request we provide the TOMs documentation.

A customer-facing incident management tool that directly supports the customer's own DPMS (intake, 72-hour deadline, supervisory authority notification draft, data subject notification) is part of our planned DPMS add-on module — currently in planning, not yet available.

Technical detail questions? Write to us — we respond with appropriate depth.