AI data protection for mid-sized businessesProtect data. Enable innovation.

01 / Legal foundations

The main misconception: The GDPR does not prohibit AI from processing personal data

First, a basic clarification: DSGVO and GDPR are the German and English abbreviations for the same European General Data Protection Regulation.

The regulation does not generally prohibit either commercial AI services or the processing of personal data by language models.

What matters is whether the specific processing is lawful and appropriately protected.

This includes a suitable legal basis, a clear purpose, data minimisation, appropriate security measures and, where applicable, a data processing agreement with the AI provider. Retention periods, subprocessors, possible transfers to third countries and individuals’ rights must also be considered.

Information obligations and the necessary documentation, particularly records of processing activities, also matter. Special categories such as health data require an additional assessment under Article 9 GDPR. Where processing is likely to result in high risk, a data protection impact assessment under Article 35 is required beforehand. Article 22 must be considered for solely automated decisions with legal or similarly significant effects. A human rubber stamp does not replace a genuine assessment. DSK: AI and data protection (German)

Consider an example:

An employee wants AI to draft a response to a customer complaint. The text contains a name, an order number and a description of the problem.

This does not automatically make the request unlawful or mean that anonymisation is mandatory. Under appropriate legal and technical conditions, an external AI service can also process personal data.

Conversely, the same process does not become lawful merely because a provider promises not to use customer data to train its models.

“No training on customer data” is an important contractual and security consideration, but it is not a complete data protection framework.

Likewise, hosting in Germany does not automatically mean GDPR compliance. Even a fully local AI model does not release a business from its data protection obligations.

The right question is therefore not: “May our AI see personal data?”

It is: “Which data does this process actually need, who processes it, on what legal basis and with which safeguards?”

02 / Transfer less data

The simplest data protection measure is often the most economical

Before considering encryption, pseudonymisation or AI gateways, we should ask:

Does the language model need this data at all?

Practical example: Revenue analysis from the ERP system

A mid-sized industrial company wants to know which product groups performed particularly well last quarter.

An obvious but unnecessarily risky approach would be to export a large order table as a CSV file and upload it to an AI chat.

That table might contain customer names, contacts, addresses, individual orders and other information the analysis does not need.

A much better approach is this:

The ERP system first calculates the required metrics itself. Only then does the language model receive an aggregated table containing product group, revenue, sales volume and year-on-year comparison.

The result: less information transferred, lower risk, usually fewer tokens and often better analysis quality.

You are a data analyst for a mid-sized industrial company.

I want to analyse revenue trends by product group.

Using the database schema below, create a read-only SQL query that aggregates net revenue, sales volume and order count by product group and month.

Personal data, customer numbers, contacts, addresses and individual order details must not appear in the query results.

Consider re-identification risks in very small groups and propose minimum group sizes or further aggregation where appropriate.

Do not invent database tables or columns. Ask questions if necessary schema information is missing.

Database schema: [Insert only the required schema, without real customer data]

Review the proposed SQL query before execution and run it with technically restricted read-only permissions. A prompt replaces neither database permissions nor a check of the results for identifiable personal data.

This is an example of privacy by design: data protection is built into the workflow’s architecture from the outset. DSK: Technical and organisational measures (German)

That creates a significant economic advantage. Data that is never transferred does not need to be detected, masked, restored or deleted at an external service later.

03 / Four architecture options

Four architecture options—and when each makes sense

Mid-sized businesses generally have four options. They are not mutually exclusive.

Option A: Commercial enterprise AI

For many businesses, an approved AI service with suitable business terms is the most economical starting point.

Examples include relevant enterprise offerings from OpenAI, Anthropic or Microsoft, as well as AI APIs delivered through professional cloud platforms.

Model quality and price should not be the only selection criteria. Contracts, processing locations, deletion and retention rules, access rights, security features and, where relevant, international data transfers need to be assessed.

It is also important to distinguish personal subscriptions from enterprise products. A personal Pro subscription does not necessarily carry the same contractual data protection terms as the same provider’s enterprise service.

Practical recommendation: Before buying additional protection software, examine the controls already available in the enterprise service you use.

Option B: Use existing enterprise security

Many mid-sized companies already use Microsoft 365, Entra ID, SharePoint and endpoint security solutions.

These often provide access controls, data classification, logging and data loss prevention (DLP).

DLP refers to mechanisms designed to detect or prevent unwanted transfers of sensitive information.

Explore those existing capabilities before introducing a separate AI privacy product. However, not every advanced AI-specific protection feature is included in every Microsoft 365 licence. Microsoft: DLP for Copilot

Another frequently underestimated problem is the accumulation of access rights in SharePoint and other knowledge systems over many years.

An AI assistant that correctly respects existing permissions does not solve the problem of too many employees having been given access to certain documents in the first place. Microsoft: Data, privacy and permissions

Option C: A central privacy layer

Once businesses develop their own AI applications, use multiple model providers or connect agents to internal systems, a central technical protection layer becomes worth considering.

A simplified architecture might look like this:

Data is inspected before the model is called. Where needed, personal information can be removed, replaced with placeholders, or the entire request can be blocked.

The advantage: privacy logic is maintained in one place and reused across several applications.

This makes the approach particularly relevant for companies that want to integrate AI systematically into their processes.

Option D: Local AI

Another option is to run the language model within your own infrastructure or an appropriately controlled private cloud environment.

This can avoid external transfers during inference, provided adjacent services, telemetry and network access are controlled as well.

The trade-offs are additional operational effort, hardware or cloud costs, and the need to match model quality and performance to the use case.

Local AI is therefore not automatically the best data protection solution. It is particularly useful where the additional technical control delivers a concrete benefit.

04 / Pseudonymisation

Pseudonymisation: Replace identifiers without making processes unusable

Automatic pseudonymisation is a particularly useful building block.

Consider a simple customer service example.

The original message reads:

“Max Mustermann reported a defect in the control module on 12 October. Please draft a friendly reply.”

Before sending it to the language model, the name is replaced locally:

“CUSTOMER_0042 reported a defect in the control module on 12 October. Please draft a friendly reply.”

The language model drafts its response using the placeholder.

Only within the controlled business environment is “CUSTOMER_0042” converted back to “Max Mustermann” where needed.

The practical advantage: the AI can still handle the business task without needing the person’s name to draft the wording.

This is pseudonymisation, not automatically anonymisation. For the business that can restore the link, the data remains personal data. Other details may also allow a person to be identified indirectly.

The recipient’s perspective needs a separate assessment. In its judgment C-413/23 P of 4 September 2025, concerning the data protection regulation for EU institutions, the CJEU clarified that pseudonymised data is not automatically personal data for every person. Actual identification possibilities matter. This does not create blanket permission for transfers or remove the controller’s information obligations. CJEU: Explanation of the judgment

Which open-source tools are useful?

One candidate is Presidio, originally developed by Microsoft.

It can detect different types of personal information using patterns, language models and custom rules, then replace or mask them.

Specialised recognition models such as GLiNER can complement Presidio. For German business data, combining several methods is particularly useful: regular expressions, checksums, known master data and context-sensitive recognition.

For example, an employee ID can usually be handled more reliably using the database structure than by analysing its characters alone.

However, a crucial limitation is often underestimated:

Automated detection of personally identifiable information (PII) cannot guarantee that every piece of personal information will be found.

The Presidio project documentation explicitly acknowledges this limitation.

A pseudonymisation solution should therefore not simply be installed and declared “GDPR-safe”.

Before production use, it needs tests with representative data structures, documented error rates, appropriate rules for content that cannot be checked, and clearly defined behaviour when technical failures occur.

You are a test engineer for a data protection component.

Create 100 fully synthetic German test cases for detecting personal data.

Include names, addresses, business contact details, employee IDs, customer numbers, SQL data, CSV files and JSON structures.

Add challenging examples, including sole traders whose business names contain personal names, indirectly identifying phrases and technical product names that might be mistaken for people’s names.

For each case, provide the input text, the expected detection spans, the expected protection mechanism and possible causes of error.

Use fictional data only.

The goal is an auditable test suite that reveals both missed personal information and incorrect masking.

This is a useful first step before passing real business data through a new filter.

05 / Protecting agents

AI agents are different: A filter in front of the model is not enough

With conventional chatbots, the focus is primarily on controlling what users enter and what responses are generated.

AI agents are more complex.

A software development agent can read files, execute shell commands, query databases, modify Git repositories and communicate through external tools.

Suppose such an agent is asked to analyse and modernise an existing ERP application.

It discovers a table containing employee data. Even if all requests to the language model pass through a local pseudonymisation proxy, additional risks may remain.

The agent might transfer data through another network route, call an unapproved MCP server or write personal information into logs and development artefacts.

A privacy proxy protects only the data flows that actually pass through it.

A sound agent architecture therefore needs several safeguards:

• Restricted file, database and network access, following the principle of least privilege.
• Synthetic or suitable test data wherever possible, rather than complete production datasets.
• Approved model providers and clearly controlled external tools.
• Protection against accidental disclosure of credentials, logs and sensitive content.
• Human approval for particularly critical or irreversible actions.

For software migrations in particular, this architecture can preserve productivity without giving an agent unnecessary data or permissions.

The most economically significant measure is often not a particularly intelligent data filter, but a well-contained working environment.

06 / Costs & benefits

What does good AI data protection cost—and when does it pay off?

Data protection cannot be evaluated seriously on software licence costs alone.

A free open-source tool can become expensive in production if it requires customisation, protection against failure and renewed testing every time an AI interface changes.

Conversely, a commercial enterprise solution can be very economical if it already covers most requirements.

The following ranges are illustrative project assumptions, not measured industry averages or vendor prices:

Return on investment should therefore be assessed on two levels.

First: What economic value does the AI application generate?

Example calculation: 30 employees each save an average of ten minutes per working day with AI. At 200 working days and an assumed fully loaded hourly cost of €60, this represents €60,000 in released working capacity per year.

If only 35% of that capacity can actually be put to productive economic use, the annual benefit is €21,000.

Second: What additional costs does the chosen data protection solution create?

For those 30 employees, a custom privacy gateway costing, for example, €40,000 to implement and operate in the first year would be difficult to justify economically for that use case alone.

But if the same gateway protects ten productive AI processes, replaces substantial manual work and enables additional valuable use cases, the calculation can look very different.

This leads to an important principle:

Not every AI application needs its own data protection architecture. Reusable safeguards can be essential to reducing the protection cost per use case.

An economic assessment must not treat legally necessary measures as optional. The aim is to choose an appropriate, economically viable option from among lawful solutions.

07 / The 30-day plan

A practical 30-day approach to AI data protection

For a mid-sized business with an existing IT team and initial AI applications, a sensible starting point does not have to be a major project lasting months.

You support the IT and data protection leads of a German mid-sized business.

Analyse the planned AI use case below.

Examine in particular:

1. Which data is actually necessary for the business purpose.
2. Which personal or confidential information might be processed.
3. Which transfer routes and external recipients are involved.
4. Which data protection questions require specialist assessment.
5. How processing can be reduced technically.
6. Which existing security mechanisms might be sufficient.
7. When an additional privacy layer or local inference might be useful.
8. Which questions remain unresolved before production approval.

Distinguish legal assessment points from technical recommendations and economic optimisation opportunities.

Do not claim definitive legal compliance. Identify missing information and uncertainties.

Use case: [Insert an abstracted description without unnecessary personal data]

Such preliminary analyses can give collaboration between business teams, IT, information security and data protection a clearer structure.

They do not replace the necessary specialist and, where appropriate, legal review.

08 / Common mistakes

Mistakes businesses should avoid

09 / AI as an assistant

How AI itself can support data protection work

AI does not only create privacy risks. It can also help prepare data protection work more efficiently.

Examples include mapping data flows, drafting documentation, identifying unnecessary fields and developing synthetic test datasets.

A particularly useful application is the systematic improvement of existing business processes.

You are an enterprise architect specialising in data minimisation, IT security and economical process automation.

Analyse the following workflow and develop three alternatives:

A. Minimal changes using existing systems.

B. A central privacy layer with rules-based and, where appropriate, AI-assisted pseudonymisation.

C. A more isolated solution with private or local AI inference.

For each alternative, compare the expected reduction in unnecessary data transfers, possible residual risks, integration complexity, maintenance effort and effects on the quality of the business outcome.

Estimate implementation effort and operating costs only under explicit assumptions, and label all figures as illustrative estimates.

Do not recommend a more elaborate architecture if a simpler solution is likely to meet the stated requirements appropriately.

Existing workflow: [Abstracted process description]

Existing systems: [ERP, CRM, Microsoft 365, AI services, etc.]

This can turn an abstract privacy discussion into a concrete comparison of architecture and economics.

10 / Protection in practice

Conclusion: The best AI data protection works in everyday practice

Germany’s mid-sized businesses do not need a blanket choice between public AI clouds and completely isolated infrastructure of their own.

They need architecture that fits the sensitivity of their data, the actual business process and the resources available.

Depending on the use case, a combination of approved enterprise AI services, suitable contracts, clear access rights, data minimisation and existing security capabilities may be sufficient. The applicable legal requirements and the effectiveness of the specific safeguards remain decisive.

Where more is needed, open-source tools such as Presidio, central AI gateways, controlled agent environments and local language models offer additional options.

What matters is their demonstrated effectiveness, not the number of technologies deployed.

A business that avoids retrieving most of the data an AI process does not need has often achieved more than one that collects everything first and then tries to mask it at considerable effort.

The most convincing economic and technical solution therefore usually does not begin with buying privacy software.

It begins with three simple questions:

What should the AI achieve? Which information does it really need? And how can we make that process as simple, controllable and data-efficient as possible?

Consistently answering those questions lays a sound foundation for productive, responsible AI that mid-sized businesses can sustain over time.