Why LLM traces become personal data stores under GDPR
An LLM application that records full prompts and outputs is writing personal data into a new store every time a user types a name, an email address or a case detail. Masking in the application or in an OpenTelemetry Collector before export, combined with retention limits and a tested erasure procedure, is what keeps self-hosted traces manageable under the GDPR. Without those controls, the trace store becomes a large, loosely governed copy of personal data that is difficult to search, shrink or explain to a supervisory authority.
The GDPR requires no certificate, audit report or attestation, so there is no single document that makes a trace store compliant. Article 32 on security of processing applies to the trace store as it does to any other system holding personal data, covering access control to the UI, the API keys used by the SDK, and the PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage behind a self-hosted Langfuse deployment. Article 17 on erasure applies as well, so the team must be able to find and remove a specific individual's data from traces, not only from the source application. Article 42 certification is voluntary and does not reduce the controller's responsibility, so the organization that operates the application remains accountable for what its traces contain.
The practical decisions sit with the controller and its implementation partner. Confirm which fields of each trace (prompt, completion, metadata, tool arguments) may contain personal data, decide where masking runs, and document the retention period for each storage tier. Then confirm with the vendor and in your own environment which masking and retention controls your chosen Langfuse edition provides, since some of them, including server-side masking and data retention policies, need an Enterprise license key. Before go-live, run an erasure test against a known identifier and record the result as evidence.
Which GDPR duties apply to trace data
Once prompts and outputs are recorded, the trace store becomes a set of records the GDPR governs in the same way as any other personal data store. The cards below set out the duties that shape how traces are collected, protected, kept, erased and moved, and the control on this page that answers each one.
Data minimization at capture
Collect only the fields an evaluation or cost review needs. A full prompt often carries names, account numbers or health details that no dashboard requires. Masking in the application or the OpenTelemetry Collector removes these values before they reach Langfuse, so the store never holds them. Check which span attributes carry raw user input, tool arguments and retrieved documents, since these are the usual sources of unexpected personal data.
Storage limitation and retention
Traces should not be kept longer than the purpose that justifies them. The retention period is a decision the organization must document, and it must be set against any longer duty to keep AI system logs. Self-hosted retention controls in Langfuse sit in the enterprise tier, so confirm whether the enterprise license covers the retention rules you need or whether a scheduled deletion job must run outside the platform.
Security of processing under Article 32
Article 32 asks the controller and processor to apply technical and organizational measures suited to the risk. For traces, this means encrypting storage and backups, restricting who can open trace views, and logging access to them. The trace store holds the same sensitive content as the source application, so its access model should match that application. Confirm which access controls are available in your Langfuse tier before you design around them.
Erasure requests under Article 17(1)
Article 17(1) lists six grounds on which a data subject can ask for erasure without undue delay, including withdrawn consent, a successful objection and unlawful processing. A trace store must be able to find every trace tied to one person across prompts, outputs, tool calls and evaluation datasets. Masking reduces this work but does not remove it, so define how a request is matched to traces and how deletion is recorded.
Transfers under Chapter V
Chapter V restricts personal data leaving the EU or EEA unless an adequate safeguard applies. A tracing service hosted outside your control can move prompts and outputs across that boundary without anyone deciding it should. Self-hosted storage in an EU or EEA region keeps traces where your transfer assessment expects them. Check where backups, support access and any evaluation model calls actually run.
Accountability without a certificate
The GDPR requires no audit report or certificate, and Article 42 certification is voluntary and does not reduce the controller's responsibility. What the organization must hold is evidence: a record of which fields are masked, the retention setting, access reviews and erasure logs. Treat these as operating records that show the controls work, and confirm with counsel or your data protection officer what evidence your supervisory authority would expect.
Mapping GDPR requirements to tracing controls
This table maps the GDPR obligations that bite on LLM traces to the controls an observability function needs and where to configure them in Langfuse or an OpenTelemetry Collector. Read each row as a question to put to your team: which control applies, where it runs, and what evidence you can show. The main takeaway is that masking before export and storage location decide most of your exposure, and some controls depend on the Langfuse enterprise license.
| GDPR requirement | What the observability function must do | How to configure it |
|---|---|---|
| Article 5 principles, including storage limitation (Article 5(1)(e), illustrative anchor) | Keep prompts and outputs containing personal data only as long as the stated purpose requires, and delete them on a defined schedule | Set data retention policies in Langfuse (enterprise key); if unlicensed, run scheduled deletion jobs on ClickHouse and blob storage and document them |
| Article 25 data protection by design and by default | Strip or pseudonymize personal data before it leaves the application, so traces hold as little personal data as possible | Use the Python SDK mask_otel_spans hook, the JS/TS LangfuseSpanProcessor mask function, or masking in the application or OpenTelemetry Collector |
| Article 32 security of processing | Restrict who can view traces, encrypt data in transit and at rest, and log administrative access | Project-level RBAC and audit logs (enterprise key); TLS on Collector receivers and exporters; authenticator extensions such as OIDC on receivers |
| Article 17 right to erasure (grounds in Article 17(1)) | Find every trace tied to a data subject by trace ID or user ID, and delete it from all stores, including backups and evaluation datasets | Tag traces with user or session IDs only as hashed pseudonyms; use Langfuse trace deletion through the API, then purge matching rows from ClickHouse and blob storage |
| Article 19 notification of erasure to recipients | Pass erasure instructions to any downstream copies, such as exported datasets or evaluation sets, and record that this was done | Keep a register of exports and dataset IDs; confirm with your Langfuse vendor how deletions propagate to dependent objects |
| Article 30 records of processing and Article 32 access evidence | Show which systems hold trace data, who can access it and when access was granted or changed | Export RBAC role assignments and audit logs (enterprise key) to your SIEM; keep the Collector and Langfuse configuration in version control |
| Chapter V transfers to third countries (Articles 44 to 50) | Keep PostgreSQL, ClickHouse and blob storage in the approved region, with no replication or support access outside it | Pin PostgreSQL, ClickHouse and S3-compatible storage to EU-controlled accounts or data centers; confirm the location of any backup and log stream |
| Article 33 breach notification (Articles 33 and 34) | Detect unauthorized access to trace stores quickly enough to meet the 72-hour window in Article 33 | Alert on audit log events and unusual export volume; test the alert path during rollout and document who is notified |
Where to mask: SDK, OpenTelemetry Collector or Langfuse server
The Langfuse Python SDK exposes a mask_otel_spans hook that patches span attributes at export time. Your application keeps the full prompt and output in memory, the hook rewrites sensitive attributes, and only the masked version is sent to the Langfuse endpoint. Redaction therefore happens inside your own process, before any data crosses the network to the Langfuse server.
- What is redacted: Attribute values your masking function matches, such as input and output fields that contain names, account numbers or identifiers, before the span is exported.
- Tradeoff: Masking logic lives in each application. Every service that uses the SDK needs the same rules, and a new service without the hook sends raw data.
- Testing: You can unit test the function against sample prompts with known personal data, which makes the rules auditable as code.
- Scope: The hook covers spans created through the SDK. Data written by other instrumentation needs its own control.
- Enterprise note: Server-side data masking is a separate Langfuse feature that requires an Enterprise license key.
Confirm with your engineering team which code paths emit spans and whether all of them pass through the same export pipeline before relying on this control.
In the JavaScript and TypeScript SDK, masking is configured with a mask function passed to LangfuseSpanProcessor. The function receives span data inside the application and returns a transformed version, so sensitive values are replaced before the span is exported. As with Python, the raw content never needs to leave the application runtime.
- What is redacted: The fields your mask function transforms, typically prompt text, completion text and any metadata that carries user identifiers.
- Tradeoff: Front-end or edge code that uses the SDK must carry the same function, which can drift from the back-end version over time.
- Consistency: Keep the mask function in a shared package so that Node services and serverless functions apply identical rules.
- Failure mode: A function that throws or returns the input unchanged can leak data without an obvious error. Add tests that assert on the exported output, not only on the function.
- Enterprise note: Server-side masking remains an enterprise feature in Langfuse, so a pure SDK approach is a self-managed control.
Check which runtimes in your estate use the JS/TS SDK and confirm that each one loads the shared mask function.
If your applications emit telemetry through OpenTelemetry without the Langfuse SDKs, masking can happen in two places. The first is inside the application, through span processors or attribute filters you write yourself. The second is in an OpenTelemetry Collector, which receives, processes and exports telemetry before it reaches Langfuse. OpenTelemetry is vendor-agnostic and does not store traces itself, so the masking rules remain in configuration you own.
- In the application: Attribute filtering runs in-process and keeps raw content off the wire, but each language SDK needs its own implementation.
- In the Collector: A single pipeline can redact attributes for many services, which centralizes rules and makes review easier. Traffic between services and the Collector still carries raw data, so place the Collector in a network zone you control.
- Access control: Collector authenticator extensions can authenticate incoming connections, for example with OIDC, which limits who can send telemetry into the pipeline.
- Configuration hygiene: Follow the OpenTelemetry configuration best practices and pin Collector versions, since component stability varies by component.
- Ownership: The Collector is often run by a platform team, so agree on who approves changes to redaction rules.
Confirm which Collector components your distribution includes and whether the attribute processors you plan to use are stable in your chosen release.
Langfuse can also mask data on the server after ingestion. This is the Langfuse server-side data masking feature, which is listed among the self-hosted features that require an Enterprise license key. Because it runs after data has arrived, the raw prompt and output have already crossed your network and been received by the Langfuse stack, which matters for where the stack is hosted and who can reach its ingestion endpoint.
- What is redacted: Data matching the masking configuration is transformed in the Langfuse backend before users see or query it.
- Central control: One configuration covers all projects on the instance, which suits organizations that cannot rely on every team to implement SDK masking correctly.
- Cost: The control requires an enterprise license and a support arrangement that you should price from the Langfuse self-hosted pricing page and your own quote.
- Limit on protection: Data already ingested may still exist in storage, so pair server-side masking with the retention and erasure processes covered on this page.
- Hosting: Keep the Langfuse stack and its ClickHouse and object storage inside your controlled environment so that raw data is never exposed to a third party.
Ask Langfuse, or your implementation partner, to confirm the current license scope and whether server-side masking applies to every data type your traces contain.
Self-hosted platforms that fit this requirement
Masking personal data in LLM traces usually involves two layers: the instrumentation that redacts data before it leaves the application, and the tracing backend that stores what remains. The platforms below cover those layers, and each one carries a licensing condition that changes what you can run, and for whom, on your own infrastructure.
Self-hosted Langfuse
Langfuse is the backend most teams evaluate first for LLM traces. Its core repository is MIT licensed, and the code under the ee directories falls under a separate enterprise license. Client-side masking works in the open source version through the Python SDK's mask_otel_spans hook, the JS/TS SDK's mask function, or a masking step in an OpenTelemetry Collector. Server-side masking and data retention policies need an enterprise license key. Confirm which controls you need before you commit to a design.
Arize Phoenix
Phoenix is an LLM tracing and evaluation tool licensed under the Elastic License 2.0. You can run it inside your own infrastructure for internal teams, but the license prohibits providing it to third parties as a hosted or managed service. That matters if you build a customer-facing product or offer a shared tracing service to other business units or partners. Confirm your masking approach in the application, because Phoenix does not inherit the controls you configure in other backends.
OpenTelemetry Collector
The OpenTelemetry Collector is Apache-2.0 licensed and sits between your applications and any tracing backend. Its processors can redact or hash attributes that carry names, email addresses or identifiers before export, and its gateway mode gives you one place to enforce that rule across services. Authenticator extensions can also limit who may send telemetry. Masking rules are only as good as the processor configuration, so test them against real trace samples and confirm which components are stable in the version you deploy.
LiteLLM gateway
LiteLLM sits between applications and model providers and can log requests, enforce guardrails and apply budgets. It is MIT licensed, but its enterprise directory is covered by a separate license, so confirm which logging, guardrail and access features you plan to use are outside that directory. Redacting personal data at the gateway can catch input before it reaches a model provider and before it reaches a trace. Verify that the gateway's own logs are masked too, since they can hold the same prompts as your tracing backend.
What Langfuse keeps behind its enterprise license
The core of Langfuse, including tracing, evaluations and the APIs for those features, is available in the MIT-licensed open source version without limits, and self-hosted deployments run the same codebase as Langfuse Cloud. The exceptions sit in the ee directories, which fall under a separate enterprise license. For a GDPR design, the practical question is which privacy controls you need that are not in the open source tier. Langfuse's license key documentation lists the self-hosted features that require an Enterprise license key: server-side data masking, data retention policies, audit logs, project-level RBAC roles, protected prompt labels, UI customization, organization creators, the org management API with SCIM, and the instance management API.
Two of these matter most for personal data in traces. Without a license, server-side data masking and data retention policies are not available, so any redaction must happen in your application or OpenTelemetry Collector before data is exported, and you must manage deletion of old traces with your own storage and database procedures. Client-side masking works without the license, as described in the masking section above. Audit logs and project-level RBAC roles are also enterprise features, which affects who can view traces containing personal data and how you evidence those access decisions. The SCIM and instance management APIs mainly affect identity provisioning and administration at scale.
Confirm current licensing with Langfuse before design sign-off, because the feature list and the boundary between the open source and enterprise tiers can change between releases. Ask Langfuse in writing which features are included in each tier for the version you plan to deploy, how the license key is issued and renewed, and whether any terms restrict how you may process data under the license. Then ask your implementation partner to map each GDPR control you rely on to either a free feature or an enterprise feature, so that the cost of the license is weighed against a specific requirement rather than assumed.
How to handle an erasure request against trace data
This sequence turns an erasure request into a documented, verifiable deletion across the trace store, its backups and any derived datasets. It shows the controller where personal data sits in Langfuse and what to record at each stage.
Verify the request and its ground
The privacy office confirms the requester's identity and checks whether the request falls under one of the six grounds in Article 17(1), such as consent withdrawn, a successful objection or unlawful processing. The controller records the ground and the decision in the request file. Done means a written decision exists before anyone touches the trace store.
Locate affected traces by identifier
The platform team searches Langfuse for traces linked to the user or session identifier the application attached to each trace, using the Langfuse interface or API. Where masking replaced the identifier with a token or hash, the team uses the mapping kept in the organization's own systems. Done means a list of trace IDs, projects and time ranges is saved with the request file, including any identifiers that could not be matched.
Delete or overwrite stored records
Engineers delete the matching traces in Langfuse, which removes the rows in ClickHouse, and remove the related objects in S3-compatible blob storage for uploaded media or large payloads. Each deletion is logged with the trace IDs and the operator. Done means a repeat search for the identifier returns no results and the blob listing confirms the objects are gone.
Check backups and derived datasets
The team checks whether snapshots of PostgreSQL, ClickHouse and object storage hold the data, and whether copies of traces were exported into evaluation datasets, prompt test sets or data warehouses. The EDPB noted in February 2026 that retention and backups complicate full erasure, so the controller must decide and document how backups expire or are restored without the erased data. Done means a written note lists each copy, its location and the agreed handling.
Confirm erasure in downstream systems
The team asks any processor or integrator that received the data, such as an evaluation service or support tool, to erase its copies and confirm in writing. Confirm which systems sit inside the organization's infrastructure and which, if any, are external. Done means each recipient has returned a written confirmation linked to the request.
Record the action and its evidence
The controller records the request, the ground, the trace IDs removed, the backup and dataset decisions and the confirmations in a register that is kept separately from the trace data. Audit logs of the deletions, where Langfuse enterprise audit logs are licensed, support this record. Done means the file can be produced to a supervisory authority or auditor without exposing the erased content.
Respond to the data subject on time
The privacy office sends the response within the timeframe set in the controller's own erasure procedure, and states what was erased, what was retained under a stated exception and how the person can complain. Confirm the applicable response period with your data protection officer and procedure, as this page does not set one. Done means the response is sent and filed with the request.
Evidence auditors and supervisors ask for
This table lists the records a controller can produce to show how personal data in LLM traces is masked, kept, accessed and erased. The GDPR requires no audit or certificate, so these items serve the controller's own accountability duty and inquiries from a supervisory authority. Read each row as a question to answer with a file, export or configuration snapshot that exists in your environment.
| Evidence item | What it shows | Component that produces it |
|---|---|---|
| Masking configuration in code | Which span attributes, prompt fields and outputs are redacted before export, and the version of that code | Application SDK masking hook or OpenTelemetry Collector processor configuration in version control |
| Masking test results | That masking was tested on sample traces containing names, email addresses and identifiers, with results kept | Test scripts and saved trace samples from a pre-release check |
| Retention settings | How long traces, observations and blobs are kept per project and where deletion is enforced | Langfuse data retention policy (Enterprise license key) or documented ClickHouse and blob storage lifecycle rules |
| RBAC role assignments | Who may view traces that may still contain personal data, by project and role | Langfuse project-level RBAC roles (Enterprise license key) and the identity provider group mapping |
| Audit log exports | Who accessed, changed or exported trace data and when | Langfuse audit logs (Enterprise license key) forwarded to the organization's log store |
| Erasure request log | Each deletion request received, its legal basis for erasure, the traces and blobs affected and the completion date | Ticketing record linked to trace IDs, user IDs and deletion job output |
| Data processing records | The purposes, categories of data and recipients for the LLM observability processing activity | Records of processing kept by the controller, updated when the tracing scope changes |
| Storage location documentation | Where PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage run, and that no trace data leaves the agreed region | Infrastructure inventory and deployment manifests for the self-hosted Langfuse stack |
What masking tooling does not solve on its own
Masking in the SDK or Collector reduces what reaches storage, but it does not make a trace store free of personal data. The cards below cover the gaps that remain after masking is switched on, and what the organization must add around the tooling.
Regex misses context-based identifiers
Pattern rules catch email addresses, phone numbers and card-like strings, but they miss a name, a rare job title, a case reference or a street described in free text. A person can be identified from a combination of details that no single pattern flags. Test masking rules against a sample of real prompts from your own application, record what slips through, and decide whether those fields need a classifier, a field-level allowlist or a restriction on what users may type.
Model outputs can reveal new personal data
Masking inspects what the application sends, but the model can generate personal data that never appeared in the prompt, for example by completing a name from training data or by combining details retrieved from documents. Output masking has to run on the response path too, and reviewers should sample traces to find generated identifiers. Confirm with your AI and privacy owners whether generated personal data falls under the same retention and erasure rules as input data.
Backups and datasets keep copies
Masking applies at export time, so any copy made before the change still holds the original text. Database backups, ClickHouse snapshots in object storage, exported CSV files and evaluation datasets built from production traces can each keep personal data after the live trace is deleted. Ask the implementation partner how backup retention and dataset exports are set up, and write down who may create an export and where it is stored.
Server-side enforcement needs enterprise features
Client-side masking depends on every application and every SDK version being configured correctly, which is hard to guarantee across many teams. Server-side data masking, data retention policies and audit logs are listed by Langfuse as Enterprise license key features for self-hosted deployments. Check the license key documentation before design, and confirm with Langfuse whether your use needs them, since a gap in any one application can otherwise reach storage unmasked.
Access rules and policy remain your duty
Masking does not decide who may open a trace that still contains personal data, how long traces are kept, or what lawful basis covers the processing. Those decisions need a written logging policy, a documented legal basis review for each application, and role-based access limited to staff who need it. Assign an owner for these records before the first trace is stored, and review them when a new application or model is added.
Pending amendments do not change duties now
The Omnibus IV and Digital Omnibus proposals are moving through the EU legislative process, but the GDPR text has not been amended as of October 2026. Current duties under Articles 17 and 32 apply to your traces today, so a planned change in the law is not a reason to skip masking or erasure procedures. Ask your legal team to track both procedures and to schedule a review of this design when a text is adopted.
Questions buyers ask about GDPR masking in LLM traces
How much does masking and erasure work for LLM traces cost?
Cost comes from four parts: the masking design in the SDK or OpenTelemetry Collector, the erasure procedure, the infrastructure that runs Langfuse or Phoenix, and any enterprise license. Masking design and erasure procedures are largely one-time work, while storage, backups and license fees recur. Costs rise with the number of applications instrumented, the number of distinct personal data types in prompts and outputs, and how many erasure requests you expect to process. DeployOpen does not publish a price list. Ask any partner for a quote that separates one-time implementation from recurring infrastructure, and state which Langfuse enterprise features, such as server-side masking or retention policies, are inside or outside the scope.
How long does GDPR masking implementation take?
Duration depends on your environment more than on the masking tool itself. The main variables are how many services emit traces, whether they use the Langfuse Python or JS/TS SDK or plain OpenTelemetry, whether you already run a Collector, and how quickly your legal and data protection teams can confirm which fields count as personal data. Self-hosted Langfuse also has its own deployment sequence covering PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage. Ask for a written timeline tied to a defined scope and a list of client dependencies, including access to test data and a named approver for the masking rules.
Can our team implement GDPR masking in traces without a partner?
Yes, if your engineers already run the stack and have the legal input they need. Client-side masking uses documented hooks: the Python SDK's mask_otel_spans hook, a mask function on LangfuseSpanProcessor in the JS/TS SDK, or masking in the application or an OpenTelemetry Collector. The harder work is not the code. It is building a complete inventory of where personal data appears in prompts, tool outputs, metadata and file attachments, testing that masking catches it, and running erasure requests across ClickHouse and blob storage. A partner adds most value on the inventory, the testing and the erasure runbook.
Is the free open source version of Langfuse enough for GDPR?
The MIT-licensed open source version includes all core features and APIs, including client-side masking, so GDPR controls that run in your application or Collector do not require a license key. Several controls do need an Enterprise license key: server-side data masking, data retention policies, audit logs, and project-level RBAC roles. If your assessment requires centrally enforced retention or access records on trace data, plan for the enterprise license or build equivalent controls around the platform. Confirm the exact feature list and terms against Langfuse's license key documentation and its self-hosted pricing page before you decide.
Does the Phoenix license limit how we can use it?
Arize Phoenix is licensed under the Elastic License 2.0, which prohibits providing the software to third parties as a hosted or managed service. Running Phoenix for your own staff and applications inside your infrastructure is the common case, but if you plan to offer LLM tracing to customers as a service, the license would need legal review before you proceed. Confirm the license terms with your counsel for your specific use, since this page does not provide legal advice. The GDPR questions, such as masking and erasure, are the same regardless of which platform you choose.
What do we need to give a partner before work starts?
A partner needs three inputs from you. First, a data inventory listing the applications, model providers, and the kinds of personal data their prompts, outputs and tool calls contain. Second, the legal basis and purpose for processing that data, confirmed by your legal or data protection team, since the GDPR requires controllers to define them. Third, a retention decision: how long traces are kept, and the rules for erasure requests under Article 17, which lists six grounds for erasure without undue delay. Without these, masking rules are guesses. Ask the partner to confirm in writing which of these inputs are assumed and which are provided by you.
Will the GDPR masking work make us compliant?
No. The GDPR requires no audit, attestation or certificate, and certification under Article 42 is voluntary and does not reduce the controller's or processor's responsibility. Masking and erasure procedures are technical and organizational measures that support your obligations, including security of processing under Article 32, but compliance is determined by your overall program and, where relevant, by your supervisory authority. DeployOpen prepares systems, controls and evidence for compliance assessments, and independent auditors and certification bodies issue any reports or certifications.
How the masking and erasure work is scoped
A scope is agreed in writing before any masking or erasure work begins. The scope starts with a data inventory: which applications send prompts and outputs to Langfuse, which fields in those traces can contain personal data (free-text prompts, retrieved documents, tool arguments, user identifiers in metadata), and where each trace is stored, including the PostgreSQL, ClickHouse and S3-compatible blob storage that a self-hosted deployment uses. Masking rules follow from that inventory. They name the patterns or fields to redact, state whether masking happens in the Python SDK's mask_otel_spans hook, the JavaScript SDK's mask function on LangfuseSpanProcessor, or in an OpenTelemetry Collector, and define how the team tests that a masked value never reaches storage. The deployment and erasure runbook covers the environment, the upgrade path and the step-by-step procedure for locating and deleting a data subject's traces across every store, with a record of each request.
The client's legal and privacy team must make several decisions before engineering starts. They need to decide which lawful basis and retention period apply to each trace category, whether a retention policy is set in the platform or by a documented manual process, and who may view unmasked data. They must also decide whether server-side masking, retention policies and audit logs, which Langfuse lists as enterprise license features, are required, or whether client-side masking and a documented procedure are enough for their risk position. DeployOpen prepares the controls, configuration, runbooks and evidence that support these decisions, and it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies provide those, and the scope should name who the client will engage for any assessment.
How DeployOpen delivers GDPR-ready LLM tracing
DeployOpen approaches GDPR-ready LLM tracing as a scoped implementation: we map where personal data enters prompts, outputs and metadata, then build masking, storage and access controls into a self-hosted Langfuse or Phoenix deployment in your own infrastructure. We document the decisions and hand over the configuration so your teams can run and audit it.
How we scope
- We map which applications, prompts and outputs can carry personal data before any tracing is switched on.
- The written scope names the masking points, whether in the SDK or an OpenTelemetry Collector, and the fields to redact.
- We agree which Langfuse features need an enterprise license key, such as server-side masking and retention policies, before work starts.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
How we build
- We deploy self-hosted Langfuse with PostgreSQL, ClickHouse, Redis or Valkey and S3-compatible storage in your own accounts or data centers.
- We configure client-side masking in the Python or JS/TS SDK, or in the OpenTelemetry Collector, and test that redacted values never reach storage.
- We set project roles, SSO and access rules so only authorized staff can view traces that still contain sensitive context.
- We test masking with representative prompts and document which personal data categories remain visible and why.
How we hand over
- You receive the architecture, data flow diagrams and a record of every masking rule and where it runs.
- We document the erasure procedure for traces, including how requests are located, deleted and confirmed in each store.
- Runbooks cover retention settings, backup, restore, and upgrade steps, including the Langfuse v3 to v4 migration requirements.
- Evidence packs list configuration, test results and access settings for your assessors. We prepare evidence but do not issue audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- We re-test masking rules when prompts, models, SDK versions or Langfuse releases change.
- We help your legal and privacy teams review changes to retention or masking scope before they reach production.
- Support scope and response commitments are set in the retainer agreement, which you should review against your own needs.
