The EU AI Act Is Not a Legal Problem. It Is a PM Problem.

Search for "EU AI Act explained" and you will find hundreds of articles. Risk tiers, Annex III, Article 17, conformity assessments, the provider versus deployer distinction. All of it accurate. Almost none of it useful to the person who actually has to make compliance happen - the Technical Project Manager sitting between the client brief and the engineering team, with a sprint starting Monday.

The legal team sets the framework. The compliance officer tracks the register. The engineers build to spec. But the PM is the one who has to translate "this system uses AI to make decisions about people" into a kickoff checklist, a sprint task, a dependency on a third-party vendor, and an honest conversation with a client about what that means for the timeline.

That translation gap is where compliance breaks down in practice. Not because anyone was negligent - but because nobody built the PM layer into the governance framework. This article is an attempt to build it. It is written from the point of view of someone who has shipped AI systems in production, caught a compliance gap mid-sprint on a live project, and is now learning the regulatory landscape seriously. Not a lawyer. A TPM.

The EU AI Act is a regulation that came into force in August 2024. It follows a phased timeline - some provisions already apply, with the most significant obligations for high-risk AI systems coming into full effect on 2 August 2026. A further extension under the Digital Omnibus proposal may shift some deadlines, but treating any extension as certain is a planning mistake. The deadline is now. Prepare for it accordingly.

The Act works through a risk classification model. Most AI systems - spell checkers, recommendation engines, spam filters - are low or minimal risk and face no significant obligations. The ones that matter to a TPM are the systems at the top of the pyramid.

The four risk tiers

• Unacceptable risk - banned outright: Social scoring systems, real-time biometric surveillance in public spaces, AI that exploits psychological vulnerabilities. These have been prohibited since February 2025. If a client brief describes anything resembling these, the conversation ends there.
• High risk - full compliance obligations: AI systems used in recruitment and hiring decisions, credit scoring, healthcare diagnostics, education and training assessments, law enforcement, border control, and access to essential services. If your project touches any of these domains, you are in high-risk territory and the full stack of obligations applies.
• Limited risk - transparency requirements only: Chatbots, AI-generated content, emotion recognition tools. Users must be informed they are interacting with an AI. Relatively straightforward to implement.
• Minimal risk - no specific obligations: Spam filters, AI in video games, content recommendation systems. Build and ship as normal.

The extraterritorial reach matters: the Act applies to any organisation placing an AI system on the EU market or deploying it to EU users, regardless of where the organisation is based. Building a hiring tool in India for a Dutch client? You are in scope.

Most compliance failures in software projects are not caused by ignorance of the law. They are caused by nobody asking the right questions at the start. By the time a legal review flags a problem, the architecture is already built, the sprint is three weeks in, and the remediation cost has multiplied by a factor of five.

Here is the set of questions I now ask at the start of any AI project - before scope is locked, before estimates are written, before a single ticket is created. These are not legal questions. They are PM questions that prevent legal problems.

Classification questions

• What decisions does this system make or influence? Not what it does technically - what it decides. Recommending a job candidate is a decision. Flagging a loan application is a decision. Generating marketing copy is not a decision in the same sense.
• Who does it affect, and how? If the AI output directly affects a person's access to something - employment, credit, education, healthcare - you are likely in high-risk territory.
• Is any EU user going to interact with or be affected by this system? If yes, the Act applies regardless of where the system is built or hosted.
• Are we the provider, the deployer, or both? Providers build the AI system; deployers use it. Different roles carry different obligations. An agency building a custom AI tool for a client is typically the provider. A client deploying a third-party AI in their HR process is the deployer. Both have obligations.

Technical questions that unlock compliance

• Where does the data live? Data residency obligations under the Act interact with GDPR and sector-specific rules. Get this on paper before infrastructure decisions are made, not after.
• How is the system's behaviour logged? High-risk systems require automatic logging of operations to enable traceability. If the architecture does not support logging from the start, retrofitting it is expensive.
• Can a human override the system's output? Article 14 of the Act is a design requirement, not a policy one. High-risk systems must enable effective human oversight - meaning the architecture has to support it, not just the documentation.
• What happens when the system is wrong? Accuracy, robustness, and fallback behaviour are compliance requirements, not just product quality considerations. The answer needs to be in the spec before build begins.

Theory is one thing. Here is what it looked like in practice. While working on TokoSmart - an Android research application commissioned by the World Bank Group to study digital financial literacy among small shop operators in Indonesia - I was reviewing the architecture during Week 2 of a fixed four-week build. I was reading a one-pager on the infrastructure setup when I noticed the Azure deployment region: West Europe (Amsterdam).

The World Bank Group Data Protection Annex that governed the project required data to reside in the US, Canada, or the UK. Not the EU. We were mid-sprint, 14 days from a non-negotiable institutional deadline, and the infrastructure was running in the wrong region.

This was not a data residency gap I had been briefed on. It was one I found because I read the architecture document and knew what the governance framework required. A PM without the technical background would have relied on the team to surface it - and the team was heads-down in build mode, not scanning for contractual compliance.

The decision that followed was a governance decision, not a technical one: do not surface this in the next client call without a remediation plan in place. Raising an unresolved compliance gap in a live institutional stakeholder session with no solution creates panic with no upside. I logged it as a formal risk, scoped the migration to Azure UK South, confirmed the path was viable, and communicated it through the right channel with a resolution attached. We fixed it without losing a day on the project.

That is what EU AI Act compliance looks like from the PM seat. Not legal review after launch. Not a checkbox at the end of the sprint. Reading the architecture document in Week 2 and knowing what to look for.

You do not need to become a compliance lawyer. You need to become someone who cannot be surprised by compliance questions - which is a different thing. Here is a practical starting point.

Add to your project kickoff checklist

• AI risk classification: Ask the question explicitly. Document the answer. If it is high-risk, escalate before scope is locked. If it is minimal risk, document that too - you want a paper trail either way.
• Data residency confirmation: Where does data live? Where does it need to live? Get the answer from the client in writing before infrastructure decisions are made. The TokoSmart gap happened because this question was assumed rather than confirmed.
• Logging and traceability: Is the architecture spec'ing for audit-ready logs from the start? If not, flag it as a build requirement, not a nice-to-have. High-risk systems need this in their architecture, not bolted on after.
• Human oversight design: How does a human intervene when the AI gets it wrong? This is an architectural decision. Make sure it is in the design spec, not just the product roadmap.
• Provider versus deployer clarity: Is BetaCraft (or your agency) the provider, the deployer, or both? This determines which obligations fall to you and which fall to the client. Get it in the SOW.

The compliance table that replaces a thousand words

The EU AI Act is, as one Coursera enterprise report put it, a potential GDPR moment for artificial intelligence. That is not hyperbole. GDPR took a domain that lived entirely in legal and compliance and made it a product concern, an engineering concern, a PM concern. It created new roles, new checklists, new lines in SOWs, and new conversations at kickoff. The AI Act will do the same - faster, because companies are not starting from zero this time.

The TPMs who understand this early have an advantage that compounds. Not because they can replace the legal team - they cannot - but because they can stop legal problems from becoming sprint problems. They ask the right questions at kickoff. They read the architecture document. They put data residency in the SOW and human oversight in the spec. They know what "high-risk" means before the client does.

That is the job. Not compliance officer. Not legal counsel. Technical Project Manager - sitting in the gap between what the regulation requires and what the team is building, making sure those two things stay aligned from Week 1 onwards.