LLM logging for the EU AI Act and data sovereignty

The logs are produced by the tracing pipeline itself, not by staff copying data by hand. Instrumented applications send traces through the OpenTelemetry SDK or the OpenTelemetry Collector, and the Langfuse Web and Langfuse Worker containers write them to PostgreSQL, ClickHouse and S3-compatible blob storage. Auditors typically ask for the instrumentation configuration, a sample of recorded events with timestamps, and evidence that the pipeline runs on every production request path. Article 12(1) of the EU AI Act asks that high-risk systems technically allow automatic recording of events over the system's lifetime, so the evidence should show that capability is always on. DeployOpen can document the instrumentation, the event schema and the test runs that confirm events are captured, but an independent assessor decides whether that meets the requirement for your system.

Retention evidence comes from the retention configuration and from data that shows records survive the period. Article 19(1) of the EU AI Act requires providers to keep automatically generated logs for at least six months unless other law provides otherwise, so the stored period must meet or exceed that floor. In a self-hosted Langfuse deployment, the data retention policy is an Enterprise license feature, so confirm early whether you need it. Evidence usually includes:

• The configured retention setting and the change history for it
• Storage lifecycle rules on the S3-compatible bucket and ClickHouse table settings
• Backup job logs that show retained records are restorable within the period

The retention period itself is a legal decision for your compliance team, not a setting DeployOpen chooses for you.

Auditors look for a record of where each data store runs, which legal entity operates it and which parties can reach it. Self-hosting inside your own EU cloud accounts or data centers gives you control of the location, but the evidence must show it. Keep an inventory of the PostgreSQL, ClickHouse, Redis or Valkey and blob storage hosts with their regions, plus network policies that block egress to non-EU endpoints. Under GDPR Article 44, remote access from a third country counts as a transfer, so support access and log shipping also belong in the record. The EDPB Guidelines 05/2021 treat storage in a cloud outside the EEA as a transfer. Confirm with your counsel how the Data Privacy Framework and the CLOUD Act apply to any provider in your chain.

Reviewers expect a list of who can view, export or delete traces, and a log of when those rights were used. In self-hosted Langfuse, project-level RBAC roles and audit logs are Enterprise license features, so confirm whether your scope includes them. Without the license, you can still record access through the identity provider, reverse proxy and database audit trails. Evidence typically includes the role matrix, SSO group mappings from the authentication setup, periodic access reviews and the audit trail of administrative changes. Access to traces containing personal data should be limited to named roles with a documented need.

Evidence should show which fields are masked, where the masking runs and how it was tested. Masking can be applied client-side in the SDK or in the OpenTelemetry Collector before data leaves the application, or server-side, where Langfuse lists server-side data masking as an Enterprise license feature. Keep the masking rules under version control, a test set of sample prompts with personal data, and the results showing that masked values did not reach storage. Regulators will look at this under the GDPR data minimization principle as well as at the logging duty. Collector authenticator settings and exporter credentials belong in the same evidence set.

Keep dated restore tests that show a full trace set can be recovered from backup and read back by the application. The stack has four stateful components, so each needs its own backup and restore path: PostgreSQL, ClickHouse, Redis or Valkey, and the S3-compatible blob storage that holds events. Restore tests should record the scope, the time taken, the person who ran it and the checks that passed. Redis or Valkey usually holds queue state rather than the long-term record, so confirm which data must survive a loss. Your backup retention must align with the logging retention you chose, or the records will not be there when an auditor asks.

Change records should show each version deployed, what was tested and who approved the change. Langfuse says updates within a major version are non-disruptive and run database migrations automatically at startup, while major upgrades follow dedicated migration guides. The v3 to v4 guide requires ClickHouse 25.12 or later, PostgreSQL 15 or later and Redis 7.0 or later, and it moves to an observations-first data model, so the record must show the pre-upgrade test and the backfill plan. Keep the release notes, the change ticket, the test results on a copy of production data and the rollback plan. Track Collector versions too, since the OpenTelemetry Collector publishes new releases regularly.

DeployOpen prepares the systems, controls and evidence for a compliance assessment, and independent auditors or the relevant authorities decide whether the evidence meets the requirement. DeployOpen does not issue audit reports, attestations or certifications. In a fixed-scope engagement, the written scope should list which evidence items are produced, in what format and by which component, and which items remain your team's responsibility. Ask the partner to show a sample evidence pack from a test environment before the engagement starts. Ongoing evidence collection can be covered by a retainer if your environment changes often.

The biggest cost drivers are the infrastructure for the stack and the instrumentation work, and both depend on your scope. Self-hosted Langfuse runs two application containers, Langfuse Web and Langfuse Worker, plus PostgreSQL, ClickHouse, Redis or Valkey, and S3-compatible blob storage, so you pay for compute, storage and backups in your own cloud account or data center. Costs rise with trace volume, the number of agents and model calls per request, and how long you retain records. Langfuse's scaling guide lists minimum resources of 2 CPU and 8 GiB for ClickHouse, with at least 16 GiB of memory for larger deployments, which is a useful starting point for sizing. Ask for the infrastructure bill of materials and the sizing assumptions in any quote.

Setup, instrumentation of your applications, data-flow mapping, masking configuration and the initial compliance evidence are one-time costs. Infrastructure, storage growth, backups, monitoring, version upgrades and any support retainer recur. Storage is the cost most likely to grow, because logs must be kept for at least six months under Article 19(1) of the EU AI Act for high-risk systems, and longer where other law requires it. Major Langfuse upgrades follow dedicated migration guides and may need about 3x ClickHouse disk headroom when backfilling historic data, so plan that capacity from the start. Ask the provider to split the quote into one-time and recurring lines.

Yes, if your team already runs Kubernetes and operates data platforms such as PostgreSQL and ClickHouse, and can own backups, upgrades and access control. Self-hosted Langfuse is documented with Docker Compose for testing and Kubernetes with Helm or Terraform for production, so the deployment itself follows known patterns. The harder parts are instrumenting every application, deciding what personal data must be masked before storage, and producing evidence that auditors accept. Be realistic about the skills gap: if no one on the team has run ClickHouse in production, a partner is usually the faster route. Note that some controls such as server-side masking, retention policies and audit logs require a Langfuse Enterprise license key.

Duration depends on scope: how many applications you instrument, how many environments you run, how much historic data you migrate, and how many approvals your legal and security teams require. DeployOpen does not publish fixed durations. The written plan for each engagement states the phases, deliverables and timeline before work starts, and the timeline is built from the inventory and the decisions your organization has to make. Ask any provider to name the dependencies on your side, such as cloud accounts, network approvals and data owner sign-off, because these often set the critical path more than the software does.

DeployOpen needs a system inventory, named data owners and input from legal and privacy teams before a fixed scope can be written. The inventory should list every AI system and application that produces prompts, outputs or tool calls, the models they call, and where those records would be stored. Data owners decide which fields are personal data and how long records must be kept. Legal input is needed to confirm the retention period under the EU AI Act and GDPR storage limitation, and to confirm whether any third-country access exposure exists. DeployOpen prepares systems, controls and evidence, but the legal conclusions remain with your organization and its counsel.

Your organization remains responsible for deciding whether a system is high-risk, how long logs are kept and whether a transfer is lawful. DeployOpen prepares the technical controls, storage location, retention configuration and evidence, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. Ask your counsel to confirm the applicable duties under Article 12(1) and Article 19(1) of the EU AI Act and under GDPR Article 44 before the architecture is fixed, because storage location and access rules follow from those answers.

Ask for a written scope that lists the applications to instrument, the environments and regions where data will live, and the storage components with their sizing assumptions. Request the retention period, the masking approach, the access model and the list of Langfuse features that need an enterprise license key. The quote should separate one-time implementation from recurring infrastructure, support and upgrade work, and state what evidence the engagement delivers. Confirm who holds the backup keys and administrative access, and ask how exit and migration are handled, including how data can be exported if you change providers.