Summary. Artificial intelligence regulation arrived faster than most compliance functions expected and in a shape most were not built for: a comprehensive European statute with extraterritorial reach and staged deadlines, a growing set of state laws targeting algorithmic discrimination and disclosure, a federal posture that swung sharply between administrations, and enforcement by agencies applying decades-old consumer protection, employment, and lending statutes to new technology. This article maps that terrain and explains how to build a governance program that satisfies most of it at once. It covers the EU AI Act's risk tiers, prohibited practices, high-risk obligations, general purpose model rules, penalty structure, and the provider/deployer classification that determines everything else. It then covers the American picture, and closes with a practical program build, checklists, a worked example, an FAQ, and related reading.

Most companies do not have an AI problem. They have an AI inventory problem.

Ask a general counsel how many AI systems the company uses and the answer is usually a number that is too small by an order of magnitude. The resume screener counts, and so does the fraud model, the pricing engine, the chatbot, the sales-call summarizer, the code assistant, the marketing copy generator, the document classifier in legal ops, the anomaly detector in security, and the recommendation model in the product. Several of those were adopted by a business unit without a procurement review, several are features quietly added by existing SaaS vendors, and at least one is being used in a way its vendor's terms prohibit.

Everything else in AI governance depends on fixing that first.

The short answer

The European Union has a comprehensive statute, Regulation (EU) 2024/1689 (the AI Act), which applies extraterritorially to providers placing AI systems on the EU market and to deployers established in the EU, and also where the output is used in the EU. Obligations phase in from 2025 through 2027. Penalties reach €35 million or 7 percent of worldwide annual turnover for prohibited practices.

The United States has no comprehensive federal AI statute. Instead:

  • State laws address algorithmic discrimination (Colorado), disclosure (Utah, California), employment decisions (Illinois, New York City), and government use (Texas), on different models and different timelines.
  • Federal agencies enforce existing law: the FTC under Section 5, the EEOC under Title VII and the ADA, the CFPB under ECOA and the FCRA, the SEC against "AI washing," and sector regulators in health, insurance, and finance.
  • The NIST AI Risk Management Framework is voluntary but has become the de facto reference for what a reasonable program looks like.

The practical convergence: almost every regime asks the same core questions. What is the system, what does it decide, who is affected, how was it tested, who oversees it, what were the risks and how were they mitigated, and what does the affected person get told? Build to those questions and you satisfy most requirements simultaneously.

Part I: The EU AI Act

Scope and who you are

The Act regulates by role, and the classification drives everything:

  • Provider: develops an AI system or general purpose AI model, or has one developed, and places it on the market or puts it into service under its own name or trademark.
  • Deployer: uses an AI system under its authority (other than for personal non-professional activity).
  • Importer, distributor, and product manufacturer have their own defined obligations.

The trap: a deployer becomes a provider if it puts its name or trademark on a high-risk system, makes a substantial modification to one, or modifies the intended purpose of a system such that it becomes high-risk. Fine-tuning a model and shipping it as your own feature can move you into the far heavier provider obligations. Companies routinely misclassify themselves here.

Extraterritorial reach. The Act applies to providers placing systems on the EU market regardless of establishment, to deployers established in the EU, and to providers and deployers in third countries where the output produced by the system is used in the EU. A U.S. company with EU customers should assume coverage.

The risk tiers

1. Prohibited practices. Certain uses are banned outright, including: subliminal or manipulative techniques that materially distort behavior and cause significant harm; exploitation of vulnerabilities based on age, disability, or socioeconomic situation; social scoring by public or private actors leading to detrimental treatment in unrelated contexts; predictive policing based solely on profiling or personality traits; untargeted scraping of facial images to build recognition databases; emotion inference in the workplace and in education (with narrow safety and medical exceptions); biometric categorization to infer sensitive attributes; and real-time remote biometric identification in publicly accessible spaces for law enforcement, subject to narrow exceptions.

The prohibitions and the AI literacy obligation applied first, in early 2025.

2. High-risk systems. Two routes:

  • Annex I: AI as a safety component of products already covered by EU product legislation (medical devices, machinery, vehicles, and others).
  • Annex III: enumerated use cases, including biometrics, critical infrastructure, education and vocational training, employment and worker management (recruitment, screening, promotion, termination, task allocation, monitoring), access to essential private and public services (including creditworthiness and insurance pricing for life and health), law enforcement, migration and border control, and administration of justice.

An Annex III system may escape high-risk classification if it does not pose a significant risk of harm, for example because it performs a narrow procedural task, but the provider must document that assessment, and systems that profile natural persons are always high-risk.

Provider obligations for high-risk systems include a risk management system across the lifecycle; data governance covering training, validation, and testing data quality and bias examination; technical documentation; automatic logging; instructions for use enabling deployer compliance; human oversight design; appropriate accuracy, robustness, and cybersecurity; a quality management system; conformity assessment and CE marking; registration in an EU database; post-market monitoring; and serious incident reporting.

Deployer obligations include using the system per instructions, assigning competent human oversight with authority to intervene, ensuring input data relevance, monitoring and reporting serious incidents, keeping logs, informing workers and their representatives before deploying at work, and, for certain public and service-related deployments, conducting a fundamental rights impact assessment.

3. Transparency-tier systems. Regardless of risk tier, providers must ensure that people are informed they are interacting with an AI system unless it is obvious; that synthetic content is marked in a machine-readable format; that deepfakes are disclosed; and that emotion recognition and biometric categorization systems inform exposed persons. Deployers of deepfakes must disclose the artificial origin, with exceptions for evidently artistic or satirical works.

4. Minimal risk. Everything else, subject only to general law and voluntary codes.

General purpose AI models

The Act imposes a separate regime on GPAI models: technical documentation, information to downstream providers, a policy to comply with EU copyright law including respecting text and data mining reservations, and a sufficiently detailed summary of training content.

Models presenting systemic risk (presumed above a compute threshold expressed in floating point operations used for training, or by Commission designation) additionally require model evaluation including adversarial testing, systemic risk assessment and mitigation, serious incident tracking and reporting, and cybersecurity protection.

Open-source models receive partial exemptions that do not extend to systemic-risk models.

Timing and penalties

Obligations phase in across roughly three years from entry into force in 2024: prohibitions and AI literacy first, then GPAI obligations, then Annex III high-risk obligations, then Annex I product-embedded systems. Deadlines have been the subject of active political debate, and simplification proposals have circulated. Verify the current schedule before relying on any date, and build the program on the assumption that the substantive obligations will apply.

Penalties: up to €35 million or 7 percent of worldwide annual turnover for prohibited practices; up to €15 million or 3 percent for most other violations; up to €7.5 million or 1 percent for supplying incorrect or misleading information to authorities, with lower caps for small and medium enterprises.

Part II: The American picture

Colorado

The Colorado AI Act, SB 24-205, codified at C.R.S. § 6-1-1701 et seq., was the first comprehensive state statute targeting algorithmic discrimination in consequential decisions (education, employment, financial or lending services, essential government services, health care, housing, insurance, and legal services).

It imposes a duty of reasonable care to protect consumers from known or reasonably foreseeable risks of algorithmic discrimination, with distinct obligations on developers (documentation to deployers, public statements, disclosure of discovered discrimination to the attorney general) and deployers (risk management program, impact assessments, consumer notice, an explanation and right to correct data and appeal to human review for adverse consequential decisions, and public disclosure).

Enforcement is exclusive to the attorney general, with rulemaking authority; there is no private right of action. The effective date has been delayed by subsequent legislation, and amendments have been actively debated, so confirm the current date and text.

Colorado matters beyond Colorado because its structure, developer versus deployer, impact assessments, notice and appeal, is the template other states are borrowing.

Texas

The Texas Responsible AI Governance Act takes a different approach: it targets intentional discriminatory use rather than disparate impact, focuses substantially on government use of AI, restricts certain practices (social scoring, biometric identification from scraped data by government entities, AI intended to incite harm), provides a cure period and attorney general enforcement, and establishes a regulatory sandbox.

The intent standard makes it considerably less burdensome for private deployers than Colorado's, which is the point of the design.

Employment-specific rules

  • Illinois HB 3773 amended the Illinois Human Rights Act to prohibit employers from using AI that has the effect of discriminating on protected characteristics in recruitment, hiring, promotion, discipline, discharge, and other terms, and from using ZIP code as a proxy for a protected class. It also requires notice to applicants and employees when AI is used for such decisions.
  • New York City Local Law 144 requires employers and employment agencies using an automated employment decision tool for hiring or promotion in the city to obtain an independent bias audit within the prior year, publish a summary of results, and provide advance notice to candidates.
  • Illinois's Artificial Intelligence Video Interview Act requires notice, explanation, consent, and deletion on request for AI analysis of video interviews.
  • Maryland restricts facial recognition in interviews without consent.

The EEOC has issued guidance applying Title VII disparate impact analysis and the ADA's reasonable accommodation requirements to algorithmic selection tools, and the federal enforcement posture on disparate impact has shifted across administrations, which is a reason to rely on the statutes and the state analogues rather than on federal guidance documents.

Mobley v. Workday, Inc., pending in the Northern District of California, is the case to watch: the court allowed claims to proceed against an AI screening vendor on an agency theory, and later permitted a nationwide collective to proceed on age discrimination claims. If vendors can be liable as agents of employers, the entire procurement and contracting posture changes.

California

California has taken a disclosure-and-transparency approach on several fronts: a training data transparency requirement for developers of generative systems made available to Californians; an AI transparency law directed at provenance disclosures and detection tools for large generative providers; frontier model safety and incident reporting legislation aimed at the largest developers; and, through the California Privacy Protection Agency, regulations addressing automated decisionmaking technology, risk assessments, and cybersecurity audits under the CCPA. Effective dates have shifted through amendment; verify before relying.

Also note the digital replica statutes addressed in Name, Image, Likeness, and Digital Replicas.

Other states and the federal layer

  • Utah's AI Policy Act requires disclosure that a person is interacting with generative AI, on request in most contexts and proactively for regulated occupations, and confirms that AI use is not a defense to consumer protection violations.
  • Sector regulators have moved: the National Association of Insurance Commissioners' model bulletin on AI use by insurers has been adopted in many states; the FDA regulates AI-enabled medical devices and has issued guidance on predetermined change control plans; banking regulators apply model risk management expectations.
  • Federal executive policy shifted substantially between administrations, with the 2023 executive order on AI revoked in 2025 and replaced with a deregulatory and competitiveness-focused directive, followed by revised OMB guidance for federal agency use and procurement. For private companies, the operative federal exposure remains existing law: Section 5 of the FTC Act, the employment statutes, the lending statutes, and the securities laws.
  • The FTC has brought a series of actions against companies making unsupported AI claims and against AI-enabled products alleged to cause harm, and has repeatedly stated that "there is no AI exemption from the laws on the books." Deceptive AI marketing claims are the easiest enforcement target in the field.
  • The SEC has charged firms with "AI washing," meaning material misstatements about AI capabilities to investors.

The NIST framework

The AI Risk Management Framework 1.0, with its Generative AI Profile, organizes governance around four functions: Govern, Map, Measure, Manage. It is voluntary and it is the most useful single document for building a program, partly because it is structured the way an auditor thinks and partly because regulators cite it.

Companies with an existing information security program will recognize the shape and can often extend that governance rather than building a parallel one.

Part III: Building the program

Step 1: Inventory

You cannot govern what you cannot list. Build a register with, for each system:

  • Name, owner, business unit, and vendor (or "internal").
  • What it does, in one sentence a non-engineer understands.
  • Decision type: does it inform, recommend, or decide? Is a human in the loop, on the loop, or absent?
  • Population affected: consumers, employees, applicants, patients, borrowers, the public.
  • Data used, including personal data, sensitive data, and biometric data.
  • Model provenance: third-party API, self-hosted open weights, fine-tuned, trained from scratch.
  • Geography: where deployed, where the output is used.
  • Contract status and the vendor's own AI terms.

How to find the shadow inventory: expense reports, SSO logs, vendor lists, browser extension inventories, network egress to model API endpoints, and a plainly worded survey that asks people what tools they use rather than whether they use "AI."

Step 2: Classify

For each system, answer:

  • Are we a provider or a deployer under the EU Act, and does the name-on-it or substantial-modification rule move us?
  • Is any use prohibited (emotion inference in the workplace is the one that catches ordinary companies)?
  • Is it high-risk under Annex III (employment and credit are the common ones)?
  • Does it make a consequential decision under Colorado's framework?
  • Is it an automated employment decision tool under NYC Local Law 144?
  • Does it trigger disclosure obligations (chatbots, synthetic media, generative outputs)?
  • Does it process personal data, triggering privacy law obligations including automated decisionmaking rules? See State Consumer Privacy Laws.

Classification determines effort. Most systems land in the minimal-obligation bucket, and the value of classification is letting you spend the budget on the handful that do not.

Step 3: Impact assessments

Multiple regimes require an assessment under different names: the EU's fundamental rights impact assessment for certain deployers, Colorado's impact assessment for deployers of high-risk systems, privacy law data protection assessments, and NIST's Map function.

Build one template that satisfies all of them:

  1. Purpose and intended use, and reasonably foreseeable misuse.
  2. Populations affected, including vulnerable groups.
  3. Data sources, provenance, quality, representativeness, and known limitations.
  4. Performance metrics and testing results, disaggregated by relevant subgroups.
  5. Identified risks: discrimination, safety, privacy, security, IP, and reliability.
  6. Mitigations adopted, and residual risk accepted, with a named accountable owner.
  7. Human oversight design: who reviews what, with what training, and with what authority to override.
  8. Notice and explanation provided to affected people, and the appeal path.
  9. Monitoring plan and review cadence.
  10. Approval signatures and date.

Do them before deployment, and again on material change.

Step 4: Design human oversight that is real

"Human in the loop" is the most abused phrase in AI governance. Regulators and plaintiffs both ask the same follow-up: how often does the human actually override? If the answer is "never," the human is a rubber stamp and provides no protection.

Design for meaningful oversight:

  • The reviewer must have the information needed to evaluate the recommendation, including the factors that drove it.
  • The reviewer must have authority and time to override, and must not be measured on throughput in a way that punishes overriding.
  • Automation bias must be addressed in training.
  • Override rates should be monitored, and a rate near zero should trigger review of whether oversight is functioning.

Step 5: Test, and keep the evidence

  • Pre-deployment evaluation against defined metrics, on data representative of the deployment population.
  • Disaggregated performance testing across protected characteristics where lawful and feasible. This raises its own legal questions (collecting protected-class data to test for bias), and the analysis should be run through counsel.
  • Adversarial and red-team testing for generative systems: prompt injection, jailbreaks, data exfiltration, harmful output.
  • Drift monitoring after deployment, with thresholds and an escalation path.
  • Bias audits where required (NYC Local Law 144 requires an independent one).
  • Documentation retained. In every regime, the assessment you cannot produce did not happen.

Step 6: Procurement and contracts

Most AI risk enters through vendors. Contract for it:

  • Disclosure of AI use, including AI features added to existing products by amendment.
  • Documentation sufficient for your own compliance: intended purpose, limitations, performance characteristics, data governance, and, for EU high-risk, instructions for use meeting the Act's requirements.
  • Training data representations: lawful acquisition, rights to use, and no use of your data to train models serving other customers without consent. This last term is the most negotiated in the market.
  • Bias audit cooperation and access to what you need to comply with NYC and Colorado.
  • IP indemnity for outputs, with attention to caps, carve-outs for customer prompts and modifications, and duty-to-defend language. See Indemnification and Limitation of Liability.
  • Security and privacy terms, subprocessor controls, and data residency.
  • Incident notification with a defined window, covering both security incidents and material performance failures.
  • Audit and evidence rights, or at least a right to conformance documentation.
  • Change control: notice before material model changes, and a right to evaluate or exit.
  • Exit: data return and deletion, and no lock-in on model artifacts you paid to create.

Step 7: Policies and training

  • An acceptable use policy for generative tools that addresses confidential information, personal data, client and customer data, code, and the obligation to verify outputs.
  • A rule that AI-generated content is reviewed by a competent human before it is relied on externally. This is not paranoia; it is the lesson of the sanctions cases discussed in Hallucinated Citations, Rule 11, and Generative AI in Legal Filings.
  • Record retention guidance covering prompts and outputs, which are discoverable.
  • AI literacy training (the EU Act imposes an express obligation on providers and deployers to ensure sufficient AI literacy among staff).
  • A clear intake path so business units request review before adopting tools, and a fast enough review that they actually use it.

Step 8: Incident response and monitoring

  • Define what counts as an AI incident: material performance degradation, discriminatory output, harmful generation, data leakage, security compromise of a model or its data.
  • Route to the existing incident response process rather than building a parallel one.
  • Know the reporting obligations: EU serious incident reporting for high-risk systems, Colorado's disclosure to the attorney general on discovery of algorithmic discrimination, privacy breach notification where personal data is involved, and any sector reporting.
  • Preserve evidence. Prompts, outputs, model versions, and logs are the record.

A worked example

Alder & Vine Insurance Group (fictional), a U.S. insurer with a small European subsidiary, inventories its AI and finds eleven systems. Four matter.

System 1: Resume screening tool from a third-party vendor, used for U.S. and EU hiring.

Classification: Annex III high-risk under the EU Act (employment). Consequential decision under Colorado. Automated employment decision tool if used for NYC roles. Covered by Illinois HB 3773 for Illinois roles.

Obligations: Alder & Vine is a deployer, not a provider, unless it brands the tool as its own. It needs vendor documentation and instructions for use, human oversight with real authority, worker notice, logs, an impact assessment, a bias audit for NYC, candidate notice, and an appeal path. It must also confirm the vendor's obligations under Mobley-style agency exposure and negotiate cooperation and indemnity terms.

The hard question: the vendor will not disclose the model's features or provide subgroup performance data, calling it proprietary. That is a procurement failure, not a legal one. Alder & Vine should either obtain the data through contract amendment or replace the vendor, because it cannot perform the required assessments without it.

System 2: Claims triage model, built in-house, that routes claims and flags potential fraud for investigation.

Classification: Not automatically Annex III, but if it affects access to essential private services or influences claim outcomes, treat it as consequential. Insurance regulators' AI bulletins apply. Adverse action and unfair claims practices rules apply.

Obligations: Governance under the insurance regulator's framework, documented testing for disparate outcomes, human review of any adverse determination, explanation to the insured, and monitoring for drift.

System 3: A customer service chatbot built on a commercial model API.

Classification: Transparency tier. Users must know they are interacting with an AI system. Utah's disclosure statute applies to customer interactions.

Obligations: Clear disclosure, guardrails against providing coverage advice that binds the company, logging, escalation to a human, and terms making clear the bot does not create coverage. Also a data flow review, because customers will paste personal and health information into it.

System 4: An emotion-detection pilot proposed by HR to analyze recorded interviews for "engagement."

Classification: Prohibited in the EU for workplace use, subject to narrow exceptions. Also legally hazardous in the United States under the ADA (inferring mental state), state biometric statutes, and Illinois's video interview law.

Recommendation: Do not deploy. This is the single most common example of a well-intentioned HR pilot walking into a prohibited practice, and the right answer is a clear "no" delivered early, before anyone has signed a contract.

Program outcome. Alder & Vine ends with a register of eleven systems, four impact assessments, two vendor renegotiations, one project cancelled, one bias audit commissioned, an acceptable use policy, and training. That is roughly a quarter's work for a small team, and it covers the EU Act, Colorado, NYC, Illinois, Utah, the insurance bulletins, and privacy law simultaneously, because the underlying questions are the same.

Checklists

Inventory and classification

  • Complete AI system register with owner, purpose, population, data, and geography.
  • Shadow AI discovery performed (expense, SSO, network, survey).
  • Provider versus deployer determination for each system.
  • Prohibited practice screen (especially emotion inference and biometric categorization).
  • High-risk and consequential-decision classification documented.
  • Disclosure-triggering systems identified.

Assessment and controls

  • Unified impact assessment template covering EU, Colorado, and privacy requirements.
  • Assessments completed before deployment and on material change.
  • Human oversight designed, with authority, training, and monitored override rates.
  • Pre-deployment testing with disaggregated metrics where lawful.
  • Red-teaming for generative systems.
  • Drift monitoring with thresholds and escalation.
  • Bias audit where required, by an independent auditor.
  • Logging enabled and retained.

Contracts and procurement

  • AI use disclosure and change notification from vendors.
  • Documentation sufficient for your compliance obligations.
  • Training data and customer data use representations.
  • IP indemnity for outputs, with caps and carve-outs reviewed.
  • Security, privacy, subprocessor, and residency terms.
  • Incident notification windows.
  • Audit or evidence rights.
  • Exit and data return terms.

Policy and people

  • Acceptable use policy for generative tools.
  • Human verification requirement for externally relied-upon output.
  • AI literacy training delivered and recorded.
  • Intake process for new tools, with a fast turnaround.
  • Record retention guidance for prompts and outputs.
  • Incident response updated to include AI incidents.
  • Named accountable executive and a governance committee cadence.

Frequently asked questions

Does the EU AI Act apply to us if we have no EU entity? Possibly. It reaches providers placing systems on the EU market regardless of establishment, and providers and deployers outside the EU where the system's output is used in the EU. Analyze by system and by customer footprint rather than by corporate structure.

We only use third-party AI tools. Are we regulated? Yes, as a deployer, and deployer obligations are substantial for high-risk uses. And you can become a provider by branding or substantially modifying a system. "We just buy it" is not a compliance position.

Is there a federal AI law coming in the United States? Comprehensive legislation has been proposed repeatedly without passage, and federal policy has shifted between administrations. Meanwhile the enforceable law is the law already on the books, applied by the FTC, EEOC, CFPB, SEC, and sector regulators, plus the growing state layer.

What is the single highest-risk AI use for an ordinary company? Employment decisions. It is high-risk in the EU, consequential under Colorado, specifically regulated in Illinois and New York City, squarely within Title VII and the ADA, and the subject of active litigation against both employers and vendors.

Do we have to tell people they are talking to a bot? In the EU, yes, unless it is obvious. Utah requires disclosure in consumer interactions, and other states have narrower rules. As a practical matter, disclose; the alternative is a deception claim under Section 5 or a state analogue.

Can we use AI to screen resumes at all? Yes, with governance: documented validation, testing for disparate impact, human review with real authority, candidate notice, accommodation processes for disabled applicants, bias audits where required, and vendor documentation. What you cannot do is buy a tool, turn it on, and rely on the vendor's assurance.

Who owns AI-generated output? Copyright requires human authorship, and the Copyright Office has registered works with AI-assisted elements only where a human contributed protectable expression, requiring disclaimer of purely machine-generated material. The D.C. Circuit has affirmed the human authorship requirement. Contractually, ownership as between you and your vendor is whatever the terms say, so read them. See AI-Generated Inventions: Who Owns What the Machine Creates.

Is training on copyrighted data lawful? Contested and actively litigated. See Fair Use After Warhol for the current state of the American case law, and note that the EU AI Act separately requires GPAI providers to have a copyright policy respecting text and data mining reservations.

How do we handle employees pasting confidential data into chatbots? Policy, plus technical controls. Enterprise deployments with no-training terms and data residency commitments, an approved-tools list, network controls on unapproved endpoints, and training. Assume some leakage has already happened and scope your response accordingly. See Trade Secrets in the Age of Remote Work and Cloud Computing.

What if a regulator asks for our AI documentation tomorrow? That is the real test of a program. The register, the classifications, the impact assessments, the testing results, the oversight design, and the training records should be producible within a day. If they are not, that is the project.

Closing thought

The regulatory picture for artificial intelligence looks chaotic, and in some respects it is: a European statute with staged deadlines under political pressure, state laws on divergent models with shifting effective dates, and a federal posture that changes with administrations.

But the underlying questions have been remarkably stable, and they are not novel. Regulators want to know what the system does, who it affects, how you tested it, who is accountable, what the affected person is told, and what happens when it is wrong. Those are the same questions product safety regulation has asked for a century and that financial model risk management has asked for decades.

A company that can answer them, with documents, for each system it actually operates, is well positioned under every regime discussed here. A company that cannot is exposed under all of them, and the exposure does not depend on which statute happens to apply.

Start with the inventory. Everything else follows from it, and nothing works without it.

Related articles

This article is provided for general informational purposes and does not constitute legal advice. AI regulation is developing rapidly and effective dates have shifted repeatedly; verify current requirements before relying on any deadline stated here. Consult qualified counsel about any particular system or program.