Operate AI with technically verifiable controls? WZ-IT implements data flows, roles, model versions, logging and operational boundaries. Legal classification remains the responsibility of the organisation and its advisers. Explore managed AI
The EU AI Act gives artificial intelligence a binding European framework. For organisations, “do we use AI?” is not enough. Role, intended purpose, affected people and resulting risk determine the obligations. This article translates the position after the AI Omnibus entered into force on 27 July 2026 into a practical assessment and implementation plan. It is technical and organisational guidance, not legal advice. As of October 2026.
Table of contents
- What the EU AI Act regulates
- Determine your role first
- The four risk levels
- GPAI: rules for foundation models
- The phased timeline
- What organisations should implement
- What the technical platform should evidence
- How WZ-IT supports implementation
- Sources
What the EU AI Act regulates
The EU AI Act is the European regulation for artificial intelligence. Its core is a risk-based approach: not every AI is treated the same, but according to the risk arising from its concrete use. The higher the risk, the stricter the obligations.
The Act does not classify a system by model or hosting location alone. The same foundation model can sit inside a lower-risk drafting tool and a high-risk recruitment application. Self-hosting does not remove obligations, although it can make versions, data flows and evidence more controllable.
Determine your role first
Obligations differ for providers, deployers, importers and distributors. Many organisations are deployers when using a purchased assistant. Supplying a system under your own name, materially changing it or providing a model can add provider obligations.
Create a short role record for every system:
- Who supplies the model and the application?
- Who determines purpose, inputs, outputs and user groups?
- Is it internal only or supplied to third parties?
- Is the model, safety component or intended purpose materially modified?
- Which documentation comes from the supplier and which evidence must the deployer create?
The four risk levels
The European Commission explains four levels:
- Prohibited practices - applications like social scoring or certain manipulative systems are banned.
- High-risk systems - including certain uses in critical infrastructure, education, employment, essential services and regulated products. Depending on role, requirements cover risk management, data governance, documentation, logging, human oversight, robustness and conformity.
- Transparency risk - people must be informed in specified situations that they are interacting with AI. Further labelling rules apply to certain synthetic content, deepfakes and public-interest text.
- Minimal risk - the majority of applications; largely without special obligations.
Classification follows the intended use rather than the product name. An internal research assistant, a public widget and a candidate-ranking system can use the same model but have very different obligations.
GPAI: rules for foundation models
A category of its own is general-purpose AI models (GPAI) - the large foundation models on which many applications build. Their providers have their own obligations, such as technical documentation and information about the training data; models with systemic risk are subject to additional requirements.
For organisations that only use such models, deployer duties and the application's risk level are central. Self-hosting also requires attention to licence, model card, provenance, version, evaluation limits and updates. Fine-tuning, distillation or own distribution should trigger a fresh role assessment.
The phased timeline
The Act entered into force on 1 August 2024 and generally applies from 2 August 2026. The Commission's current timeline is:
| Date | Rules |
|---|---|
| 2 February 2025 | initial prohibited practices and AI literacy (Art. 4, rewritten by the AI Omnibus) |
| 2 August 2025 | governance and GPAI obligations |
| 2 August 2026 | general application and transparency rules under Art. 50 |
| 2 December 2026 | new prohibition: AI for generating non-consensual intimate content ("nudifiers") and child sexual abuse material (Art. 5(1)(ba) and (bb)) |
| 2 December 2026 | machine-readable marking under Art. 50(2) also for systems placed on the market before 2 August 2026 (Art. 111(4)) |
| 2 December 2027 | Annex III high-risk systems, including employment uses |
| 2 August 2028 | high-risk safety components of Annex I regulated products |
The later high-risk dates were changed by the AI Omnibus (Regulation (EU) 2026/1744), which entered into force on 27 July 2026. Older timelines should therefore not be reused without checking.
The Omnibus also rewrote Article 4: providers and deployers take measures to support the AI literacy of their staff. They no longer have to ensure a specific "sufficient level" of AI literacy.
Supervision in Germany: the AI Market Surveillance Act (KI-MIG) of 22 July 2026 has been in force since 29 July 2026. The central market surveillance authority is the Federal Network Agency (Bundesnetzagentur, Section 2(1) KI-MIG). BaFin is competent for financial activities, the Länder for public bodies. The act adds national fines of up to EUR 50,000 (Sections 15, 16).
What organisations should implement
Start with an auditable inventory rather than a generic policy:
- Discover systems, including embedded AI in SaaS, support, recruitment and development tools.
- Record role and purpose, user groups, affected people and permitted data classes.
- Assess prohibitions and risk, then identify transparency and potential high-risk obligations.
- Support AI literacy with measures under Art. 4, such as training by role and risk instead of one generic presentation.
- Retain supplier evidence, including model card, version, limitations, subprocessors and change information.
- Define operations, human oversight, incidents, logs, retention, updates and shutdown.
- Reassess changes, because a new purpose, model or data source can change classification.
Data protection, worker participation, copyright, professional secrecy and information security continue to apply alongside the AI Act.
What the technical platform should evidence
Not every system needs full prompt and response retention. Uncritical full logging can itself create data-protection and worker-monitoring risks. The log design should reflect purpose, data class and retention.
Useful technical capabilities often include:
- explicit versions for model, prompt, knowledge base and application,
- separate user, administration and evaluation roles,
- audit trails for model and source changes,
- source traceability for knowledge-grounded answers,
- quality, latency and failure metrics without unnecessary clear-text data,
- approvals and human oversight for consequential actions,
- tested shutdown, rollback and incident handling.
An observability layer such as Langfuse can support traces, versions and evaluation. What it is allowed to store needs a separate decision.
How WZ-IT supports implementation
WZ-IT translates requirements into technology: controlled managed AI infrastructure, model and gateway operations, identity integration, permission-aware RAG, data-minimised observability, and documented update and rollback paths. An internal AI assistant is a common starting point for governed knowledge access.
We provide the technical foundation and system description. Legal role and risk classification, and any required conformity assessment, remain with the responsible organisation and its advisers.
