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. 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.

• Enforcement timelines are real, but the dates moved in June 2026 - prohibited systems were banned in February 2025 and general-purpose AI (GPAI) model obligations began in August 2025, but the GPAI enforcement powers themselves begin August 2, 2026. The high-risk (Annex III) deadlines are now in flux: a Digital Omnibus provisional agreement reached June 16, 2026 would push high-risk obligations to December 2, 2027. That deal is not yet final law - plan against the original timeline and treat the delay as upside, not a reason to pause compliance work
• 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

1. 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.
2. 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?
3. 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.
4. Review vendor obligations and pin your inference region - 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. Add data-residency routing to your AI gateway so inference runs in EU regions (Bedrock, Vertex, or Foundry EU regions) where required - this overlaps directly with GDPR data-residency and with the vendor-sovereignty controls covered in the policy-as-code guide.
5. 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.
6. 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.

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.