The EU AI Act applies to you too, without high-risk AI

Many leadership teams at mid-market companies file the EU AI Act under "topic for tech giants" or "topic for highly regulated applications like lending and medical diagnostics." Both are partly true, and every company that uses AI systems, regardless of size or industry, already carries duties under the regulation today.

The practical consequence: a company that lets employees use ChatGPT in their daily work, runs a chatbot on its website, or pre-screens job applications with AI assistance has regulatory duties, whether or not anyone in the building has registered that yet.

That holds regardless of company size. A fifty-person company carries the same basic duties as a large corporation, just with fewer resources to implement them. That's exactly why a pragmatic approach focused on the essentials pays off more than trying to regulate every conceivable eventuality at once.

The EU AI Act comes into force in stages. Since February 2025, the ban on certain AI practices and the duty to ensure sufficient AI literacy under Article 4 have applied, for employees who use AI systems or are accountable for their outputs. Since August 2025, duties apply for providers of general-purpose AI models, along with the governance structures of member states.

Since August 2026, most of the remaining rules apply: the requirements for high-risk systems under Annex III and transparency duties, such as labeling AI-generated content and disclosing that a customer is interacting with a chatbot rather than a human. High-risk systems embedded in already-regulated products (medical devices or machinery, for example) get a longer transition period until August 2027.

The duty to ensure sufficient AI literacy sounds abstract, but it's concrete in intent: employees who operate an AI system or are accountable for its outputs must be trained well enough to judge the system's capabilities and limits. That spans everything from a customer service employee reviewing an agent's suggested reply, to a manager who folds an AI-generated metric into a decision.

For most companies that means, in practice: a short, role-specific training rather than a general AI lecture for everyone, documented with date and attendee list. That documentation is, if it ever comes to it, the only proof the duty was met. The record counts, not the intent. A useful rule of thumb: someone operating an AI system needs different training than someone who merely consumes its outputs. The depth of literacy should match proximity to the system.

The prohibited practices (social scoring or certain manipulative techniques, for instance) apply to very few mid-market use cases, but should still be checked once and documented as excluded. Two other duties are more practically relevant: transparency toward customers when a chatbot or AI-generated content is in use, and the AI literacy of the employees working with these systems.

Anyone using AI in HR decisions (candidate pre-screening or performance review, say) or in credit decisions is often operating in high-risk territory under Annex III, and carries substantially broader duties there: risk management, documentation, human oversight. That classification should be checked legally case by case, not assumed or ruled out across the board.

An often-underestimated source of risk is employees using publicly available AI tools without authorization, for example entering confidential contract drafts or customer data into a freely accessible chat tool. That's less a problem of the AI Act itself than a data protection risk, one that should be captured in the same stocktaking exercise, because both issues share the same root: AI usage without documented authorization.

First, an AI inventory: a complete list of all AI systems in use, including applications employees use on their own initiative, and AI features already embedded in purchased software. That last point is routinely overlooked. Many software vendors have added AI features without procurement flagging it separately.

Second, a risk classification: sort each system into prohibited practice, high-risk, limited risk or minimal risk, with a documented rationale. Third, governance and evidence: training records for AI literacy, labeling of AI-assisted customer interactions, and a review of supplier contracts for AI-relevant clauses.

These three steps can be completed in a few weeks if one person owns the responsibility, usually leadership itself or a staff function like compliance or IT working with the business units. Without that ownership, the stocktaking exercise reliably stalls, because it's not clearly assigned to anyone alongside day-to-day business.

Most mid-market companies are "deployers" under the regulation, using a provider's AI systems rather than developing models themselves. A deployer's duties are lighter than a provider's, but real: use in line with the provider's instructions, human oversight where mandated, and retention of relevant records.

It's essential to check in the supplier contract which of these duties the vendor contractually shifts onto the customer. A contract that silently assumes the customer performs its own risk assessment changes the actual workload considerably compared with a contract that leaves that assessment with the provider.

This role can also shift: a company that uses a general-purpose model to build its own agent for a specific task, and hands that agent to its own customers, becomes a provider under the regulation for that system, with the broader duties that brings. That increasingly affects mid-market companies building their own AI features into a product, not just software vendors.

Oversight of the EU AI Act sits with national market surveillance authorities, complemented in Germany by sector-specific regulators. Violations can draw fines scaled to the severity of the breach and the company's global annual revenue. Prohibited practices are sanctioned considerably more strictly than, say, incomplete documentation.

More relevant in practice than fine amounts is that an authority, when in doubt, usually asks for information and remediation before sanctioning. A company with a maintained AI inventory and documented risk classification can deliver that information within days. Without that groundwork, a routine inquiry quickly turns into a rushed project under time pressure.

The scope of AI use keeps growing in most companies: new agents, new vendor features, new team decisions to adopt a given tool. An AI inventory built once and never maintained goes stale within a few months. Governance has to become an ongoing process, triggered by every new application that goes live, not a project with an end date.

The most workable trigger is to attach AI inventorying to an existing process rather than creating a new one: IT procurement, new software approval, vendor onboarding. Each of these already has an approval step, so adding an AI check to it is a small increment, not a new committee.

This piece is not a substitute for legal advice, and we're not offering a binding legal classification. Where we recommend bringing in specialized legal counsel: the binding classification of individual systems and contract drafting. Where we add value: the technical stocktaking, risk classification from an operational point of view, and the operating model that turns classification into practical consequences: who's accountable for a system, what records get collected on an ongoing basis, and how new AI applications enter the inventory before they go live.