AI Regulation for German Companies: A Practical Compliance Guide

Artificial intelligence is already inside ordinary German B2B work. A sales representative uses a language model to prepare an account brief. A service team summarizes calls. A manufacturer predicts machine failure. A bank reviews transactions with a machine learning model. An HR team receives software that ranks applicants. These uses may look like separate technology projects, but they create one governance question: can the company explain what each system does, who is accountable, what data it uses, and what happens when it is wrong?

This guide is for German companies that develop, buy, integrate, or deploy AI. It is practical guidance, not legal advice. The legal and institutional position described here is current to September 2026. That date matters because the EU AI Act is phased, the Digital Omnibus changed parts of the timetable, and Germany has now established a central market surveillance role. Always verify the consolidated law and obtain advice for a high impact or regulated use case.

The short answer for German B2B leaders

Do not wait for a single German AI statute before acting. Regulation (EU) 2024/1689, the Artificial Intelligence Act, is directly applicable. Its first obligations, including prohibited practices and AI literacy, have applied since 2 February 2025. Governance and general purpose AI model provisions applied from 2 August 2025. Most of the Act applies from 2 August 2026, subject to specific transitions. Following the EU Digital Omnibus, sensitive Annex III high risk uses have a transition to 2 December 2027 and high risk AI embedded in regulated products to 2 August 2028. Check the Commission timeline and AI Act framework and the consolidated EUR-Lex text.

The practical priority is visibility. Build an inventory, classify every use by role and risk, stop prohibited practices, protect personal data, involve worker representatives where required, and make vendors provide evidence. A policy that does not change access, procurement, design, training, review, logging, and incident response is not an AI control system.

EU AI Act implementation and the 2026 timetable

The AI Act follows a risk based structure. It prohibits a narrow set of unacceptable practices, imposes obligations on high risk systems, sets transparency duties for particular interactions and content, and creates obligations for general purpose AI models. It can apply to a company outside the Union when its system or output is placed on the Union market, used in the Union, or its output is used in the Union. A German company therefore cannot assume that outsourcing inference to a non European provider removes the Act from the project.

• Since 2 February 2025, the prohibited practice rules and the Article 4 AI literacy duty apply. The Commission explains that AI literacy is an obligation to take appropriate measures, not a requirement that every employee reach one prescribed certification level.
• Since 2 August 2025, governance provisions and obligations for providers of general purpose AI models apply. A deployer buying a hosted model is not automatically the GPAI provider, but it remains responsible for its own use, data, instructions, and downstream decisions.
• From 2 August 2026, the core Act applies in general, including most obligations for deployers and providers, with exceptions and transition rules. National supervision and penalties also become operational according to the applicable provisions.
• The 2026 Digital Omnibus, Regulation (EU) 2026/1744, adjusted parts of the implementation timetable. Its official EUR-Lex text should be read with the consolidated Act. Do not rely on a pre-Omnibus date spreadsheet.
• The Commission's guidelines, FAQs, voluntary codes, and standards help interpret or demonstrate compliance, but they do not all have the force of legislation. Record the legal status of every source in your compliance register.

For each system, record the applicable article, actor role, original application date, transition provision, current date, and evidence needed. Distinguish binding regulation, a German statute, regulator guidance, a harmonized standard, an industry code, and an internal target. This prevents a common German governance error: presenting a proposed implementation bill or a useful supervisory FAQ as though it were enacted law.

Who supervises AI in Germany?

Germany uses a sector aware model. The Bundesnetzagentur AI pages explain its role as central contact point and market surveillance authority under the German implementation framework. The KI-MIG, the Act on AI Market Surveillance and Innovation Support, entered into force on 29 July 2026. The Bundesnetzagentur operates the central complaint channel and coordinates with other authorities. A natural or legal person can submit a suspected AI Act violation through its AI Service Desk complaint office.

The arrangement is not a universal transfer of every AI question to Bonn. Existing specialist authorities remain important in regulated product and sector areas. The Bundesnetzagentur describes a hybrid model in which specialist market surveillance and supervisory bodies retain responsibilities where they already have subject matter competence, while the Bundesnetzagentur handles central coordination and certain previously unallocated areas. For example, BaFin remains relevant for financial supervision, and media authorities remain relevant for their remit. The Bundesnetzagentur market surveillance overview is an orientation source, not a substitute for checking your sector.

Data protection is a separate but connected track. The Federal Commissioner for Data Protection and Freedom of Information, the BfDI, covers federal public bodies and specific federally supervised sectors. Most private companies are supervised by the data protection authority of the relevant German state. The BfDI's AI overview correctly emphasizes that the AI Act supplements rather than replaces GDPR. For a private B2B company, identify the competent Landesdatenschutzbehörde before a dispute arises. The BfDI contact finder helps distinguish federal and state responsibility.

The German authorities' implementation materials are useful but not all binding. The BfDI's statements on draft legislation, the Commission's FAQs, and a state DPA's orientation paper are interpretations or policy positions unless a legal rule says otherwise. Keep them in the legal register with a label such as binding law, supervisory guidance, nonbinding recommendation, draft, or internal control.

GDPR and BDSG still govern the data

The AI Act does not create a lawful basis for processing personal data. Start with the GDPR on EUR-Lex and the German Federal Data Protection Act, BDSG. For every AI use, document purpose, data categories, data subjects, controller and processor roles, lawful basis, recipients, retention, international transfers, security, and data subject rights. A prompt sent to a hosted model, an embedding, a transcript, a generated profile, and a model output can all be personal data depending on context.

The core questions are familiar even when the technology is new. Is the purpose specific and compatible? Is the data necessary and accurate? Is the processing transparent? Is there a valid Article 6 basis, and an Article 9 condition for special category data? Are international transfers covered by an appropriate mechanism? Does a processor agreement describe the processing? Can the company answer access, correction, deletion, objection, and restriction requests? A vendor's statement that it is GDPR compliant does not answer these questions for your deployment.

Do a data protection impact assessment when processing is likely to result in a high risk, including systematic and extensive evaluation, large scale sensitive data, or systematic monitoring. Connect the DPIA to the AI risk assessment, but do not merge them into a generic scorecard. The DPIA addresses rights and freedoms under GDPR. The AI Act assessment addresses the system category and its obligations. Security, trade secret, confidentiality, and sector assessments may still be needed.

BDSG adds important German context. Section 26 is relevant to employee data processing for employment purposes, but it is not a blanket permission to profile workers with AI. Section 37 addresses automated decisions in the insurance context, and Section 22 regulates scoring and credit reports. The exact provision depends on the use case and should be checked in the current statute. Do not infer from a general business interest that an automated ranking is lawful.

Works councils and employment decisions

Employment AI is both a rights issue and an implementation issue. The Works Constitution Act, Betriebsverfassungsgesetz or BetrVG, can give a works council information, consultation, and co-determination rights. Section 87(1) no. 6 is especially relevant when technical equipment is intended to monitor employee behavior or performance. Section 90 and Section 92 can also matter for workplace planning and personnel planning. Section 80(2) gives information rights in the council's statutory tasks. Read the BetrVG on gesetze-im-internet.de.

The AI Act also specifically addresses high risk systems used in employment and worker management. Where a deployer uses a high risk system at work, the organization must pay attention to instructions, human oversight, monitoring, logging, and information duties. Depending on the system and national implementation, workers and representatives may need information before use. Collective agreements, employment contracts, anti-discrimination law, occupational safety, and GDPR transparency apply alongside the AI Act.

Involve the works council before selecting a system, not after the contract is signed. Share the intended purpose, data flows, model behavior, error patterns, decision authority, monitoring, retention, and change process. Agree what the council can inspect and how concerns are escalated. Avoid individual productivity surveillance unless there is a clear legal basis, necessity, proportionality, and agreed process. A technically impressive dashboard can still be an unlawful monitoring system.

Automated decisions need a human route

Article 22 GDPR restricts decisions based solely on automated processing, including profiling, when the decision produces legal effects or similarly significantly affects a person. Exceptions and safeguards exist, but they are not a checkbox. If AI ranks a supplier, flags fraud, determines a credit condition, filters a job applicant, suspends an account, or denies a service, ask whether a person genuinely decides or merely confirms the machine.

A compliant human review is informed, independent, empowered, and timely. The reviewer must understand the system's purpose and limitations, see the relevant factors, challenge the output, access source information, and change or reject the recommendation. A worker who must approve hundreds of model decisions in seconds, without authority to disagree, is not meaningful oversight. Define thresholds, mandatory second review, automatic holds, appeal channels, and correction procedures.

Transparency should be usable. Tell an affected person that automated processing is used where required, explain the logic and consequences at an appropriate level, provide a route to obtain human intervention, and explain how to contest the decision. Keep examples of notices and samples of decisions. Do not promise an explanation that the company cannot produce. The AI Act's transparency duties, GDPR Articles 13 to 15 and 22, consumer law, and sector rules may overlap without being identical.

Sector rules change the risk assessment

A German B2B company should map sector law before classifying the AI system. In finance, AI may affect creditworthiness, insurance pricing, fraud detection, customer communication, outsourcing, model risk, or prudential governance. BaFin's supervisory expectations, the EBA and ECB where relevant, DORA for digital operational resilience, AML rules, consumer protection, and the AI Act can apply together. Use the BaFin AI information and the DORA regulation as starting points.

For manufacturers, AI embedded in a product can be a safety component and can trigger conformity assessment obligations under the AI Act and the applicable product regime. Consider machinery, medical devices, toys, radio equipment, vehicles, industrial cybersecurity, product liability, and functional safety. Keep the AI technical file connected to the product technical documentation. A cloud model that changes after release may require a different change control from a deterministic component.

Critical infrastructure operators and suppliers should assess energy, transport, banking, health, water, digital infrastructure, and other relevant regimes. The AI Act's high risk areas can overlap with NIS2, the German implementation of NIS2, KRITIS requirements, resilience duties, and incident reporting. Use the European Commission NIS2 page and the BSI overview of critical infrastructure. AI governance cannot weaken operational security, availability, recovery, or the duty to report a serious incident.

Other B2B sectors have their own overlays. Construction and engineering may have safety and professional liability implications. Healthcare suppliers may touch medical device and patient confidentiality rules. Telecommunications and media have specialist regulators. Public sector procurement brings additional transparency, accessibility, and tender requirements. A general AI policy should therefore point to sector playbooks rather than pretend that one approval path fits every system.

AI literacy is an operating control

Article 4 requires providers and deployers to take measures to support AI literacy for staff and other people operating or using systems on their behalf. The Commission's AI literacy questions and answers state that the obligation applies from 2 February 2025. As of the 2026 changes, there is no single prescribed level or universal certificate. The organization must still consider technical knowledge, experience, education, training, the system context, and affected people. National market surveillance authorities supervise this duty.

Build a role based curriculum. A sales user needs confidential data rules, hallucination checking, copyright awareness, and customer disclosure. A support agent needs escalation, sensitive data handling, and safe use of summaries. A developer needs evaluation, prompt injection defense, logging, release control, and model limitations. An HR manager needs discrimination awareness, human decision safeguards, and works council process. An executive needs risk appetite, accountability, and the difference between a vendor claim and evidence.

Keep a training matrix with role, systems used, learning objective, delivery date, assessment, refresher trigger, and evidence. Test behavior with realistic scenarios. Can a user recognize a fabricated citation? Can they refuse to paste a payroll export into a public chatbot? Can they report a prompt injection or unsafe autonomous action? Completion percentage is useful, but a short practical assessment and sample quality review show whether training works.

Procurement and vendor controls

Procurement is where many German companies first encounter AI risk. A supplier may call a feature AI, machine learning, automation, analytics, or an assistant. Ask for the actual system boundary, model provider, version, purpose, data flows, hosting, sub-processors, retention, training use, security controls, and change notice. Identify whether your company is deployer, provider, importer, distributor, or product manufacturer for this arrangement.

• Require a system description, intended purpose, prohibited use restrictions, model and feature versions, limitations, evaluation results, and supported languages.
• Require GDPR information, controller or processor roles, Article 28 terms where applicable, lawful transfer mechanism, deletion process, retention, sub-processors, and assistance with data subject rights.
• Require security evidence, access controls, encryption, tenant separation, vulnerability handling, prompt injection controls, incident contacts, recovery targets, and independent assurance where proportionate.
• Define whether inputs, outputs, feedback, and telemetry train a shared model. Prohibit secondary use of confidential or personal data unless expressly approved.
• Set notice and approval for material model, data, hosting, sub-processor, prompt, safety, or pricing changes. Make a model change a change management event, not merely a release note.
• Reserve access to evidence and cooperation for an audit, regulator request, serious incident, affected-person inquiry, and exit. Include deletion or return, portability, fallback, and a tested termination plan.

Do not accept a certificate labelled AI Act compliant as the whole due diligence package. The vendor may be compliant in its provider role while your purpose, data, instructions, configuration, or human oversight creates a separate problem. Make the contract allocate tasks, but retain internal ownership of the deployment decision.

Inventory and classify before scaling

Start with discovery, not a polished policy. Ask every function to list purchased SaaS, APIs, browser tools, open source models, embedded product features, pilots, spreadsheets, bots, agents, and tools paid by expense card. Compare responses with identity records, software asset management, cloud bills, procurement records, data processing registers, security questionnaires, product roadmaps, and support tickets. Shadow AI is a signal that the approved path is unavailable or too slow.

Each record should identify owner, purpose, users, data, supplier, model, location, connected actions, affected people, sector, autonomy, outputs, and lifecycle stage. Add a confidence rating so unknowns are visible. Then apply a decision tree: prohibited practice, high risk system, GPAI dependency, transparency trigger, personal data processing, employment use, regulated product, critical infrastructure, or ordinary low impact assistance. Reassess after a new data source, user group, integration, model, geography, or downstream action.

Transparency, logging, and oversight by design

Article 50 creates transparency duties for specified AI interactions and generated or manipulated content. For a customer assistant, tell people when they are interacting with AI unless an exception applies or the context makes it obvious. For synthetic audio, images, video, or text, define when a notice, provenance metadata, visible label, or internal record is needed. Coordinate notices with GDPR information, consumer protection, advertising, copyright, accessibility, and German language requirements. A hidden disclaimer in general terms is weak design and weak evidence.

Logging should permit a proportionate reconstruction. Capture system and model version, timestamp, user or process, relevant input reference, output, confidence or signal, policy result, action, human reviewer, override, and incident link. Minimize sensitive data in logs, restrict access, define retention, and prevent silent overwrite. For agents, also record tool calls, permissions, external actions, approvals, and rollback. If the company cannot determine why a customer or worker was affected, it does not have meaningful operational control.

Human oversight is a design requirement, not a job title. Give reviewers authority, time, information, domain knowledge, and a safe way to reject the output. Define low confidence handling, automatic stops, dual review for high impact actions, escalation, and fallback. Test whether reviewers actually override bad recommendations. Track overrides without treating every override as model failure: a healthy review process may produce more overrides than a rubber stamp.

Implementation roadmap for a German company

In the first 30 days, appoint an executive sponsor, an AI governance lead, and an owner for every known system. Issue an interim rule for personal, special category, customer confidential, employee, and trade secret data. Freeze unapproved high impact experiments while preserving a safe sandbox. Build the inventory, screen prohibited practices, identify employment and sector overlays, locate unknown vendors, and record the current legal source and date for every conclusion.

In days 31 to 60, approve a taxonomy and decision tree. Publish acceptable use rules and role based AI literacy training. Update procurement questionnaires and priority contracts. Complete GDPR screening and DPIAs where indicated. Configure enterprise identities, least privilege, retention, logging, notices, human review, and incident intake for the highest exposure systems. Start a central evidence folder with links to source, approval, test, and decision records.

In days 61 to 90, test rather than merely document. Evaluate accuracy, robustness, security, language performance, accessibility, and relevant group outcomes. Sample human reviews and logs. Run tabletop exercises for a confidential data leak, a biased hiring recommendation, an agent taking an unauthorized action, and a vendor model change. Complete the works council process for applicable tools. Report open risks, overdue evidence, training, incidents, upcoming application dates, and owners to leadership.

After 90 days, operate a quarterly review and a release gate. New models, prompts, data, integrations, countries, user groups, and decisions should trigger the right level of reassessment. Include retirement and exit. A system that no longer has a business owner or cannot meet logging and vendor requirements should be restricted or shut down.

Evidence and KPIs that stand up to questions

• Inventory with system owner, role, purpose, version, data, supplier, affected people, classification rationale, application date, and approval.
• Legal register distinguishing binding law, enacted German implementation, authority guidance, standards, codes, draft proposals, and internal targets.
• Prohibited practice screen, high risk assessment, DPIA, employment review, sector review, and documented decision rationale.
• Training matrix, practical assessments, acceptable use acknowledgements, and refresher triggers.
• Data provenance, quality tests, evaluation results, subgroup and language results, limitations, technical documentation, and change records.
• Vendor questionnaires, contracts, model information, sub-processors, security evidence, incident commitments, audit evidence, and exit plan.
• Notices, labels, scripts, accessibility tests, human oversight instructions, override samples, logs, incident reports, and corrective actions.

Useful KPIs combine coverage with effectiveness. Track the percentage of uses inventoried and owned, classification completion, high risk assessments completed, approved tool adoption, role based training and assessment coverage, vendor evidence coverage, changes reviewed before release, systems with tested rollback, human review completion, override rate, error rate by relevant group and language, unresolved incidents, time to contain, time to correct affected records, and overdue actions.

Do not turn KPIs into a green dashboard that hides risk. A low override rate may mean a good model or an intimidated reviewer. A high training completion rate may coexist with shadow AI. Pair each metric with a sample, threshold, owner, and action. Report exceptions and trends to leadership, the works council where relevant, and the data protection officer or security function when their remit is engaged.

Failure modes to avoid

• Treating the provider's marketing statement as your classification, DPIA, human oversight, or deployment approval.
• Assuming every generative tool is prohibited, or assuming every productivity assistant is outside the AI Act.
• Building a policy without configuring identity, data loss prevention, retention, logging, notices, review, or incident response.
• Deploying employment AI without early works council and data protection involvement.
• Calling a person human in the loop when they cannot understand, challenge, or stop the output.
• Using the old AI Act timetable after the 2026 Digital Omnibus changed transition dates.
• Presenting BfDI commentary, Commission guidance, a voluntary code, or a draft German bill as binding law.
• Keeping sensitive prompts forever, copying them into tickets, or sending personal data to a consumer account.
• Testing only English benchmarks for a German customer or workforce process.
• Buying a compliance platform that creates a duplicate spreadsheet instead of integrating with procurement, identity, privacy, security, product, and incident systems.

Build versus buy

Buy mature commodity controls where they fit: identity and access management, software discovery, training delivery, ticketing, evidence storage, monitoring, vulnerability management, and supplier questionnaires. Configure or build the judgment layer around your business: use case taxonomy, role analysis, prohibited practice gate, risk appetite, human review, German language evaluation, works council workflow, sector mapping, and executive reporting.

A platform can correlate evidence and remind an owner. It cannot decide whether a scoring tool significantly affects a person, whether a model is a safety component, whether a reviewer is genuinely independent, or whether a processing purpose is compatible. For a small or mid-sized company, a controlled register, approved catalogue, contract addendum, training matrix, review checklist, and incident workflow may be enough to start. Larger companies should connect those controls to GRC, privacy, security, quality, product lifecycle, and supplier systems.

The best operating model makes the safe path the easy path. Give employees approved tools with enterprise identity and clear data settings. Give product teams a fast risk triage. Give procurement reusable clauses. Give reviewers usable explanations and authority. Give leadership evidence tied to business outcomes. That approach supports innovation while preserving a defensible record.

What can we do for you?

Magna Products helps German B2B companies turn scattered AI use into controlled, useful operations. We can map your AI inventory, classify system roles and use cases, screen GDPR, BDSG, employment, works council, and sector impacts, design approved workflows for GPAI tools and agents, strengthen vendor controls, and connect human review, logging, incidents, and evidence to the systems your teams already use. Talk with Magna Products to arrange a focused discovery workshop and leave with a prioritized 30, 60, and 90 day implementation backlog.