The practical answer

Identify the intended use, the people affected and your organisation’s role before selecting controls. Ask engineering teams for traceable evaluations, clear human responsibilities and change records. Those deliverables support a compliance assessment; they do not replace one.

Begin with the use case and the current rules

The European Commission describes the AI Act as a risk-based framework with different obligations and application dates. AI literacy and prohibited-practice rules began applying in February 2025; general-purpose model obligations followed in August 2025. The Commission’s current guidance describes further application in August 2026 and later dates for certain high-risk systems.

Do not use a generic deadline checklist as a legal assessment. Confirm the current rules, any exceptions, your provider or deployer role and the intended use with qualified advisers. Revisit that assessment when the system’s purpose changes.

Source: European Commission: AI Act framework and current application timeline

Ask for evidence your reviewers can inspect

A useful engineering handover explains what the system does, its dependencies, its limits and how it was tested. Record which model or service version was evaluated and the conditions of the test. Keep a decision record for important changes rather than relying on a presentation created at launch.

Avoid putting unnecessary personal data into diagnostic logs. Decide which events are needed to investigate failures, who can inspect them and how long they should be retained. That decision belongs in the design, before production traffic arrives.

  • An inventory of AI uses, owners, providers and connected systems.
  • A data-flow map including external services and access permissions.
  • Representative evaluation cases with acceptance and failure criteria.
  • A named human review path and an operational fallback.
  • Version, change and incident records appropriate to the use case.

Make human oversight a real workflow

A review button is not enough if the reviewer has no context or time to challenge an output. Show the relevant source material, make uncertainty visible and allow escalation. Decide which actions the system may suggest and which it may execute.

For consequential uses such as employment decisions, the legal classification and safeguards deserve specific attention. A familiar interface does not make the underlying use low risk. Keep suitability decisions with accountable people.

Staff the gaps you actually have

An AI engineer can connect the system, a quality specialist can build evaluations, and a platform engineer can make operation observable. Legal interpretation and organisational policy require their own responsible owners.

Use an OutCode brief to describe the technical evidence you need, the systems involved and the skills missing from your team. Do not ask a software supplier to certify compliance simply because they built the application. This article is an engineering planning guide, not legal advice.