Self-hosted LiteLLM for GDPR prompt logging controls

Three separate data flows in a self-hosted LiteLLM gateway need their own controls, and treating them as one leads to gaps in your records. The first is the message and response content sent to logging callbacks, which are the external logging providers you connect. The second is prompt content stored in spend logs in your database. The third is spend metadata, such as key, team, model and cost figures, which LiteLLM keeps so that budgets and rate limits work. The setting turn_off_message_logging stops messages and responses from reaching logging providers, but spend metadata is still tracked. Map each flow to a named setting in your own configuration, then confirm in a test environment which fields each one writes for your LiteLLM version.

The store_prompts_in_spend_logs setting decides whether prompt content is stored at all. If your team needs cost attribution and usage history but has no documented purpose that requires the text of prompts, turning this off means there is nothing to redact or delete later. This is the strongest data minimization option available, and it follows the default-protection idea in Article 25(2), which requires that only the personal data necessary for each purpose is processed, including its storage period. The trade-off is that incident investigation and quality review lose access to prompt text. The decision belongs to the data owner and the privacy lead together, and the reason for it should be written down before the setting is changed in production.

The beta redaction header, x-litellm-enable-message-redaction, lets a calling application request redaction on each request. Because the control sits with the caller, a missing or misconfigured header means that request is handled without redaction. Plan for this by setting redaction at the level of client libraries or internal SDK wrappers, and by testing a sample of requests to confirm what is actually stored and sent to logging providers. Since the feature is in beta, do not cite it as a control in your record of processing until your own tests show consistent behavior on your version. Review the release notes at each upgrade, because beta behavior can change between releases.

Scheduled deletion of old spend logs, configured with maximum_spend_logs_retention_period, applies the storage limitation principle in Article 5(1)(e), which says personal data should be kept only as long as necessary for the purpose. Choose the period from the documented purpose of each log category, then write it into the record of processing as the envisaged time limit for erasure under Article 30(1)(f). Privacy notices must state the storage period or the criteria used to set it, under Articles 13(2)(a) and 14(2)(a). Verify that the deletion job runs, check its logs, and confirm that database backups and any logging provider copies follow the same retention rule, because a deletion schedule in the gateway does not reach those copies on its own.

Before relying on these controls, run a short evidence exercise in staging. Send test prompts that contain clearly fictional personal data, then check the database, the logging provider and the backup restore path for each one. Export the relevant configuration, record the LiteLLM version tested, and note which features are beta. Ask your LiteLLM partner or the vendor to confirm the behavior of each setting for the version you will run. Keep the results with the record of processing so that a reviewer can see the configuration, the chosen periods and the test outcomes together. Repeat the exercise after each upgrade, since a change in version can change what is written where.

Your record of processing should state, for each category of data your LiteLLM gateway handles, the envisaged time limit for erasure where that is possible. Article 30(1)(f) asks for this, so the gateway's logging layer belongs in the entry from the start. For a self-hosted LiteLLM proxy, the categories usually include prompt and response content, spend metadata tied to virtual keys, users and teams, and any application logs the proxy writes. Keep these as separate rows, because each may serve a different purpose, carry a different period and sit under a different control. Agree the category list with your privacy and engineering leads before anyone fills in the period column.

Articles 13(2)(a) and 14(2)(a) link the storage period, or the criteria used to set it, to your privacy notices. Whatever you record internally must match what data subjects are told. If your notice states that prompts are kept for a set time, the spend log retention setting and the prompt storage switch must enforce that statement. Where your notice describes criteria rather than a fixed period, record those criteria in the record of processing and show how the gateway configuration implements each one. Article 5(1)(e) supports the same logic: personal data should be kept only for as long as the purpose requires.

Build the mapping as a table with one row per LiteLLM setting. Map turn_off_message_logging to the decision on whether message content reaches logging providers at all. Map store_prompts_in_spend_logs to whether prompt content is stored in the database. Map maximum_spend_logs_retention_period to the deletion schedule for spend logs, and name the setting that produces each period. Record the beta x-litellm-enable-message-redaction header only if your team has tested it and accepts its beta status for the flow in question. LiteLLM's enterprise documentation places team-level logging in the Enterprise offering, so confirm your license before listing it as a control. Each row needs a data category, a retention period, a purpose and a named owner.

The retention period itself has to come from your own assessment of necessity for each purpose. Confirm the default values in the release you run, then test each default against that purpose and change it where it does not hold. Article 25(2) expects only the personal data necessary for each specific purpose to be processed, including with respect to how long it is stored. Record who approved each period and the reason for it. Also document how erasure requests reach gateway logs. The EDPB's news item of 18 February 2026 described challenges hindering full implementation of the right to erasure. Write down the path from a request to deletion in spend logs, prompt storage and any downstream logging provider, and note where that path cannot reach. Ask your vendor to confirm whether individual records can be deleted, or only purged by schedule.

Redaction, the prompt storage switch and spend log retention reduce how much personal data reaches a model provider, but they do not settle whether Chapter V of the GDPR applies. Two locations decide that: where your self-hosted LiteLLM gateway runs, and where each model provider processes and stores prompts. The EDPB's Guidelines 05/2021 (version 2.0) treat remote access from a third country as a transfer, even where a person only views data on a screen for support or administration, and treat storage in a cloud outside the EEA as a transfer as well. A gateway hosted in an EU region can therefore still create a transfer if an engineer abroad can open prompt logs, or if a configured provider endpoint sits outside the EEA.

Before you choose providers, check each one against the transfer mechanism that would cover it. The EU-US Data Privacy Framework adequacy finding in Commission Implementing Decision (EU) 2023/1795 covers only US organizations on the Data Privacy Framework List. Confirm that the exact legal entity you contract with is listed, not only its parent or brand. The General Court upheld that decision in September 2025, and an appeal is pending as Case C-703/25 P. Because the outcome could change the basis you rely on, record the status you checked, the date you checked it, and ask counsel to confirm it before you sign or change routing.

Hosting location is not the only exposure. The US CLOUD Act provision at 18 U.S.C. 2713 requires electronic communication and remote computing service providers to preserve or disclose data in their possession, custody or control, whether that data sits inside or outside the United States. An EU region operated by a US-headquartered provider can still be reached by that obligation. The EDPB's Guidelines 05/2021 (Example 12) say that using an EU processor subject to third-country law with extraterritorial effect is not itself a transfer, but complying with a third-country authority request would be. Assess that exposure with each provider before you engage it, and document the assessment alongside your transfer analysis.

EDPB Recommendations 01/2020 (version 2.0) address the case where a provider must access data in clear text and the destination's public authorities have powers that go beyond what is necessary and proportionate. In that case the EDPB cannot envision an effective technical supplementary measure. Redaction or encryption at your gateway may reduce what the provider sees, but it does not fix a provider that needs plaintext prompts. Plan this as a design decision: build a provider register with hosting and support access locations, Data Privacy Framework status and CLOUD Act exposure, then route sensitive team traffic only to providers that pass, or to private models in your own infrastructure. Use LiteLLM's per-team and per-key model restrictions to enforce those routes.