deliveryL2 GuidedGovernance & Compliance

EU AI Act awareness

The EU AI Act (Regulation 2024/1689) is the world's first comprehensive legal framework for artificial intelligence, entering force in August 2024 with phased compliance deadlines through 2027.

·Official AI tool policy exists and is communicated to all developers
·Basic audit tracking is in place (which developers use which AI tools)
·EU AI Act awareness training or briefing has been conducted

·AI tool policy is reviewed at least annually
·Approved tool list is maintained and accessible

Evidence

·Published AI tool policy document with distribution records
·AI tool usage tracking dashboard or report
·EU AI Act training completion records

What It Is

The EU AI Act (Regulation 2024/1689) is the world's first comprehensive legal framework for artificial intelligence, entering force in August 2024 with phased compliance deadlines through 2027. It applies to any organization that places AI systems on the EU market or uses AI systems affecting EU residents - which means any organization with EU customers, EU employees, or EU operations is potentially in scope.

EU AI Act awareness at L2 means the engineering organization understands what the regulation covers, which parts apply to their systems and workflows, and what the compliance obligations are for the AI systems they're building and using. It does not yet mean full compliance infrastructure - that's L3 and beyond. It means the team has done the reading, classified their AI use cases by risk tier, and identified the obligations that apply.

The Act operates on a risk-tiered model. Prohibited AI systems (Article 5) include social scoring, real-time biometric surveillance in public spaces, and systems that exploit psychological vulnerabilities - almost certainly not in scope for an engineering team. High-risk AI systems (Annex III) cover specific use cases in critical infrastructure, employment decisions, education, law enforcement, credit scoring, and health. The most likely engineering relevance here is AI systems used in hiring, code-driven credit decisions, or healthcare applications. General-purpose AI models (Article 51-52, Title VIII) like GPT-4 and Claude are subject to transparency requirements when integrated into downstream products. Limited-risk systems require transparency disclosures (users must know they're interacting with AI). Most AI coding tools fall into the minimal-risk category and have no specific obligations.

For most engineering organizations, the immediate practical impact of the EU AI Act is in three areas: (1) if you're building AI-powered products that customers use, those products may be subject to the Act's requirements; (2) if you use AI systems in decisions that materially affect EU employees (performance management, hiring, work allocation), those uses require specific safeguards; (3) if you integrate general-purpose AI models (like Claude or GPT-4) into your products, you inherit transparency obligations from the model provider and may need to pass them to your customers.

Why It Matters

Enforcement timelines are real - the EU AI Act is not theoretical future regulation; prohibited systems were banned in February 2025, high-risk system requirements apply from August 2026, general-purpose AI model obligations from August 2025. Organizations that have not started compliance work are already behind on some provisions
Fines are material - penalties of up to 35 million euros or 7% of global annual turnover for prohibited AI violations; up to 15 million euros or 3% turnover for other violations. These are GDPR-scale enforcement risks
Compliance requires documentation that takes time to build - high-risk systems require technical documentation, conformity assessments, registration in the EU database, and ongoing monitoring. Building these from scratch after a notice of inquiry is not feasible; they need to be built proactively
Customer contracts are already changing - EU enterprise customers are starting to require AI Act compliance representations in their contracts. Engineering organizations without awareness of their obligations cannot make accurate representations
The Act affects what AI tools you can use in your delivery pipeline - using AI systems that make or influence employment decisions about EU employees triggers high-risk requirements even if those systems are internal

Getting Started

Classify your AI use cases by risk tier - make a list of every AI system you build and every AI tool you use internally. For each, determine which risk tier applies: prohibited (don't do it), high-risk (significant compliance obligations), limited-risk (transparency requirements), minimal-risk (no specific obligations). Most coding AI tools are minimal-risk; AI-driven hiring or performance management tools are high-risk.
Focus first on what you build, not just what you use - the most significant obligations apply to AI systems you place on the market or deploy to EU users. Audit your product catalog: which features use AI? Of those, which affect EU users? For each, what risk tier applies based on use case?
Assign a compliance owner for AI Act - this does not need to be a full-time role at L2, but it needs to be someone's explicit responsibility. Typically the CISO or a senior legal/compliance person. Engineering should have a named technical counterpart who understands both the regulation and the technical systems.
Review vendor obligations - if you're using general-purpose AI models (Claude, GPT-4) in your products, review Anthropic's and OpenAI's compliance documentation. They are responsible for their model-level obligations; you are responsible for your deployment-level obligations, including informing users when they interact with AI.
Build a product documentation habit - the EU AI Act requires technical documentation for high-risk systems. Start building documentation practices now even if your systems are minimal-risk: system architecture, intended purpose, training data sources (if you train custom models), testing methodology, known limitations. Documentation built continuously is much less painful than documentation assembled retroactively.
Put EU AI Act on the quarterly legal review agenda - the Act's implementing regulations and guidance are still being developed. New guidance from the AI Office, member state implementations, and enforcement decisions will clarify obligations over time. Quarterly review ensures your awareness stays current.

Tip

The EU AI Act's definition of "high-risk" in employment contexts covers AI systems used to make or significantly influence decisions about hiring, work allocation, promotion, termination, or performance evaluation. If you are building or using any AI in HR processes affecting EU employees, assume high-risk requirements apply and verify with legal counsel.

6 steps to get from here to the next level

Common Pitfalls

Assuming the EU AI Act only applies if you sell to EU customers. The Act applies based on where AI systems are deployed and where their effects are felt - not just where you sell. If your AI system affects EU residents (employees, users, third parties), you may be in scope. Jurisdictional assessment requires legal review, not just common sense.

Conflating GDPR compliance with AI Act compliance. GDPR governs personal data; the AI Act governs AI systems. They overlap significantly (AI systems often process personal data) but are separate frameworks with separate obligations. GDPR compliance does not imply AI Act compliance for systems in scope of the Act's higher requirements.

Treating the risk classification as a one-time exercise. AI systems evolve, use cases expand, and the Act's guidance continues to develop. A high-risk classification that's assessed once and never revisited may become incorrect as the system or its deployment context changes. Build a process for reassessing risk classification when systems change materially.

Underestimating the documentation burden for high-risk systems. The technical documentation required for high-risk systems is extensive: intended purpose, performance metrics, testing methodologies, known limitations, data governance records, human oversight mechanisms, and conformity assessment. Organizations that discover they have high-risk systems six months before an enforcement deadline are in a genuinely difficult situation.

Ignoring the general-purpose AI model transparency requirements. If you build products that use models like Claude or GPT-4 and those products interact with EU users, you likely have disclosure obligations: users should know they're interacting with an AI system, and in some cases they need to know which AI system. Review your product UX against these requirements specifically.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob's company sells software to EU enterprise customers. The sales team has started getting contract addendums from EU customers asking for AI Act compliance representations. Bob has been CCed on several of these and doesn't know how to respond - he doesn't know which parts of the product use AI, which risk tier they fall in, or what obligations apply.

What Bob should do: Bob should commission a two-week internal audit with three outputs: (1) an inventory of all AI-powered features in the product, (2) a risk tier classification for each feature based on the Act's criteria, (3) a list of the specific obligations that apply to high-risk or limited-risk features. This audit requires involvement from product, engineering, and legal. Bob should use the output to brief the legal team so they can respond to customer contract requests accurately, and to prioritize the compliance work queue. The act of building the inventory is itself a governance improvement - many organizations discover AI features they had forgotten about or features whose AI components had expanded beyond the original scope.

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah uses AI tools internally to help analyze developer productivity data - including data about EU-based team members. She's been asked by the HR team whether the AI-assisted performance analysis she's been running falls under the EU AI Act's employment provisions.

What Sarah should do: Sarah should take this question seriously and escalate it to legal counsel rather than self-certifying a conclusion. AI systems used to support decisions about work allocation, performance evaluation, or promotion for EU employees are explicitly called out in the Act's high-risk category. Even if Sarah's analysis is advisory (she presents insights, managers decide), if the AI outputs influence employment decisions about EU residents, it may be in scope. Sarah should document exactly how the AI is used in her workflow: what inputs go in, what outputs come out, who uses those outputs and how. This documentation is the basis for a legal assessment. If the legal assessment says the use is high-risk, Sarah and Bob will need to implement the required safeguards before continuing.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor is building an internal tool that uses Claude to analyze code quality trends and generate recommendations for which engineers should take on which types of work (matching developers to tasks based on their apparent strengths). He thinks of it as a productivity tool, not an AI employment system.

What Victor should do: Victor needs to pause and get a legal assessment before deploying this tool to any EU employees. "Recommending who should take on which work" is precisely the kind of AI-assisted work allocation decision that falls under the Act's employment-context high-risk provisions. The fact that it's internal and advisory doesn't automatically exempt it. Victor should document the tool's design (inputs, logic, outputs, how recommendations are used) and bring it to legal with the specific question: does this fall under EU AI Act Article 6 and Annex III category 4 (employment, workers management)? If it does, Victor needs to implement the high-risk system requirements or redesign the tool to fall outside the regulated use case. Victor should also treat this as a learning moment for the team - the boundary between "productivity tool" and "AI employment system" is not obvious, and having a clear internal review process for new AI tools prevents similar situations in the future.

What Victor should do - role-specific action plan