AI Act in practice: what it means for your business workflows

What the AI Act is, in brief

An EU regulation that sets obligations for developers and operators of AI systems according to how risky they are. It applies in stages: prohibited practices and AI literacy obligations from 2 February 2025, rules for general-purpose AI models (GPAI) from 2 August 2025 and transparency obligations under Article 50 from 2 August 2026. The Digital Omnibus package moved the obligations for high-risk systems to 2 December 2027, and for systems built into regulated products to 2 August 2028.

For the exact wording, work with the primary sources: Regulation (EU) 2024/1689 and the European Commission’s current implementation timeline.

Important: the AI Act does not apply only to AI providers, but also to deployers - companies that put AI into their own operations. If you use AI to process documents, approve things, or make decisions about clients or employees, it applies to you.

Four risk categories

The AI Act sorts systems into four categories by impact. For business workflows, the main thing is to check whether the process falls into a high-risk area, such as HR, lending, education, critical infrastructure or product safety components.

1. Unacceptable risk (prohibited)

Systems the AI Act bans outright: social scoring of citizens, behavioural manipulation causing psychological harm, real-time biometric identification in public spaces (with exceptions), building facial recognition databases by scraping the internet.

Does it apply to you? Probably not - these scenarios are outside typical business deployments.

2. High risk

AI systems that significantly affect human rights, safety or access to essential services. These include:

• recruitment and HR decisions (candidate scoring, employee evaluation)
• credit scoring and decisions on financial products
• decisions in education (admissions, assessment)
• critical infrastructure
• product safety components
• AI for the judiciary or public administration

These systems carry extensive obligations: risk management, data quality, documentation, human oversight, transparency, evaluation, registration in the EU database.

3. Limited risk

This covers systems that interact with people or generate content: chatbots, voice assistants, generated text and images. Internal document extraction, invoice classification or certificate checks usually fall under minimal risk unless they are part of a high-risk process.

Obligations: transparency under Article 50. Users must know they are talking to AI, and generated content must be labelled. We recommend keeping basic system documentation anyway - see below.

4. Minimal risk

AI spam filters, AI in games, simple recommender systems. No special obligations, just recommended good practice.

What it means in practice for business workflows

If your company uses AI for document processes (invoices, certificates, standards, QA checks) and you do not decide automatically about people or their access to services (recruitment, loans, benefits), it will typically be lower risk. Even so, it makes sense to classify the specific use case before deployment.

Five things you should have in order regardless of category:

1. Model and system documentation

• Which model is used and for what purpose
• What data goes in, what comes out
• Who owns the process and who is accountable
• What the system’s limits are (where the model struggles or makes mistakes more often)

2. Human oversight of critical decisions

Anything that can have a significant consequence (approving an invoice, accepting a certificate, a purchasing decision) should have a clear human checkpoint. It doesn’t have to check every case, but it must be clear when it enters the process and who is accountable.

Bulk confirmation of low-risk standard cases by an operator is fine, as long as there is monitoring and the option of later review.

3. Audit trail

For significant decisions you need to be able to show afterwards: what data went in, what the model assessed, who confirmed it, when, and with what justification. If an auditor asks “why did you approve this invoice on 3 April 2026?”, you must have an answer.

4. Transparency towards users

Users of the system (operators, employees) and, where relevant, external parties (clients, suppliers) should know that AI is part of the process. Not as a mandatory notice on every screen, but in internal documentation and communication.

5. Data governance

What happens to the data the AI processes? Where does it go, how long is it kept, who has access? If you process personal data, this has to coexist with GDPR - the AI Act does not replace it, it complements it.

What to do today

If you are only considering an AI deployment, build the following into the design from the start - it pays back in speed and in savings on later changes:

• Risk mapping before deployment. Does the workflow fall into the high-risk category? If so, a stricter regime applies. If it is lower risk, you usually deal mainly with transparency, documentation and good operational practice.
• Human validation for everything critical. Not as a check-box, but as a genuinely working checkpoint with measurable added value.
• Audit logging from the first line. Easy when designed in, expensive when added later.
• Living documentation. Not a one-off PDF, but a continuously maintained record of who changed what, when and why.
• Evaluation pipeline. Measuring accuracy and drift in production. Without it you cannot prove the system works.

What it means for choosing a vendor

If an external partner is helping with your AI deployment, check:

• Can they design an auditable workflow? Not just the model, but the whole process with logs, escalations and checkpoints.
• Do they document the model? Which versions they use, how it behaves, where its weaknesses are.
• Do they handle data governance? Where does the data go, how is it stored, is it used for training?
• Do they have an evaluation framework? How accuracy is measured, how often it is checked, how it responds to drift.
• Do they account for compliance? Not just GDPR, but also the AI Act and, in regulated sectors, specific standards.

If a vendor says “AI Act? Don’t worry, it doesn’t apply to us” - be careful. It applies to everyone who designs, sells or operates AI in the EU. The only question is to what extent.

The timeline you should care about

• 2 February 2025: prohibited practices and AI literacy obligations apply.
• 2 August 2025: rules for general-purpose AI models (GPAI), governance and related parts of the regulation apply.
• 2 August 2026: transparency obligations under Article 50: users must know they are talking to AI, and generated content must be labelled.
• 2 December 2027: obligations for high-risk AI systems (postponed by the Digital Omnibus package).
• 2 August 2028: high-risk systems built into regulated products.

If you operate or design an AI workflow that will run in 2026 and beyond, it should be designed now so that compliance can be demonstrated. Adding an audit trail and documentation after the fact tends to be expensive.

The link to on-prem and data governance

An interesting effect of the AI Act and of data governance in general: it strengthens the case for local (on-prem) AI solutions in regulated industries. The reason: an on-prem model, where data never leaves the company, can have a simpler compliance path - accountability is clear, data flows are controllable, the audit trail sits in your own infrastructure. With the cloud you have to deal with data processing agreements, sub-processors and international transfers.

This does not mean the cloud is wrong - for lower risk it can be fine with good contracts and controls. But for highly regulated environments, on-prem is becoming a stronger argument than ever. I covered when on-prem makes sense in a separate article.

Key takeaways

For most companies with document processes, the AI Act is no reason to panic. It is, however, a reason to build compliance thinking into AI workflow design from the start, not after deployment. Five things - documentation, human oversight, audit trail, transparency, data governance - are good practice just as much as a regulatory obligation.

If you have a workflow that doesn’t handle this today, you have two options: add it proactively, or deal with it in a panic at the first audit. The first option is a lot cheaper.

On the Monitoring and evidence page we describe how we map test findings to the AI Act, ISO/IEC 42001 and DORA.

Note: this article is a practical introduction, not legal advice. For an assessment of your specific situation, consult a lawyer specialising in AI and data protection.