Most companies deploying AI today assume the regulation does not apply to them — that the EU AI Act is a concern for large tech companies building models. That assumption is wrong. If your business operates, integrates, or further distributes an AI system, you are a deployer under the regulation and you have your own statutory obligations. A violation can mean a fine of up to 3 % of global annual turnover or €15 million, whichever is higher.
This article is not legal advice, and the interpretation of some provisions is still being refined. It is a practical orientation map: where you stand under the EU AI Act, what most high-risk deployments require, and what to verify before you sign off a project to production.
When and what entered into force
The EU AI Act is an EU regulation — it applies directly in all member states including Slovakia, with no need for national transposition. It entered into force in August 2024, but obligations are being introduced in phases:
- February 2025: Prohibition of AI systems with unacceptable risk (manipulative techniques, social scoring, real-time biometric categorisation in public spaces).
- August 2025: Obligations for providers of GPAI models (general-purpose AI models, such as large language models) plus publication of the Code of Practice. Fines also become applicable from this date.
- August 2026: Most remaining provisions enter into effect — including obligations for high-risk AI systems. This is the deadline that affects the majority of B2B deployments.
If you are deploying AI today in critical infrastructure, HR, access control, education, or healthcare — you have until August 2026 to get ready. That is not much time.
Four risk categories — where you stand
The EU AI Act classifies AI systems into categories according to risk. The category determines which obligations apply.
Unacceptable risk — prohibited applications. This includes state-run social scoring of citizens, manipulative techniques exploiting subliminal stimuli, and real-time biometric identification in public spaces. For B2B industrial deployments this category is generally irrelevant.
High risk — the strictest regulation for permitted systems. Annex III of the regulation exhaustively lists the areas: biometric identification, critical infrastructure (energy, water, transport), education (admissions, assessment), employment and HR (recruitment, performance evaluation, dismissal), access to essential private and public services (credit scoring, emergency calls), law enforcement, migration management, and administration of justice. A customer-support chatbot is typically not high-risk — but a chatbot that triages medical requests or decides whether to reject a loan application may be.
Limited risk — transparency obligations. Systems that interact with people (chatbots), synthesise content (deepfakes, AI-generated text), must be clearly labelled. Users must know they are interacting with AI when that is not obvious from the context.
Minimal risk — no special obligations. The large majority of B2B AI applications (document processing, predictive analytics, recommendation systems) fall here — provided they do not meet the criteria for higher categories.
Practical delineation: If your AI system feeds into decisions that have legal or similarly significant effects on natural persons, or if it operates in one of the Annex III areas — carry out the classification exercise. If you work exclusively with internal data analytics that have no impact on natural persons, you are most likely in the minimal-risk tier.
Obligations of the deployer for high-risk systems
Article 26 of the EU AI Act defines the obligations of the deployer — the company that operates a high-risk system even if it did not develop it. Key points:
Technical and organisational measures. You must put in place adequate measures to ensure the system is used correctly and as intended, in accordance with the provider's instructions. This includes configuration, access rights, and monitoring.
Human oversight. For high-risk systems you must ensure that a competent person reviews and verifies AI outputs before any action with an impact on a natural person is taken. Having an "override" button is not enough — the reviewing person must have the necessary competence and a genuine ability to change the decision. In an industrial setting this means defining responsible roles and documenting the procedure.
Monitoring. You must monitor system behaviour in the production environment and identify risks and anomalies. If you discover the system is functioning differently from its intended purpose, you have an obligation to notify the provider. This is a strong argument for AI agent observability and evals as a compliance-mandatory element, not an optional one.
Records and logs. For high-risk systems you must retain operational logs to an extent that permits post-hoc audit. Retention periods depend on the sector. If an AI system makes decisions in HR or financial services — those logs are evidentiary material.
Notification of affected persons. Natural persons subject to a decision made by a high-risk AI system have the right to know that AI was used. In practice this means disclosure within processes (e.g., a note in a loan rejection letter or an HR decision).
Data governance. Training and validation datasets for high-risk systems must satisfy requirements for relevance, representativeness, and the absence of discriminatory patterns. If you are the provider — this is your obligation. If you are the deployer — you must verify that the provider has this documentation.
Risk management — what it means in practice
The EU AI Act requires continuous risk management throughout the entire lifecycle for high-risk systems, not a one-off assessment at deployment. In practice this means:
- Before deployment: Documented risk analysis — what harms the system could cause, the likelihood, and the mitigations. Not a hastily written document, but a living artefact that is updated with every material change to the system.
- During operation: Regular review — has the use case changed? Has the model changed? Have the input data changed? Any of these changes can alter the risk profile.
- After an incident: Documented response procedure, notification to the regulator if the incident had a serious impact.
From a methodology standpoint, risk management under the EU AI Act is close to what companies already do for ISO 27001 or GDPR DPIA — it is not a new concept, just a new application in the AI domain. If you have an existing ISMS security framework, extend it with AI-specific controls rather than building a parallel structure.
Documentation — what to have ready
This is the area where most companies fall furthest behind. The EU AI Act assumes that high-risk systems have accessible technical documentation — not for auditors, but as a living management tool. At a minimum:
- Description of the system and its intended purpose — what the system does, what decisions it is used for, who the affected persons are.
- Architecture and data flows — where data enters, where it is processed, where outputs are stored.
- Training and validation datasets (if you are the provider) — origin, scope, quality measures, absence of bias.
- Testing and validation results — including edge cases and failures. This is directly related to how to measure the quality of an LLM application.
- Human oversight procedure — who reviews AI outputs, how, and when.
- Risk register — identified risks, mitigations, and responsibilities.
- Incident response procedure — escalation, notification, and corrective actions.
Records must be retained for a period appropriate to the regulatory context of the system — in financial services and healthcare, typically several years.
Intersection with GDPR
The EU AI Act and GDPR complement each other — the AI Act does not repeal or replace GDPR. If your AI system processes personal data (as most business applications do), both regulations apply simultaneously.
Key intersections:
Legal basis for processing. Even where the AI Act permits certain processing, you still need a GDPR legal basis — consent, legitimate interest, or contract. Deploying AI in HR without an explicit legal basis is a GDPR violation, not just an AI Act one.
DPIA (Data Protection Impact Assessment). If a high-risk AI system processes personal data, it will very likely trigger the obligation to carry out a DPIA under GDPR Article 35. In practice it makes sense to run the DPIA and the AI Act risk assessment in parallel — they share a large portion of their inputs.
Rights of data subjects. GDPR guarantees the right to an explanation of an automated decision. The AI Act adds that the affected person must be informed that AI was used. Combined: your processes must be able to provide a human-intelligible explanation of why the AI decided as it did. This has a direct impact on what eval processes you build and how you log decisions.
Data for training. If you are fine-tuning a model on your own company data that contains personal data — you need a legal basis for that. This is an area where GDPR and LLMs on company data imposes additional requirements. Anonymisation before training is the solution, but it must be genuine anonymisation — pseudonymisation within the meaning of GDPR is not sufficient.
Transparency obligations for limited-risk systems
Even if your system is not high-risk, transparency obligations may apply. Relevant for most B2B companies deploying chatbots or generative AI:
- Any system that interacts with people via text or voice and could be mistaken for a human must be labelled as AI — unless this is obvious from the context.
- Systems generating synthetic content (text, images, audio, video) for the public must be machine-detectably marked (watermarking or metadata).
- An exemption exists for systems where the AI nature is obvious from the context (e.g., the user has themselves launched an AI generator).
In practice: if you deploy an AI assistant in customer support — it must be clear from the initial communication that the user is interacting with AI. If you generate marketing content using AI — consider how to integrate that labelling.
What to do now — priority checklist
August 2026 is less than a year away. For companies with more complex systems, that is not much time. Recommended approach:
- 1.Portfolio classification — review all AI systems and assess which category each falls into. If in doubt, consult a lawyer specialising in technology regulation.
- 2.High-risk systems first — for each high-risk system, launch a risk assessment and a documentation inventory. Identify the gaps.
- 3.Human oversight audit — are your processes capable of genuine human oversight, or is it just a formality? Define responsible roles, competencies, and escalation paths.
- 4.Logging and monitoring — ensure you have logs at a level that permits post-hoc audit. If you are deploying AI agents, this is especially critical.
- 5.GDPR × AI Act overlap — if you do not yet have a DPIA for AI systems processing personal data, add one.
- 6.Supply chain — if you are purchasing an AI system from an external vendor, request the technical documentation required under the AI Act. Unavailability of documentation is a warning sign.
- 7.Internal training — people responsible for human oversight must understand the limits of the systems they are reviewing. "I approved it because the AI recommended it" is not human oversight.
Frequently asked questions
Does the EU AI Act apply to small companies too?
Yes. The regulation contains no exemption for small and medium-sized enterprises in the high-risk category. There are only minor reliefs for small companies in the area of technical documentation — but the core obligations (human oversight, risk management, records) apply equally. If you are an SME and you are deploying AI in HR or in decisions about access to services, the obligations apply to you.
Is a customer-support chatbot high-risk?
In most cases no — if the chatbot merely answers questions and a human operator decides on material matters. But watch out for edge cases: a chatbot that triages medical requests and on the basis of the AI response emergency assistance is or is not dispatched may be classified differently. Always assess the specific use case, not just the form (chatbot vs. something else).
If we use a model from OpenAI or Anthropic, are they responsible?
Model providers have their own obligations — particularly for GPAI models (transparency, copyright, safety testing). But Article 26 is addressed to deployers — that is you. The model provider is not responsible for what you do with their model in your product. The responsibility for the deployment, use case, human oversight, and documentation rests with the deploying company.
How do EU AI Act fines differ from GDPR fines?
GDPR: fines of up to 4 % of global turnover or €20 million (whichever is higher) for the most serious violations. EU AI Act: fines of up to 3 % of global turnover or €15 million for deployers in cases of high-risk violations; stricter for prohibited practices (7 % / €35M). Both regulations can be violated simultaneously by the same situation — cumulative fines are possible.
What if our system is not high-risk but we process data in a cloud outside the EU?
The AI Act on this point is a separate issue from where data is processed — that is governed by GDPR. But both regulations are typically violated at the same time: deploying a high-risk AI system with personal data, without a DPIA, on infrastructure lacking standard contractual clauses, is a fourfold violation. Deployments in regulated sectors (healthcare, financial services) have additional sector-specific rules on top. For these cases the argument for on-premises or EU-hosted LLM is not only technical but also compliance-driven.
*The EU AI Act has introduced a new type of accountability — not just for what companies do with data, but for what AI systems do to people. The good news is that companies that already have their GDPR processes and security management in order have a solid foundation. MP Industrial Solutions helps technical teams assess where they stand from a compliance perspective, and put in place the documentation, monitoring, and human oversight processes before the deadline or an audit arrives.*