The EU AI Act is the most prominent example of risk-based AI regulation, and other jurisdictions are moving in similar directions. Legal teams will interpret it. Engineering teams will have to implement it.
The core idea is simple: obligations scale with the risk of the use case. A spam filter and a system that screens job applicants are not treated the same way. Most of what that means in practice lands in backlogs, pipelines and runbooks.
This is not legal advice. Obligations, timelines and classifications depend on your role and use case, and they continue to be clarified through guidance and standards. Confirm specifics with counsel.
Know what you have
You cannot classify systems you have not listed. Start with an inventory of every AI system in production or development:
- What it does and who uses it
- Which models it relies on, including third-party APIs
- What data it processes
- What decisions or actions it influences
- Where it is deployed and which markets it serves
- Who owns it
Shadow AI matters here. A team calling a hosted model from a spreadsheet macro is still using an AI system.
Understand your role
Risk-based regimes distinguish between those who develop or place a system on the market and those who deploy it. Obligations differ by role. Many enterprises are both: they build some systems and buy others.
Record your role per system. It shapes which documentation you produce and which you request from vendors.
Classify by risk
The Act groups uses into broad tiers: practices that are prohibited, high-risk uses with substantial obligations, uses with transparency obligations, and minimal-risk uses. General-purpose AI models have their own provisions.
Engineering does not make the final classification, but it should supply the facts: intended purpose, affected people, degree of autonomy and the decisions the system supports. Legal makes the call with that evidence.
What high-risk tends to mean in engineering terms
For systems that land in higher-risk categories, expect requirements in areas like these, described here in general terms:
- Risk management — a documented, maintained process for identifying and mitigating risks across the lifecycle
- Data governance — knowing where training and evaluation data came from, how it was prepared and how it was checked for relevant biases
- Technical documentation — architecture, design choices, evaluation results and limitations
- Logging — records that let behaviour be traced after the fact
- Transparency to deployers — clear instructions for use, capabilities and limits
- Human oversight — designed-in ways for people to monitor, intervene and override
- Accuracy, robustness and security — tested and monitored, including against manipulation
None of this is exotic. It is good production practice written down and kept current.
Build controls into delivery
The cheapest compliance is the kind that falls out of normal engineering:
- Evaluation harnesses that produce versioned reports on every release
- Model, prompt and data versions recorded alongside deployments
- Structured logs of inputs, tool calls, outputs and human decisions, with retention aligned to policy
- Oversight implemented as explicit approval states, not a promise that users can override
- Change control that triggers reassessment when intended use, model or data materially changes
Aim for controls designed to support your compliance obligations, with evidence generated automatically rather than assembled in a panic before review.
Transparency is a product feature
Some obligations concern telling people they are interacting with AI or that content is generated. Treat disclosure as UX work: where it appears, how it reads, and how it behaves across channels and languages.
Manage your vendors
When you deploy third-party models or AI products, you depend on their documentation. Ask for model documentation, evaluation summaries, data handling terms and change notification commitments. Keep them with the system record.
Where to start
- Build the AI system inventory and assign an owner to each entry
- Work with counsel to record your role and a provisional risk classification
- Pick one likely higher-risk system and map current controls against the requirement areas above
- Turn gaps into backlog items with owners and dates
Incubics builds logging, evaluation and oversight into delivery so your legal and compliance teams have evidence to work with.