The Hamburg Commissioner for Data Protection and Freedom of Information (HmbBfDI) has set out, in a nine-page case study dated November 5, 2026, how it reviewed LLMoin, a chatbot built for the Hamburg administration on top of an OpenAI model, found its safeguards sufficient, and then adopted the same system for drafting correspondence on the data protection complaints it handles. The regulator does not claim that the model is free of personal data. It assumes the opposite - that the model is, in all likelihood, not anonymous - and concludes it can be used anyway, provided the system around it prevents such data from coming back out.

The case study is also a candid account of a workload problem. According to the HmbBfDI, it received 4,220 complaints under Article 77 of the GDPR in 2025, 62 percent more than the year before, and its staff did not grow at the same pace. In 2026, the number is still rising at roughly the same rate. A supervisory authority that spends much of its time telling companies how to deploy AI lawfully is now doing so itself, under its own interpretation of the rules it enforces.

In Short

Hamburg's privacy watchdog checked a chatbot the city built on an OpenAI model, decided its protections were good enough, and now uses it to help staff write letters about privacy complaints. It matters because the watchdog says an AI model that may hold personal data from its training can still be used, as long as the tool wrapped around it stops that data from leaking out, and that logic applies to any business building on someone else's model. Humans still decide every case and supply the legal reasoning, and the most sensitive complaints never go near the tool.

A wrapper, not a model

LLMoin was commissioned by the Senate Chancellery of the Free and Hanseatic City of Hamburg a few months after the release of ChatGPT in November 2022, according to the case study, and the HmbBfDI followed its development closely. Its design starts from a constraint rather than a capability. The Hamburg Senate has neither trained its own AI model for the system nor fine-tuned an existing one. LLMoin "operates at the AI system level," the case study states. "It forms a wrapper around the AI model that channels the inputs and outputs."

The model currently inside that wrapper is OpenAI's GPT-5.6 Terra, located in a Microsoft Azure cloud under a data processing arrangement. When the HmbBfDI carried out its supervisory review, the system ran on GPT-4.1. The document does not date the review or say whether the move to the newer model was assessed separately; a footnote says only that the conclusion on anonymity "will also apply to the current GPT-5.6 Terra model."

The modular design is meant to make the model replaceable without changes to LLMoin itself. Preparations are underway to use models hosted locally by Dataport, the public administration's IT service provider, and the current cloud setup "can thus be adapted in the future depending on the protection requirements of the processed data and in light of the geopolitical situation," according to the HmbBfDI. The authority does not elaborate on the geopolitical point. A configuration planned for 2027 envisages an AI model hosted on-premises at Dataport which, combined with further technical and organizational measures, is meant to allow the system to handle data with higher confidentiality requirements.

The Senate Chancellery makes LLMoin available to all Hamburg authorities and, increasingly, to public agencies in several other German federal states, which the case study does not name. Each agency decides whether and for what to use it. Within Hamburg, the Senate Chancellery has approved it only for personal data with standard protection requirements, and use cases that would make it a high-risk AI system under the EU AI Act, which the document calls the AI Regulation, are excluded. Obligations for the high-risk systems listed in Annex III of that law are now due from December 2, 2027 under a provisional agreement reached in 2026.

Users see four functions. Summarization shortens texts and filters out the most important content. Content generation produces texts in the style of typical administrative documents, with configurable parameters such as writing style and length. Search finds information in data collections provided across the federal state or in an authority's own sources. Free prompting opens a chat window in which users write their own inputs or pick pre-created prompt templates.

The EDPB opinion behind the review

The legal benchmark for the review was EDPB Opinion 28/2024 of December 18, 2024, in which the board of EU data protection authorities set out when AI models can be considered anonymous and how unlawfully processed training data affects their later use. The opinion rests on the premise that, depending on how training is conducted, personal data may be contained in an AI model. According to the EDPB, as summarized by the HmbBfDI, such data could be "absorbed" by the model parameters.

That is a problem for anyone using a model whose training data may have been collected or used unlawfully. The case study describes the three scenarios the EDPB sets out for that situation:

  • In the first, personal data remains in the model and the developer uses it as controller. Unlawful processing during training may weigh against the developer in the balancing of interests under Article 6(1)(f) of the GDPR, to the extent that the system outputs the data again.
  • In the second, a different controller uses the model. That controller has an independent obligation to ensure the lawfulness of the training and to prevent the output of unlawfully processed training data.
  • In the third, the model was successfully anonymized after unlawful training. If anonymization is demonstrated, the earlier unlawful processing does not affect the model's use, and the model falls outside the GDPR.

The HmbBfDI draws one common thread from all three: the focus lies on the AI system, not the model. Its handling of the threshold question is blunt. Determining whether a model is anonymous "is hardly feasible without knowing the specific methodology used by the AI model's developers," according to the case study. "A pragmatic approach is therefore to accept that the model is, in all likelihood, not anonymous."

On that assumption, the second scenario generally applies: the model may be used if sufficient risk-mitigation measures prevent the extraction of any personal data that may have been unlawfully incorporated into it. Regardless of whether a model stores personal data, the EDPB also requires mandatory system-level measures against specific risks of misuse, such as deepfakes, disinformation or fraud, and against negative impacts on fundamental rights, including non-discrimination, the right to work and mental health, according to the case study.

A footnote carries a technical reading that could matter well beyond Hamburg. Paragraph 43 of the EDPB opinion, according to the HmbBfDI, leaves open whether direct access to a model must be assessed in addition to extraction through the system. The authority assumes that both cases mean system-level access and do not refer to methods of direct model analysis such as mechanistic interpretability. Another footnote adds that a claim of anonymity must be maintainable "on a permanent basis," which will regularly require measures similar to those in the first two scenarios.

The erasure gap

One question the opinion leaves open, and the HmbBfDI says so plainly. If AI models can absorb personal data, data subjects' rights follow, including erasure under Article 17 of the GDPR. These are "questions that the EDPB itself, unfortunately, does not answer," the case study states.

Enforcing such rights at the parameter level is not currently feasible, according to the authority. "Methods for model-internal deletion (machine unlearning) are considered a field of scientific research that has not yet reached technical maturity." Extracting isolated parameter nodes carries a constant risk of residual information or collateral damage to the model's functions. The EDPB limits itself to requiring AI providers to keep evaluating whether unlearning techniques are feasible, and the opinion "does not establish binding criteria or enforceable erasure obligations directly applicable to the AI model." The difficulty of removing data from a model once it has been trained has been raised in advertising technology circles too. The case study's footnotes on the same point cite a handout on AI in federal authorities from the federal data protection commissioner, the BfDI, dated December 22, 2025, and a DSK resolution of March 10, 2026 on the EU's digital fitness check.

Filters do not close that gap. A footnote cites the German data protection conference, the DSK, which in its guidance on AI and data protection of May 6, 2024 took the position that suppressing undesirable outputs with filters does not amount to erasure under Article 17. Filters may still serve the rights and freedoms of a person affected by a specific output.

Hamburg retires its own theses

The case study also marks a shift in Hamburg's position. Because the EDPB has adopted a unified position, Opinion 28/2024 is now the binding standard for supervisory review, and the Hamburg Theses on Personal Data in LLMs, published in an HmbBfDI discussion paper dated July 15, 2024, "are therefore no longer authoritative for the HmbBfDI, even though they lead to a similar conclusion." Hamburg's earlier view that models do not hold personal data was challenged in 2025 by legal researchers who argued that large language models can qualify as personal data. In practice, according to the case study, both the EDPB and the Hamburg Theses require system-level safeguards aimed at preventing output that breaches the GDPR.

Ten safeguards, one overall judgment

During the review, it was acknowledged at the outset that modifying the model directly to make it anonymous is technically unfeasible, so the extraction risk had to be handled at the system level. "There is no single, universally applicable solution here," the case study states. Measures have to be chosen from a range of technical and organizational options that, taking costs into account, achieve sufficient mitigation when viewed as a whole. The HmbBfDI assessed the following measures, implemented by the Senate Chancellery, as sufficient overall.

Filters and the system prompt

An output filter acts after the model has produced its answer and suppresses or modifies results classified as impermissible or risky. Filters can be rule-based, working from defined patterns or deny lists, or AI-based. According to the HmbBfDI, they serve in particular to implement Article 21 of the GDPR, the right to object, and can suppress information known to be false or unlawfully represented in the model before users see it. LLMoin uses an output filter for exactly these purposes.

A content filter classifies outputs semantically, by topic, message or risk category, to catch deepfakes, disinformation or fraud. LLMoin's content filter sorts content into four categories - hate, sexuality, violence and self-harm - and suppresses matching outputs.

Provider-side protection sits with OpenAI. During development of its models, OpenAI takes measures, including in the post-training phase, to reduce the reproduction of training data, personal data among it, according to the case study, which cites an OpenAI document on privacy. Providers can also run their own content filters on API access.

The system prompt carries application-specific instructions that reach the model before the user's input. LLMoin's system prompt tells the model, among other things, not to make decisions and not to output personal data that the user has not supplied in the prompt. The authority is careful about what that achieves. "The system prompt is not a substitute for technical safeguards," the case study states, though it can contribute to an architecture designed for purpose limitation, risk mitigation and user guidance.

Retrieval and grounding

The search function uses retrieval-augmented generation, with semantic similarity search in a vector database. Responses are linked to a potentially curated database rather than drawn only from the model's parametric knowledge, and data in such a system can be deleted, corrected and controlled through role and permission mechanisms more easily than data represented in model parameters. The information available is essentially what each specialized authority provides. The limit is spelled out: "Outside of the 'search' function, however, this measure does not provide any protective effect." A footnote widens the definition, saying RAG in the broader sense applies whenever a system fetches information to enrich a prompt on its own, whether in a static rule-based setup or in an agent-based system that pulls information from available interfaces as needed.

Prompt-based grounding differs in that users paste the relevant context into the prompt themselves. If the model is told to base its answer on that material rather than its parametric knowledge, risks can be reduced. In LLMoin, according to the HmbBfDI, this is likely the most common scenario involving personal data, because users enter information from their specialized procedures to have the system generate draft texts.

Three of LLMoin's four basic functions use RAG or prompt-based grounding, according to the case study, which counts this design as a usage-restricting measure in its own right. Only free prompting falls outside, and there the protective effect depends on how each user works.

Rules, testing and training

The Senate Chancellery's global guidelines apply to every agency using LLMoin. They prohibit the processing of data requiring a high level of protection, automated decision-making, and the retrieval of personal data from the model's knowledge base unless the data subject made that data publicly available. That exception draws the case study's clearest criticism. "It would have been desirable for the retrieval of personal data to be completely prohibited in accordance with the system prompt's instructions, provided that the information is not contained in the user prompt or upload," the HmbBfDI writes. The written rules for users, in other words, are looser than the instructions given to the model.

Red teaming was commissioned by the Senate Chancellery during development, and further measures were derived from its results and implemented. The case study lists what such testing can probe: prompt injection, filter bypass, regurgitation, training data extraction, unauthorized output of personal data, and circumvention of the system prompt and usage rules. "Red teaming should not be viewed as a one-time demonstration of security," according to the authority, but as a supplementary method whose results feed back into filters, prompts, RAG configuration, rules and training. The document does not say who carried out the exercise or what it found.

The training concept covers the risk of hallucinations, the permissible handling of personal data, the limits of automated decisions, automation bias and the duty to carry out independent expert review. It is backed by a network of multipliers - colleagues who pick up questions, misuse and adjustment needs in a decentralized and ongoing way - which the case study ties to the requirement for sufficient AI competence among staff.

4,220 complaints and a staffing gap

The section on the HmbBfDI's own use opens with a number. In 2025, the authority received 4,220 complaints under Article 77 of the GDPR, a 62 percent increase on the previous year, "without the increase being offset to the same extent by an expansion of staff." PPC Land's calculation from those two figures puts the 2024 total at roughly 2,600. The case study cites the authority's 2025 activity report as the source.

Hamburg is not an isolated case. Bavaria's data protection authority recorded a record 9,746 complaints and related submissions in 2025, up 61 percent on 2024, and in July 2026 the EDPB asked the European Commission for a legal basis to share information across regulators as AI complaints stretched national authorities.

Against that backdrop, the HmbBfDI looked at AI support for complaint handling, from communication with parties, such as hearings and status updates, to drafting regulatory decisions. Complaints filed with a supervisory authority regularly contain personal data, sometimes special categories of it, descriptions of sensitive personal circumstances and information about third parties. Their outcomes affect complainants, controllers and sometimes others directly. An LLM-based system in this setting, the case study states, "requires particularly careful design and a clear definition of its scope of application."

The authority relies on Article 6(1)(e) of the GDPR, processing necessary for a task carried out in the public interest, in conjunction with Section 4 of the Hamburg Data Protection Act or the first sentence of Section 40(3) of the Federal Data Protection Act. That is the same chain of provisions it generally applies to case handling. Necessity, according to the HmbBfDI, has to be read in light of an administrative approach oriented toward cost-effectiveness, efficiency and citizen-friendliness. Citing legal commentary, the case study says processing that merely speeds up the performance of tasks is also considered necessary, and the concept can cover efficiency gains from digitizing administrative processes.

Drafting, not deciding

"The system must not replace the legal assessment performed by employees," the case study states. LLMoin may neither decide complaints nor carry out legal assessments that shape the authority's decisions within the meaning of Article 22 of the GDPR.

The reasoning leans on the Court of Justice of the European Union's SCHUFA judgment of December 7, 2023 (C-634/21). According to the HmbBfDI, it can be inferred from that ruling that AI-generated suggestions may be classified as automated decisions even if they only play a decisive role in the subsequent human assessment of the facts. The authority published a press release on the judgment's effects on AI applications the same day. The SCHUFA litigation has continued since; in October 2026, Germany's Federal Court of Justice ruled on four appeals over credit score disclosure, holding that the creation of a score can itself be an automated decision.

The safeguards follow from that reading. Internal guidelines prohibit automated decision-making, training sessions address automation bias and the limits of generative AI, and prompt templates are built so that the system performs no legal assessment. Case officers must state the relevant legal considerations themselves or, if they left them out of the prompt, supply them afterwards. When discretionary considerations are missing, LLMoin asks which considerations led to the decision and whether they should go into the document. It then "merely assists with the formulation and structuring of the results, which have already been made by humans."

Sequence matters here. Case officers must first read the case file in its entirety and must not let themselves be significantly guided by an AI-generated summary, according to the case study. Only after reviewing the file do they decide what kind of letter, with which key arguments and discretionary considerations, LLMoin should pre-draft. Every result must be thoroughly reviewed and adjusted where necessary.

What stays out of the system

Data requiring a high level of protection may not currently be entered into LLMoin at all, under an internal administrative regulation. The HmbBfDI calls this restriction "a snapshot in the context of a multi-stage rollout," linked in part to the particular client structure of the Hamburg administration.

Working out which data falls into that category is "not a trivial matter," according to the authority, which responded by inventorying and classifying the types of cases it typically handles. Complaints about data processing in a psychotherapy practice, or involving information from criminal proceedings, are generally unsuitable and must be handled exclusively by a human. Yet the line is not mechanical. Special category data under Article 9 of the GDPR, or a link to an area such as criminal prosecution, indicates high confidentiality requirements without settling the question automatically. The decisive factor is the actual risk in each case: the extent to which discrimination or other legal infringements would be expected if the information became public.

Some text is kept away from the model for a different reason. The HmbBfDI decided not to let LLMoin draft notices of appeal rights, even though a precise entry in a prompt template could produce them. A word-for-word reproduction of the notice of legal remedies set by the legal department is essential, and textual deviations "can never be completely ruled out even with a precise prompt template." Where consistency matters most, the authority has found it advisable not to use LLMoin at all, or only for parts of a document.

Testing with real case files

Rollout came in phases. In the first, personal data was off-limits, and staff gained experience on non-critical tasks such as drafting articles for the annual report and summarizing anonymized court decisions.

The second phase brought personal data in. For LLMoin to produce typical HmbBfDI letters, their content and style are described in prompt templates that precede the case-specific input. The case study uses the word "trained" for this step, but the mechanism is instructions in the prompt rather than training of the model. A test group created and refined several templates, which staff can now select in the interface. The group worked first with synthetic case files and then, in a second step, with non-anonymized ones. Its findings fed into the data protection impact assessment.

Testing with real data, the authority argues, is permissible under the CJEU's judgment of October 20, 2022 in C-77/21, which held that purpose limitation does not in principle preclude such tests where the purposes are compatible. It also considers such testing appropriate under Article 32(1)(d) of the GDPR, which requires a process for regularly testing the effectiveness of technical and organizational measures. Although LLMoin is not a high-risk system, the case study points to Article 9(6) of the AI Act, which highlights the role of preliminary tests in protecting fundamental rights. The results went into a training campaign that uses examples from complaint handling to teach staff to check outputs critically, avoid invalid inputs, recognize hallucinations and keep professional responsibility for themselves.

After testing, the system was rolled out across the agency for case files with standard confidentiality requirements, with use left to each employee's discretion. The benefit over drafting from scratch varies by area of responsibility, according to the HmbBfDI, and "not every department or file can be processed efficiently using LLMoin."

Disclosure without labels

Information obligations rest with whichever operator is responsible in a given context. The HmbBfDI's privacy policy states that, in appropriate cases, it uses the Senate Chancellery's LLMoin, among other things to process Article 77 complaints, that personal data may be transferred to the Senate Chancellery for that purpose, and links to further information. Individual letters carry no mark. "It is not legally required to individually label each letter to indicate that it was specifically pre-formulated by an AI system," the case study states.

The final paragraph turns to a consequence that is not strictly legal. "The implementation of an AI system for text generation results in significant stylistic and structural standardization of the results an authority for data protection presents to the public," the HmbBfDI writes. That is why, in its view, such a system should not simply be imposed from above but designed through a participatory process "with a generous timeline."

What the case study leaves out

For a document framed by a workload problem, it contains no figures on results. It does not say how many complaints or letters LLMoin has helped with, how much time case officers have saved, how often drafts needed correcting, or how many employees use the tool. It does not name the other federal states whose agencies use LLMoin, the party that performed the red teaming, or what that exercise uncovered. It does not date the supervisory review or say whether GPT-5.6 Terra was reviewed separately from GPT-4.1. Nor does it discuss how a regulator that cleared a system, and now relies on it for its own casework, would approach any later complaint about that system.

Why this matters for marketing

The second EDPB scenario is where most of the advertising and marketing industry sits. Agencies, publishers, retailers and ad tech vendors that build assistants, customer service bots or content tools on models from OpenAI and others are deployers of a third party's model, not its developers. The Hamburg case study is a supervisory authority's worked example of what that position requires: treat the model as probably not anonymous, then put output filters, grounding, usage rules, adversarial testing and staff training around it, and document why the combination is enough.

What does the Hamburg approach not settle for a company? Several limits apply beyond the public sector. Under the DSK view the case study cites, a filter that stops a name from appearing is not erasure, so the data may remain in the model. The EDPB has set no enforceable erasure obligation at model level. And the SCHUFA reading, under which a suggestion can count as an automated decision when it drives the human outcome, reaches AI-assisted credit, insurance or eligibility tools as much as a regulator's letters. The legal footing also differs: the HmbBfDI relies on a public task under Article 6(1)(e), while a company deploying the same kind of tool would typically need another basis, and the question of how far legitimate interest stretches is being reworked in Brussels, where a Council Presidency compromise of September 2026 struck an unconditional right to object from a proposed GDPR clause on AI.

German regulators have built a sizeable body of AI guidance, and the case study draws on it, including the DSK's guidance on technical and organizational measures for AI systems from June 2025. Other authorities have focused on the models themselves; the Dutch Autoriteit Persoonsgegevens said in May 2025 that most generative AI models currently fall short of its GDPR preconditions. The EDPB has since turned to how training data is collected, with guidelines that tell AI developers to avoid sites blocking scraping through robots.txt. The Hamburg authority itself has been active on consumer AI hardware, publishing a report on Ray-Ban Meta glasses in September 2026.

The case study is one authority's interpretation. It binds neither other supervisory authorities nor the courts, and it describes a public administration rather than a company. Whether other regulators accept a deployer's system-level safeguards as an answer to a model's unlawful training, without proof that the model is anonymous, remains untested in enforcement.

Timeline

Summary

Who: The Hamburg Commissioner for Data Protection and Freedom of Information (HmbBfDI), which reviewed and now uses LLMoin, and the Senate Chancellery of the Free and Hanseatic City of Hamburg, which commissioned and runs the system. OpenAI supplies the model, hosted in Microsoft Azure, and the public IT provider Dataport is preparing locally hosted alternatives.

What: A nine-page case study on LLMoin, a chatbot wrapped around an OpenAI model (GPT-4.1 at the time of review, GPT-5.6 Terra now). The HmbBfDI assumes the model is likely not anonymous and, applying the second scenario of EDPB Opinion 28/2024, accepts its use because of ten system-level measures: output and content filters, OpenAI's own protections, a system prompt, RAG, prompt-based grounding, usage rules, red teaming, training and usage-restricting functions. The authority uses LLMoin to pre-draft complaint correspondence, with case officers supplying all legal reasoning and sensitive cases excluded.

When: The case study is dated November 5, 2026. The authority received 4,220 complaints in 2025, up 62 percent, and says the rise continues in 2026. An on-premises configuration is planned for 2027.

Where: Hamburg, Germany, with LLMoin also used by public agencies in several other German federal states, under EU law: the GDPR, the AI Act and the EDPB opinion that applies across the EU.

Why: The HmbBfDI faces a rising complaint load without matching staff growth, and it uses the case study to show how a deployer can meet the EDPB's expectations for a third-party model whose training data may include unlawfully processed personal data. The approach places responsibility on the system around the model, since deleting data from the model itself is not technically feasible and the EDPB sets no enforceable erasure obligation at model level.