Is your AI ready to be explained? A practical look at the EU AI Act

Learn what the EU AI Act means for businesses, including risk tiers, compliance requirements, key deadlines, AI governance, and practical steps to prepare.

Sep 25, 2026 13 min read

Is your AI ready to be explained? A practical look at the EU AI Act

AI rarely enters a company through the front door. More often, it arrives in pieces. A support team turns on an AI assistant. Marketing starts producing campaign drafts with generative tools. HR tests software that ranks applicants. Sales adds lead scoring. A product team connects a recommendation model to customer behavior. Someone in operations builds a small internal workflow that summarizes reports every morning.

At first, none of this looks like a governance problem. It looks like work getting done.

Then the questions start. Who approved the tool? What data does it use? Does it affect customers, employees, candidates, or users in the EU? Can the company explain how the output is produced? Is a person checking the result, or is the system quietly influencing decisions on its own?

That is where the EU AI Act becomes practical.

The regulation entered into force on 1 August 2024, but its obligations are being applied in stages. Some rules are already live, while others depend on the type of AI system, its risk level, and whether it is placed on the EU market or affects people in the EU.

For companies, the AI Act is not just a legal document. It is a test of whether AI use is visible, documented, controlled, and explainable.

What the EU AI Act really tries to control

A short answer to “What is the EU AI Act?” is easy to give. But it does not help much inside a company. The harder, more useful answer is that the AI Act looks at what an AI system actually does once it is built, sold, connected to data, or used in a business process.

That is why two AI tools can sit under very different rules.

A website chatbot that answers basic product questions is one thing. An AI system used to screen job applicants, assess creditworthiness, influence access to education, support biometric identification, or sit inside a safety-related product is something else entirely. The regulation is concerned with the effect the system may have on people, not only with the technology behind it.

For companies, this changes the starting point. It is not enough to say, “We use AI.” The company has to know where AI is used, what decisions or recommendations it supports, who sees the output, and whether the system could affect someone’s rights, opportunities, safety, or access to services.

The dates matter, but the calendar is not the whole story

The question “When did the EU AI Act come into force?” has a clear answer: 1 August 2024. The harder question is “When does EU AI Act take effect for a specific company or system?”

That depends on the obligation.

Prohibited AI practices and AI literacy obligations started applying in February 2025. Obligations for general-purpose AI models started applying from August 2025, with additional transitional rules for some models already on the market. Transparency obligations under Article 50 became applicable from 2 August 2026.

There has also been a major update to the timeline. The AI Omnibus entered into force on 27 July 2026 and extended the application dates for high-risk AI systems: 2 December 2027 for Annex III high-risk systems and 2 August 2028 for high-risk AI embedded in regulated products under Annex I.

That is why the EU AI Act deadlines 2026 can be a misleading phrase if read too quickly. Some 2026 obligations are active. Some high-risk obligations moved later. The practical takeaway is not “everything is delayed.” It is “the timeline is staggered, and companies need to know which bucket each AI system falls into.”

Waiting until the final deadline is a poor strategy. AI inventories, vendor reviews, technical documentation, oversight processes, logging, transparency notices, and product changes all take time. Large organizations may spend months simply finding where AI is already being used.

The EU AI Act tiers are where the work begins

The EU AI Act tiers are often explained as a neat pyramid: unacceptable risk, high risk, limited risk, and minimal risk. In real companies, the sorting process is less neat.

At the top are prohibited practices, where the regulation draws a hard line because the use is considered unacceptable; if a company crosses that line, the penalty exposure is the highest. High-risk systems sit in a different category. They are not banned, but they have to be handled much more carefully, especially when they touch areas such as employment, education, credit, healthcare, public services, biometric identification, or safety-related products.

Limited-risk AI is usually less heavy, but it can still create obligations. If a person is talking to a chatbot, or if content has been generated or manipulated by AI, the company may need to make that clear. Minimal-risk systems carry fewer formal requirements. However, many businesses will still want internal rules to ensure AI tools do not spread through the organization without clear ownership, review, or basic documentation.

A useful AI Act project, therefore, starts less like a legal memo and more like an investigation.

What systems exist?
What do they do?
Who owns them?
What data do they process?
Who sees the output?
Does the output influence a person’s rights, access, opportunity, price, ranking, or treatment?

Without those answers, risk classification becomes guesswork.

What companies may need to prove

The phrase EU AI Act compliance requirements can sound like a checklist that legal teams can handle alone. In practice, many requirements become technical and operational very quickly.

A company may need to show how an AI system was tested. In practice, this can mean being able to:

Show how an AI system was tested
Maintain logs
Provide technical documentation
Demonstrate that a human can review or override an output
Monitor system performance after launch
Inform users when they are interacting with AI
Maintain vendor documentation for a third-party tool that was quietly adopted by one department six months ago

This is where the question “What are the main requirements of the EU AI Act?” becomes more concrete.

Companies need visibility into their AI systems, a way to classify risk, documentation that matches the system’s role, governance around data and model behavior, human oversight where required, transparency for users where applicable, and monitoring after deployment. The exact obligations depend on the company’s role and the system type, but the direction is clear: AI needs owners, records, controls, and review points.

A policy alone will not do this.

A policy may say “human oversight is required.” The product still has to show where that oversight happens. A policy may say “users must be informed.” The interface still needs the notice. A policy may say “outputs must be monitored.” Engineering still needs logs, alerts, dashboards, thresholds, and escalation paths.

That is the part companies often underestimate. Compliance turns into product work, data work, UX work, security work, and integration work.

How the AI Act can affect the business

The answer to “How will the EU AI Act affect your business?” depends less on company size and more on where AI sits in the work.

A company that builds AI products for EU customers may need to look closely at product architecture, user notices, model monitoring, documentation, risk classification, and the vendors or models sitting underneath the product. A company that only uses third-party AI tools still has work to do, especially around procurement, access rights, contracts, vendor evidence, and internal approval. For teams experimenting with generative AI, the first problems are often more basic: what data employees can enter, which outputs need review, and which use cases should never move into production without a proper check.

The effect is usually practical before it is dramatic.

An AI register has to be maintained. New tools need an approval path. Vendor documentation has to be collected before a platform becomes part of a real workflow. A chatbot notice has to appear in the right place. Logs need to be kept in a way that helps later, not in a way that only looks good on paper. If a system may be high-risk, the company needs to know that early enough to adjust the product, the process, or the rollout plan.

Over time, this starts to influence ordinary business decisions. A product roadmap may change because a feature needs more documentation or human review. A security team may block a tool until data access is clearer. An enterprise buyer may ask how an AI feature works before signing. A customer may want to know whether content, scoring, recommendations, or decisions involve AI.

For companies that can answer those questions cleanly, the AI Act becomes easier to manage. For companies that cannot, the problem is usually not the regulation itself. It is the lack of visibility inside their own systems.

How to comply without turning it into theatre

The practical version of how to comply with EU AI Act does not begin with a hundred-page document.

It begins with a map.

Find the AI nobody put on a roadmap

The first job is not to classify risk. It is to find what is already in use.

Some systems will be obvious: a chatbot on the website, a recommendation engine in the product, a copilot used by the support team. Others will be less visible. An HR platform may include automated screening. A marketing tool may generate audience segments. A vendor dashboard may summarize customer behaviour with AI. A data team may be testing generative AI on internal documents.

All of that matters.

The company needs a clear picture of what is running today, including tools that started as experiments and quietly became part of daily work. Formal AI projects are only part of the story.

Put a name next to every system

An AI system without an owner becomes a problem later.

Someone has to know why the tool is there, what data it touches, who can use it, and what the output is supposed to mean. This person does not need to be a lawyer, data scientist, and security specialist at the same time. But they should be able to keep the system visible inside the company and pull the right people in when something changes.

Ownership also prevents the usual drift. A vendor adds a new AI feature. A team connects another data source. A model starts being used in a slightly different way. Without an owner, those changes often happen without anyone asking whether the risk has changed too.

Sort the use cases by actual risk

Once the company knows what it has, the next question is how each system is being used.

Some cases will be simple. An internal summary tool is usually easier to handle than AI that affects hiring, pricing, access to services, credit decisions, customer ranking, or employee evaluation. The more a system touches people’s opportunities, rights, or treatment, the more carefully it needs to be reviewed.

This step does not need to solve every legal question immediately. It should separate the obvious low-risk tools from the systems that deserve proper legal, technical, and business review.

Keep documentation people can actually use

Documentation should help someone understand the system six months later.

What data goes in? What does the system produce? Who reviews the result? What are the known limits? Which vendor documents exist? Is there monitoring? Are decisions logged? Do users need to be told when AI is involved?

That kind of record is useful because it reflects how the system works in practice. It also saves time later, when legal, security, procurement, an enterprise buyer, or an auditor asks for evidence.

A folder full of generic policy text will not help much if nobody can explain the actual workflow.

Add controls where they matter

After the systems are mapped, owned, and documented, the company can decide what needs to change.

Some tools may only need clearer ownership. Others may need access restrictions, better logs, human review, performance checks, incident routes, content labelling, or approval steps before rollout. Existing systems may also need review cycles, especially if vendors update features or teams start using the output in new ways.

The controls should fit the use case. A low-risk internal assistant does not need the same treatment as a system that influences customer access, hiring, or regulated services. The point is to make AI manageable without turning every small tool into a compliance project.

The work is manageable when it is built into existing product, data, and security processes. It becomes painful when treated as a last-minute compliance exercise.

Where Attico fits

The hard part usually begins after the legal discussion.

A company may know that it needs an AI inventory, clearer ownership, user notices, logs, or human review points. The question is: Where do those things live in the actual system? In the product interface? In the admin panel? In the data pipeline? In a vendor review process? In the reporting layer? That is where the work stops being abstract.

Attico can help map the AI that is already inside the business: obvious systems like chatbots or recommendation engines, and quieter ones like lead scoring tools, AI summaries in reporting platforms, HR screening features, support automation, or internal assistants connected to company data. The value of that mapping is practical. It shows what data each system touches, who uses the output, which teams own the workflow, and where the company may need stronger records or controls.

After that, the work becomes more technical. Some teams may need audit trails. Others may need clearer data-flow documentation, access rules, monitoring dashboards, AI-generated content labels, transparency notices, or a human review step added to a workflow that currently runs too invisibly.

For product teams, this means turning governance into ordinary implementation tasks: where the disclosure appears, what gets logged, how a model output is reviewed, what happens when the system changes, and how the company can later show what happened.

For companies using third-party AI tools, Attico can look at how those tools connect to the existing stack, what data they receive, what the vendor can document, and what still has to be controlled on the company’s side.

Attico does not replace legal counsel. But once the legal position is clear, the company still has to build the workflows, interfaces, integrations, records, and monitoring needed to make it work in practice.

FAQ

What is the EU AI Act?

The EU AI Act is the EU’s framework for deciding how different AI systems should be controlled, with the strictest rules reserved for uses that may affect people’s rights, safety, access to services, work, credit, education, or similar areas.

When does the EU AI Act take effect for businesses?

The regulation is not applied all at once: it entered into force on 1 August 2024, while different obligations start on different dates, so each company has to look at what kind of AI it uses and which deadline applies to that specific system.

What are the main requirements of the EU AI Act?

For companies, the practical work usually comes down to knowing where AI is used, classifying the risk, keeping the right documentation, making sure people understand when AI is involved, and adding human review, monitoring, logging, and security controls where the system requires them.

How to comply with the EU AI Act in practice?

Start by mapping the AI already used across the business, including vendor tools and internal experiments, then assign owners, document data flows and outputs, review the risk level, add missing controls, and involve legal, product, engineering, data, and security teams before the system becomes hard to untangle.

Article Authors

Knows how to find and use the strengths of the team to achieve goals. Conscientious and customer oriented. For Drupal events, he brewed beer in a home brewery.