AI compliance & EU AI Act

The AI Act works with four risk classes. The higher the risk, the stricter the duties — and the more expensive non-compliance becomes. Every system from the inventory gets assigned to a class.

The four tiers:

• Prohibited — social scoring, manipulative AI, real-time facial recognition in public spaces (with narrow exceptions), emotion recognition at work or in education. These practices have been banned since February 2025 — anyone using them must stop immediately.
• High-risk — AI in hiring, credit scoring, education decisions, law enforcement, migration control, critical infrastructure. The strictest duties apply here: conformity assessment, technical documentation, risk management, human oversight, logging, high data quality. Duties apply from August 2026.
• Limited risk — chatbots, deepfakes, AI-generated content. The duty: transparency. Users must know they are interacting with AI or seeing AI-generated content.
• Minimal risk — everything else (spam filters, recommender systems, AI autocomplete). No specific duties from the AI Act, but GDPR and other regulations continue to apply.

Special case: General Purpose AI (GPAI):

• Models like GPT-4 or Claude have their own duties from August 2025
• Mainly affects providers, not users — but anyone fine-tuning and distributing their own models can fall under this

The classification is documented per system, with reasoning. This isn't an Excel exercise — in an audit, this reasoning is the first thing asked for.

From the gap list, a framework emerges that gets built into existing structures — not a parallel universe of forms. Compliance no one uses is worse than no compliance.

What's in the framework:

• AI policy — one page on what staff may and may not do (e.g. no customer data into public ChatGPT, no code into external APIs without approval)
• Onboarding checklist for new AI tools — risk classification, DPIA check, DPA question, data flow sketch, approval workflow
• Templates — technical documentation, risk assessment, DPIA, DPA addendum for AI specifics, training data provenance
• Roles and responsibilities — who is the AI officer? Who decides on approvals? Who reviews technical documentation?
• Audit trail — where are decisions recorded? How long are logs kept?
• Escalation and incidents — what to do in case of a data leak, bias incident, complaint?

Self-hosted as a compliance lever — where it fits:

• For particularly sensitive data, use local models (e.g. Ollama with Gemma) — no third-country transfer, no Schrems II risk
• Self-hosted stack for law firms, practices, public bodies, KRITIS operators — quality below frontier models, but auditable locally
• Hybrid architecture: non-critical tasks in the cloud, sensitive routines local — a pragmatic middle path that works for most SMBs

The framework grows with the company. First AI tool: one-page policy + one entry in the record of processing. Ten tools later: same framework, just extended. Templates and processes stay the same.

Compliance isn't a project you close out — it's an ongoing state. Once the framework is in place, it's about staff training, update discipline and regular review.

Training — on two levels:

• General awareness for all employees — what is AI, what may I do, what not, how do I spot problematic tools, who do I report incidents to?
• In-depth training for responsible roles — data protection officers, AI officers, IT leads. Risk classification, DPIA, technical requirements

Update discipline:

• When a new AI tool is introduced, it runs through the onboarding checklist — no exceptions
• For larger model updates (e.g. new model provider, new training data set), the risk assessment is updated
• Legal updates (new AI Act guidelines, BaFin notices) are folded into the framework — quarterly check

Regular audits — internal and external:

• Semi-annual internal self-check against your own checklist — what has changed, what's new, where are the gaps?
• External audits in regulated industries (BaFin review, ISO 27001, industry-specific audits) prepared in good time — the documentation is ready instead of being scrambled together under audit pressure
• Penetration tests for AI systems with an external interface — prompt injection, jailbreaking, data extraction

What happens on incidents:

• A clearly defined reporting path within 72 hours for reportable data breaches (Art. 33 GDPR)
• Incident documentation, root cause analysis, corrective measures — reviewed in audits
• Lessons learned flow back into the framework

With this ongoing upkeep, compliance turns from a costly risk factor into a competitive advantage — B2B customers, insurers and funding applications increasingly ask for solid AI compliance.