AI Act deployer check: why it is your best entry point into AI transformation

Updated on 28 September 2026: we have brought this article in line with the version of the AI Act that has applied since 27 July 2026 (Omnibus package, Regulation (EU) 2026/1744) and corrected how the transparency obligations under Article 50 are split between the roles.

You already deploy AI, even if you do not develop it

The most common misconception about the AI Act goes like this: "That is for the big tech companies, not for us. We don't build AI." The second sentence is true. It just doesn't matter.

The AI Act distinguishes two roles. The provider develops an AI system, or has it developed, and places it on the market or puts it into service under its own name. The deployer uses it within its own organisation. The Act sets out obligations for both roles. They differ, but both are binding.

Check this quickly against your own day-to-day business. Does your sales team use ChatGPT to draft quotes? Is Copilot running in your Office applications? Does your CRM sort customers with an AI feature the vendor added in an update? Then you are a deployer within the meaning of the AI Act, without having written a single line of code. Which obligations follow from that depends on the specific system and its purpose.

This is already happening today. The obligation to support the AI literacy of your own staff has applied to deployers since February 2025. Since the end of July 2026 it has been worded more leniently, but it still exists. Further obligations apply in stages.

None of this is a reason to panic. Most obligations for deployers of everyday office tools are manageable and can be met with internal resources. They do, however, assume that you know which AI is actually running in your company. That is where the deployer check begins.

What really applies and when: the literacy obligation, transparency from 2.8.2026 and what the Omnibus postpones

Three dates give the topic its structure. Once you know them, there is no need for hasty action, and no reason to hope the whole thing will go away.

Since 2 February 2025: the AI literacy obligation. Article 4 of the AI Act requires providers and deployers to look after the AI literacy of staff who work with AI systems. In its original version, they had to ensure a "sufficient" level. Since 27 July 2026 the version amended by the Omnibus package applies: companies must take measures that support the development of AI literacy. They do not have to guarantee any specific level for each individual. The obligation itself still applies. Certain AI practices, such as manipulative systems, have also been prohibited since February 2025 (Article 5). For a long time supervision was missing. According to the European Commission, the rules on supervision and enforcement have applied since 3 August 2026. In Germany, the Federal Network Agency (Bundesnetzagentur) has been the central market surveillance authority since 29 July 2026 under the German AI market surveillance act (KI-MIG).

Since 2 August 2026: transparency obligations. Article 50 splits these duties between the two roles. Providers must make sure that chatbots disclose that they are AI and that AI-generated content is marked in a machine-readable way. Deployers must disclose when they publish deepfakes or AI-generated text intended to inform the public on matters of public interest. For text, this does not apply if a person has reviewed it editorially and someone holds editorial responsibility. Deployers of emotion recognition or biometric categorisation systems must inform the people exposed to them. Relevant for mid-sized companies: if you have a chatbot developed under your own name and put it into service on your own website, you may count as a provider yourself. Exactly where that line runs has not yet been settled. The date stayed in place despite the Omnibus package. The only transitional period concerns the marking obligation: providers whose systems were already on the market before 2 August 2026 have until 2 December 2026 to comply.

What the Omnibus postpones (and what it does not). The Omnibus package is an EU amending package intended to simplify the AI Act. Parliament approved it on 16 June 2026 and the Council on 29 June. It was published as Regulation (EU) 2026/1744 on 24 July and has applied since 27 July 2026. It postpones the obligations for high-risk systems. For stand-alone high-risk applications (for example AI in applicant screening or credit decisions about private individuals), the deadline moves from 2 August 2026 to 2 December 2027. For AI in regulated products such as machinery or medical devices, it moves from 2 August 2027 to 2 August 2028. Under a new transitional rule, high-risk systems that are already on the market or in service before these dates are in principle only covered if their design is significantly changed afterwards. How far this relieves deployers in individual cases has not yet been settled. In addition, the literacy obligation is softened: companies must now "support" AI literacy through measures rather than ensure a sufficient level. The obligation remains, but the standard is considerably weaker, and how authorities will interpret it is still open. The Omnibus also adds new prohibitions: AI systems that generate intimate deepfakes without the consent of the person shown, or child sexual abuse material, are banned from 2 December 2026.

To give a sense of scale: infringements of the prohibited practices can be fined up to 35 million euros or 7 percent of worldwide annual turnover, infringements of the deployer obligations for high-risk systems or of the transparency obligations up to 15 million euros or 3 percent. For small and medium-sized enterprises, the lower of the two figures applies in each case. The literacy obligation under Article 4 is not specifically listed among these fines. How strictly authorities will actually check remains open, because enforcement practice has yet to develop. The size of the ranges shows how seriously the legislator takes the rules.

The sober conclusion: the Omnibus mainly postponed what affects very few mid-sized companies today, namely the high-risk obligations. What matters to most of them already applies: the literacy obligation since 2025, the transparency obligations since August 2026. Waiting for the Omnibus therefore postpones nothing that is currently due.

Note: This article is for general information only and does not constitute legal advice. Please seek qualified legal advice for an assessment of your individual case.

The deployer check in 5 steps: from tool inventory to mapping obligations

The deployer check does not replace a legal opinion. The AI Act does not prescribe it in this form either. It is, however, the practical way to find out which obligations apply to you: a structured stocktake with internal resources. You need one person in charge, one spreadsheet, two to three weeks of calendar time. Each of the five steps builds on the one before.

Step 1: Inventory your AI use, including shadow AI

Record every system in which AI is at work. They fall into three categories:

• Obvious tools: ChatGPT, Copilot and similar assistants that employees use directly.
• Embedded AI features: AI functions in software you already use, such as text suggestions in the CRM, automatic prioritisation in the ticketing system or translation features.
• Shadow AI: tools that business units have introduced without IT approval. A company-wide email will not uncover them; conversations will. Ask each department specifically what they use to write texts, create images, screen applications or analyse data.

For each system, note its name, its purpose, which department uses it and which data goes into it. For now, the inventory needs nothing more.

Step 2: Assign a risk class

The AI Act does not treat all AI the same way. Most of your systems are subject only to limited obligations, mainly the literacy obligation and, in certain cases, transparency obligations. You need to look more closely at use cases the AI Act classifies as high-risk, for example AI-supported applicant selection or assessing the creditworthiness of private individuals. And there are prohibited practices that have been banned since 2 February 2025.

You do not need to hire a lawyer for every tool to classify them. Free guidance for mid-sized companies is available from the chambers of industry and commerce (IHK) and the Mittelstand-Digital centres, among others. Roughly classify each system from step 1. Be honest about where you are unsure. Those open questions are a result of the check too.

Step 3: Derive the obligations for each system

The obligations follow from the risk class. In practice, this means:

• All systems: you must take measures so that the people who work with them build the AI literacy they need (Article 4). This obligation already applies.
• Customer-facing systems or published content: the transparency obligations under Article 50 have applied since 2 August 2026. Making a chatbot disclose that it is AI and marking AI content in a machine-readable way is primarily the provider's job. Still check whether your chatbot does this, and whether you had it developed under your own name, because then you may count as a provider yourself. As a deployer, you must disclose when you publish deepfakes or AI text that is intended to inform the public on matters of public interest and has not been reviewed editorially. The same applies if you use emotion recognition or biometric categorisation.
• High-risk systems: here Article 26 requires, among other things, use in accordance with the provider's instructions for use, human oversight by competent staff, control of input data to the extent you control it, ongoing monitoring, retention of logs for at least six months and reporting of serious incidents, first to the provider and then to the market surveillance authority. If you use such a system in the workplace, you must inform employees and their representatives beforehand. Thanks to the Omnibus package these obligations apply later (for most affected systems on 2 December 2027), but they are the most demanding. If you only start on them in 2027, you are starting too late.

Step 4: Name the people responsible

A table without names stays on paper. Name one responsible person for each system. This does not have to be someone from IT; ideally it is someone from the department that actually uses the system. From then on, this person answers three questions: What do we use the tool for? Which data goes into it? Who checks the results before they take effect? The check as a whole also needs an owner at management level who can make decisions when two departments disagree.

Step 5: Document the gaps

The last step is the most valuable one: write down what is missing. Typical gaps are tools without a clear purpose, systems without a named owner, unclear risk classifications, missing training, and no rule on which data may flow into external AI services. Prioritise by deadline. Anything concerning literacy and transparency comes first, because those obligations already apply. Anything concerning possible high-risk systems comes next, with enough lead time.

What you end up with is a working list: every system recorded, classified, assigned its obligations and a named owner, with open points prioritised. That gives you something you can manage. From here on, the check becomes a tool.

Why the check delivers more than compliance: your first honest AI inventory

Look at the result of the check again, this time without the compliance lens. What is on the table? A list of all AI tools actually running in your company, including those that business units use without approval. An overview of who works with what. And an honest record of where rules, owners or clarity about data are missing.

That is exactly the foundation you need for the next steps anyway.

For assessing readiness: whether your company is ready to run AI productively depends on its current state. Ambition tells you little. Which processes already involve AI today? Where are results produced that nobody checks? Without an inventory you are guessing. With one, you can make an actual assessment.

For governance (the rules and responsibilities for using AI): you can only write rules for AI use for systems you know about. A policy that ignores how AI is actually used will itself be ignored. The gaps documented in the check (missing ownership, unclear data flows) are your governance agenda in raw form.

For first agentic workflows: by this we mean processes in which AI carries out work steps on its own, within clearly defined limits and with human control at the right points. The AI Act already demands exactly this operational discipline from deployers of high-risk systems: use in accordance with the instructions for use, oversight by competent staff, control of input data and ongoing monitoring. If you practise these patterns early, even where they are not yet legally required, you build the capability that productive operation will later depend on.

In our experience, many companies have not yet dealt with implementing the AI Act in a systematic way, and clearly named responsibilities are the exception. If you carry out the check, you do more than meet obligations. You know where you stand, and you can plan from there instead of starting from zero with every new AI initiative.

You only know which obligations apply to you once you have taken stock. The same stocktake is the first work step of the transformation. That is where the deployer check pays off.

From check to operation: governance and approval levels from the start

The result of the deployer check is a list: which AI systems you run, who uses them, with which data, and where rules are missing. The most common mistake at this point is to turn it into a set of rules that disappears into a binder. A better approach is to derive a simple operating rule from each gap, one that works on Monday morning.

At its core, you need two kinds of rules.

First: who may approve what? Not every AI output needs the same level of control. A draft text for internal use is different from a quote sent to a customer, or an assessment that affects a person. Sort the use cases from your check into two or three approval levels: what can go out without review, what needs a look from the person responsible in the department, and what the management decides. We did not invent this: the AI Act itself requires human oversight by competent staff for high-risk systems. The same logic, on a smaller scale, makes sense for any use of AI: there is always a named person who is accountable for what the system does day to day.

Second: which data may go where? The check has shown which tools your teams actually use, often including those nobody officially knew about. The rule for this fits on one page: which categories of data (customer data, contracts, personnel data, internal figures) may go into which tool, and which may go into none. It answers a question employees would otherwise answer for themselves, each in a different way.

If you want to go further, the deployer obligations for high-risk systems under the AI Act provide the blueprint: use in accordance with the provider's instructions for use, control of input data, ongoing monitoring, retention of logs for at least six months, and reporting of serious incidents. Even if your systems are not (yet) classified as high-risk, these five points simply describe what separates orderly operation from an experiment. If you introduce a slimmed-down version of them for all AI tools, you will not have to retrofit anything later.

The test for each of these rules is the same: can someone in accounting or a project lead in sales decide within thirty seconds whether what they are about to do is allowed? If so, the rule will be followed. If the answer is a reference to chapter 7, section 3, it will be ignored, and you are back to the shadow AI that the check has only just brought to light.

This is how the check becomes an operating system in the literal sense: documented responsibilities, clear data flows, defined approvals. It is the foundation on which you can then responsibly set up the first automated AI workflows, without every new application reopening the governance question from scratch.

Typical mistakes: waiting, over-regulating, delegating to IT

We keep seeing three reactions to the AI Act. Each of them costs more than it saves.

Mistake 1: waiting, because the Omnibus has postponed things. The Omnibus package postpones the obligations for high-risk systems to December 2027, or August 2028 for AI in regulated products. What it does not postpone: the transparency obligations have applied since 2 August 2026, and only providers get a transitional period until December 2026 for marking AI-generated content. The obligation to support AI literacy in the company has applied since February 2025, in a softened form but still in force. And since August 2026 the national market surveillance authorities have been enforcing the rules, in Germany mainly the Federal Network Agency. If you keep waiting now, you are waiting for relief that will not come for the obligations that already apply. On top of that, you need the tool inventory from the check anyway, for every further AI decision and for more than compliance. Waiting leaves every obligation in place and only delays the benefit.

Mistake 2: over-regulating. The opposite extreme is a 50-page AI policy that is legally watertight and unusable in practice. In a company with 100 employees nobody reads it, and what nobody reads steers nothing. The result is a standstill on paper only: business units keep using AI, now without asking. What works is a small number of clear rules drawn from the result of the check: which tools are approved, which data they must not see, and who approves new applications. One page that people follow beats a binder that puts them off.

Mistake 3: treating the check as an IT ticket. IT can list tools. It cannot decide which risks the company takes on, who oversees an AI system or which uses fit the business. Yet that is exactly what the AI Act requires of deployers of high-risk systems: human oversight by competent staff, clear responsibilities, control over input data. These are questions of organisation and leadership. You can delegate the work of carrying out the check, but the responsibility stays with management. The check belongs on the management agenda, with IT involved as a participant rather than handed the whole task.

The pragmatic middle ground is unspectacular. Start now, keep the rules small and make responsibilities clear.

Your next step: the check as a 2-week project

The deployer check is not a year-long project. For a mid-sized company with 50 to 200 employees, the first two steps (the tool inventory and the assignment of risk classes) can be done in two weeks. It takes real attention, but it is not a major construction site either: one responsible person who drives the topic, plus short surveys in the business units, is enough to get started.

What you need internally:

• One person with a mandate from management. This does not have to be someone from IT. What matters more is that they are allowed to ask questions across all departments and get answers.
• Honest feedback from the business units. The inventory stands or falls on employees also naming the AI tools they use unofficially. That only works if it is clear that the aim is an overview and that nobody will be sanctioned.
• A simple document instead of a rulebook. A table listing the tool, its purpose, its users and a provisional risk assessment is enough for the first two weeks.

External support is not always necessary. Free services, for example from the chambers of industry and commerce, offer initial guidance. Outside help becomes useful at three points: when the risk classification remains unclear (especially for systems that could affect hiring or assessment decisions), when nobody internally has the capacity to drive the topic reliably, or when the check is meant to produce real operating rules afterwards, such as who approves what and which data may go where.

If you have reached that point, we offer a governance intro call with no obligation. We are not selling a product, and you commit to nothing. We look together at your inventory, or at how to set one up. Afterwards you decide for yourself whether and how to continue. In the worst case you have invested an hour and know where you stand. In the best case, the deployer check marks the start of running AI productively in your company.

Either way, one question remains: do you know today which AI is actually running in your company?

Frequently asked questions

Does the AI Act apply to us if we only use ChatGPT or Microsoft Copilot? Yes. The AI Act distinguishes between providers, who develop AI systems or have them developed and offer them under their own name, and deployers, who use them in a professional context. If your company uses ChatGPT, Copilot or AI features in its CRM, you are a deployer. The obligation to take measures for the AI literacy of your own staff (Article 4) has applied to deployers since 2 February 2025. Which further obligations apply depends on how risky the purposes of use are. That is exactly what the deployer check clarifies.

Which obligations already apply to deployers today, and which are still to come? The prohibition of certain AI practices and the obligation to support the AI literacy of staff already apply, both since 2 February 2025. The transparency obligations have also applied since 2 August 2026. For deployers this mainly means: deepfakes and AI text intended to inform the public on matters of public interest must be disclosed as AI-generated, and so must the use of emotion recognition or biometric categorisation. Making chatbots disclose that they are AI is primarily the providers' job. Since 3 August 2026 the national market surveillance authorities have also been supervising compliance. Still to come are further prohibitions from 2 December 2026 and the extensive obligations for high-risk systems (such as human oversight, control of input data, retention of logs for at least six months and incident reporting), which apply from 2 December 2027 for most use cases.

What exactly does the EU Omnibus package postpone, and what should we still not wait for? The Omnibus package, an EU amending package adopted in June 2026 and in force since 27 July 2026, postpones the obligations for high-risk systems: for the use cases listed in the Act (such as recruitment or credit decisions about private individuals) from 2 August 2026 to 2 December 2027, and for AI in regulated products to 2 August 2028. The transparency obligations, which have applied since 2 August 2026, are not postponed (only the providers' marking obligation has a transitional period until 2 December 2026), and neither is the literacy obligation, although it has been softened. Waiting is therefore not worthwhile: the obligations relevant to most companies already apply, and you need the tool inventory the check produces for every further AI step anyway.

Is an AI usage policy enough, or do we need more? A policy is a start, but it does not answer the decisive questions: which AI systems are actually running in your company (including those business units use without approval), which risk class they fall into, and who is responsible for each system? Then there is the literacy obligation, which requires concrete measures so that the people who work with AI build the skills they need, for example training or guidance suited to the specific use. A document on the intranet alone will hardly achieve that. The sensible order is inventory first, then mapping the obligations, then rules that work day to day: who may approve what and which data may go where.

How much effort does a deployer check mean for a company with 50 to 200 employees? Less than most people expect. At this size, the inventory and the mapping of obligations can be done as a two-week project. You need one responsible person with backing from management, short surveys in the business units on how AI is actually used, and a simple framework for the risk classification. External support makes sense when the risk classification is unclear or when nobody internally has time to drive the topic. You do not need it for the inventory itself.