The EU AI Act creates different obligations for different systems and actors. A team consuming a model API should not assume it has the same responsibilities as the model's provider. Equally, using a third-party model does not settle the responsibilities associated with the application built around it.
This is an engineering preparation guide. Classification and legal obligations require review against the applicable legislation and the system's actual use.
Use the current application timeline
The Act entered into force in 2024; that is different from the dates on which particular provisions apply. The Commission's AI Act overview describes the staged approach, including general-purpose model obligations from August 2025 and transparency provisions from August 2026.
The Commission's July 2026 AI Omnibus announcement reports extended dates of 2 December 2027 for Annex III high-risk systems and 2 August 2028 for high-risk AI embedded in Annex I products. A timeline copied from an earlier article can therefore be misleading. Recheck current legal text and guidance before setting a release or compliance deadline.
Start with a system record
Document the intended use, affected people, deployment locations, model provider, data inputs, outputs and human decision points. Identify who develops, supplies, configures and operates each part.
A recruitment ranking application deserves a different assessment from an internal tool formatting meeting notes. Industry labels alone do not determine classification. Intended purpose, the legal definitions, exceptions and the organization's role matter.
An engineering inventory can include:
- A named system owner and a versioned purpose statement.
- Model and application versions, including material configuration changes.
- Data sources, access permissions and retention decisions.
- Known limitations and evaluations relevant to the intended use.
- Escalation, human oversight and incident-handling paths.
Produce evidence that answers a question
Suppose an assistant summarizes support tickets. Test whether the summary preserves the customer's issue, exposes information across accounts or invents an action already taken. Keep the test inputs, expected criteria, model configuration and reviewed results together.
Those tests support specific technical conclusions. They do not by themselves establish legal compliance, eliminate bias or certify the whole service. A fairness library or security scanner cannot replace a documented assessment of the actual use case.
Design for change and review
Make model updates reviewable. Preserve enough information to investigate a reported failure while avoiding unnecessary collection of sensitive content. Give operators a way to stop or constrain an affected feature and direct users to a responsible contact.
Review the Commission's enforcement guidance alongside the applicable law with qualified counsel. Turn confirmed obligations into assigned engineering work, with evidence and review dates, rather than publishing an unsupported compliance badge.
Sardar Mukhshaf
Full-Stack & DevOps Engineer
I build scalable web applications, secure backend systems, and production-ready cloud infrastructure. My engineering focus spans interface design, API architecture, deployment pipelines, and observability. Follow for more deep dives into system architecture, performance engineering, and emerging technologies.
More from the practice
Keep the useful ideas close.
Follow new articles with your preferred RSS reader.
Open the RSS feed ↗
