EU AI Act compliance: a roadmap for companies that deploy AI

The AI Act divides responsibility between those who build or place an AI system on the market, the providers, and those who use one under their own authority, the deployers. A bank that buys a credit-scoring model, a retailer that licenses a CV-screening tool and a manufacturer that runs a safety-monitoring system are all deployers. Most large European companies are deployers of dozens of systems and providers of few. That makes the deployer chapter the part of the Regulation most CIOs will actually live with.

Article 26 of the Regulation sets those duties for high-risk systems. According to the European Commission's AI Act Service Desk, deployers must take appropriate technical and organisational measures to use systems in line with the instructions for use, and must assign human oversight to people with the necessary competence, training and authority. They must also monitor operation and, where a system may present a risk, suspend its use and inform the provider and the market surveillance authority. A serious incident must be reported immediately.

These obligations are independent of the contract. A provider can supply documentation, logging features and a conformity assessment, but it cannot perform your human oversight or tell your employees that a system is being used on them. The same text requires deployers who are employers to inform workers' representatives and affected workers before a high-risk system is used at work, and to inform individuals who are subject to decisions that Annex III systems make or assist. Those tasks sit inside the deploying company.

The implication for a CIO is that procurement alone cannot discharge the duty. Contracts should secure the artefacts you need, such as instructions for use, access to logs and incident notification, but the operating model must be yours. The action this quarter is to name an accountable executive for each high-risk use case and to write down, system by system, who exercises oversight, who reads the logs and who speaks to affected people.

Status can change. The Regulation treats an organisation as the provider, with the heavier provider obligations, where it puts its own name or trademark on a high-risk system, makes a substantial modification, or changes the intended purpose of a system so that it becomes high risk. This is the trap for innovation teams that fine-tune a vendor model for a new use. Add a gate to your change process so that any repurposing of an AI system triggers a classification review before it reaches production.

The timetable has changed since 2024 and several versions are still in circulation. The Commission states that the AI Act entered into force on 1 August 2024 and became applicable on 2 August 2026, with exceptions. The Digital Omnibus on AI, which the Commission says entered into force on 27 July 2026, moved the start of obligations for Annex III high-risk systems to 2 December 2027. For high-risk AI built into regulated products such as lifts or toys, the rules apply from 2 August 2028.

The delay does not mean there is nothing to do. The Commission states that the prohibited practices and the AI literacy obligations have applied since 2 February 2025, and that the governance rules and obligations for general-purpose AI models applied from 2 August 2025. A ninth prohibition, introduced by the Omnibus, applies from December 2026. The transparency rules take effect in August 2026, which matters to any deployer using chatbots, synthetic media or emotion recognition. Article 4 requires measures to support the AI literacy of staff and others using AI on your behalf, although the Omnibus amended its wording, so confirm against the consolidated text.

Regulators have also begun to publish the interpretive material that companies need. The Commission released draft guidelines on classifying high-risk systems on 19 May 2026, with practical examples of what is and is not high risk. Until they are final, classification judgements should be documented with their reasoning so that they can be revisited. The date change has also created uncertainty for suppliers, some of whom will slow their own readiness work, which raises the risk that deployers inherit gaps.

For planning, we recommend treating December 2027 as the date by which controls must be operating and evidenced, and the months before it as the period in which they are designed, tested and rehearsed. Work that is already due, namely literacy, the screening of prohibited uses and transparency, should not wait. A twelve-month plan that front-loads inventory, classification and literacy will absorb further timetable changes without being rewritten.

General-purpose AI deserves its own line in the plan. Employees now reach assistants and copilots through browsers, office suites and collaboration tools, often without a procurement event. The provider of the model carries the general-purpose obligations that applied from August 2025, but you carry the use. Publish an acceptable-use position, decide which tools are approved for which data, and make sure the transparency duties are understood by anyone who generates public-facing text, images or audio with AI.

Every later step depends on a complete list of AI systems in use, including those embedded in software that the business bought without calling it AI. This is harder than it sounds. According to McKinsey's 2026 State of AI survey of 1,719 participants in 97 nations, nearly nine in ten respondents report regular AI use in at least one function, and 44% say AI is scaling across their enterprise, up from 38% a year earlier. Use is spreading faster than central visibility.

The same survey points to a governance gap that an inventory would expose. Among mid-level managers and individual contributors, 47% report having experienced a negative effect from AI, compared with 31% of executives and senior managers. Whatever the precise causes, the people closest to the tools see more problems than those who sponsor them. An inventory built only from procurement records and executive interviews will therefore under-count both the systems and the incidents.

Eurostat's data on enterprise adoption shows the scale of the task by company size. In 2025, 17% of small enterprises, 30.36% of medium enterprises and 55.03% of large enterprises in the EU used AI technologies. Large groups are where use is widest and where the Act's obligations will concentrate. Across all enterprises with ten or more employees, 19.95% used AI in 2025, an increase of 6.47 percentage points on 2024, which indicates how quickly the population of systems is growing.

The practical method is to combine three sources: a scan of contracts and software spend, a technical discovery of AI features and model calls across the estate, and a short attestation from every business unit head. Each entry should record the purpose, the decision it informs, the people affected, the data used, the provider and the human check in place. Then apply the Annex III areas and the prohibitions to produce a first-pass risk class for every system, with the reasoning written down.

A usable inventory is a living record, not a one-off survey. Assign each entry an owner who is accountable for keeping it current, and connect it to the processes that create new systems: architecture review, vendor onboarding, data protection screening and change control. Each of those is a point at which a new or modified AI use can be caught. Without these hooks, the register decays within months and the programme loses the evidence base that it was built to create.

Eurostat reports that in 2025 the share of enterprises using AI ranged from 5.21% to 42.03% across member states. Denmark recorded the highest share at 42.03%, followed by Finland at 37.82% and Sweden at 35.04%. The lowest shares were in Romania at 5.21%, Poland at 8.36% and Bulgaria at 8.55%. The largest increases between 2024 and 2025 were in Denmark, Finland and Lithuania. The pattern is a Nordic lead and a slower south and east, with the average at 19.95%.

For a multinational group, this spread has operational consequences. Business units in high-adoption markets will bring the most systems into scope and the most requests for exceptions, while units in low-adoption markets may be deploying a handful of embedded tools without any central review. A single global policy is necessary, but a group that assumes uniform maturity will mis-allocate its compliance effort and miss shadow use in the markets where governance is least developed.

Enforcement will also be national in practice. From August 2026 the AI Office and the authorities of the member states share responsibility for oversight, so the same system may be examined by different regulators with different priorities. Companies headquartered outside the EU are not exempt: the Regulation reaches providers and deployers whose AI output is used in the Union. UK, US and Gulf groups with European subsidiaries or customers should map their systems to the countries in which outputs land.

The implication is to run the inventory as a federated exercise with a common template and country owners, then consolidate. Ask each market to identify its high-risk candidates, its works-council or employee-representation requirements and any local regulator contact. This is also the point to align with data protection teams, because Article 26 expects deployers to use the information from providers to comply with their data protection impact assessment duties under the GDPR.

Employee representation deserves early attention. The Regulation requires employers to inform workers' representatives and affected workers before a high-risk system is used at work, and in several member states works councils and unions hold additional consultation rights over monitoring technology. Human resources systems such as recruitment screening and performance analytics sit in Annex III's employment area. Engage the relevant representatives while the design is still open, because late notification can delay a deployment that is otherwise ready.

Legal text becomes manageable when it is converted into controls with owners. We find that the deployer duties for a high-risk system reduce to six: use in line with the provider's instructions; named, competent human oversight; monitoring with a path to suspend and escalate; log retention; information to workers and affected individuals; and impact assessment where required. Each can be assigned to a role, tested and evidenced, which is what an auditor or regulator will ask to see.

Log retention is the most concrete technical requirement. Article 26(6) requires deployers to keep the logs automatically generated by a high-risk system, to the extent they are under the deployer's control, for a period appropriate to its purpose and of at least six months unless other Union or national law provides otherwise. That has architecture consequences: confirm that the logs exist, that your contract gives you access, where they are stored and who can read them, and reconcile the period with data protection retention rules.

Impact assessment has two strands. Article 26 requires deployers to use the information that providers supply to carry out a data protection impact assessment where the GDPR requires one. Separately, the Regulation's recitals state that public bodies and private entities providing public services should carry out a fundamental rights impact assessment before putting a high-risk system into use. Whether that applies to you depends on the sector and the Annex III category, so treat it as a classification outcome rather than an assumption.

The action for the CIO is to build a control library once and attach it to every high-risk entry in the register. The oversight control should specify the competence required, the authority to override and the training record. The monitoring control should define triggers for suspension and the incident route to the provider and authority. Written this way, a new system joins the programme by inheriting controls rather than inventing them.

Human oversight fails quietly when it becomes a signature. An overseer who sees hundreds of recommendations per hour and approves nearly all of them is not exercising control. Define what the overseer can see, how much time they have, what training they have received and what happens when they override. Track override rates and escalations as management information. A pattern of zero overrides is a warning sign that deserves investigation, not a mark of system quality.

Article 99 sets three ceilings. Breaches of the prohibited practices attract administrative fines of up to EUR 35 million or, for an undertaking, up to 7% of total worldwide annual turnover in the preceding financial year, whichever is higher. Breaches of the other listed operator obligations, which include the deployer duties, carry fines of up to EUR 15 million or 3%. Supplying incorrect, incomplete or misleading information to authorities carries up to EUR 7.5 million or 1%. For SMEs the lower of the two limits applies.

These are ceilings, not tariffs, and regulators will weigh the nature, gravity and duration of an infringement. For a large deployer the practical risk from a deployer-duty breach is therefore the 3% tier, together with orders to suspend a system. A bank that has to withdraw a credit-decision model for remediation, or a retailer that must switch off a screening tool during hiring season, loses more through disruption than through the fine.

Commercial exposure arrives sooner than regulatory exposure. Customers in regulated sectors will begin to ask suppliers how they classify and control AI, and procurement teams will add AI Act clauses to master agreements. Providers will seek to push obligations downstream in their terms, particularly around permitted use, since using a system outside its intended purpose can change a deployer's status. The Regulation allows a deployer to become treated as a provider in some circumstances, for example by modifying a system or changing its intended purpose.

Review your supplier contracts against four questions. Does the provider warrant its classification and conformity? Do you receive instructions for use, logs and incident notification? Who bears the cost if the system must be suspended? Are there restrictions on adapting or repurposing the system that your teams may already be breaching? Resolve these at renewal where possible, and prioritise the vendors behind your highest-impact use cases.

Insurance and finance functions should be involved. Boards and insurers are beginning to ask how AI risk is governed, and the Act's penalty structure gives them a reference point. Document the controls you have, the residual risks you accept and the supplier dependencies you rely on, so that the answer to a lender or underwriter is the same as the answer to a regulator. Consistency between those audiences is itself a sign of a mature programme, and it limits the effort of repeated questionnaires.

The sequencing matters more than the tooling. In the first quarter, appoint an accountable executive, agree a risk taxonomy aligned to the Annex III areas, and build the inventory. In the second, classify systems, screen for prohibited uses, and start literacy training for the people who oversee or rely on AI. In the third, design and pilot the six controls on the two or three highest-impact systems. In the fourth, extend the controls to all high-risk entries and rehearse an incident and a regulator request.

Resourcing should reflect that most of the work is operational. Legal counsel interprets the classification calls, but technology teams will build discovery, logging and monitoring, and the business will supply the oversight. A small central team, usually in technology or risk, can own the register, the control library and the reporting, while country and business owners maintain their entries. Boards should receive a short quarterly view: systems by risk class, controls evidenced, open exceptions and supplier gaps.

The programme should also be linked to value. The same register that shows which systems are high risk can show which are used heavily, which have no owner and which duplicate one another. This is where the work pays back beyond compliance, by retiring redundant tools, consolidating vendors and directing investment to the uses that matter. McKinsey's finding that AI is scaling across the enterprise at 44% of respondents suggests that portfolios will grow quickly and that the cost of unmanaged duplication will grow with them.

We close with a caution. This briefing is information, not legal advice, and the Regulation, the Omnibus amendments and the Commission guidelines continue to evolve. The durable decision is organisational: put one accountable owner, one register and one control library in place now. If the guidelines change a classification, you will update an entry rather than rebuild the programme, and your evidence will already be in order when the 2027 date arrives.

Good board reporting is short and consistent. Show the number of systems by risk class, the share of high-risk systems with named owners and evidenced controls, the open supplier gaps, the incidents and near misses, and the decisions the board is being asked to take. Add one line on value: which uses are growing, which are idle, and where consolidation is possible. A board that sees compliance and value in one page is more likely to fund the work properly and sustain it beyond the first deadline.

Karter McKinley supports AI and technology implementation for deployers: building the AI inventory and risk classification, mapping Article 26 duties to owners and controls, and linking each register entry to its business case. We work alongside your legal counsel and data protection officer, and this briefing is information rather than legal advice.