EU AI Act 2027: What AI Builders Must Do by December

I am an engineer, not a lawyer, and this is not legal advice. It is the engineering view: what the dates are, which kinds of systems they touch, and which parts of the work land on the people who build AI products. If you sell into Germany, the rest of the EU, or to companies that do, this is the year to plan for it.

The dates that matter in 2027 and 2028

The AI Act entered into force in 2024 with obligations phasing in over several years. In 2026 the EU amended the timeline. The amendment, Regulation (EU) 2026/1744, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. The key dates for builders:

Source for all four rows: K&L Gates via the National Law Review. Gibson Dunn's summary of the provisional agreement gives the same high-risk dates.

The important point: this was a deferral, not a repeal. The high-risk obligations are the same; the clock moved.

Is your system high-risk?

The Annex III categories are use-based. The National Law Review summary lists employment, education, credit assessment, law enforcement and critical infrastructure among them. In builder terms, the systems most likely to be caught are:

• Recruitment and HR tools that screen CVs, rank candidates or evaluate employees.
• Education tools that grade, assess or decide admission.
• Credit and insurance tools that score individuals.
• Systems used in critical infrastructure or by public authorities in sensitive decisions.

What usually is not high-risk: an internal assistant that summarises documents, a support chatbot that answers product questions, an invoice-extraction pipeline, a coding agent. Those still carry transparency duties if they interact with people, but not the full high-risk regime.

Classification depends on the intended purpose and the exact wording of the Act and its annexes, so get a lawyer to confirm the edge cases. The engineering mistake is assuming you are out of scope because your product is "just a feature". An AI-powered candidate-ranking feature inside a general HR tool is still candidate ranking.

What already applies: Article 50 transparency

If you ship chatbots, voice agents or generative features to people in the EU, Article 50 is live now. In short, per the text of Article 50:

• AI systems that interact directly with people must be designed so those people know they are dealing with an AI, unless that is obvious to a reasonably observant person.
• Systems that generate synthetic audio, images, video or text must mark their outputs in a machine-readable format so they are detectable as AI-generated, as far as technically feasible.
• Deployers of deepfakes must disclose that the content is artificially generated or manipulated.
• The information must be given clearly, at the latest at the first interaction, and meet accessibility requirements.

For a voice agent, that means the disclosure goes in the first line of the call, not in the terms of service. I cover this in AI voice agents for customer service.

The engineering work behind high-risk compliance

If your system is high-risk, the Act's obligations translate into things engineers build. These are the areas I would start on now, because each one takes longer than it looks:

Risk management and testing

You need a documented process for identifying risks and testing against them throughout the lifecycle. For an AI system, that means an evaluation suite that runs on every change, with cases for the failure modes that matter: bias across groups, wrong outputs, unsafe actions. If you do not have evals today, that is the first gap to close. See why AI agent projects fail, and the evals that prevent it.

Data governance

You need to know what data trained, tuned or grounds your system, where it came from, and how you checked it for quality and representativeness. For retrieval-based systems, that includes the documents your assistant answers from.

Logging and traceability

High-risk systems need automatic logging so that what the system did can be traced afterwards. In practice: log inputs, retrieved context, model and prompt version, tool calls, outputs and human decisions, with retention rules. Design this into the architecture; it is painful to retrofit.

Human oversight

The system must be designed so that people can understand its outputs, override them and stop it. That means review screens, clear confidence or reason information, an override path and a kill switch that does not require a deployment.

Technical documentation

You need documentation of how the system is designed, what it is for, its limits and how it was tested. If your architecture and eval results already live in your repository, this becomes assembly rather than archaeology.

A plan for 2027

If your product might be high-risk and you serve the EU, here is the order I would work in:

• January to March: classify each AI feature with legal input. List which are high-risk, which only carry transparency duties and which carry neither.
• March to June: close the engineering gaps for high-risk features: logging, eval suites, human-oversight interfaces, data lineage.
• June to September: write the technical documentation from what you built, and run an internal review against the obligations.
• September to November: fix what the review found, and freeze the process so new features go through it by default.
• 2 December 2027: high-risk obligations apply.

Products in the Annex I category (AI inside regulated products such as medical devices or machinery) have until 2 August 2028, but those sectors already run conformity processes, so starting in 2027 is still sensible.

What this means if you build outside the EU

I work with clients in the US, the UK, Canada, the UAE, Australia and India as well as Germany. The AI Act applies based on where systems are placed on the market or used, not where the team sits. If EU residents use your product, or an EU company deploys it, assume the Act is relevant and check.

The good news is that most of the engineering work is just good practice: evals, logs, human review and clear documentation make any AI system easier to trust and debug. I built the Avenuor platform with role-based access enforced on the server and an actor recorded on every change, not for a regulator, but because a system you cannot audit is a system you cannot fix.

Work with me

I build AI agents, chatbots and voice agents with the logging, evals and human-review steps that regulation increasingly expects. If you are planning 2027 work for EU users, see AI agent development and my page for clients in Germany, or book a scoping call. I will work alongside your legal adviser, not replace them.