Why this matters even if you're based in the US

The EU AI Act applies to any organization that deploys or provides AI systems used in the European Union — regardless of where that organization is headquartered. If your company has EU customers, EU employees, or AI systems that produce outputs affecting EU residents, the Act applies to you. The extraterritorial reach mirrors the model established by GDPR, and enforcement will follow the same pattern: regulators will pursue organizations with EU market presence first.

The timeline you need to know

The Act entered into force in August 2024. Most obligations follow a phased implementation schedule. Prohibited AI practices — systems that manipulate behavior, exploit vulnerabilities, or conduct unauthorized biometric surveillance — became enforceable in February 2025. High-risk AI system obligations, which affect the broadest range of commercial deployments, become enforceable in August 2026. General-purpose AI model rules, which cover systems like large language models used in commercial products, became effective in August 2025.

What counts as high-risk

The Act classifies AI systems as high-risk based on the domain in which they operate and the potential for harm to fundamental rights. High-risk categories include AI used in hiring and employment decisions, credit scoring and financial services, educational assessment, healthcare diagnosis and treatment, law enforcement, critical infrastructure management, and systems that determine access to essential public services. If your organization uses AI in any of these domains — including third-party AI tools used for these purposes — you are likely subject to high-risk obligations.

This is the classification question your board should be asking right now: which AI systems we currently use or deploy would be classified as high-risk under the Act? Most organizations cannot answer this question because they have not completed an AI system inventory. That gap is itself a compliance risk.

What high-risk providers must do

Organizations that provide high-risk AI systems face the most substantial obligations. They must implement a quality management system covering the AI development lifecycle, conduct conformity assessments before market placement, register systems in the EU AI Act database, prepare technical documentation demonstrating conformity, and establish post-market monitoring processes. Human oversight mechanisms must be embedded in the system design itself — not bolted on afterward.

Organizations that deploy high-risk AI systems developed by others carry a different but still significant set of obligations. Deployers must conduct fundamental rights impact assessments, implement human oversight, maintain usage logs for a minimum of six months, and report serious incidents to national authorities.

The board conversation you need to have

EU AI Act compliance is not an IT project. It is a governance question that requires board-level attention for three reasons. First, the penalties for non-compliance are material: up to €35 million or 7% of global annual turnover for prohibited practice violations, and up to €15 million or 3% for other violations. Second, compliance requires decisions about which AI systems to continue using and which to modify or retire — decisions with significant business implications. Third, the Act's transparency and accountability requirements will be visible to customers, partners, and regulators in ways that affect market position.

Your board should be asking: Which of our AI systems would be classified as high-risk? Have we completed a fundamental rights impact assessment for those systems? Do we have the technical documentation required for conformity assessment? Is our AI governance program capable of supporting ongoing compliance obligations?

Where to start

The most urgent first step is an AI system inventory. You cannot assess your compliance posture without knowing what AI systems your organization uses, who uses them, for what purpose, and whether any qualify as high-risk under the Act's classification framework. This inventory should cover internally developed systems, third-party AI tools, and AI embedded in enterprise software platforms — the last category being the most commonly overlooked.

Once you have an inventory, the next step is a classification assessment against the Act's risk categories. For systems that qualify as high-risk, a gap analysis against the applicable requirements will define your compliance roadmap. Organizations with August 2026 deadlines for high-risk obligations have a narrow window to complete this work.

Clavant conducts EU AI Act readiness assessments specifically designed for US organizations with EU market exposure. If your organization has not yet assessed its EU AI Act posture, that work should begin now.

Two frameworks, two different purposes

ISO 42001 and the NIST AI Risk Management Framework are the two most widely referenced AI governance standards in commercial use today. They are not competitors — they address different organizational needs and operate at different levels of specificity. Understanding the distinction is the first step toward choosing the right foundation for your AI governance program.

ISO 42001 is a management system standard. Like ISO 27001 for information security, it specifies the requirements for establishing, implementing, maintaining, and continually improving an AI Management System (AIMS). It is auditable, certifiable, and designed to produce documented evidence of governance. Organizations that achieve ISO 42001 certification can demonstrate to customers, regulators, and partners that their AI governance meets an internationally recognized standard.

The NIST AI RMF is a voluntary framework. Published by the National Institute of Standards and Technology in January 2023, it provides guidance — not requirements — organized around four functions: Govern, Map, Measure, and Manage. It is designed to be flexible and adaptable to any organization size, sector, or AI use case. There is no certification, no audit, and no pass/fail outcome. It is a structured way of thinking about AI risk.

When ISO 42001 is the right choice

ISO 42001 is the right primary framework when your organization needs to demonstrate AI governance to external parties. If your customers are asking for evidence of AI governance in vendor due diligence, if your sector is likely to face regulatory requirements aligned to international standards, or if you operate in markets where ISO certification carries weight — particularly in Europe, the Middle East, and increasingly in Asia-Pacific — ISO 42001 provides a credible, auditable response.

It is also the right choice if your organization already operates within an ISO management system environment. Organizations with ISO 27001 or ISO 9001 certifications will find the structure of ISO 42001 immediately familiar. The clause structure, annex approach, and audit methodology are consistent across ISO management system standards, which significantly reduces implementation effort.

When NIST AI RMF is the right choice

The NIST AI RMF is the right starting point when your primary audience is US-based and your goal is to build internal AI risk management capability rather than achieve external certification. It is widely referenced by US federal agencies, used in US government procurement requirements, and cited in emerging US state AI legislation. If your organization serves the US federal government or operates in sectors with NIST-aligned regulatory expectations — financial services, healthcare, critical infrastructure — the RMF provides the right vocabulary and structure.

The RMF is also well-suited for organizations in early stages of AI governance maturity. Its flexibility and lack of certification requirements make it a lower-friction starting point than a full ISO 42001 implementation. Many organizations use the RMF to build foundational practices and then layer ISO 42001 requirements on top as their program matures.

The case for using both

The most robust AI governance programs use both frameworks in combination. The NIST AI RMF's GOVERN function maps closely to ISO 42001's leadership and organizational context requirements. The MAP function aligns with ISO 42001's risk assessment and AI system inventory requirements. MEASURE aligns with performance evaluation and monitoring. MANAGE aligns with risk treatment and continual improvement.

Building your program on the NIST AI RMF's conceptual structure while implementing controls that meet ISO 42001's requirements gives you the best of both: a flexible, risk-based approach to AI governance with the option to pursue certification when the time is right.

The practical question for your organization

Start with three questions. First, do your customers, regulators, or partners require or request evidence of AI governance that an ISO 42001 certification would satisfy? Second, does your organization already operate within an ISO management system? Third, is your primary regulatory environment US-centric or international? The answers will point clearly toward one framework as your primary foundation — and toward the other as a complementary reference.

If you are unsure how to answer these questions for your specific context, that uncertainty is itself a signal that an AI governance assessment is the right first step.

The spreadsheet problem

When organizations first attempt to document AI risk, the instinct is to open a spreadsheet. It is familiar, accessible, and requires no new software. A GRC leader or compliance manager builds a tab with columns for system name, risk description, likelihood, impact, and owner. It gets shared in a Teams channel. For six months, nothing happens to it.

This pattern is nearly universal, and it fails for predictable reasons. Spreadsheets have no workflow — a risk identified in column F has no mechanism to trigger a remediation task, escalate to a risk owner, or notify a committee. They have no version control — when someone edits a cell, the previous state is gone unless someone remembered to save a copy. They have no access controls — everyone with the link can edit everything. And they have no audit trail — when a regulator asks who reviewed a risk assessment and when, the spreadsheet cannot answer.

What a defensible AI risk register actually requires

A defensible AI risk register is one that you could present to a regulator, an auditor, or a board member and answer three questions with documented evidence: What AI systems does your organization operate? What risks have you identified for each system? What have you done about those risks, and when?

Meeting this standard requires five structural elements that spreadsheets cannot reliably provide. First, a linked AI system inventory — each risk entry must be traceable to a specific, documented AI system with a defined owner, purpose, and deployment context. Second, a consistent risk taxonomy — likelihood and impact ratings must be applied consistently across all entries using defined scales, not subjective judgment varying by contributor. Third, an audit trail — every change to a risk entry, every status update, every review must be timestamped and attributed to a named individual. Fourth, a workflow — risk treatment tasks must generate assignments, deadlines, and escalation paths. Fifth, a review cadence — the register must document when it was last reviewed, by whom, and what changed.

The ISO 42001 requirement

ISO 42001 requires organizations to identify and assess AI-specific risks as part of their AI Management System. Clause 6.1 requires a documented risk assessment process with defined criteria for risk acceptance. The standard does not prescribe a tool, but it does require that the process be repeatable, documented, and subject to regular review. A spreadsheet maintained inconsistently by one person does not meet this requirement in practice, even if no specific tool is mandated.

What good looks like in practice

Organizations with mature AI risk registers maintain a structured inventory of AI systems that feeds directly into the risk register — every system in scope has corresponding risk entries. Risk owners receive automated reminders when treatments are due or when risks require re-review. The committee reviews a dashboard view of the register at each meeting, with changes since the last review highlighted. When a new AI system is proposed for deployment, a risk assessment is a required step in the approval workflow before deployment is authorized.

This is the Register, Monitor, Intervene mandate in practice. Register: every AI system is documented. Monitor: risks are reviewed on a defined schedule. Intervene: when a risk exceeds the acceptance threshold or a treatment is overdue, the governance structure escalates and acts.

Getting from spreadsheet to defensible register

The transition does not require expensive software. It requires three things: a defined AI system inventory process, a consistent risk taxonomy applied across all entries, and a governance cadence that treats the register as a living document rather than a filing artifact. Many organizations accomplish this in Notion, Airtable, or a purpose-built GRC tool, depending on their existing technology environment and compliance requirements.

The most important shift is cultural, not technical. The AI risk register must be treated as an operational governance tool — reviewed at every committee meeting, updated when AI systems change, and referenced in every AI deployment decision. The moment it becomes a document that exists to satisfy auditors rather than to inform decisions, its value collapses.

What shadow AI is and why it proliferates

Shadow AI refers to the use of AI tools by employees without organizational knowledge, approval, or governance oversight. It is the AI equivalent of shadow IT — the unauthorized software and cloud services that proliferated in enterprises before IT governance caught up with user behavior. And like shadow IT before it, shadow AI is spreading faster than most organizations realize.

The proliferation is driven by the same forces that always drive shadow technology adoption: organizational AI governance processes are slow, approval cycles are long, and employees have immediate productivity needs. When a marketing manager can accomplish in twenty minutes with an AI writing tool what previously took two hours, the motivation to wait for IT approval is minimal — especially when the tool is free, accessible from a personal browser, and leaves no obvious trace in corporate systems.

The scale of the problem

Recent workforce surveys consistently find that a substantial majority of employees in knowledge-worker roles use AI tools that their employers have not formally approved. Estimates vary by sector and methodology, but figures above 60% are common in technology, professional services, and financial services. The rate is lower in heavily regulated industries like healthcare and financial services — not because employees are less inclined to use AI tools, but because data handling awareness is higher and the perceived risk of unauthorized tool use is more salient.

The more revealing data point is the gap between what employees report using and what their IT or security departments believe is in use. In most organizations, that gap is large. Executives routinely underestimate shadow AI prevalence by a factor of two or more.

Why it creates governance risk

Shadow AI creates risk across four dimensions. The first is data exposure. When employees use consumer AI tools for work tasks, they frequently input sensitive information: customer data, financial projections, legal documents, intellectual property, personally identifiable information. Many consumer AI platforms use user inputs to train their models unless users opt out — an opt-out that most employees are unaware of and have not exercised. The result is organizational data flowing into third-party AI systems with no data processing agreement, no security assessment, and no visibility to the organization's privacy or security teams.

The second dimension is output reliability. AI systems produce outputs that can be confidently wrong. Employees using unauthorized tools without governance oversight may act on those outputs without the verification processes that an approved, governed AI system would require. The errors are invisible until they cause harm.

The third dimension is regulatory exposure. Under GDPR, UK GDPR, HIPAA, and emerging AI-specific regulations, organizations are responsible for how personal data is processed — including processing by AI tools used by their employees, regardless of whether those tools were officially authorized. "We didn't know employees were using it" is not a defense that regulators accept.

The fourth dimension is the governance gap itself. An AI governance program that does not account for shadow AI is measuring the wrong population. Risk registers and use case inventories that capture only approved AI systems may represent a minority of the actual AI activity occurring in the organization.

How to measure your organization's shadow AI exposure

Start with a workforce survey that asks directly about AI tool usage — not about approved tools, but about any AI tools used for work tasks in the past month. Design the survey to minimize social desirability bias by framing it as a capability assessment rather than a compliance audit. The gap between survey results and your approved AI inventory is your shadow AI exposure baseline.

Layer in network and endpoint data if your security infrastructure supports it. DNS query logs, web proxy data, and browser extension inventories can identify AI platform domains that are not in your approved tool list. This approach has better coverage than surveys but requires security team involvement and may require privacy notice updates depending on your jurisdiction.

Closing the gap without closing the door

The governance response to shadow AI is not prohibition — it is friction reduction combined with oversight. Employees use unauthorized tools because authorized tools are unavailable, slow to approve, or unknown. The most effective interventions address each of these causes directly.

Establish a fast-track AI tool review process that can assess and approve low-risk AI tools within two weeks. Publish an approved AI tools list that is easy to find and regularly updated. Create a lightweight self-service request process for new tool requests. And establish a safe-to-report culture where employees who have been using unauthorized tools can disclose without fear of disciplinary action — the disclosure itself is the governance outcome you want.

Shadow AI is a symptom of governance friction, not malicious intent. Organizations that address the friction will reduce the shadow — and gain visibility into the full scope of their AI use in the process.

Why most AI governance committees fail

The most common failure mode for AI governance committees is not lack of authority — it is lack of operational connection. A committee that meets quarterly to review a static risk report and approve policies that no one reads is a governance theater performance. It generates documentation. It does not generate governance.

The second most common failure mode is over-engineering. Organizations that attempt to build a twelve-member committee with a forty-page charter, six subcommittees, and a forty-five-day approval process for any AI tool will find that the business routes around them. Speed-to-market pressure is real. A governance structure that cannot respond in days — not months — will be circumvented, not reformed.

The committee structure that actually works is lean, operationally connected, and built around a simple mandate that every member can articulate and act on.

The Register, Monitor, Intervene mandate

Register. Monitor. Intervene. These three words define the operational mandate for an effective AI governance committee, and they are simple enough to survive translation across organizational levels — from board presentation to department head briefing to individual contributor onboarding.

Register means every AI system in use by the organization is documented in an AI use case register before it is deployed. No AI system operates in governance shadow. The register captures the system's purpose, owner, data inputs, risk classification, and approved use boundaries.

Monitor means the committee reviews the register on a defined cadence, tracks risk treatment progress, receives alerts on significant changes to AI systems or their risk profiles, and maintains visibility into the regulatory environment that affects each system.

Intervene means the committee has the authority and the operational pathway to pause, modify, or retire AI systems that exceed risk thresholds, violate policy, or trigger incident response. Authority without a mechanism to exercise it is not governance — it is aspiration.

The right committee structure

An effective AI governance committee for a mid-market organization typically has five to seven members. The chair should be a senior executive — ideally the Chief Risk Officer, Chief Legal Officer, or equivalent — with organizational authority to make binding decisions. Members should include representatives from legal and compliance, information security, the business unit with the highest AI deployment volume, IT or engineering, and either an independent AI governance advisor or a data privacy officer.

Each member should have a defined role, not just a seat. The legal and compliance representative owns regulatory monitoring and policy maintenance. The security representative owns AI vendor risk and system security controls. The business unit representative owns the use case register for their domain and serves as the intake point for new AI system requests. The IT or engineering representative owns technical controls and integration approvals.

Meeting cadence and operating rhythm

Monthly meetings work better than quarterly for organizations with active AI deployment programs. The agenda should follow a consistent structure: risk register review (what changed since last meeting and why), new AI system approvals (requests in queue, decisions made), regulatory update (what changed in the regulatory environment), and open items from prior meetings. Meetings should last sixty to ninety minutes. If they consistently run longer, the agenda is too broad or the register is not well-maintained between meetings.

Between meetings, the committee chair or a designated AI governance function should maintain the register, respond to time-sensitive approval requests, and monitor for regulatory or incident triggers that require an emergency meeting.

The charter design principle

The committee charter should be short enough to read in ten minutes and specific enough to answer three questions without ambiguity: What does this committee have the authority to decide? What decisions require escalation to the board? What triggers an emergency meeting? A charter that cannot answer these questions quickly will not be consulted when decisions need to be made quickly.

The charter should explicitly define the AI system approval process — the steps a new AI system must complete before deployment authorization, including risk classification, security review, legal review, and committee approval. This process is the committee's most operationally important function. Getting it right, and keeping it fast enough to be useful, is the design challenge that distinguishes effective AI governance from compliance theater.

Why HIPAA and AI intersect in ways organizations underestimate

HIPAA was written before large-scale AI deployment in healthcare was a practical reality. The statute does not mention artificial intelligence. The implementing regulations — the Privacy Rule, Security Rule, and Breach Notification Rule — were designed for a world of electronic health records, not for a world in which AI systems analyze clinical notes, predict patient deterioration, match patients to clinical trials, and generate discharge summaries.

This regulatory gap creates two risks. The first is that healthcare organizations assume AI tools fall outside HIPAA's scope because the regulation does not explicitly address them. This assumption is incorrect. HIPAA's applicability is determined by what information the AI system processes and who uses it — not by what category of technology it is. The second risk is that organizations assume their AI vendor relationships are covered by their existing business associate agreement frameworks without reviewing whether those agreements address AI-specific risks. They often do not.

When an AI system is subject to HIPAA

An AI system is subject to HIPAA when it creates, receives, maintains, or transmits protected health information on behalf of a covered entity. This includes clinical decision support tools that analyze patient records, AI-assisted diagnostic systems, patient communication platforms using AI, revenue cycle AI tools that process claims data, and any AI system that ingests, generates, or stores data that includes individually identifiable health information.

The covered entity remains the accountable party under HIPAA regardless of whether the AI system is developed internally or purchased from a vendor. When a healthcare organization deploys a third-party AI tool that processes PHI, the vendor becomes a business associate and must execute a business associate agreement that covers the AI-specific uses of that data.

The business associate agreement gap

Standard BAA templates were not designed with AI in mind. Most existing BAAs address data access, breach notification, and basic security requirements — they do not address whether the vendor uses PHI to train AI models, what happens to PHI-derived insights after the contract ends, whether the AI system's outputs may be used for purposes beyond the contracted service, or what oversight mechanisms the vendor has for AI system accuracy and bias.

Healthcare organizations that have deployed AI tools under standard BAAs should review those agreements against these questions. The most consequential gap in most existing BAAs is the absence of any provision addressing model training: whether the vendor may use PHI inputs to improve their AI model, and if so, on what terms. Several major AI vendors have faced regulatory scrutiny precisely on this question.

The minimum necessary principle and AI systems

HIPAA's minimum necessary standard requires covered entities to make reasonable efforts to limit PHI use and disclosure to the minimum necessary to accomplish the intended purpose. Applied to AI systems, this principle raises questions that most AI procurement processes do not currently address. Does the AI system require access to the full patient record, or only specific data elements? Can the system be configured to operate on de-identified or pseudonymized data? Does the system's access scope expand over time as its functionality is used for additional purposes?

AI systems frequently require access to broader data sets during training and fine-tuning than they require during inference. Organizations should understand and document the data access requirements for each phase of an AI system's lifecycle — not just its production operation.

AI-specific risks under the Security Rule

The HIPAA Security Rule requires covered entities to implement administrative, physical, and technical safeguards to protect the confidentiality, integrity, and availability of electronic PHI. AI systems create several Security Rule considerations that legacy security frameworks were not designed to address.

Model inversion and membership inference attacks can extract information about training data from AI models — including whether specific individuals were included in a training set. Adversarial inputs can cause AI systems to produce incorrect outputs in ways that may affect patient safety and that may not be detectable without specific monitoring. AI system outputs that inform clinical decisions carry availability and integrity obligations that go beyond standard data backup and access control requirements.

The risk analysis required under the Security Rule should explicitly assess AI-specific threats and vulnerabilities. Most risk analyses completed before 2023 will not have done so adequately.

Where to start

Begin with an inventory of every AI system — including third-party tools — that processes, accesses, or generates PHI. For each system, assess whether an adequate BAA is in place and whether that BAA addresses AI-specific risks including model training use of PHI. Review the minimum necessary compliance posture for each system's data access scope. And ensure that your HIPAA risk analysis addresses AI-specific threats and that your incident response procedures cover AI system failures and outputs that may constitute breaches.

The intersection of HIPAA and AI is an area where regulatory guidance is actively developing. OCR has signaled increased enforcement attention to AI in healthcare, and the HHS AI Strategy published in 2024 establishes clear expectations for AI governance in healthcare organizations. The organizations that move now to close the HIPAA-AI gap will be in a substantially stronger position when enforcement attention increases — as it will.