· SEQIS

AI in the Enterprise: A Practical Guide to Data Protection, the AI Act and Compliance

Where is the red line between compliant AI use and an untenable legal risk?

AI-generated illustration: a glowing data sphere with interconnected nodes on a futuristic platform
AI-generated image

In 2025, artificial intelligence (AI) is a fundamental pillar of corporate strategy. Yet after the initial hype, companies in the German-speaking region (the DACH region) face critical, strategic questions that go beyond the raw performance of the models.

In which area can these models be used safely — for development, text generation or test-case creation? What are the actual advantages and disadvantages of the various AI models in operational use?

Above all, though: what happens to your sensitive company data? Is your data used to further develop the AI model? How secure is your data really? Where is it stored — in the EU or potentially in third countries? And who exactly can see your prompts?

The answers to these questions define the “red line” between a compliant, sustainable AI implementation and an untenable legal risk. In this article we answer precisely these questions.

1 A Taxonomy of Modern AI Models

To make well-founded decisions, a clear distinction between the available model categories is required.

1.1 Large Language Models (LLMs): The Foundation

Large language models (LLMs) form the basis of the current generative AI revolution. They are trained on huge text and data sets and use deep-learning techniques to process and generate human language. Their core competencies span a wide range of natural language processing (NLP) tasks, including text summarisation, machine translation, question answering and the writing of creative text.

The most important players in this space include the GPT model family (Generative Pre-trained Transformer) from OpenAI, Gemini from Google, the Claude model family from Anthropic — which focuses on safety and complex reasoning — and the Llama model family from Meta.

1.2 Specialised Generative Models

Alongside the generalist LLMs, a market for highly specialised models optimised for specific tasks has developed.

Code Generation and Analysis

These models are trained specifically on programming languages, software libraries and development concepts. They serve as “pair programmers” and understand the specific context of a codebase, including file structures, import dependencies and naming conventions.

The most prominent example is GitHub Copilot, which uses a suite of different models, including GPT-4.1 and Claude 3.5 Sonnet. Other specialised code models include Devstral and Grok Code Fast. Germany’s Federal Office for Information Security (BSI) sees the “analysis and hardening of program code” as a major opportunity of this technology.

Image, Video and Audio Generators

These models do not operate primarily on text; they are specialised in generating and editing visual or auditory data. Well-known examples are image generators such as DALL-E 3 and Midjourney, video generators such as OpenAI’s Sora and Pika Labs, as well as voice generators such as ElevenLabs. Their fields of application range from marketing and design to the creation of synthetic training data.

1.3 Multimodal Models: The Next Evolutionary Stage

The latest generation of AI models is multimodal, meaning it can process several types of information (modalities) simultaneously, such as text, images, audio and code.

Models such as GPT-4o, Google Gemini and Alibaba Qwen 2.5 Omni can handle complex requests that combine different data types. For example, they can analyse a chart (image), extract the code it contains (text) and deliver a spoken summary (audio). This capability opens up new use cases in data analysis, accessibility and creative design.

1.4 Open Source vs. Proprietary Models: A Fundamental Difference

The strategically most important distinction for companies is that between proprietary and open-source models.

  • Proprietary models: These are closed (“closed source”) models developed by companies such as OpenAI, Anthropic and Google and offered as a commercial service (typically via an API). The model architecture and training data are trade secrets.
  • Open-source models: With these models, the model weights and often the training code are publicly available. Prominent examples are Meta’s Llama model family and the models from Mistral AI.

This choice represents a fundamental setting of the course for data governance:

  • Path A (proprietary): Companies that use a proprietary API outsource the technical operational and data-protection risk to the provider. They depend on its contractual assurances (e.g. in the data processing agreement), its security architecture and its handling of data transfers to third countries. This requires an in-depth legal review of the provider’s policies (see Chapter 4).
  • Path B (open source): Companies that operate an open-source model on their own infrastructure (on-premises or in a private cloud in the EU) fully assume the risk and the control themselves. The advantage is maximum data sovereignty: sensitive data never leaves the company’s controlled environment. Questions about data training, storage location and third-party access become trivially answered (“does not happen” or “internal only”). The downside is the significantly higher costs and the technical complexity of implementation, maintenance and fine-tuning.

2 Fields of Application and Practical Deployment Scenarios

The categorised models enable a broad range of use cases whose suitability depends on the respective data sensitivity.

2.1 Software Development and IT Operations

The IT sector benefits massively from specialised AI models.

  • Automated code creation: AI-assisted “pair programmers” such as GitHub Copilot considerably accelerate software development by suggesting code blocks in real time and automating routine tasks.
  • Debugging and code analysis: Models with deep logical understanding (e.g. Claude 3.7 Sonnet, GPT 4.5) are used to find errors in complex systems. The BSI highlights the ability to “analyse and harden program code” as a strategic opportunity.
  • Generation of test cases: A highly profitable use case is the automated creation of software tests. Based on real-world problems, a 3-step process was developed that increases efficiency:
    1. Input (prose): A requirement in natural language (e.g. a user story) is handed to the LLM.
    2. Output (BDD): The model generates structured acceptance criteria from it in BDD format (Behaviour-Driven Development), e.g. “Given-When-Then”.
    3. Output (code): The LLM transforms the BDD cases into a runnable test file (e.g. Cucumber) and generates the finished automation code (e.g. in JavaScript).

2.2 Text Generation and Corporate Communication

This is the classic field of application for LLMs, ranging from internal processes to external marketing.

  • Marketing and content creation: AI models generate marketing copy, blog posts, social-media updates and advertising content. Specialised tools such as Jasper or Copy.ai use these core models. Coupled with image generators such as DALL-E or Midjourney, entire campaigns can be created.
  • Internal documentation and knowledge management: Efficiency in everyday office work is boosted by the automated summarisation of meeting notes, the drafting of emails and the creation of technical documentation.
  • Automated customer service: LLMs are the driving force behind advanced chatbots and conversational agents that can answer customer queries in natural language.

2.3 Strategic Analysis and Research

Models with large context windows and real-time internet access enable new forms of strategic analysis.

  • Domain-specific document analysis: Models such as Claude 2, which can process up to 100,000 tokens (equivalent to 100+ pages), are used to analyse extensive specialist documents. Use cases include reviewing legal contracts or interpreting medical study data.
  • Market and trend research: Models with integrated real-time web access (e.g. Perplexity, Grok or the new Claude feature) can be used to monitor live data, analyse market and competitive trends and conduct research with direct source citations.

The diversity of these use cases — from creating public marketing copy to analysing strictly confidential legal documents or debugging code that processes personal data — makes it clear that a company cannot choose one AI model. A tiered AI strategy must be developed that is based on the data sensitivity of the respective use case. One possible architecture could look as follows:

  • Tier 1 (public data): Use of consumer tools for non-confidential tasks (e.g. general research, brainstorming for public blog posts).
  • Tier 2 (confidential/proprietary data): Mandatory use of enterprise/API versions with a data processing agreement (DPA) for internal documents, emails or the development of non-critical code.
  • Tier 3 (top-secret/personal data (PII/GDPR)): Mandatory use of services with guaranteed EU data residency (e.g. Google Vertex AI in an EU region) or self-hosted open-source models.

Answering the questions about fields of application thus directly defines the compliance requirements for answering the questions about data protection.

3 Opportunities and Risks at a Glance

The use of AI models carries a dual potential of considerable benefits and equally significant risks.

3.1 Benefits: Productivity, Innovation and Scalability

The primary benefits of AI use are operational and strategic in nature.

  • Productivity gains and time savings: The automation of routine tasks — whether in software development or test creation — is the biggest lever. Developers can concentrate on complex problems instead of writing boilerplate code. Studies show a reduction in test-creation time of 60–80%.
  • Quality improvement and error avoidance: In software engineering, LLMs help lower the error rate in code and ensure consistent code quality. AI-assisted testing tools are able to identify edge cases and security gaps that human testers often overlook.
  • Democratisation of knowledge and scalability: By combining low-code platforms with generative AI, even employees without deep programming skills (“citizen developers”) can create functional applications. This relieves the central IT departments and accelerates digitalisation across the entire company.

3.2 Downsides and Inherent Risks

These benefits are offset by technical, operational and legal risks.

Technical limitations: The models are not error-free.

  • Hallucinations: A well-known problem is “hallucinating” — the generation of plausible-sounding but factually wrong or nonsensical information. This represents a critical risk when the models are used for analysis or decision-making tasks.
  • Latency and cost: The most capable models (e.g. GPT-4.5) are often slower (higher latency) and more expensive to run, which can limit their use in real-time applications.

Security risks (operational and implementation): The BSI warns of specific dangers throughout the entire lifecycle of the models.

  • Prompt injection: Attackers can, through manipulated inputs (prompts), get the models to bypass their internal safeguards, generate malicious content or reveal sensitive information.
  • The risk of code analysis: One of the greatest benefits — the ability to analyse code for errors — simultaneously carries one of the greatest risks.

This contradiction, the “analysis paradox”, represents a new, critical gateway for data exfiltration. The causal chain of this risk is as follows:

  • A developer wants to check a proprietary application for vulnerabilities and hands the complete source code to an AI service (e.g. the OpenAI API) with the prompt: “Analyse this code for security gaps.”
  • At that moment, the company’s most valuable intellectual property (IP) is transmitted to a third-party provider (e.g. OpenAI or Anthropic), together with a potential list of its vulnerabilities.
  • The data transfer goes to the USA, where storage takes place.
  • Even if the enterprise API policy prohibits training on this data (which is the case), the data is stored by default for 30 days for abuse monitoring.
  • During these 30 days the data — the source code — is potentially exposed to inspection by the provider’s employees and access by US authorities (under the CLOUD Act).

This process turns a well-intentioned security audit into a potentially catastrophic IP theft or security incident. The “analysis paradox” conclusively shows that security-critical use cases (such as the analysis of proprietary code) may only take place on a Tier-3 architecture (on-premises open source).

4 Critical Analysis of Data Governance

Here we answer the user’s critical data-protection questions, analyse the policies of the main providers (OpenAI, Anthropic, Google, Meta) and draw the decisive dividing line between consumer and enterprise services.

As soon as a company in the DACH region uses an AI to process data relating to employees or customers (personal data), it is subject to the GDPR. In this scenario the company acts as the “controller” and the AI provider (e.g. OpenAI) as the “processor”.

Under Article 28 of the GDPR, concluding a data processing agreement (DPA) is mandatory for this constellation. This contract governs the rights and obligations of both sides and ensures that the processor processes the data only in accordance with the controller’s instructions.

This is where the “red line” runs: AI providers make such a DPA available exclusively for their paid business, team or enterprise offerings.

The implication is a clear legal verdict: using freely available consumer services (such as ChatGPT Free/Plus, standard Gemini or Claude Free/Pro) for any company data (particularly personal data, but also trade secrets) is a direct violation of the GDPR. The required legal basis for data processing is missing.

The following analysis of the consumer tools therefore serves primarily to raise awareness of the risks that arise from the “shadow IT” use of these tools by employees. The analysis of the enterprise/API products assesses the residual risks that remain despite a valid DPA.

4.2 Case Study: OpenAI (ChatGPT vs. API)

Training

  • Consumer (ChatGPT Free/Plus/Pro, Sora): YES. By default, OpenAI uses the content (prompts and responses) of users of these services to train and improve its models.
    • Opt-out: Users can object to this use via a privacy portal (“do not train on my content”).
    • Exception: So-called “temporary chats” are not saved in the history and are not used for training.
  • Enterprise (API, ChatGPT Enterprise/Team/Edu): NO. OpenAI contractually guarantees that customer data submitted via the API or the enterprise services is not used to improve or train the models.

Data security & access

  • Consumer: YES. Prompts and conversations can be viewed by authorised human reviewers at OpenAI in order to validate model responses or process feedback. With enterprise accounts (Team/Business), the administrators of your own company can also view their employees’ chat histories.
  • Enterprise (API): CONDITIONALLY YES. The data is not viewed by humans for model improvement. However, it is retained by default for up to 30 days and can be reviewed both automatically and potentially by humans for “abuse monitoring”.
    • ZDR option: For qualified enterprise customers, OpenAI offers a “Zero Data Retention” (ZDR) option. When activated, the data is no longer stored for abuse monitoring.

Storage

  • Where: Data is stored primarily in the USA.
  • The “OpenAI Ireland” problem (Schrems II risk): Many EU companies conclude their DPA with OpenAI Ireland Ltd. on the assumption that this keeps them safely within the scope of the GDPR. The contract documents (DPA), however, list the US parent company (OpenAI, LLC) as a sub-processor. This legally legitimises a data transfer to the USA. There, the data is subject to US surveillance laws (e.g. the CLOUD Act) — precisely the situation the European Court of Justice (ECJ) classified as highly problematic in the Schrems II ruling. Legal experts such as Steiger Legal assess the legal situation for EU customers as “unclear”. In a legal context, “unclear” means an incalculable risk that use will be classified as inadmissible by a data protection authority.

4.3 Case Study: Anthropic (Claude Consumer vs. API)

Training

  • Consumer (Claude Free/Pro/Max): YES. With a significant policy change in September 2025, user data from these services is now used by default for model training.
    • The aggressive “opt-out” and the 5-year period: The system is designed as an “opt-out”. The consent dialog, however, is misleadingly worded as an “opt-in” (“You can help improve Claude”), but pre-selected by default.
    • The consequence: If the user agrees (even inadvertently), the retention period for their data is extended from the usual 30 days to five years.
    • The catch: If the user objects to training (opt-out), they lose access to personalisation and memory functions. This coupling of the service to consent to data processing seriously calls into question the “voluntariness” of consent — a core requirement of the GDPR.
  • Enterprise (API, Claude for Work/Team): NO. These services are explicitly not affected by the policy change. Anthropic contractually guarantees not to use API data for training.

Data security & access

  • Consumer: YES. Conversations flagged for a safety review are viewed by Anthropic employees and can be used to train internal safety models.
  • Enterprise (API): NO. Unless the user proactively provides feedback (e.g. via the thumbs-up/down function). In that case the conversation can be used for quality control.

Storage

  • Where: Data storage takes place exclusively in the USA.
  • The “multi-region processing” catch: To improve latency (speed) for global customers, Anthropic expanded the processing of data in August/September 2025 to data centres in several regions, including Europe and Asia. This does not change the core problem for EU customers, however: the data may be processed briefly in the EU, but is then permanently stored in the USA. This still constitutes a transatlantic data transfer, which is considered problematic under Schrems II.

4.4 Case Study: Google (Gemini Apps vs. Vertex AI)

Training

  • Consumer (Gemini Apps): YES. By default, conversations and data are used to train the AI models.
    • The “privacy vs. functionality” trade-off: To stop training, the user must deactivate “Gemini Apps Activity” in their Google account.
    • The catch: Deactivating this setting simultaneously disables all powerful extensions. The integration with Gmail, Google Docs and Google Drive then no longer works.
    • Implication: Like Anthropic, Google forces the user to choose between full functionality and privacy. This is a problematic form of “coerced” consent within the meaning of the GDPR.
  • Enterprise (Vertex AI / Google Cloud): NO. As part of the Google Cloud Platform, Vertex AI offers a strong contractual “training restriction”. Neither prompts nor customer data are used to train the models.

Data security & access

  • Consumer: YES. Prompts are viewed by human reviewers at Google in order to improve the services. Google explicitly warns users not to enter confidential information.
    • The 3-year problem: Human-reviewed conversations are stored for up to three years, even if the user deletes their Gemini activity. Google states that this data is anonymised, but the long retention period represents a massive compliance problem and potentially contradicts the “right to be forgotten” (Art. 17 GDPR).
  • Enterprise (Vertex AI): NO. Prompts and responses are not accessible to human reviewers, except for abuse monitoring or if the customer explicitly provides feedback.

Storage

  • Consumer: Global, in Google data centres, including the USA.
  • Enterprise (Vertex AI): CLEAR CONTROL. This is the decisive advantage of the Google platform for EU customers. As a Google Cloud service, Vertex AI offers clear data residency controls. A company can stipulate contractually and technically that its data does not leave the EU. This “data residency” guarantee solves the Schrems II problem more effectively than the “US sub-processor” models of OpenAI and Anthropic.

4.5 Case Study: Meta (Llama and Meta AI)

Llama (open-source model)

  • Data protection: Entirely dependent on the host. If a German company operates Llama 3 on its own servers in Frankfurt, data is not used for external training, is stored internally and is viewed only by internal staff. Self-hosted open-source models offer maximum data sovereignty.
  • Acceptable Use Policy: Meta’s policy for Llama is not a data protection policy. It merely governs what the model may not be used for (e.g. illegal activities, violence, fraud, exploitation of children).

Meta AI (consumer product in Facebook, Instagram, etc.)

  • Training: YES. Meta explicitly trains its AI models on the public user data of its platforms, including public posts, photos and captions. Private messages are (according to Meta) not used.
  • Opt-out: There is no simple opt-out button. Users (especially in the EU) have to fill in a complex form and explain in detail why the processing affects their rights. Meta reserves the right to reject this request.
  • Implication: This is the most privacy-hostile implementation among the major providers and completely unusable for any enterprise use.

5 Synthesis and Comparative Overview

Now we can answer the following questions.

5.1 Is My Data Used for Further Development?

  • With consumer products (ChatGPT Plus, Claude Pro, Gemini Apps): Yes, by default. All providers use this data for training. OpenAI and Google offer an opt-out. The opt-out at Anthropic and Google, however, comes with considerable disadvantages (loss of functionality or 5-year storage). At Meta (Facebook/Instagram), an opt-out is barely practicable.
  • With enterprise/API products (OpenAI API, Vertex AI, Claude API): No. All three major providers (OpenAI, Anthropic, Google) guarantee in their data processing agreements (DPAs) that customer data from the API services is not used to train their models.

5.2 How Secure Is My Data?

  • With consumer products: Low security. The data is exposed to inspection by the provider’s human reviewers and is stored for potentially very long periods (up to 3 years at Google, 5 years at Anthropic).
  • With enterprise/API products: High security. The data is protected by industry standards (encryption, access controls). The residual risk lies in the temporary storage (usually 30 days) for “abuse monitoring” and the potential access by US authorities (Schrems II risk). Services with “Zero Data Retention” (ZDR) or guaranteed EU residency offer the highest security.

5.3 Where Is It Stored?

  • OpenAI & Anthropic: Primarily in the USA. Even if an EU contracting party (OpenAI Ireland) or EU processing (Anthropic) is involved, the USA remains the storage location or a sub-processor, which represents a data-transfer risk (Schrems II).
  • Google (Vertex AI): Controllable. As the only one of the major US providers, it offers a clear option for storage and processing exclusively within the EU.
  • Meta (Llama): With self-hosting, the storage location is your own infrastructure (e.g. Germany).

5.4 Who Can See My Prompts?

There are three groups that can view prompts:

  • Provider (human reviewers): With all consumer products. With enterprise/API products, only for narrowly defined purposes such as abuse prevention or when the user actively provides feedback.
  • Your own administrators: With enterprise team licences (ChatGPT Team, Claude for Work, Google Workspace), the administrators of your own company can view employees’ conversations.
  • The public: When using open-source tools hosted by third parties, or with insecure implementations.

5.5 Comparative Matrix of Data Governance: Consumer vs. Enterprise Models (as of 2025)

The following table summarises the critical differences and visualises the “red line” (see 4.1) between consumer and enterprise services.

ProviderProduct (consumer)Product (enterprise/API)Default training (consumer)?Default training (enterprise)?Data storage (location)Retention period (consumer)Human access (consumer)?DPA available?
OpenAIChatGPT Free/Plus/ProAPI, ChatGPT EnterpriseYes (opt-out possible)NoUSA (with EU sub-processor issue)30 days (after deletion)YesEnterprise only
AnthropicClaude Free/Pro/MaxAPI, Claude for WorkYes (opt-out forces 5-year period)NoUSA5 years (with training) / 30 days (without training)Yes (for safety)Enterprise only
GoogleGemini AppsVertex AIYes (opt-out disables functions)NoEU residency possible3 years (for reviewed chats)YesEnterprise only
MetaMeta AI (in apps)Llama (self-hosted)Yes (opt-out barely possible)No (depends on the host)Global / USAUnlimitedYesNo / N/A

6 Final Recommendations for Data-Protection-Compliant Use

Based on the preceding analysis, clear recommendations emerge for companies in the DACH region that want to use AI models in a data-protection-compliant way.

6.1 Recommendation 1: Ban Consumer Tools for Enterprise Purposes

The analysis in Chapter 4 shows unmistakably: using consumer products (such as ChatGPT Plus, Claude Pro, Gemini Apps) for any processing of company data (code, internal memos, customer data) is a clear violation of the GDPR.

The reasons are:

  • No data processing agreement (DPA) is available.
  • The data is used by default for the provider’s model training.
  • The data is viewed by the provider’s human reviewers.
  • An uncontrolled data transfer to the USA takes place.

Companies must issue clear internal usage policies that prohibit the use of this “shadow IT” and enforce them technically (e.g. by blocking the endpoints).

6.2 Recommendation 2: Mandatory Conclusion of a Data Processing Agreement (DPA)

For any use of external AI services (including enterprise/API) to process data that is potentially personal, a DPA under Art. 28 GDPR is mandatory. This contract ensures that the provider does not use the data for its own purposes (such as training). Without a valid DPA, the use is illegal.

6.3 Recommendation 3: Assessing the Transatlantic Data-Transfer Risk (Schrems II)

The greatest remaining risk despite a DPA is the data transfer to the USA. Since the ECJ’s “Schrems II” ruling and the end of the “Privacy Shield” agreement, data transfers to the USA — where data is subject to access by US authorities — are legally highly problematic.

  • The problem: Both OpenAI (via US sub-processors) and Anthropic (through US storage) carry this risk.
  • The safest proprietary solution: Choosing a provider that offers contractually and technically guaranteed data residency within the EU. Currently, among the major US providers, Google Cloud with Vertex AI offers this most clearly.
  • The most sovereign solution (open source): Self-hosting powerful open-source models (e.g. Llama, Mistral) on your own infrastructure (on-premises) or in a European private cloud. This eliminates the third-party data-protection risk entirely, but comes with higher technical costs.

6.4 Technical and Organisational Measures (TOMs)

Regardless of the chosen model, companies must take accompanying technical and organisational measures (TOMs). These include mandatory staff training (particularly on “prompt hygiene”), the implementation of anonymisation and pseudonymisation gateways that filter out sensitive data (such as names or IDs) before it is handed to an API, and the enforcement of strict internal access controls.

6.5 Summary Assessment

Choosing the right AI model in 2025 is a risk trade-off. For non-critical tasks that involve no sensitive data or trade secrets, the enterprise APIs of OpenAI and Anthropic often offer the highest performance.

As soon as personal data (GDPR) or valuable intellectual property (e.g. source code, R&D data) is to be processed, however, the priority shifts from raw performance to compliance. In this scenario, the only legally defensible solutions are those that offer guaranteed EU data residency (such as Google Vertex AI) or that eliminate the data-protection risk entirely through self-hosting (open source).

Source: This article was originally published on the SEQIS Blog. The title illustration was generated with Gemini (Google AI). The original article includes an extensive, numbered list of sources with further links.

Originally published at SEQIS Blog