AI Governance & Compliance: EU AI Act, US Frameworks

When I started briefing executives on AI regulation three years ago, the conversation was abstract. Today it is operational. The EU AI Act is in force, US frameworks are landing in contracts and tenders, and state laws like the Colorado AI Act and New York City’s bias audit rule are reshaping how AI systems must be built and documented. The question on every architect’s desk is no longer “is this regulated?” but “how do we build for it?”.

In this article I want to walk through the AI governance and compliance landscape as I now see it from the architect’s chair. I will cover the EU AI Act risk tiers and obligations that become effective in 2026, the US frameworks including NIST AI RMF and the recent executive orders, state-level laws, the intersection with GDPR, sector-specific requirements in healthcare and financial services, and the practical patterns I use to implement compliance and prepare for audit.

If you are responsible for AI architecture in 2026, regulation is no longer a back-office concern. It is a design constraint that shapes which models you can use, what evidence you must produce and how you must respond when something goes wrong.

The regulatory landscape now has three overlapping layers. The first is horizontal AI regulation that applies across sectors, led by the EU AI Act. The second is sector-specific regulation that applies in particular industries like healthcare and finance. The third is general purpose laws like GDPR, anti-discrimination law and consumer protection law that have new force when applied to AI systems.

The interactions between these layers are not always tidy. A bank deploying a customer-facing AI assistant in Europe is subject to the EU AI Act, GDPR, banking regulation, anti-discrimination law and the obligations of its prudential regulator. The architect’s job is to map the system to all of them.

There is also a temporal dimension. Many obligations phase in over several years. The EU AI Act, for example, has obligations effective at six months, twelve months, twenty-four months and thirty-six months after entry into force. Architects need a roadmap, not a one-time review.

Compliance in 2026 is not a state. It is a discipline. The regulations move, the systems move, the evidence must keep up.

The good news is that the underlying principles converge. Risk-based governance, human oversight, transparency, evaluation, monitoring and incident response appear in every framework. An architecture that does these things well is broadly compliant before any specific framework is applied.

The EU AI Act is the most consequential AI law in the world. It applies to providers and deployers of AI systems that are placed on the market or used in the EU, regardless of where the provider is established. That extraterritorial reach makes it relevant for almost any large enterprise.

The Act uses a risk-based approach with four tiers.
 

The Act entered into force in August 2024. Key obligations phase in:

• Prohibited practices from February 2025
• General-purpose AI obligations from August 2025
• High-risk obligations from August 2026 for most use cases
• High-risk obligations for embedded systems by August 2027

For most enterprise architects, the 2026 date is the critical one. That is when the bulk of the high-risk obligations apply, including conformity assessment, post-market monitoring and incident reporting. Programmes that started preparation in 2024 are now operationalising controls. Programmes that have not started are in a difficult position.

High-risk systems carry a long list of obligations. For an architect, the relevant ones include:

• Risk management system covering the full lifecycle
• Data governance, including representativeness and bias mitigation
• Technical documentation that an authority could review
• Record-keeping and logging
• Transparency to users about AI use
• Human oversight, including the ability to intervene and override
• Accuracy, robustness and cybersecurity
• Quality management system covering the organisation
• Post-market monitoring, including drift and incident detection
• Serious incident reporting to authorities
• Conformity assessment before placing on the market

Each of these maps to architectural components I have already described in other articles. The risk management system aligns with NIST AI RMF. The data governance aligns with model governance. The post-market monitoring aligns with drift detection. The human oversight aligns with the secure deployment patterns.

The conformity assessment is the new element for many enterprises. For some high-risk systems, the assessment is internal. For others, it requires a notified body. Architects need to know which path applies to their system and design the evidence base accordingly.

The penalties are significant. Up to seven percent of global turnover for the most serious violations. The Act treats AI compliance with the same seriousness as GDPR, and enforcement is expected to follow a similar trajectory.

If you are building a system that touches recruitment, credit, education, critical infrastructure, biometrics or law enforcement, assume it is high-risk and design accordingly.

The Act also imposes obligations on providers of general-purpose AI models, the foundation models that underlie much of the modern AI stack. These obligations apply primarily to model providers, but they cascade through to deployers who need to choose compliant providers.

The obligations include:

• Technical documentation of the model
• Information for downstream providers
• Summary of training content
• Compliance with EU copyright law

For models with systemic risk, additional obligations on evaluation, adversarial testing, incident reporting and cybersecurity
For architects, the practical implication is that vendor selection now includes a compliance check. Does the vendor provide the required documentation? Do they classify their model as systemic risk? Do they have a clear approach to copyright in training data?

The leading vendors are responding to these requirements. Documentation packages are being published, model cards are becoming more detailed and contractual terms are evolving. Architects should expect to see compliance documentation as part of vendor due diligence.

For organisations that fine-tune open-source models, there is a question of whether the fine-tuning makes the organisation a provider of a general-purpose model. The legal interpretation is still evolving, but the cautious approach is to maintain the same documentation discipline as if you were a provider.

The general-purpose obligations also include voluntary codes of practice that some vendors are signing. Adoption of a code of practice can simplify compliance and signal commitment, and is worth tracking when selecting vendors.

The NIST AI Risk Management Framework, published in early 2023, has become the de facto reference for AI governance in the US. It is voluntary, but it is increasingly cited in contracts, tenders and sector guidance.

The framework has four core functions: Govern, Map, Measure and Manage. Each function has categories and subcategories that describe specific outcomes. The framework also defines seven characteristics of trustworthy AI: valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed.

For architects, the framework is most useful as a checklist for system design. Every system should have a documented position on each characteristic, with evidence behind it.

The Generative AI Profile, released by NIST in 2024, extends the framework with specific guidance for generative AI risks. It covers risks like confabulation, dangerous content, environmental impact, intellectual property and information integrity. Architects working with generative AI should use the profile alongside the core framework.

The NIST framework is also the basis of much US federal AI procurement. Federal agencies are required to assess and manage AI risk using NIST-aligned approaches. Vendors selling to the federal government should expect NIST-based questions in their security and risk reviews.

State and sector regulators are also adopting NIST as a reference. The convergence simplifies compliance for organisations that adopt the framework as their baseline.

The US federal landscape is fragmented but increasingly active. Executive Order 14110, issued in October 2023, set out a wide-ranging federal AI agenda covering safety, security, equity and innovation. While its status has shifted with administration changes, many of its operational impacts persist.

Key federal initiatives that affect architects include:

• NIST work on AI safety, including the AI Safety Institute
• OMB guidance for federal agencies on AI use and procurement
• FTC enforcement on AI claims, bias and consumer protection
• EEOC guidance on AI in employment decisions
• HHS guidance on AI in healthcare
• Treasury and CFPB activity on AI in financial services
• DHS work on AI in critical infrastructure

The trajectory is more sectoral and enforcement-driven than horizontal. Architects should track the regulators relevant to their sector and use case rather than waiting for a single horizontal law.

The federal procurement angle is significant. Selling AI to the federal government, or to suppliers who sell to the federal government, increasingly requires NIST-aligned documentation, model cards, evaluation evidence and incident reporting. The procurement floor is becoming a de facto compliance floor for many organisations.

The lack of a single federal AI law means that compliance in the US is built from multiple sources. The architect’s job is to map them, prioritise based on applicability and risk, and design once rather than for each separately.

State-level laws are where some of the most concrete obligations are landing. Architects need to track them because they apply based on where users are, not just where the organisation is.

The Colorado AI Act, effective in 2026, applies to high-risk AI systems that make consequential decisions affecting consumers. It imposes obligations on both developers and deployers, including impact assessments, risk management programmes, consumer notice and the right to appeal. It is the closest US analogue to the EU AI Act’s high-risk regime.

New York City Local Law 144 has been in force since 2023 and requires bias audits of automated employment decision tools. Employers using such tools must commission an annual independent audit and publish the results. The law has shaped how employment AI vendors document and evaluate their systems.

California has multiple laws affecting AI, including AB 2013 on training data transparency, SB 942 on AI disclosure for content and various proposals on automated decision-making. The trajectory is toward stronger consumer rights and transparency obligations.

Other states have enacted or are considering laws on AI in insurance, employment, criminal justice and consumer protection. Texas, Illinois, Utah and others have specific provisions worth tracking.

For architects, the practical implication is that an AI system deployed nationally must comply with the strictest applicable state law. This often means designing to a higher floor than any single jurisdiction requires, and documenting the system in a way that supports state-level disclosures and audits.

GDPR is a decade old but it is increasingly the live regulator of AI in Europe, alongside the AI Act. The intersection has several pressure points that architects need to understand.

Article 22 restricts solely automated decision-making with legal or significant effects. AI systems that make consequential decisions without meaningful human review can trigger this restriction. Architects should design human-in-the-loop steps that are real, not nominal.

The data minimisation principle constrains training and inference data. An AI system that collects more personal data than necessary, or retains it longer than necessary, breaches GDPR. Architects should design for minimal collection, short retention and tight purpose limitation.

The right to information, access and erasure applies to AI systems that process personal data. Implementing erasure is particularly hard for fine-tuned models. The DPAs have started to indicate that fine-tuning on personal data without a clear lawful basis and without erasure capability is problematic.

Cross-border transfer rules apply to vendor models hosted outside the EU. The Schrems decisions and the EU-US Data Privacy Framework have shaped how vendor model use is structured. Architects should expect to see data residency and processing location as a critical vendor selection criterion.

GDPR is the regulator that has the most enforcement history and the strongest fines. Until the AI Act has its first major enforcement, GDPR remains the more immediate risk for most AI deployments.

The interaction with the AI Act creates duplication but also clarity. The AI Act is the substantive AI risk framework. GDPR is the personal data protection framework. Architects need both for a complete view.

Healthcare AI is one of the most heavily regulated domains. Architects working in this space need to understand both the AI-specific rules and the underlying healthcare regulations.

In the US, the FDA regulates AI as a medical device when it meets the device definition. The FDA has issued guidance on software as a medical device, AI and machine learning, and good machine learning practice. The pre-determined change control plan concept allows certain model updates without new submissions, but the framework is strict.

HIPAA continues to apply to AI systems that process protected health information. Business associate agreements with vendors are required, and the security rule applies to the AI infrastructure. The minimum necessary principle constrains what data can flow into AI systems.

The HHS Section 1557 rule on non-discrimination applies to AI used in healthcare, including bias testing and mitigation obligations. The interplay between Section 1557 and state laws creates a complex compliance map.

In the EU, the AI Act treats certain healthcare AI as high-risk, with obligations on top of the existing Medical Device Regulation. Conformity assessment becomes a layered exercise.

For architects, the practical implications are significant. Clinical AI requires evidence standards that are closer to pharmaceutical development than software. Documentation, traceability and post-market monitoring are not optional. Vendor selection has to consider the regulatory posture of the vendor’s models.

Healthcare programmes often need a dedicated regulatory function that works alongside the architecture function. The pace of regulatory change is fast enough that this function is a critical investment.

Financial services has the longest history of model regulation through the SR 11-7 model risk management framework in the US and equivalent guidance globally. AI sits inside this existing framework but with new requirements.

Key regulators and their AI focus:

• OCC, Fed and FDIC for banking, applying SR 11-7 to AI models
• CFPB for consumer financial services, focused on bias and explainability
• FINRA and SEC for securities, focused on supervision of AI-assisted decisions
• State insurance regulators, focused on bias and consumer protection
• Treasury and FinCEN for AI in financial crime

The model risk framework requires identification, validation, monitoring and governance of every model. AI extends this with documentation of training data, evaluation across protected classes, explainability for adverse decisions and ongoing monitoring for drift.

Consumer protection laws like the Equal Credit Opportunity Act and the Fair Credit Reporting Act impose additional obligations on AI used in credit decisions. Adverse action notices must be specific and meaningful, which is technically demanding for complex models.

In the UK and EU, the FCA, PRA, EBA and EIOPA have issued guidance on AI in financial services. The AI Act overlays this with high-risk obligations for credit scoring and certain insurance use cases.

For architects, the implication is that AI in financial services must satisfy three layers: the model risk framework, the consumer protection laws and the AI-specific regulation. The documentation burden is high. The benefit is that mature model risk functions in banks are usually well placed to extend to AI, if the engineering function engages with them early.

How do architects actually implement all of this? I use a small set of patterns that recur across compliance regimes.

Pattern 1: Risk-tier the use case. Every new use case gets a risk classification based on EU AI Act tiers, NIST risk levels and sector-specific factors. The classification drives the level of governance and the evidence required.

Pattern 2: Build the evidence base from day one. Model cards, data sheets, evaluation reports, decision logs and incident logs are produced as the system is built, not retrofitted before audit. Use templates and automation to lower the cost.

Pattern 3: Make controls code-enforceable. Where possible, encode controls as CI checks, runtime guardrails or platform features. A policy in a document is a policy that gets ignored. A policy in a CI gate is a policy that gets followed.

Pattern 4: Centralise the registry, federate the implementation. A single source of truth for every AI artefact, with implementation owned by the business units. The registry is the artefact regulators will ask for first.

Pattern 5: Design for human oversight by default. Every high-impact decision has a documented human review point. Document the actual oversight, not the theoretical one.

Pattern 6: Build in monitoring and incident response from launch. Drift detection, evaluation regression, abuse monitoring and incident playbooks are launch requirements, not future enhancements.

Pattern 7: Plan for retirement. Every model has a planned retirement path, including data deletion, registry archiving and notification of users where required.

These patterns work because they convert compliance from paperwork into engineering. Architects who get them right deliver compliant systems as a natural by-product of good engineering, not as a separate workstream.

The documentation an audit will ask for falls into a small number of categories. I build these into the standard delivery pattern for every AI system.

The system documentation includes:

• Use case description and intended use boundary
• Architecture diagram and component inventory
• Risk classification under each applicable framework
• Risk management plan and residual risk acceptance

The model documentation includes:

• Model card for each model in use, including vendor models
• Data sheet for each dataset used for training or fine-tuning
• Evaluation reports including fairness and safety
• Lineage from data to model to deployment

The operational documentation includes:

• Monitoring plan including drift and incident detection
• Incident response runbook and recent incident logs
• Change history including model and prompt versions
• Human oversight design and review records

The compliance documentation includes:

• Mapping to applicable frameworks (EU AI Act, NIST, sector rules)
• Vendor risk assessments and contracts
• Privacy impact assessment where personal data is involved
• Conformity assessment records for high-risk systems

The documentation that does not exist when the auditor asks is the documentation that does not exist. Build it as you go.

I store all of this in the same governance platform as the model registry, so that the evidence is queryable and exportable. When an audit comes, the answer to most questions is a search rather than an investigation.

Audit preparation has shifted from a periodic project to a continuous discipline. The systems that audit well are the systems that are designed to be auditable from day one.

I structure audit preparation around three layers.

The first layer is the architecture, where controls are designed into the system. The registry, the evaluation pipeline, the monitoring stack and the incident response process are all set up so that an auditor can trace any decision or action.

The second layer is the operational discipline, where the controls actually run. Approvals happen. Evaluations run on schedule. Incidents are logged. Reviews take place. The evidence is generated as a natural by-product of normal operation.

The third layer is the periodic assurance, where internal audit or external assessors test that the controls work as designed. Findings feed back into the architecture and operational layers.

For external assurance, the trend is toward independent third-party assessments. ISO/IEC 42001 certification is gaining traction. Some sector regulators are requiring or recommending external validation. Vendors are increasingly asked for SOC 2-style reports for their AI systems.

The cultural ingredient that matters is treating audit as a learning function, not a defensive one. Auditors who find weaknesses are doing the organisation a favour. The architecture should welcome that feedback and improve, rather than dressing up evidence to pass.

For organisations operating across jurisdictions, compliance becomes a portfolio problem. The operating model has to handle multiple frameworks without creating proliferating workstreams.

I use a hub-and-spoke model. A central AI governance function owns the policy, standards, registry, evaluation pipeline and tooling. Business units own implementation, with the central function providing reference architectures, libraries and review.

Within the central function, jurisdiction specialists track the regulatory landscape and translate it into policy updates. When the EU AI Act phases in a new obligation, the relevant specialist updates the policy, the standards and the platform controls. Business units inherit the updates automatically.

The hub-and-spoke model is also how I handle sector-specific overlays. A bank doing credit decisioning needs to satisfy both general AI governance and credit-specific rules. The sector specialist provides the overlay, business units inherit it.

Cross-jurisdictional coordination is essential. A change in one jurisdiction often has implications elsewhere. The central function tracks the dependencies and ensures that changes are propagated consistently.

For organisations that are new to this, the temptation is to start with one jurisdiction and expand. That usually creates rework. The better path is to design to the highest applicable standard, even if it means doing slightly more than the minimum in some jurisdictions. The cost is lower than retrofitting later.