What EU AI Act compliance means for software teams: risk classification, obligations by role, documentation to maintain, and how to build compliance into delivery.
EU AI Act compliance software obligations depend on two things: what the system does and what role your organization plays in supplying it. Teams frequently assume the regulation applies uniformly, then either over-engineer for low-risk systems or miss obligations on higher-risk ones.
This is an operational overview for engineering and product teams. It is not legal advice, and classification decisions in particular should be confirmed with qualified counsel.
Establish role and risk classification first
Your obligations differ depending on whether you develop and place a system on the market, or deploy someone else's system in your own operations. Organizations often occupy both roles for different systems, and each needs classifying separately.
Risk classification then determines the weight of obligation. The framework distinguishes prohibited practices, high-risk uses, systems with transparency obligations, and everything else.
The practical step is to inventory every AI system in use, including embedded features in third-party products, and classify each. Most organizations discover systems nobody had catalogued, particularly features added to existing SaaS tools.
Where obligations concentrate
High-risk classification carries the substantive requirements: risk management across the lifecycle, data governance covering training and testing data quality, technical documentation, logging sufficient for traceability, transparency to deployers, human oversight design, and accuracy, robustness, and cybersecurity appropriate to the use.
Uses touching employment decisions, access to essential services, credit assessment, education, and similar areas are the common high-risk cases for ordinary business software. If your system materially influences a decision about a person in these domains, assume the classification applies until advised otherwise.
Transparency obligations apply more broadly, including disclosing that a person is interacting with an AI system and marking synthetic content.
What to build into delivery
Rather than treating compliance as a document produced before launch, build the artifacts as part of engineering work.
System inventory with purpose, classification, owner, model versions, and data sources, maintained as systems change rather than assembled annually.
Technical documentation describing intended purpose, design, training and test data characteristics, performance metrics, known limitations, and the human oversight arrangement. Written during development, this is largely a byproduct of good engineering practice.
Logging with sufficient retention to trace how a specific decision was reached, including model version, inputs, and outputs, with personal data handled appropriately.
Evaluation records showing accuracy and robustness testing, including performance across relevant subgroups where the use case affects people differently.
Human oversight design documented as a mechanism rather than a claim: what a reviewer sees, what they can change, and evidence they can act meaningfully rather than rubber-stamping.
Incident process covering detection, assessment, correction, and notification where required.
Practical sequencing
Start with the inventory, because you cannot assess obligations for systems you have not catalogued.
Classify with counsel, documenting the reasoning for each decision. Defensible reasoning matters as much as the conclusion.
For anything potentially high-risk, close the documentation and logging gaps first, since these are the hardest to reconstruct retrospectively.
Build the artifacts into your development lifecycle so they stay current. Compliance documentation maintained separately from the system diverges within a release or two.
Working with vendors
If you deploy third-party AI systems, you need information from the supplier: intended purpose, limitations, performance characteristics, and instructions for use.
Ask for it before purchase and write it into contracts. Suppliers unable to provide documentation for a system you will use in a regulated context are a risk you inherit.
Frequently asked questions
Does this apply to us if we are outside the EU?
Potentially, where systems are placed on the EU market or their output is used in the EU. Confirm your position with counsel rather than assuming geography excludes you.
Are internal-only tools in scope?
Deployer obligations can apply to internal use, particularly where the system affects employees. Classification depends on use, not on whether it is customer-facing.
What if we only use a third-party model through an API?
You are likely a deployer of any system you build on it, with obligations attaching to your system and its use.
How much documentation is enough?
Enough for a competent reviewer to understand purpose, design, data, performance, limitations, and oversight without consulting the team.
Explore our software and web capabilities or contact Voquarn Code to discuss governance for AI systems in delivery.
Written by
Moueen Togarvi
Founder & CEO at Voquarn Code, focused on product engineering, search growth, and practical AI systems.