AI Compliance Requirements Under EU AI Act and US Executive Orders

Two regulatory regimes now bind enterprise AI use, and they do not agree on method. The EU AI Act imposes documented, affirmative obligations on anyone who builds or deploys AI systems touching EU residents. US executive orders, by contrast, mostly direct federal agencies, so private-sector enforcement is left to a growing patchwork of state law. Security teams asking "how do we find the AI tools employees are already using without approval" are really asking a compliance question in disguise: you cannot produce the audit logs, access records, or oversight evidence either regime demands for a tool you don't know exists. That is the throughline of what follows.

What the EU AI Act and US executive orders require of enterprises

The EU AI Act is the world's first comprehensive horizontal law governing artificial intelligence, in force since August 2024 and rolling out in phases tied to risk tier. It does not treat AI as a single category of thing to regulate once. It sorts systems by the harm they could cause and attaches obligations to that sorting, with enforcement dates spread across multiple years tied to risk tier.

The US picture runs on a different logic: federal action stops short of a comprehensive statute, leaving states to fill the gap. Trump's Executive Order 14179, "Removing Barriers to American Leadership in Artificial Intelligence," signed January 20, 2025, revoked the prior administration's Executive Order 14110 in full. No comprehensive federal AI statute has replaced it. The most recent executive action, signed June 2, 2026, and titled "Promoting Advanced Artificial Intelligence Innovation and Security," directed federal agencies to harden their own systems against AI-enabled threats on 30- and 60-day timelines, set up a voluntary framework for pre-release federal access to covered frontier models, and told prosecutors to prioritize criminal enforcement against AI-enabled cyberattacks. But it stops short of creating mandatory licensing, preclearance, or permitting requirements for AI models. That gap gets filled by states: various state statutes each impose their own obligations, independent of whatever happens at the federal level.

The structural difference matters more than the headline comparison suggests. The EU AI Act puts affirmative, documented compliance duties on both the companies that build AI systems and the companies that use them. US executive orders mostly bind federal agencies or offer voluntary frameworks to private industry, so the binding obligations on private enterprises come from state legislatures, not federal policymakers. Treating a voluntary federal framework as a substitute for EU-style documentation requirements, or assuming that the absence of a federal AI statute means no exposure, both produce the same outcome: a compliance gap nobody budgeted for.

Which enterprises are in scope and for which obligations

Most large enterprises are already in scope for binding AI obligations, regardless of headquarters location, because of how far the EU AI Act's reach extends and how many US states have filled the federal vacuum with their own statutes.

The Act's extraterritorial logic mirrors GDPR almost exactly: if an AI system is used within the EU, or produces outputs that affect EU residents, the organization behind it must comply, no matter where the model runs or where the company is incorporated. A US bank running AI-driven loan approvals for European customers is in scope even if every server sits on domestic soil. A non-EU vendor whose AI system gets deployed by EU law enforcement is in scope even without a single European office.

Scope under the Act runs by function, not by company size or industry label. Providers, the organizations that develop AI systems or direct their development and place them on the EU market under their own name, carry the full weight of Articles 8 through 17: technical documentation, risk management, and lifecycle obligations. Deployers, the organizations that use those systems in a professional setting, carry separate duties under Article 26, including human oversight, monitoring, and incident reporting. A deployer cannot point to its vendor's compliance paperwork and call the matter closed. Cloud platforms that actively make third-party AI systems accessible to EU deployers can also qualify as importers or distributors. Many enterprises occupy more than one role at once, acting as a deployer of a vendor's model in one business unit while serving as a provider of an internally built tool licensed out to clients in another.

The US state layer adds its own triggers. Colorado, Texas, California, Utah, and Illinois each define jurisdiction differently, and an enterprise with employees or customers in any of those states cannot treat federal inaction as a green light. You need more than legal analysis of statute text to determine which obligations apply. It requires a governance layer capable of applying different rules to different teams and jurisdictions at once, because the same AI deployment might be a "provider" system in one market and a "deployer" system in another. Speakeasy's enterprise AI control plane is built around that problem: it provides the access control and policy enforcement infrastructure to apply EU, US state, and internal compliance rules consistently, regardless of where the AI system runs or which team stood it up.

The practical starting point for any compliance program is a role determination for every AI system in active use, not a risk-tier label slapped on after the fact, because documentation and control requirements track role first and risk second. Mapping those roles at scale, and enforcing the obligations attached to each one, is itself an infrastructure problem. Speakeasy helps organizations inventory their AI deployments, classify them by functional role, and apply role-specific access policies across teams, turning the mapping exercise into an enforceable system.

What the high-risk AI obligations demand operationally

The high-risk tier of the EU AI Act does not ask for a compliance binder. It requires working systems: risk management processes, data governance controls, automatic logging, human oversight mechanisms, and cybersecurity safeguards that run for as long as the AI system is in use, not just at launch.

Providers of high-risk systems face obligations under Articles 8 through 15 that start before the product ever reaches a customer. Training, validation, and testing data have to meet defined quality criteria, with bias evaluation built in. Technical documentation under Article 11 has to exist before the system goes to market and stay current afterward, not get drafted retroactively when an auditor asks. Article 12 requires the system itself to generate logs automatically, and Article 26(6) requires deployers to store those logs securely for a minimum of six months, unless other Union or national law, particularly data protection law, sets a different term.

Deployers carry a parallel set of duties under Article 26: human oversight, ongoing monitoring, incident reporting, and strict adherence to the provider's intended use case. Repurpose a system beyond what the provider specified, and the deployer's liability increases accordingly. Transparency rules under Article 50, already in force as of August 2, 2026, require disclosure whenever a user interacts with AI, labeling of AI-generated content, and notice when someone is subject to emotion recognition or biometric categorization.

The penalties scale with the violation. Prohibited practices carry fines up to €35 million or 7% of global annual turnover, whichever is higher. Non-compliance with high-risk obligations tops out at €15 million or 3% of turnover. Feeding incorrect information to regulators brings fines up to €7.5 million or 1.5% of turnover. None of those figures scale down for a smaller company, and the reputational damage from a public enforcement finding doesn't scale down either.

On the US side, the compliance demands sit mostly with federal agencies and contractors: the 30- and 60-day hardening timelines from the June 2026 order, the voluntary pre-release access framework for frontier models, and the stated priority on criminal enforcement for AI-enabled cyberattacks.

Among the high-risk obligations, the logging requirement is what a compliance program must get right for the rest to work in practice. Automatic, secure, long-retention audit logs are already a live obligation for deployers right now, and they are the single requirement that dictates what any governance system actually has to build.

Shadow AI as unmeasured compliance exposure

The question security teams ask most often, how to find out which AI tools employees are using without IT's blessing, is the practical front line of EU and US compliance exposure, not a side concern. A deliberately deployed high-risk system is at least visible to the compliance team. The AI tools employees adopt on their own, Cursor, Claude, consumer ChatGPT, assorted browser extensions, are not, and that invisibility is precisely what makes Article 26(6) logging obligations impossible to satisfy.

Sensitive AI interactions routed through personal email accounts sit entirely outside enterprise logging and data-loss-prevention reach. A significant share of this traffic never touches a system IT controls. IT cannot produce logs for a system it does not control. The compliance math is blunt: if a high-risk AI system, or any system that falls under GDPR or a sector rule like HIPAA, is running without IT's knowledge, the enterprise cannot produce the logs Article 26(6) requires, cannot demonstrate the human oversight Article 26 requires, and cannot satisfy Article 11's documentation requirements. The enforcement exposure exists whether or not anyone in the compliance department knows the tool is there.

Agentic architectures make the problem worse, not smaller. An AI agent calling internal APIs, querying a database, or triggering an action inside a SaaS platform can run entirely outside the security team's field of view, and yet the tool calls and data access that agent performs are what audit logs are supposed to capture. The parallel to shadow IT is direct: enterprises already built policy enforcement, access controls, and visibility tooling to deal with unsanctioned SaaS adoption a decade ago. Most have not built the equivalent layer for AI yet, which leaves agentic tool use as the biggest blind spot in most compliance programs today.

There is a reliable fix on the supply side. Enterprises that roll out an approved, enterprise-grade AI alternative see unauthorized tool use drop sharply, which tells you that banning shadow AI outright works less well than giving employees a sanctioned option that does the same job under logging and access control. Prohibition without an alternative just pushes the behavior further from view.

How prompt injection becomes a compliance event

In a regulated environment, a successful prompt injection attack is a compliance trigger as much as a security problem, one that can force GDPR breach notification, HIPAA reporting, or a SOX audit finding, whether or not any human being intended for the unauthorized access to happen.

The mechanism works as follows. An injected instruction causes an AI agent to reach data or systems outside its authorized scope. That unauthorized access meets the legal definition of a breach under several frameworks at once, and the agent's lack of "intent" carries no legal weight in that determination. The model did what it was told, by an attacker it had no way to distinguish from a legitimate user.

That reality drives the design constraint that matters most here: only access controls enforced at the data layer, independent of the model itself, can stop an injected instruction from turning into a compliance event. Model-level defenses, prompt filtering, output screening, and the like, are not sufficient on their own, because the model itself is the attack surface being manipulated. The practical response is the least-privilege agent pattern: give each agent only the permissions its specific task requires, so a successful injection still can't reach anything beyond that narrow scope.

Real-time content inspection has to live in the governance layer surrounding the model, not inside the model and not as a post-hoc review weeks later. A violation pattern can emerge across several turns of a conversation that looks harmless turn by turn, so per-request review alone misses it. Catching that pattern requires something watching the whole session, not just the individual request.

The governance infrastructure that makes satisfying both frameworks tractable

Audit logging, access control, real-time threat detection, and observability sit at the intersection of EU AI Act deployer obligations, US executive order requirements, and basic agentic security. These are not four separate projects that can be staffed and shipped independently. They have to operate as one governed layer, because a gap in any single one defeats the regulatory test for all of them.

Article 26(6) sets a floor of six months for retaining automatically generated logs, to the extent those logs are under the deployer's control, and sector rules in healthcare, financial services, and public companies often require longer. A log that only records that an AI call happened is not enough. It needs to capture what was requested, what data got touched, what action followed, and which identity initiated it. That requires granularity at the agent level, the tool level, and the individual action level. Agentic systems add signal types that traditional application logs were never built to capture: intermediate reasoning steps, which tool an agent chose and why, and handoffs between agents working the same task.

Access control has to follow the same granularity. Role-based access control needs to operate at the action level inside each AI tool or MCP server, not at the level of the tool or toolkit as a whole. A governance model that can only permit or block an entire GitHub integration cannot satisfy a least-privilege requirement, because it has no way to express the distinction that actually matters. A junior developer role, for instance, might reasonably call GITHUB_CREATE_PR and GITHUB_MERGE_PR while being blocked from GITHUB_DELETE_REPO. Blocking the whole toolkit to avoid that one dangerous action isn't a compliant substitute, it's just a less useful version of the same exposure.

High-risk obligations under the EU AI Act require monitoring and oversight that catch failures as they happen, not in a quarterly review. Speakeasy's observability layer is one example of infrastructure built for that requirement: it surfaces AI usage, access, and incident events across an organization, producing the continuous audit trail that high-risk governance calls for and running continuously in the background, whether or not anyone remembers to check it.