EU AI Act: What Should You Do Once You Know the Risk Level?

💡 Summary: Key Takeaways

• The risk pyramid is a useful starting map, not a decision system. A company needs to know whether a system is prohibited, high risk, subject to transparency requirements, or minimal risk. Its compliance assessment cannot stop there.
• The same model creates different consequences in different jobs. A hotel information chatbot, a candidate-ranking tool, and a healthcare triage system may use the same AI provider without carrying the same legal or operational burden.
• The real question is not the risk label but the operating map. What does the system do, whom does it affect, what is the company's role, where does the data go, does human oversight work in practice, and which other laws apply?

A company buys an AI tool that prioritises candidates in its recruitment process. The vendor says the product complies with the EU AI Act. The company performs an initial review and classifies the system as high risk.

That is not a bad start.

But it is not enough. The “high-risk” label tells the company how serious the system may be. It does not, by itself, say which role the company holds, which records it must keep, what it must explain to candidates, how its recruitment team should challenge a recommendation, what evidence it should request from the vendor, or what other laws such as the GDPR require.

Reducing the EU AI Act to four risk levels is practical. I used that framework in the first article for precisely that reason. It is difficult to understand the Regulation without knowing that a system may be prohibited, high risk, subject to transparency requirements, or minimal risk.

Companies do not, however, make decisions on a pyramid. They make decisions across products, data, suppliers, processes, human oversight, and chains of responsibility.

This article is about the operating work that begins after the risk label.

What does the risk level tell you?

The current consolidated text of the EU AI Act assesses AI systems in their context of use. The European Commission also commonly explains the framework through four levels: unacceptable risk, high risk, limited risk, and minimal risk.

This classification does two things well.

First, it helps a manager see the scale of the potential harm quickly. A hotel chatbot and a recruitment-ranking system do not perform the same job. A healthcare-triage recommendation and a restaurant recommendation do not carry the same consequence either. It is reasonable that rules become more demanding as the effect of an incorrect output grows.

Second, it clarifies the company's first screening questions. Is the use prohibited? Is it high risk? Must the user be told that they are interacting with AI? Does the system remain in the minimal-risk category?

Up to that point, the pyramid works.

It often becomes incomplete at the next question: How will this classification change our daily operation?

High-risk systems face requirements concerning risk management, data governance, technical documentation, record-keeping, instructions for use, human oversight, accuracy, robustness, and cybersecurity. These do not end with the legal department preparing a few documents. They affect product design, supplier contracts, logging, user interfaces, training, and incident management.

A chatbot considered low risk may not face the same burden under the EU AI Act. If personal data is sent to a third-party model, however, the GDPR or Türkiye's KVKK still matters.

The risk level is therefore the first answer, not the final one.

The same model, three different business consequences

A hotel uses a large language model in its website chatbot. A visitor asks about breakfast times, room features, or airport transfers. An incorrect answer may damage the customer experience, cause a complaint, or cost revenue. In most cases, however, the system does not seriously affect fundamental rights, health, or safety.

Use the same model to rank job applications and the position changes. The system may now influence a person's access to employment. Annex III of the Act treats certain uses in employment and worker management as high risk. Saying “the model is the same” tells us very little because the purpose has changed.

Use that model in the first conversation between a medical-tourism company and a prospective patient, where it assesses symptoms and suggests urgency, and the position becomes more sensitive again. The system may only be providing information. But if triage, diagnosis, treatment guidance, or a medical-device function enters the process, the EU AI Act, product safety, and data protection raise separate questions. The distinction between healthcare chatbots, triage, and medical devices is examined in more detail in a separate article in this series.

All three examples may present the user with the same chat window. The legal and operational difference comes from what the system does, not what the interface looks like.

This is the distinction I want to preserve throughout this series. Companies often give too much weight to the question, “Which model are we using?” Legal and operating risk usually appears in a different question: “Which real-world decision did this output change?”

Company role is separate from the risk label

The EU AI Act does not speak only to the organisation that develops a model. It defines different roles, including provider, deployer, importer, distributor, product manufacturer, and authorised representative.

A company using an existing system in its own operation will often be a deployer. The same company may move closer to the provider role when it offers another product to customers under its own name.

The more important point is that a role can change. A distributor, importer, deployer, or other third party may face provider obligations if it places the system on the market under its own name, makes a substantial modification, or changes its intended purpose into a high-risk use.

That may sound like a technical footnote. For the business, it enters the build-or-buy decision directly.

Using a system is one thing. Adding your own data, decision flow, interface, and brand before putting it on the market is another. A supplier's compliance statement does not automatically clear the system you ultimately create.

The first row in an AI inventory should therefore not ask only, “Which AI system do we have?” A better question is: For what purpose, for which user, within which decision, and in which role are we using it?

Transparency is not an alternative to high-risk controls

For chatbots, the most visible obligation is often transparency. When a system is designed to interact directly with people, users should be told that they are interacting with AI unless that fact is already reasonably obvious. Deepfakes, synthetic content, emotion recognition, and biometric categorisation have their own disclosure requirements.

This can give companies false comfort. “We told the user it was AI, so we are done.”

They may not be.

Transparency helps the user understand what they are dealing with. If the system contributes to a high-risk decision, however, data governance, human oversight, record-keeping, accuracy, incident reporting, and conformity assessment may still apply. If the system processes personal data, data-protection rules continue to operate separately.

For a hotel chatbot, saying “This conversation uses an AI-assisted service” is often a sensible starting point. But if the guest enters a passport number, health condition, information about a child, or a special request, transparency is no longer the only issue.

Disclosure does not legitimise the data flow. It only removes the curtain from the relationship.

Human oversight is not an approval button

Human oversight is an important requirement for high-risk systems. In many companies, however, it can easily become a merely formal condition.

An employee clicking “approve” on a recommendation may not amount to real oversight. That employee needs to understand the system's limits, know when to reject its recommendation, and understand what happens after a rejection. Without time, evidence, and authority, the person becomes only the signature at the end of the automation.

This is a matter of operating design. If human oversight is meant to work, role definitions, training, interfaces, records, and exception flows need to be designed together.

In a recruitment system, can the HR specialist record why they changed the ranking? Does the system explain enough about the basis of its recommendation? Is there training on automation bias? What record is opened when a candidate objects?

These questions look legal. They are operating questions.

The general-purpose model provider has separate responsibilities

Using OpenAI, Anthropic, Google, or another provider of a general-purpose model does not automatically make the company a general-purpose model provider. The Act establishes separate provider-side requirements for those models, including technical documentation, a copyright policy, a summary of training content, and more demanding safety assessments for models with systemic risk.

But the model provider meeting its own obligations does not remove your responsibilities for the system you build.

When a company connects an existing model to a customer-service chatbot, it remains responsible for its data flow, user disclosures, supplier choices, and the function it has created. Connecting the same model to a sensitive decision in credit, recruitment, or healthcare requires a different assessment.

The right question is not simply, “Is the model provider compliant?” That question should be asked, but it is not enough.

A better question is: What system did we turn this model into, and which real-world outcome does that system affect?

Data protection enters through a separate door

The EU AI Act does not replace the GDPR. Nor does it replace Türkiye's KVKK.

A system may be considered low risk under the EU AI Act and still require a data-protection assessment if it processes a person's name, email address, travel plans, health information, or personal data entered in free text.

This becomes particularly difficult in chatbots because user input is unstructured. In a form field labelled “name” or “telephone,” you can predict what is likely to arrive. In a chatbot, a user may disclose an illness, a child's age, passport information, or data about another person in the first message.

If that data is sent to a third-party model provider, questions arise about controllers, processors and subprocessors, international transfers, retention, model training, masking, security, and notice.

That is why the third article in this series moves outside the EU AI Act. Sending a chatbot conversation to a third-party AI provider is a data-protection issue in its own right.

A better checklist for companies

There is no need to discard the risk pyramid. It simply should not become the only tool.

When I assess a company's AI systems for the first time, I find the following order more useful:

1. What job does the system perform?
2. Whose decision, right, access, or safety does its output affect?
3. What is the reasonable consequence of an incorrect output?
4. Is the company a provider, deployer, distributor, importer, or more than one of these?
5. Is the use prohibited, high risk, or subject to transparency requirements?
6. Which technical and contractual evidence should be obtained from the general-purpose model provider?
7. Where is personal or special-category data processed, and where is it transferred?
8. Does human oversight carry real decision-making authority?
9. Does this problem need to be solved with AI at all?

The final question matters. In some cases, a conventional business rule, a simpler form, a well-designed approval flow, or a solution that remains inside an existing SaaS product may be cheaper and less risky.

Compliance work should not ask only, “How do we make this compliant?” Sometimes the better question is, “Is it worth building the system this way?”

From the pyramid to an operating map

Risk levels are a useful way to understand the EU AI Act for the first time. But if you are building an AI inventory, buying a product, or offering an AI-enabled system to customers, you need a second map on top of the pyramid.

That map brings roles, data flows, decision points, human oversight, supplier evidence, and other laws into the same view.

This is also where the business cost appears. The model fee is not always the main expense. Keeping logs, cleaning data, building an appeal process, training staff, auditing suppliers, and monitoring the effect of incorrect outputs may cost more.

Good AI governance is therefore not simply a compliance checklist. It is the work of understanding which decisions a company brings closer to AI and whether it can carry the consequences.

The risk level still needs to be asked. The real work begins after it.