Bavaria’s Privacy Regulator Puts AI Agents on Its 2027 Audit List: What Its New GDPR Guidance Asks

Bavaria’s data protection authority for the private sector has told companies where it will be looking next year. In a press release issued from its Ansbach headquarters on November 3, 2026, the Bayerisches Landesamt für Datenschutzaufsicht (BayLDA) said the use of so-called AI agents will be one of its focus topics for 2027, backed by a thematic series of audits. Alongside the announcement, the authority has added a new set of questions and answers on AI agents to its artificial intelligence information page, setting out how it reads the GDPR when software plans and carries out tasks on its own.

The guidance is in German. What follows is our translation and analysis of the key positions, with the original wording checked against the BayLDA’s own pages. Quotations are our translations unless noted. For companies with operations in Bavaria, which include a long list of automotive, insurance and industrial groups, it is the clearest signal yet of the questions an examiner is likely to ask.

What the BayLDA announced

Most of the November 3 press release describes the authority’s preventive work: talks at industry conferences, regular exchanges with insurance and automotive working groups, and the view that data protection “must not only begin once something has gone wrong,” in the words of BayLDA President Michael Will. The release mentions a September 29 panel at the Bitkom Privacy Conference in Berlin on the future of the GDPR and the EU’s Digital Omnibus, and the BvD autumn conference in Stuttgart on October 14 and 15, where a BayLDA specialist spoke on the risks and legal requirements of autonomous AI agents.

Two points carry practical weight.

• AI agents in 2027. The BayLDA says agents differ from classic AI applications because they “increasingly process information independently, combine different data sources and carry out actions.” It lists purpose limitation, transparency, access permissions and effective human control as the main legal questions, and says it plans a thematic audit series on agent use in 2027 to make new risks visible early and, where necessary, enforce compliance through targeted checks.
• Company DPOs. The release addresses reform discussions about the national obligation to appoint a data protection officer under Section 38(1) of the Federal Data Protection Act (BDSG). Regardless of how the law ends up, the authority says, in-house data protection expertise remains indispensable, and qualified DPOs are partners in preventive supervision for large and small companies alike.

The press release itself is not the guidance. It points readers to the authority’s existing AI page, where the agent material now sits under a heading marked “NEU” (new).

The BayLDA’s positions on AI agents, in eight answers

The new section on the BayLDA’s AI and data protection page is written as a series of questions. Its definition is functional: AI agents are “AI-supported software systems that can plan and carry out several steps largely independently to reach given goals,” using other applications, combining information from different sources and triggering further actions. The authority’s example is an agent asked to organize a business trip that reads the user’s calendar, researches trains, compares hotels, prepares a booking and creates a calendar entry. Some agents also have a persistent memory.

From there, the answers can be summarized as eight positions:

1. The GDPR applies in full. Agents need a legal basis under Article 6, sufficiently specific purposes, and adherence to purpose limitation, data minimization, transparency and security. The BayLDA acknowledges a real difficulty: at the start of a task, it often cannot be known which processing an agent will actually perform, only afterward. “The technical autonomy of an AI agent does not, however, release the controller from its data protection obligations.”
2. Technical access is not legal permission. Asked whether agents may access all available company data, the answer is a flat “No.” Under Article 5(1)(c), agents should reach only the data and functions their defined tasks require, and those boundaries must be set before deployment. The authority singles out email inboxes, document stores, CRM systems and HR software, and notes that a scheduling agent “regularly does not need comprehensive access to all personnel files or confidential customer documents.”
3. Reusing data is a purpose question, not a technology question. Using existing data through an agent is not a change of purpose merely because new technology is involved. What matters is whether the original purpose still applies. Summarizing a client project’s correspondence can stay within project work. Using the same correspondence to assess individual employees’ performance may be further processing that must pass the compatibility test in Article 6(4). The agent’s own selection and combination of sources can push it over that line.
4. Memory needs its own justification. Persistent memory can accumulate information about individuals and produce detailed profiles. Controllers should ask whether permanent storage is needed at all, how long it is needed, how data about different people and purposes can be kept apart, and how stored items can be corrected or deleted. The BayLDA also separates memory from model training: storing something in an agent’s memory does not mean it trains the model, and lawful memory use does not make training lawful.
5. Data subject rights reach the agent’s working files. Personal data may sit not only in source documents but in stored interactions, agent memories, generated assessments and logs, and information the agent creates, such as an assessment of someone’s reliability, can itself be personal data. Controllers must be able to find it for access requests under Article 15, correct it under Article 16, and delete copies held in memory and other stores under Article 17, with Article 19 notifications where data was passed on. The right of access does not, however, automatically entitle anyone to the whole AI model.
6. Telling people about the agent depends on what it does. Using an agent does not always create a separate duty to name the technology. But people must be able to understand the essential circumstances, which for agents may mean explaining purposes, sources and recipients, especially where the agent combines data from different origins, produces personal evaluations or takes far-reaching steps on its own. EU AI Act transparency duties for systems that interact directly with people can apply on top.
7. A rubber stamp is not human review. Agents that decide, for example, which job applicants get a rejection may fall under Article 22. Not every AI-prepared decision is a solely automated one, but “a merely formal confirmation of the AI result by a human is not sufficient.” The human must be able to exert independent and effective influence on the outcome.
8. The agent is never the controller. Responsibility follows the ordinary rules in Articles 4(7), 26 and 28. A company deploying an agent for its own purposes will usually be the controller, and external AI providers may be processors, joint controllers or independent controllers depending on the facts. Where an agent calls external services, controllers must check those data flows, processor terms and any third-country transfers under Chapter V.

The risk list examiners are likely to use

The BayLDA names seven risks that arise from agents’ extended capabilities. Read as an audit checklist, they translate into questions a reviewer can ask of any deployment:

• Unintended access: does the agent reach personal data the task does not need?
• Impermissible linking: are datasets combined without adequate purpose limits?
• Unintended disclosure: can the agent send personal data to external services or unauthorized recipients?
• Persistent storage: does data survive in memory and get reused in later tasks?
• Inaccurate information: are false or invented statements about people stored and reused?
• Manipulated instructions: can prompt injection through web pages or documents push the agent into unintended actions or transfers?
• Limited traceability: can anyone reconstruct which personal data the agent used or passed on?

Against those risks, the authority lists technical and organizational measures under Articles 25 and 32: limiting access rights to necessary data and functions, separating data and memory by purpose, restricting persistent memory and setting retention periods, traceable but data-minimal logging of relevant access and actions, protections against manipulated instructions and unauthorized transfers, human approval for particularly risky actions, the ability to interrupt or switch off automated steps, and technical support for access, correction and deletion requests.

Its worked example ties several of these together. An agent compiles an inaccurate assessment of a person’s creditworthiness from various customer documents and stores it. The person asks for access and correction. The controller must be able to establish what data is processed, where the wrong assessment is stored, and how its further use can be stopped or the data corrected. Systems should be designed from the start so that personal data is findable, correctable where necessary and deletable when the law requires.

A DPIA is not automatic, but the bar is close

The BayLDA says deploying an agent does not by itself trigger a data protection impact assessment. Article 35 still turns on whether processing is likely to result in a high risk. But it lists the features that raise the risk, including independent choice of processing steps, wide data access and automated decisions, and says the DPIA question deserves particular care where agents combine large amounts of data from different sources, process special categories, evaluate employees or make decisions with significant effects. Whatever the outcome, controllers should document the assessment in a way others can follow.

That last instruction matters for the 2027 audits. An examiner will rarely accept “we decided no DPIA was needed” without the reasoning behind it.

Older material on the same page, and one date to treat with care

The agent answers sit on a page the BayLDA has built up since 2024. Earlier sections distinguish between AI training and AI use, describe three roles (an AI operator using systems for its own purposes, usually a controller; an AI-as-a-service provider, usually a processor; and an AI model provider), and walk through records of processing, legal bases, DPIAs, transparency and data subject rights. The page also links a downloadable checklist on GDPR-compliant AI, which is labeled as a consultation draft, version 0.9, dated January 24, 2024.

Readers should treat one statement on that page with caution. It says the EU AI Act applies almost fully, in stages, by August 2, 2026 at the latest. The EU’s Digital Omnibus on AI, Regulation (EU) 2026/1744, which entered into force on July 27, 2026, moved the high-risk deadlines: Annex III high-risk obligations now apply from December 2, 2027, and rules for AI embedded in regulated products from August 2, 2028. Our guide to how the AI Act and GDPR interact after the omnibus covers the revised timetable. None of that changes the GDPR analysis the BayLDA sets out, which applies now.

How to get ready for a Bavarian agent audit

German supervisory authorities have often run thematic audits by sending written questionnaires to a sample of companies, followed by document requests and, in some cases, on-site checks. The BayLDA has not published the 2027 questionnaire. Based on its own guidance, a company using agents should be able to show:

• an inventory of agents in use, including those embedded in office suites, CRM and HR tools, with an owner and a defined task for each;
• the access each agent has, why it needs it, and how it is technically restricted;
• entries in the record of processing activities that describe purposes, data categories, recipients, external services called by the agent, and retention for memory and logs;
• a documented purpose analysis for any reuse of existing data, especially employee data;
• a DPIA, or a written reason for not doing one;
• a working route for finding, correcting and deleting personal data in agent memory and generated outputs when a request comes in;
• the points where a human must approve an action, and evidence that those reviews are substantive;
• processor terms and transfer mechanisms for each AI provider involved.

Captain Compliance’s data mapping, records of processing, assessment and DSAR workflows can help teams build and keep that documentation in one place, and our AI governance tools are designed to keep an inventory of AI systems and the guardrails assigned to them. Documentation shows what a company decided. It does not prove an agent stayed within its limits, which is why the BayLDA’s emphasis on logging and the ability to interrupt an agent matters as much as the paperwork.

For further reading, Norway’s regulator has taken a similar line, covered in our piece on Datatilsynet’s warning about AI agents. The memory risk is explored in how AI systems quietly build permanent profiles of people, and the injection risk in our guide to prompt injection safeguards. Teams unsure about the impact assessment threshold can start with when a DPIA is required, and for the German rules that sit alongside the GDPR, including the DPO appointment duty, see our overview of the German Federal Data Protection Act.

Frequently asked questions

Who does the BayLDA supervise?

The BayLDA supervises the private sector in Bavaria: companies, associations, freelancers and other non-public bodies. Bavarian public authorities fall under a separate regulator, the Bavarian State Commissioner for Data Protection.

Is the new material binding?

No. It is the authority’s interpretation of the GDPR, not a new rule. But it tells companies how the BayLDA will read the law in complaints and in its 2027 audits, and other German authorities often coordinate positions through the national data protection conference (DSK).

Does every AI agent deployment need a DPIA?

No. The BayLDA says a DPIA depends on the specific processing. It asks for particular care where agents link large volumes of data from different sources, handle special-category data, evaluate employees or make significant decisions, and for the result of the assessment to be documented either way.

If an agent stores something in memory, is that the same as training the model?

No. The authority distinguishes the two. Memory storage does not necessarily mean the data is used for training, and a lawful memory function does not make training on the same data lawful.

Has the BayLDA said which companies it will audit in 2027?

No. The press release announces a thematic audit series on AI agents for 2027 but gives no sample, sector or timetable.

The question an examiner will start with

Most AI governance programs were built for tools that answer when asked. The BayLDA’s guidance is written for tools that act, and its central demand is simple to state and hard to meet: before an agent runs, the company should know what it is allowed to touch, and afterward, it should be able to show what it actually touched. Companies that cannot yet answer the second half have about a year before someone in Ansbach asks.