Quick answer
The EU AI Act sorts artificial intelligence systems into four tiers based on potential harm: unacceptable risk, high risk, limited risk, and minimal risk. Each tier carries specific compliance duties, ranging from outright bans for manipulative systems to light transparency rules for basic chatbots, requiring IT teams to map their software inventory accurately.
Key points
- Systems face classification from banned to minimal risk depending on their intended use case.
- High-risk deployments demand rigorous documentation, human oversight, and data quality checks.
- Classification depends heavily on vendor claims and context, making independent verification difficult.
Prerequisites
Enterprise IT teams must establish a comprehensive inventory of every artificial intelligence model, vendor tool, and internally developed algorithm currently in use before attempting compliance classification. Without a complete software bill of materials that tracks underlying components and intended business functions, mapping tools to regulatory tiers is impossible. Organizations need clear internal ownership, typically involving legal, compliance, and engineering leads, to review system documentation. Furthermore, teams must gather detailed technical specifications from external vendors regarding training data, model architectures, and intended deployment contexts. Vendors often market tools broadly, so internal technical staff must verify the actual operational boundaries of each system. Finally, IT buyers should review official European Union documentation to understand statutory definitions rather than relying solely on third-party interpretations or marketing summaries that might downplay regulatory exposure or misstate compliance obligations.
Worked task
To classify a hypothetical customer service routing tool, follow these ordered steps. First, review the primary function of the software against statutory definitions to determine if it falls into the prohibited category, such as cognitive behavioral manipulation or untargeted facial image scraping. Second, check if the deployment sector appears in the high-risk annexes, covering critical infrastructure, employment evaluation, or law enforcement. Third, assess whether the system interacts directly with humans, which triggers transparency obligations typical of limited risk, such as labeling synthetic content. Fourth, document the specific operational context, noting that a general-purpose model shifts tier depending on whether a company integrates it into a high-risk human resources workflow or a low-stakes internal wiki search. Fifth, record the final classification decision in the enterprise asset management register alongside the rationale and supporting technical documentation provided by the vendor or internal developers.
Checking the result
Verifying a risk classification requires cross-referencing initial assessments against independent technical audits and legal reviews. IT buyers should test whether the assigned tier holds up when subjected to edge cases, such as unexpected user inputs or secondary business uses that cross into regulated domains. For instance, if a marketing chatbot is repurposed to handle initial loan inquiries, its risk profile shifts immediately, invalidating the previous minimal-risk label. Teams must interview the engineering personnel who deployed the model to confirm that its actual runtime behavior matches the vendor's documentation. Conducting periodic peer reviews with external compliance specialists helps catch blind spots where internal teams might underestimate regulatory exposure to maintain project momentum. Finally, document all verification steps and discrepancies in an audit log to demonstrate due diligence if regulatory authorities eventually request proper classification methodology.
Limitations
Relying on static risk categories presents significant operational hurdles because artificial intelligence capabilities evolve faster than legislative frameworks. Statutory definitions leave room for interpretation, meaning different legal counsels may reach conflicting conclusions about the exact tier of a borderline enterprise application. Vendors frequently update their models, which can silently alter performance characteristics, data handling practices, or intended use cases, potentially pushing a minimal-risk tool into a higher regulatory bracket without warning. Furthermore, self-assessment mechanisms mean organizations bear the full burden of proof without receiving pre-approval stamps from regulatory bodies. This creates lingering legal uncertainty for IT buyers who must invest heavily in compliance measures while navigating ambiguous regulatory guidance. Enterprises cannot treat classification as a one-time administrative task; continuous monitoring is mandatory, yet tooling for automated continuous risk re-evaluation remains immature and fragmented across the current software market.
Audit your current artificial intelligence inventory today and map every deployed model to its provisional regulatory risk tier before enforcement deadlines approach.
FAQ
Are internal productivity tools exempt from the EU AI Act?
Not entirely. While purely internal tools face fewer restrictions, they still fall under transparency rules if they interact with employees in ways that affect employment conditions or evaluations.
Who is responsible for classifying a custom-built machine learning model?
The deployer or developer using the model within the European Union market bears the primary responsibility for determining its correct risk category and meeting associated compliance duties.
Do open-source models avoid high-risk classifications?
Open-source availability does not automatically exempt a model; classification depends on the specific commercial deployment context and intended use case rather than the licensing model alone.
Topics: EU AI Act risk categories explained, eu ai act, compliance, risk management
Updated