The AI Act: what applies to ordinary companies and what does not

What follows from that is small for most companies. An internal assistant that answers staff questions from company documents is, as a rule, not a high-risk system. What remains is a notice to users and measures on AI literacy. The bulk of the Act's obligations does not attach to the fact that software contains AI, but to what it is used for.

The Act allocates obligations by role, not by company size.

A provider develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trade mark. A deployer uses an AI system under its own authority, unless it does so in a purely personal capacity (Article 3 points 3 and 4). The Commission illustrates the difference with a CV screening tool: whoever develops it is the provider, and the bank that uses it is the deployer (Navigating the AI Act).

If you buy a finished system, you are the deployer. Most documentation and conformity obligations sit with the provider. You only become a provider yourself if you put your own name on a high-risk system, modify it substantially, or change its intended purpose so that it becomes high-risk (Article 25).

The Act sorts systems by risk: prohibited practices, high-risk systems, systems subject to transparency obligations, and everything else. On the bottom tier the Commission states that the majority of AI systems can be developed and used subject to existing legislation without additional legal obligations (Navigating the AI Act). An assistant for your own workforce almost always belongs there, with the exception of the transparency obligations in Article 50.

The prior question is also worth asking: whether your software is an AI system under the Act at all. The Commission published guidelines on that definition on 6 February 2025 (guidelines on the definition).

Annex III lists eight areas (Annex III):

1. biometrics, such as remote identification or emotion recognition 2. critical infrastructure, such as control of electricity, water or road traffic 3. education, such as admission, assessment of learning outcomes, exam monitoring 4. employment, such as shortlisting applicants, promotion, dismissal, performance monitoring 5. essential services, such as public benefits, creditworthiness assessment, risk pricing in life and health insurance, emergency call triage 6. law enforcement 7. migration, asylum and border control 8. administration of justice and democratic processes

A system that answers staff questions from manuals, contracts or inspection reports sits in none of these areas. Nor does it become high-risk because many people use it or because the content is confidential. The purpose decides. Point the same system at job applications to shortlist candidates and you land in area 4, and in a different set of obligations.

Even inside those eight areas there is a filter. A system is not high-risk where it performs only a narrow procedural task, improves the result of a previously completed human activity, detects decision-making patterns without replacing the human assessment, or performs a preparatory task. Profiling of natural persons, by contrast, is always high-risk (Article 6(3)).

Article 50 is the part that actually reaches an ordinary business.

Paragraph 1 requires providers of systems that interact directly with people to design them so that those people are informed they are dealing with an AI system, unless that is obvious anyway.

Paragraph 2 requires providers of systems generating synthetic audio, image, video or text content to mark the outputs in a machine-readable format and make them detectable as artificially generated. The technical solution must be effective, interoperable, robust and reliable as far as this is technically feasible (Article 50).

Both paragraphs address the provider. As a deployer you are affected indirectly: check at purchase whether the provider meets them, and implement the paragraph 1 notice yourself if you put your own interface in front of the system.

Article 4 requires providers and deployers to take measures supporting the development of AI literacy among their staff. The recast by the Digital Omnibus states explicitly that this does not require guaranteeing any specific level of AI literacy for any individual. The obligation has applied since 2 February 2025 and has been enforceable by national market surveillance authorities since 2 August 2026. No particular training format is prescribed; training, guidance or documentation may all fit, depending on prior knowledge and the intended use (Commission AI Literacy Q&A).

For an internal assistant outside those eight areas, the obligations that dominate public debate fall away:

• No entry in the EU database. The registration duty for deployers concerns high-risk systems under Annex III and there essentially public bodies (Article 49).
• No fundamental rights impact assessment. Article 27 covers public bodies, private providers of public services, and deployers of creditworthiness and insurance risk systems (Article 27).
• No risk management system, no conformity assessment, no technical documentation under Chapter III. Those are high-risk obligations.
• No replacement of data protection law. The GDPR continues to apply alongside (Article 2(7)).

The Digital Omnibus, Regulation (EU) 2026/1744 of 8 July 2026, entered into force on 27 July 2026 and moved both high-risk dates, because harmonised standards and national structures were not yet in place (Commission). Article 50 is substantially unaffected; only machine-readable marking for systems placed on the market before 2 August 2026 was deferred (KPMG Law).

In Germany, since the market surveillance and innovation promotion act for AI entered into force on 29 July 2026, the Bundesnetzagentur is national coordinator, market surveillance authority, and point of contact and complaints. It runs an AI service desk that advises companies on implementation (BMDS press release).

The fine ranges are tiered: up to 35 million euros or 7 per cent of worldwide annual turnover for prohibited practices, up to 15 million euros or 3 per cent for breaches of Article 50, in each case whichever is higher. For small and medium-sized enterprises the lower of the two figures applies instead (Article 99).

IonKon is the provider of the delivered system; your company is the deployer.

IonKon meets the marking obligation in Article 50(2) through signed metadata attached to every output. Whether an output carries that marking can be checked with a tool supplied alongside, independently of IonKon. The notice under Article 50(1) is already configured in the supplied interface and stays permanently visible above every page. What stays with you is keeping the system within its intended purpose and the AI literacy measures under Article 4.

The detailed split for customers, covering roles, technical implementation and the limits of the marking, is set out at [the AI Act page for customers](/en/ki-verordnung).

This article reflects the position as at 12 August 2026 and is not a substitute for legal advice. Whether a particular system counts as high-risk, and which role your company holds in a given case, depends on the purpose and the circumstances of use. Have doubtful cases checked by a lawyer. The Bundesnetzagentur AI service desk is additionally open to companies as a point of contact (Bundesnetzagentur).