EU AI Act & AI Governance
The EU AI Act applies in stages, some obligations already today, and in daily work it is often unclear which application falls where. We turn it into work steps: from the AI inventory through documentation and transparency to policy, training and logging.
Any company that uses AI is likely to have obligations under the EU AI Act, even if the systems are bought rather than built. Some already apply, others have just been postponed. We do not provide legal advice: the legal assessment of an individual case stays with lawyers and the company’s data protection officer. We supply the specialist and technical groundwork and put into practice whatever they decide.
How the AI Act classifies AI systems
The EU AI Act takes a risk-based approach: the greater a system’s risk to people and fundamental rights, the stricter the requirements. At the top are prohibited practices, such as social scoring by public authorities or exploiting the vulnerabilities of particular groups. These bans have applied since February 2025. Below them sit high-risk systems, meaning AI in sensitive areas such as hiring, education, creditworthiness or in regulated products. They come with extensive requirements for risk management, data, documentation, logging and human oversight.
One level further down are the transparency obligations. People interacting with an AI must be able to tell, and AI-generated or manipulated content has to be labeled in certain cases. For most applications, such as text summaries or spam filters, the AI Act adds no obligations, which is called minimal risk. The AI literacy duty and other laws such as the GDPR still apply. General-purpose AI models, meaning large, versatile language models, have a regime of their own. Those obligations are aimed primarily at the providers of the models.
The role determines the obligations
Providers develop an AI system, or have it developed, and place it on the market under their own name. Deployers use a system under their own authority. Most companies are deployers, for example when using an AI assistant in their office suite or purchased recruiting software.
Roles can shift. A company that offers a system under its own name or substantially changes its purpose can become a provider and take on considerably more obligations. A custom chatbot built on someone else’s language model can fall under this as well. Anyone building a third-party model into their own application easily underestimates that. The question should be settled early, ideally with legal counsel.
What applies since when
The AI Act entered into force on August 1, 2024 and becomes applicable in stages. What counts is the position after the AI Omnibus, the amending regulation to the AI Act, which has been in force since July 27, 2026.
- Since February 2025, the prohibited practices apply, along with the duty to promote AI literacy under Article 4. The AI Omnibus amended that article: the duty remains, but no specific level of literacy has to be guaranteed.
- Since August 2025, the obligations for providers of general-purpose AI models apply. Since August 2026, the AI Office can enforce them. Models already on the market before August 2025 have a transition period until August 2027.
- Since August 2026, the transparency obligations under Article 50 apply. Providers of generative AI must also mark their outputs in a machine-readable way. The AI Omnibus also introduced a further ban, on AI systems that generate non-consensual intimate depictions.
- The obligations for high-risk systems were postponed, to December 2, 2027 for applications under Annex III and to August 2, 2028 for AI in regulated products under Annex I. This postponement has been adopted and is no longer a proposal.
The postponed deadlines are no all-clear: bans, AI literacy and transparency already apply. By contrast, the Commission’s proposals to amend the GDPR, which are part of the wider Digital Omnibus, have not been adopted. Guidelines and standards are also still in progress. As far as we know, the guidelines on classifying high-risk systems exist only as a draft. Only the texts in the Official Journal of the EU are binding.
Start with the inventory
The starting point is a complete AI inventory. It covers not only your own projects but also AI features in standard software, tools used by individual teams and applications that employees use on their own. That kind of shadow AI is easily overlooked, and an inventory without it is incomplete. For each entry we record what the system is used for and who works with it, whether the company is provider or deployer, and which risk class provisionally applies, with reasons, for legal and data protection to review. Added to that are the data that flows in, the model behind it, where processing happens and the names of whoever is responsible for the business side, technical support and approval.
These entries are also the core of the documentation and get extended with test results, approvals and changes. For high-risk systems the AI Act demands much more, such as technical documentation and risk management on the provider’s side, and retention of logs and human oversight on the deployer’s side. An inventory that is not maintained is out of date after a few months. The approval process should therefore update it automatically.
Policy, ownership and training
AI governance means that decisions about AI are not made at random. A few binding building blocks are enough. An AI policy sets out which tools are allowed, which data may be entered and how new use cases get approved. A responsible person, or a small team from IT, the business, data protection and legal, assesses the use cases, and every new application goes through the same steps before use: classification, review, tests, approval.
In training, employees learn what the tools they use can do, where the limits are and what is allowed. The depth depends on task and risk, and participation and content are documented. A one-off video with no connection to the tools actually in use hardly serves the purpose of AI literacy. For orientation on the management system, standards such as ISO/IEC 42001 or the NIST AI Risk Management Framework help. They do not replace the legal obligations but do help structure processes. We cover the interplay with the GDPR separately under GDPR-Compliant AI.
What can only be shown in operation
Much of what the AI Act requires only shows in day-to-day operation, so the technical side belongs in from the start. Requests, responses, sources used and model versions are logged in a traceable way, with data protection and retention periods in mind. Before approval we test applications with typical and critical cases, and we repeat the tests when the model or the data changes. Quality, error rates and unusual behavior are observed continuously, and it is set who reacts.
Where decisions affect people, we define human oversight: who reviews results, who can override them and in which cases the AI must not decide. Chatbots state clearly that you are talking to an AI, and AI-generated content is labeled wherever that is required.
What you get
An overview of all AI systems
An AI inventory shows which systems are running in the company, who is responsible for them and which obligations follow.
Classified before launch
Each use case is assigned to a risk class and a role in a traceable way before it goes live.
Documentation that answers questions
Purpose, data, tests and approvals are on record, so questions from customers, auditors or authorities can be answered.
Clear ownership
An AI policy and named owners turn one-off decisions into a repeatable process.
Platforms & tools
We are not tied to any vendor and work with what is already running in the company. The list is a selection.
- Microsoft Purview
- Microsoft Foundry
- Amazon Bedrock Guardrails
- Gemini Enterprise Agent Platform
- MLflow
- Langfuse
- OpenTelemetry
- Confluence
- Jira
- Azure Monitor
How we work
Record the AI systems
Together with the business teams we build an inventory of the AI applications in use and planned, including AI features in standard software.
Classify and prepare the questions
We provisionally assign each use case a risk class and role, and prepare the questions that data protection and legal counsel will settle.
Implement technically and organizationally
We put logging, testing, monitoring, labeling and human oversight in place and draft the AI policy, roles and approval process.
Enable the team
We train staff by role and hand over templates and documentation, so new use cases can be classified without us.