- The Act is extraterritorial: it reaches US providers and deployers whose systems are placed on the EU market or whose outputs are used in the EU, regardless of where the company sits.
- It is risk-tiered: a short list of prohibited practices, heavy obligations for high-risk use cases like employment and credit, transparency duties for AI interaction and synthetic media, minimal risk left alone.
- Most high-risk obligations map onto controls a NIST AI RMF-aligned program already runs; build one governance stack and map it twice, then budget separately for the genuinely new pieces like conformity assessment.
Why a US company should care
The EU AI Act is the first comprehensive horizontal AI law from a major market, and its jurisdictional trigger is not where your company is incorporated. The Act reaches providers and deployers that place AI systems on the EU market, and it also reaches systems whose outputs are used in the EU, wherever the operator sits. A US company with no European entity, no European data center, and no European sales team can still be in scope if a hiring model it runs from Ohio scores candidates in Frankfurt, or if a SaaS product it ships is adopted by customers in Madrid. That output-based hook is the part American teams most consistently underestimate.
If this rhymes with GDPR, that is not an accident. The same Brussels-effect dynamic applies: when the cost of maintaining a separate EU-only variant of a product exceeds the cost of meeting the stricter standard everywhere, multinationals quietly adopt the EU bar as the global bar. Expect a second-order version of the effect too. Even where the formal obligation falls on your EU customer as deployer, that customer will push Act-shaped documentation and assurance demands upstream into your contracts. US vendors will feel the Act through procurement long before any regulator calls.
This article is deliberately a US lens, not an EU compliance manual. The questions it answers are the ones a US CTO actually asks: when does this reach me, which of my systems does it touch, what does the heavy tier really demand, and how much of the governance work my teams already did under NIST-aligned programs can I reuse. For the domestic regulatory picture that work grew out of, see the US AI governance deep-dive. Nothing here is legal advice; it is an architect's orientation.
The risk pyramid
The Act's core design decision is that obligations scale with risk, not with technology. It does not regulate transformers or gradient descent; it regulates what a system is used for. Four tiers result, and almost every scoping conversation comes down to placing a use case on this pyramid.
/\
/ \
/BAN \ PROHIBITED: social scoring,
/______\ certain manipulative uses
/ \
/HIGH-RISK \ Annex use cases: hiring,
/____________\ credit, and similar. Heavy.
/ \
/ TRANSPARENCY \ Disclose AI interaction,
/__________________\ label synthetic media
/ \
/ MINIMAL RISK \ Largely unregulated
/________________________\
At the apex sit prohibited practices: uses the EU considers incompatible with fundamental rights, such as social scoring and certain manipulative or exploitative techniques. These are banned outright, and no enterprise roadmap should be anywhere near them. Below that sits the tier that generates nearly all the real compliance work: high-risk systems, defined largely by annexed use-case lists covering areas like employment decisions, creditworthiness, education, essential services, and safety components of regulated products. If your system materially influences one of those decisions about people in the EU, assume the heavy tier until counsel says otherwise.
The transparency tier is lighter but broad: tell people when they are interacting with an AI system, and label synthetic media and deepfakes as machine-generated. Everything else, which in practice is the bulk of an enterprise estate, lands in minimal risk and is largely unregulated. The strategic consequence is that classification, not remediation, is the first battle: an accurate inventory that places each use case on the pyramid does most of the work, because the bottom tier costs you nothing.
What high-risk actually demands
The high-risk tier reads intimidating in the original, but to anyone who has run model risk discipline in a US bank, the substance is strikingly familiar. The Act asks for a risk management system operated across the lifecycle, data governance over training and evaluation data, technical documentation, automatic logging, human oversight designed into the system, accuracy and robustness requirements, and a conformity assessment before the system reaches the market. Renamed, that is a model risk management program with a pre-market gate bolted on.
| Act obligation | The control you likely already run |
|---|---|
| Risk management system | Model risk lifecycle: tiering, validation, periodic review |
| Data governance | Data quality, lineage, and bias testing on training data |
| Technical documentation | Model documentation, model cards, design records |
| Logging | Audit trails and inference-time observability |
| Human oversight | Human-in-the-loop review and override paths |
| Accuracy and robustness | Evaluation suites, drift monitoring, adversarial testing |
| Conformity assessment | Closest analog: validation and sign-off, formalized as a market gate |
Two honest caveats. First, familiarity is not equivalence: the Act expects these controls documented in its shape, evidenced continuously, and in some cases assessed against harmonized standards, which is more prescriptive than most internal model risk policies. Second, conformity assessment has no true US analog. It is a pre-market conformity exercise, in many cases performable as a self-assessment against standards, in others involving a third-party body. Treat it as a new gate in your release process, not a document to backfill. The underlying engineering controls, though, are the same ones described in the model risk deep-dive, which is exactly why reuse is the right strategy.
General-purpose models and the phased timeline
The Act also regulates general-purpose AI models directly, a layer added late in the negotiations once foundation models made the original use-case framing look incomplete. GPAI providers carry transparency obligations: technical documentation, information for downstream integrators, and disclosures around training content. Models designated as posing systemic risk carry stronger duties, including model evaluation, adversarial testing, and incident reporting. For most US enterprises the practical consequence is indirect: you consume GPAI rather than provide it, so your leverage point is demanding that documentation from your model vendors and keeping it on file. If you fine-tune or substantially modify a model and place the result on the EU market, your role can shift toward provider, which is a classification question worth escalating to counsel early.
Timing matters because the Act arrives in stages rather than all at once. It entered into force in 2024, with obligations phasing in over the following years: prohibitions first, GPAI duties next, and most high-risk requirements later, on a schedule running through roughly 2025 to 2027, with some categories later still. As of mid-2026 several tranches are already live and others are approaching, while guidance and standards work continue to move underneath them. Treat every date you have heard as approximate and check current status before committing a compliance plan to it.
The US enterprise playbook
The uncomfortable secret of AI Act readiness is that most of the work is not compliance engineering at all. It is discovery. The majority of effort in a typical US program goes into finding out which systems are in scope in the first place, because AI estates grow through acquisitions, shadow deployments, and vendor features that quietly turned themselves on. A four-step sequence covers the ground.
- Map exposure. For every AI-backed system, ask one question: do its outputs reach people or decisions in the EU? Include the indirect paths: EU employees scored by US HR tools, EU end users of a global product, EU customers consuming your API. Systems with no EU output path exit the analysis here, and many will.
- Classify against the pyramid. Place each in-scope use case on a tier. Be strict about the high-risk annex categories: employment, credit, education, essential services. Ambiguous cases get a documented rationale, not a shrug.
- Assign ownership. Decide, per system, whether you act as provider or deployer, and name an accountable owner for each obligation set. That distinction drives most of what you owe, and it is easy to get wrong when you fine-tune or white-label.
- Close the documentation gap. Compare what the heavy tier demands against what your governance program already produces, and fill the deltas: usually conformity-shaped documentation, EU-specific registration steps, and evidence packaging rather than net-new engineering controls.
Run steps one and two now even if your EU exposure looks negligible, because the inventory itself is reusable. It is the same asset your responsible AI program needs anyway, and building it once under a planning horizon is far cheaper than rebuilding it under an enforcement letter.
Reuse your NIST work, do not rebuild
The single most expensive mistake a US enterprise can make here is standing up a second governance stack for Europe. The overlap between the Act's high-risk obligations and a NIST AI RMF-aligned program is substantial and structural, not cosmetic: both are anchored in lifecycle risk management, documented system context, measurement and monitoring, and meaningful human oversight. If your organization has operationalized the RMF's govern, map, measure, and manage functions, you have already built most of the machinery the Act inspects. The correct architecture is build once, map twice: one set of controls, one evidence pipeline, and two thin mapping layers that express the same artifacts in NIST vocabulary for US stakeholders and in Act vocabulary for EU market access.
Concretely, that means your model inventory grows EU-relevant fields such as risk tier, provider-or-deployer role, and output geography; your model documentation template grows the sections the Act's technical documentation expects; your monitoring stack retains logs in a form that satisfies record-keeping duties; and your existing oversight and override designs are described in the Act's terms. None of this requires new platforms. It requires a crosswalk, an owner, and discipline about keeping one canonical source of truth per control.
The architect view
Strip away the treaty language and the Act is best understood as a market-access requirement, the same category of thing as a safety certification on hardware: if you want your system's outputs used in the EU, this is the gate fee. That framing settles the architecture question. Market-access requirements do not deserve a bespoke organization; they deserve a lane in the governance platform you already run, with the Act as one more obligation set mapped onto one canonical control library, one inventory, and one evidence pipeline.
The part that fails in practice is not the initial mapping but the maintenance. Classification is a snapshot of a moving estate: a minimal-risk chatbot becomes a transparency-tier system when it starts generating customer-facing media, and a deployer becomes something closer to a provider when a team fine-tunes a vendor model and ships it. Wire classification review into change management, at the same trigger points where security review already lives, so that tier assignments age with the systems they describe rather than with the annual audit calendar.
Finally, hold the line on what this article is. The engineering and governance substance of the Act is stable enough to plan against; the legal specifics, the dates, thresholds, designations, and their interpretation, are live and jurisdiction-dependent, and they belong with counsel who track them professionally. The architect's job is to make sure that when counsel says which systems must comply, the platform can answer with evidence in days rather than quarters. If you want to feel the classification mechanics rather than read about them, the governance sandbox in the Lab is the place to push buttons. Orientation, not legal advice.