The EU AI Act entered into force in August 2024 and its obligations are rolling in through 2026 and 2027. If you are building software that includes AI — or advising a business that is — you need to understand what it actually requires. Not the GDPR-style "we'll figure it out later." Real obligations, real timelines, real consequences.
This is not a legal overview. It is a builder's guide: what classification means for your system, what documentation you need to produce, and what changes in the way you write and deploy code.
The risk classification system
The Act divides AI systems into four risk categories. Where your system lands determines almost everything else.
Unacceptable risk — banned outright
A small set of systems are prohibited entirely: real-time biometric surveillance in public spaces (with narrow law enforcement exceptions), social scoring by governments, subliminal manipulation, exploitation of vulnerable groups. If you are building any of these, stop.
High risk — the category that affects most serious business software
This is where the Act has the most practical weight. High-risk AI systems include:
- AI used in hiring, performance management, or work allocation
- AI in credit scoring, insurance risk, or financial services
- AI in critical infrastructure management (energy, transport, water)
- AI in health, medical devices, or emergency services
- AI in education assessment or access to vocational training
- AI used by law enforcement or border management
- AI systems that influence fundamental rights
If your system makes or substantially supports decisions in any of these areas, you are building a high-risk AI system and the full compliance framework applies.
What "substantially supports" means in practice is deliberately broad. A system that classifies loan applications for a human to review is arguably high-risk. A system that flags employee performance for a manager to action is arguably high-risk. If you are unsure, assume high-risk until you have legal advice saying otherwise.
Limited risk — transparency obligations only
Chatbots and systems that interact directly with users must disclose that they are AI. Deepfakes must be labelled. If you are building a customer-facing conversational AI, you need a disclosure mechanism. That is the main obligation here — and it is easy to implement.
Minimal risk — no specific obligations
Most AI systems used in business — recommendation engines, spam filters, document summarisation tools — fall here. You can build and deploy these without the compliance overhead of the high-risk framework, though good engineering practice and data governance still apply.
What high-risk compliance actually requires
If your system is high-risk, here is what the Act requires. This is not exhaustive — read the regulation or get legal counsel for the full picture — but it covers the engineering-facing obligations.
Risk management system
You need a documented risk management process, maintained throughout the system's lifecycle. Not a one-time document — a living process that identifies risks, estimates their probability and severity, evaluates testing outcomes, and documents residual risks after mitigations.
In engineering terms: this is a formalised version of what good teams already do informally. The Act requires you to write it down, keep it current, and link it to your testing artefacts.
Data governance
Training, validation, and testing data must meet specific quality standards: fit for purpose, representative of the operational environment, examined for biases, documented with their provenance and processing history.
This is the part most teams underestimate. If you trained on public datasets, you need to document them, examine them for representativeness, and — if your system affects people in protected categories — examine them for bias. That examination needs to be written down.
Technical documentation
Before deploying a high-risk system, you must produce technical documentation covering: the system's intended purpose, the technical characteristics of the AI model, the training approach and data used, performance metrics and testing results, human oversight mechanisms, and measures to ensure security and accuracy.
This is substantial. If you are thinking "we'll document after we build," that is not compliant. The documentation is part of the deployment artefact.
Logging and transparency
High-risk AI systems must log enough information to audit their decisions after the fact. What inputs triggered what outputs. What version of the model was running. When and how the system was used.
Log retention periods depend on the use case. For some high-risk categories, logs must be kept for years.
Human oversight
High-risk systems must be designed to allow human oversight — not just in theory, but in practice. This means:
- The system must be able to be interrupted, overridden, or disengaged
- The outputs must present enough information for a human to understand and assess them
- The system must flag its own uncertainty where relevant
A system designed to make fully autonomous decisions with no human-in-the-loop review mechanism is not compliant with the high-risk framework. Period.
Conformity assessment
Before market deployment, high-risk systems require a conformity assessment — a formal evaluation of whether the system meets the Act's requirements. For most high-risk categories, this is a self-assessment by the provider (documented). For some categories (biometrics, critical infrastructure, law enforcement), third-party certification is required.
What changes in the way you build
The EU AI Act does not mandate specific technologies or architectures. But it does impose constraints that affect engineering decisions.
Explainability is not optional. If your system makes high-risk decisions, it must be possible to explain why. Black-box models that cannot be interrogated are not compliant for high-risk use cases. This pushes toward architectures where the reasoning is auditable — structured outputs, confidence scores, decision trees, RAG with source citations — and away from "the model just said so."
Versioning is mandatory, not good practice. You need to be able to identify exactly which version of the model was running when a decision was made. Model versioning, deployment records, and the ability to reproduce historical decisions are compliance requirements, not nice-to-haves.
Bias testing is a deliverable. For high-risk systems, you cannot ship without bias testing and documented results. If your system affects people, you need to test whether it affects protected groups differently and document what you found — and what you did about it.
Audit logs are a first-class engineering concern. Logging for compliance is different from logging for debugging. Compliance logs need to be tamper-resistant, retained for defined periods, and structured for querying by regulators. This is infrastructure work, not an afterthought.
The EU AI Act and Belgian businesses
Belgium is in the EU, so the Act applies. What that means practically for a Belgian KMO:
If you are deploying an AI system that your business built — even an internal tool — and it falls in a high-risk category, you are the provider under the Act and the full compliance framework applies to you.
If you are using a third-party AI tool (a SaaS product, an API) in a high-risk context, you are the deployer. Your obligations are lighter — mainly ensuring the tool is used within its intended purpose, informing your workers when AI makes decisions affecting them, and having human oversight where required. But the risk classification still matters: if you are using a third-party tool to make high-risk decisions, you cannot disclaim the obligations entirely.
For most Belgian KMOs using AI in document processing, customer communication, or operational analytics, the practical reality is:
- The system is probably minimal or limited risk — you have transparency obligations and good data governance to maintain, but not the full high-risk framework
- If you are unsure, you need a classification decision, not a guess — and that classification should be documented
This is where the AI Readiness Audit becomes relevant: an honest assessment of what you are running, where it sits in the classification framework, and what gaps exist.
The timeline you need to know
- February 2025: Prohibited AI practices apply. If you are running a banned system, it is already illegal.
- August 2025: GPAI (General-Purpose AI) model obligations apply — relevant if you are building foundation models or deploying models that were not purpose-built for your specific use case.
- August 2026: High-risk AI system obligations apply. This is the big one. If you are building or deploying a high-risk system, you need to be compliant by then.
- August 2027: Additional high-risk categories (Annex I systems — embedded in regulated products) apply.
If you are reading this in mid-2026, the August 2026 deadline is immediate. High-risk systems need to be compliant now.
What to do if you are not sure where you stand
-
Classify what you are running. For every AI system in use or in development, determine its risk category. Document that determination and the reasoning.
-
For high-risk systems, run a gap assessment. Compare your current documentation, logging, testing artefacts, and human oversight mechanisms against the Act's requirements. Identify gaps.
-
Prioritise the gaps that require architecture changes. Logging and versioning are retrofittable. Explainability is not — if you have a black-box model in a high-risk use case, that is an architectural decision you need to make now.
-
Get the documentation written. Technical documentation, data governance records, risk management documentation — these take time to produce properly and they need to exist before deployment, not after.
WDC's AI Readiness Audit is designed for exactly this situation: an honest review of what you are running, where it sits under the EU AI Act, and a written remediation plan. Fixed price, two weeks. If you are just starting a new AI build and want to get the classification right from the start, that is what the AI Opportunity Assessment covers. Book a call if you want to talk it through first.