Private AI use company | IT-Medienrecht

Private AI Accounts in Businesses: Compliance Risks and Secure Enablement

Using private accounts on ChatGPT & Co. for corporate purposes poses significant risks. It can lead to data protection breaches, leaks of trade secrets, and labor law conflicts. If your company intends to use artificial intelligence (AI), you need either clear prohibitions or a properly established "secure enablement" framework. This framework must include robust technical, contractual, and behavioral rules.

Why Private AI Accounts Become a Compliance Risk in the Corporate Context

Many teams already work with AI assistants. Often, these are not accessed via company licenses but through private accounts. This practice immediately introduces a range of liability issues for the organization.

Loss of Control Over Data

Depending on the AI provider, it becomes challenging to fully control what information has been entered into a prompt. Without a contractually secured opt-out for training purposes or clear data deletion periods, proving compliance with data protection principles is difficult. These include the principle of purpose limitation (Art. 5 para. 1 lit. b GDPR) and storage limitation (Art. 5 para. 1 lit. e GDPR). Accountability, as per Art. 5 para. 2 GDPR, fails in practice if entries are made via private accounts without proper logs, binding guidelines, or data processing agreements (Art. 28 GDPR).

Unlawful International Data Transfers

Many AI providers process data outside the EU. Without a reliable transfer basis, such as those defined in Art. 44 et seq. GDPR, companies face the risk of substantial fines. While the EU-US Data Privacy Framework offers a viable adequacy decision, it applies only to certified US companies and requires correct integration. Private use of AI circumvents any company-level transfer due diligence, creating significant legal exposure.

Trade Secrets in the Insecurity Loophole

Trade secrets are only protected if "appropriate confidentiality measures" have been taken (Section 2 No. 1 b GeschGehG). Tolerating private AI channels directly undermines these measures. There is no contractually secured confidentiality standard, no technical access control, and no audit trail. In the event of a dispute, this lack of protection can lead to considerable claims. For a comprehensive strategy, consider developing a confidentiality strategy for startups.

Pitfalls Under Employment and Works Constitution Law

The involvement of the works council is usually required as soon as the use of AI tools is controlled, monitored, or evaluated. Section 87 (1) no. 6 BetrVG (technical equipment for monitoring behavior/performance) regularly imposes a co-determination obligation here. This applies regardless of intent, as the objective suitability for monitoring is sufficient to trigger this requirement.

Liability for Incorrect Content and Rights Chains

AI can produce "hallucinated" facts, introduce license ambiguities in generated code or images, and lead to the unauthorized use of confidential information. Such issues can trigger contractual and tortious liability. Without clear approval processes and source documentation, it is difficult to prove that work or services were provided with due care. This risk is particularly relevant in areas like product liability for software and AI.

Interim Conclusion: Risks of Private AI Accounts

Private AI accounts offer organizational convenience but are legally a "blind flight." No one knows precisely what data goes where, who accesses it, or how long it is stored. Furthermore, it's unclear whether their use is compatible with the GDPR, the GeschGehG, or the company's internal confidentiality architecture.

Legal Framework: GDPR, GeschGehG, Employee Data, Co-determination

GDPR Obligations of the Controller

• Legal Basis & Purpose (Art. 5, 6 GDPR): Corporate data processing requires a viable legal basis and a clear purpose. Private accounts bypass this essential control mechanism.
• Special Data (Art. 9 GDPR): Even seemingly harmless prompts can inadvertently include health, trade union, or biometric data. Private use lacks a robust protection architecture for such data, and a categorical exclusion of this content is unreliable without technical control.
• Data Processing Agreement (Art. 28 GDPR): When using an external provider, a data processing agreement is mandatory. This agreement must specify minimum content, including the subject matter, duration, type of data, and technical and organizational measures (TOMs). Private accounts preclude an effective contract between the controller and the provider.
• Security (Art. 32 GDPR) and DPIA (Art. 35 GDPR): Depending on the process and risk involved, a Data Protection Impact Assessment may be required. In any case, appropriate TOMs must be implemented. This is technically impossible if employees use private tools without corporate oversight.
• International Transfers (Art. 44 ff. GDPR): Compliance with international data transfer regulations (e.g., DPF certification, SCCs, TIA) is impossible without established corporate governance.

Employee Data Protection

Specific requirements apply to employee data. Section 26 BDSG is often interpreted more narrowly, particularly after ECJ ruling C-34/21. Consequently, the general legal bases of the GDPR must frequently be applied. For private AI use, this means consent is only voluntary to a limited extent within an employment relationship. Legitimate interest (Art. 6 para. 1 lit. f GDPR) demands careful consideration and the implementation of technical protective measures.

Trade Secrets

Protection under the GeschGehG necessitates proactive measures. These include clear policies, employee training, access restrictions, and technical barriers. Private AI channels significantly undermine these crucial elements. Companies that tolerate private use weaken their legal position, as outlined in Sections 2, 3 GeschGehG. Willful violations may even lead to criminal prosecution under Section 23 GeschGehG.

Co-determination Under the BetrVG

The introduction and use of AI tools, logging, proxy blocks, or Data Loss Prevention (DLP) rules are typically subject to co-determination (Section 87 (1) No. 1, 6 BetrVG). Without a works agreement, both outright bans and "permission with conditions" can be legally challenged.

EU AI Act (Outlook)

The EU AI Act regulates the obligations of providers, distributors, and users ("deployers") of high-risk AI. Initial bans have been in force since February 2025. Obligations for general-purpose AI and further stages will take effect incrementally from August 2025/2026. For companies, this means that processes for model labeling, risk assessment, logging, and incident handling will become standard. Improvised private use simply does not fit into this evolving compliance framework.

Practical Anchor: EDPB ChatGPT Task Force

The EDPB ChatGPT task force emphasizes transparency, legal bases, data accuracy, and minimization. These are precisely the fields that are structurally undermined when AI is used privately within a corporate setting.

Typical Risk Scenarios – and How They Arise

Scenario 1: "Just a Quick Check"

An account manager copies customer data into a prompt to obtain a tonality check. This presents several problems: it involves personal references, possibly special categories of data, lacks a data protection basis, and uses unknown transfer paths. The result is a violation of Art. 5, 6, 28, 32 GDPR, and puts confidentiality at severe risk.

Scenario 2: Pitch Concept with Confidential Figures

A creative director uses a private AI account to validate price sheets, margin data, and product roadmaps. This information typically constitutes business secrets. Without appropriate measures (Section 2 No. 1 b GeschGehG), the protection for these secrets no longer applies, significantly weakening the company's legal position.

Scenario 3: Code Snippets and Git Links

A developer requests explanations for code via a private tool and includes Git links for context. Besides potential license/copyright risks, the link itself can expose secrets, such as repository structure, branch names, or ticket details. Depending on the provider, meta or access data might also be sent to third countries.

Scenario 4: HR Texts with Employee Data

HR personnel generate employment references using a private account, inputting internal performance data. Employee data is subject to stringent rules. Consent in an employment relationship is particularly problematic, especially if the ultimate destination of the data is unclear.

Scenario 5: Monitoring "by Mistake"

IT attempts to prevent private AI use but activates proxy logging without a works council agreement (BV), which records user entries. This constitutes a technical device for monitoring behavior as defined by Section 87 (1) No. 6 BetrVG, making it a tricky situation without proper co-determination.

Scenario 6: False Statements in the Customer Project

A privately used AI tool generates "hallucinated" technical content. Without a documented source or review obligation, and without versioning, proving due diligence becomes impossible. This significantly escalates contractual liability risks for the company.

Prohibit or Allow in a Controlled Manner? – A Governance Model That Works

Companies essentially have two viable options: (A) a clear ban with technical enforcement, or (B) "secure enablement" via approved company accounts. Mixed approaches often lead to friction and compliance gaps.

Clear Ban on the Private Use of AI for Business Purposes

Objectives: Protect personal data, safeguard business secrets, and ensure compliance with co-determination rights and contractual obligations.

Building blocks:

1. Policy: Implement a general ban on the use of private AI accounts for company purposes. This includes prohibiting the entry of personal data, customer data, source code, confidential documents, and non-public roadmaps into external tools. The policy should reference Art. 5, 6, 28, 32, 35, 44 et seq. GDPR and Section 2 No. 1 b GeschGehG.
2. Technology: Employ DNS/proxy blocks for known AI domains, Data Loss Prevention (DLP) rules (e.g., copy-paste blocks for sensitive classes), secrets scanners, browser policies, and mobile device management.
3. Organization: Provide comprehensive training with clear negative and positive examples. Establish a whistleblower interface for incidents and define a structured approval process for any exceptions.
4. Labor Law: Enforce the ban via the employer's right of direction (§ 106 GewO) and specific contractual clauses. Ensure coordination with the works council, including a works agreement (BV) according to § 87 para. 1 no. 1, 6 BetrVG.

Pros & cons: While a ban offers legal security and can be communicated quickly, it may inhibit innovation and efficiency within the company.

"Secure Enablement" – Controlled Authorization, But the Right Way

Goals: Leverage productivity gains from AI without compromising data protection and confidentiality. To achieve this, it's crucial to manage AI in the company with legal aspects and risk management in mind.

Building blocks (minimum standard):

1. Approved Providers & Licenses:

   Only use enterprise contracts that include: Data Processing Agreements (DPAs) in accordance with Art. 28 GDPR, documented Technical and Organizational Measures (TOMs) (Art. 32), an explicit opt-out from training, clear data residency, defined deletion periods, and support SLAs. For US providers, DPF certification or Standard Contractual Clauses (SCCs) + Transfer Impact Assessments (TIA) (Art. 44 ff. GDPR) are essential. Furthermore, consider best practices for multi-tenant architectures in the SaaS sector for data separation.

2. Identities & Access:

   Implement Single Sign-On (SSO)/Multi-Factor Authentication (MFA), role-based authorizations, tenant isolation, comprehensive logging, and robust key management. Prohibit the use of private accounts for business purposes.

3. Use Case Catalog:
   • Permitted: Generic text optimization without personal references, boilerplate generation, and code explanations using synthetic examples.
   • Prohibited: Personal data, customer dossiers, confidential financial figures, unresolved IP assets, health data, and company/trade secrets.
   • Yellow Zone (only with approval/DPIA): Internal evaluations with pseudonymization and production-related prototypes.
4. Prompt Hygiene & Output Review:

   Establish mandatory instructions prohibiting the sharing of sensitive content. Maintain a "red flag" list of forbidden inputs. Implement dual control approval for external use of AI-generated content. Require source references and versioning. This approach embeds EDPB guidelines (transparency, accuracy) directly into the organization's processes. Moreover, be aware of issues like copyright and AI-generated images.

5. Company Agreement:

   Develop a comprehensive company agreement covering rules on AI use, logging, purpose limitation, deletion periods, training, and incident processes. Ensure clear demarcation from performance/behavioral monitoring to avoid "micro-monitoring." This agreement is a key component for managing contracts in agile working methods.

6. DPIA & Risk Register:

   Conduct a pre-assessment (Art. 35 GDPR) for each sensitive use case. Assign clear responsibilities and implement annual re-certification of providers.

7. AI Act Readiness:

   Prepare for "AI-supported" labeling, risk assessments, logging, and data source transparency. These measures should be tailored to relevant obligations and transition periods of the AI Act.

Model Modules for Guidelines, Contracts, and Technology

Note: These formulations serve as practical building blocks. They must be adapted to the specific size of the company, its sector, the works council situation, and existing policies.

Policy Principle

1. Scope and Objective:

   This policy regulates the business use of AI systems. Employees' private accounts may not be used to process company information or personal data. The primary objective is to ensure compliance with data protection laws (in particular Art. 5, 6, 28, 32, 35, 44 et seq. GDPR) and the protection of business secrets (Section 2 No. 1 b GeschGehG).

2. Categorization of Information:

   Information is classified into public, internal, confidential, and strictly confidential categories. Entries into AI systems are only permitted for the "Public" and "Internal" classes, provided there are no personal references. "Confidential" and "Strictly confidential" information is generally excluded from AI system input.

3. Prohibited Content:

   It is strictly prohibited to enter personal data (including special categories under Art. 9 GDPR), customer data, source code, passwords, access tokens, financial/price lists, roadmaps, internal legal documents, or confidential third-party data into AI systems.

4. Permitted Use:

   Permitted uses include generic formulation, structuring, and ideation aids without personal references. These must be utilized with approved company licenses and an explicit opt-out from training.

5. Approval Procedure:

   Use cases not covered by this policy require prior approval from data protection, information security, and – where relevant – the works council. A Data Protection Impact Assessment (DPIA) obligation must also be checked.

6. Review and Labeling:

   Content generated by AI must always be reviewed by experts. External use of such content must be labeled if legally required or contractually guaranteed.

Contract Modules

Data Processing Agreement (Art. 28 GDPR) – minimum points for AI providers:

• Subject matter/type/purpose of processing; categories of data/data subjects; duration.
• Technical and Organizational Measures (TOMs): including encryption at rest/transport, client separation, key management, role models, incident handling, sub-processor approval.
• Sub-processors: detailed list, pre-approval procedure, and information obligations in the event of changes.
• Data deletion/return: clearly defined deadlines, formats, and proof.
• Audit and information rights; support with data subject rights, DPIA, and notifications.
• Third-country transfers: DPF certification or SCCs + TIA, along with supplementary measures.

Tip: Many AI enterprise offerings provide features such as training opt-out, data residency, and zero retention modes. Confidential data cannot be used securely without these critical options.

Company Agreement

1. Purpose and Validity: Define the agreement's goal as achieving efficiency gains through approved AI applications, explicitly prohibiting performance/behavior profiling.
2. Permitted Tools/Use Cases: Establish a clear whitelist of approved AI tools and use cases, subject to change management procedures.
3. Data Protection/TOMs: Specify the scope of logging, pseudonymization requirements, deletion concepts, and ensure access is restricted to defined roles.
4. Transparency/Information: Mandate informing the workforce, maintaining documentation, and providing necessary training.
5. Monitoring/Reporting: Implement aggregated usage reporting, strictly prohibiting individual monitoring. Outline procedures for violations and incident management.
6. Evaluation: Schedule a review after 12 months or in the event of legislative changes, taking the AI Act Roadmap into account.

Technical Protective Measures

• Identities: Implement SSO/MFA, conditional access, and role-based approvals.
• Data Flow Control: Utilize DLP rules in the browser/end device, clipboard control for sensitive classes, and secret scanners in IDEs/repositories.
• Network: Allow proxy access only for whitelisted domains of approved providers; block known public AI endpoints.
• Client Protection: Ensure separate tenants, key sovereignty, and logging with data-saving pseudonymization.
• Sandboxing: Establish internal "AI sandboxes" with synthetic or depersonalized data for experimental purposes.
• Lifecycle: Implement version control for prompts/outputs, binding review checklists, and archiving according to retention periods.

Training & Communication

• Case Studies Instead of a Desert of Paragraphs: Provide practical examples clarifying what is allowed and what is forbidden in prompts.
• "Red Flags": Highlight critical information that must never be entered, such as personal references, customer lists, pricing models, source code, secret agreements, or health information.
• Alternative Courses of Action: Offer guidance on using internal templates, pseudonymization techniques, synthetic dummies, and secure enterprise models.
• Reporting Channels: Establish low-threshold incident reporting (e.g., for "false prompts") to foster a no-fear-of-error culture, while still ensuring clear and regulated remedial action.

Fazit

Allowing the private use of AI for corporate purposes introduces a multitude of legal and security risks. These include the absence of proper data processing agreements, unclear international data transfers, potential loss of confidentiality, conflicts with works constitution law, and a lack of verifiable due diligence. Two main approaches offer a compliant path forward: a consistent ban (supported by technical enforcement and training) or controlled enablement. The latter requires company licenses, robust contracts, stringent TOMs, clear company agreements, and defined use-case limits. In both models, it is crucial to operationalize data protection principles, actively manage trade secret protection, and prepare for the AI Act to ensure productivity without compliance collateral damage.