Law, Regulation, and Policy

Legal compliance is not a property of a model. It is a dated claim about a specific system, its intended use, the actor performing that use, the jurisdiction, the effective date, and the source version on which the analysis relies. Change any element and the answer may change. A general-purpose model can be lawful in one product and prohibited in another; the same company can be a deployer in one transaction and a provider in the next.

This makes law an engineering input, not a ceremony after launch. Market choice affects data rights, documentation, interface notices, human review, logging, incident clocks, and whether a system may be offered at all. Those constraints reach into Chapter 6, Chapter 74, Chapter 59, Chapter 56, Chapter 57, Chapter 53, and Chapter 60.

This chapter supplies an operational method for finding and preserving that claim. It is not legal advice. Counsel must interpret the law for the facts, but engineering must maintain the facts and evidence on which that interpretation depends.

Start with source and status

Not every governance document is law. A useful legal register records the source type and its current status before extracting a requirement.

The vocabulary matters. Enacted does not necessarily mean effective. Signed does not mean ratified. Ratified does not necessarily mean in force. A proposed bill, a voluntary code, official guidance, and an enforceable regulation can address the same control without sharing legal force. Preserve each source, publication date, version, and retrieval date rather than storing a paraphrase called “the AI rules.”

Classify before mapping controls

Compliance starts from a system inventory, not from a model name. The workflow is deliberately repetitive because deployment changes are common.

The result should answer six questions in order:

1. Inventory the service, its data, decisions, users, affected people, and markets.
2. Identify every actor and its role in each supply chain.
3. Classify the system and intended use under both AI-specific and existing law.
4. Map horizontal and sectoral law, then check effective dates, transitions, and exceptions.
5. Map each obligation to a control and artifact, and assign an owner and reviewer.
6. Monitor changes in both the system and the governing sources.

The EU AI Act: several classifications, not one pyramid

Regulation (EU) 2024/1689 is a horizontal AI law, but it does not sort every system into four mutually exclusive tiers. Its structure combines prohibited practices, high-risk classifications, transparency duties, and a parallel regime for general-purpose AI models. Other Union and national law continues to apply (European Parliament and Council of the European Union 2024).

Scope and use-based duties

Article 2 reaches more than EU-established companies. It covers providers placing systems or general-purpose models on the Union market regardless of establishment, EU deployers, specified supply-chain actors, and some third-country providers or deployers where the output is used in the Union. That is direct statutory scope. The separate Brussels effect describes the economic choice to reuse an EU-oriented design elsewhere; it is not a substitute for the scope analysis (Bradford 2020).

The principal paths are:

• Prohibited practices. Article 5 defines practices that are barred when their statutory elements are met. Labels such as “social scoring” or “biometric identification” are only shorthand; the text includes conditions and exceptions that must be tested.
• High-risk systems. Article 6(1) covers certain safety components and products listed through Annex I when the specified product-law and conformity conditions apply. Article 6(2) and Annex III cover enumerated uses in areas including biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, and justice. Article 6(3) provides a bounded route for some Annex III systems not to be high-risk; profiling systems do not receive that route. Not every high-risk assessment requires a third-party auditor.
• Transparency. Article 50 assigns different provider and deployer duties for direct interaction, machine-readable marking, emotion recognition, biometric categorisation, deepfakes, and certain public-interest text. “Label synthetic media” is too crude: the responsible actor, output type, disclosure mechanism, and exception differ.
• General-purpose AI. Chapter V applies at the model-provider layer in parallel with the classification of downstream systems. A downstream use can therefore add its own high-risk or transparency obligations.

High-risk providers must support risk management, data governance, technical documentation, logging, human oversight, accuracy, robustness, cybersecurity, conformity assessment, registration, post-market monitoring, and incident handling where the corresponding provisions apply. Deployers have different duties, such as following instructions, assigning competent oversight, monitoring use, retaining controlled logs, and supporting affected-person or data-protection procedures. A fundamental-rights impact assessment is required only for the deployers and uses specified in Article 27, not for every high-risk deployment.

General-purpose models and systemic risk

Article 53 requires a general-purpose AI provider to maintain technical documentation, give downstream providers information needed for integration, adopt a copyright-compliance policy, and publish a sufficiently detailed training-content summary. A provider outside the Union may also need an authorised representative. A qualifying open-source model can be exempt from parts of the technical-documentation and downstream-information duties, but not from the copyright policy or training-content summary; the exemption does not cover models with systemic risk (European Commission 2025).

Training compute above 10^25 FLOP creates a rebuttable presumption of high-impact capability. It is not an automatic final classification. A provider can submit a substantiated rebuttal, and the Commission may designate a model using the statutory criteria even when the presumption is not the route. Providers of general-purpose models with systemic risk must add model evaluation, documented adversarial testing, systemic-risk assessment and mitigation, serious-incident reporting without undue delay, and cybersecurity for the model and its infrastructure (European Parliament and Council of the European Union 2024; European Commission 2025).

The current transition calendar

The date belongs in the classification record. Regulation (EU) 2026/1744, the enacted Digital Omnibus, entered into force on 27 July 2026 and changed the original schedule (European Parliament and Council of the European Union 2026).

This table is a snapshot, not a permanent truth. Preserve the authentic acts and the consolidated text used for analysis. The Omnibus itself demonstrates why a launch checklist cannot hard-code a date and then stop monitoring it.

Roles move along the value chain

An organization can occupy several roles at once. Record the role per system, market, and transaction.

Role can change by action. Under Article 25, rebranding, a substantial modification, or changing the intended purpose so that a system becomes high-risk can make an importer, distributor, deployer, or third party the provider. A procurement contract can allocate evidence and cooperation, but it cannot erase a statutory role.

This is why vendor review cannot end with “the model is compliant.” Ask which legal entity made which claim, for which revision and intended purpose, and whether the integration changes the role or classification.

The United States: overlapping authorities, not an empty space

The United States has no single comprehensive horizontal federal AI statute for private systems as of this chapter's review date. That does not create a legal vacuum. Consumer protection, anti-discrimination, employment, credit, privacy, health, product safety, intellectual property, contract, and other sectoral rules can govern an AI-mediated act just as they govern the same act performed with other software.

Federal documents also differ in reach. OMB Memorandum M-25-21 governs covered federal agencies' own use of AI and expressly does not create rights or obligations for the public. M-25-22 governs covered federal acquisition; its requirements can reach a vendor through procurement and contract terms, not as a general private-market AI statute (Office of Management and Budget 2025; Office of Management and Budget 2025). NIST's AI Risk Management Framework and Generative AI Profile organize voluntary risk work into Govern, Map, Measure, and Manage. They are not laws or NIST certifications. Selected controls become binding only when a law, regulation, order, or contract incorporates them (Tabassi 2023; National Institute of Standards and Technology 2024).

State law must be read actor by actor and date by date:

These examples do not form a universal US tier system. California's incident clock, Colorado's adverse-outcome review, an Illinois employer's use restriction, and a federal procurement clause attach to different events and actors. A preemption strategy or executive order is not itself a judgment that every state rule is invalid.

International instruments and standards

The Council of Europe Framework Convention on Artificial Intelligence and Human Rights, Democracy and the Rule of Law is a treaty designed to bind parties after entry into force. It was opened for signature in 2024, and the European Union ratified it in 2026, but the treaty had not met its entry-into-force threshold by 5 August 2026. Its status must therefore be recorded as signed or ratified per participant, not as universally enforceable current law (Council of Europe 2024).

The OECD AI Principles are a non-legally-binding Council Recommendation. They offer a shared vocabulary for human rights, transparency, robustness, safety, traceability, and lifecycle risk management; they do not certify a product or create a reporting mandate by themselves (Organisation for Economic Co-operation and Development 2024).

ISO/IEC 42001:2023 specifies requirements for an organizational AI management system. An organization can obtain third-party certification of a defined management-system scope against it. ISO itself does not certify organizations, and the certificate is not a finding that a particular model is safe, correct, or legally compliant. The standard is voluntary unless incorporated into law or contract (ISO/IEC 2023). A crosswalk between frameworks shows correspondence, not equivalence.

These distinctions produce two independent axes:

• Legal force: enacted law, binding rule, treaty in force, contract, guidance, standard, or voluntary policy.
• Assurance object: organizational management system, system classification, model evaluation, data right, incident process, or a particular legal requirement.

A strong audit of a management system can still say little about a specific model's behavior. A strong behavioral evaluation can still omit data rights. Neither becomes a legal opinion merely because it is independent.

Existing law still governs the system

AI-specific law adds to rather than replaces existing duties. A legal map should include at least:

• Data protection and privacy. The GDPR can govern collection, training, inference, profiling, data-subject rights, security, impact assessment, retention, deletion, and personal-data-breach reporting. Its Article 33 72-hour breach clock is distinct from an AI safety-incident clock (European Parliament and Council of the European Union 2016). The data inventory and deletion evidence therefore belong with Chapter 59.
• Consumer protection. Deceptive capability, disclosure, price, endorsement, or safety claims can matter even when no AI-specific tier applies.
• Employment and credit. Anti-discrimination, notice, accuracy, explanation, and review rules can attach to the decision and the deployer, not merely to the upstream model.
• Product safety and liability. An AI component can inherit sector-specific obligations and evidence from the product into which it is integrated.
• Intellectual property and contract. Copyright, database rights, licences, terms, confidentiality, and trade-secret controls affect corpus acquisition, output use, model access, and evidence sharing.

Copyright does not have one global answer

Training and corpus acquisition must be analyzed separately by jurisdiction, source, licence, use, and procedural posture. In the United States, 2025 district-court decisions illustrate the limits of generalization. Bartz v. Anthropic treated the training use before it as fair use while separating acquisition and retention of pirated copies. Kadrey v. Meta granted summary judgment on the record presented and emphasized the plaintiffs' failure to establish the relevant market harm. Thomson Reuters v. Ross rejected fair use for a different, non-generative system competing in a legal-research market (United States District Court for the Northern District of California 2025; United States District Court for the Northern District of California 2025; United States District Court for the District of Delaware 2025).

Those decisions are jurisdiction-specific, fact-specific, and tied to procedural posture. They do not settle whether all training is fair use, whether a particular corpus was lawfully acquired, or how another country's exceptions apply. A settlement does not create precedent. The engineering response is provenance: retain source, acquisition method, licence or exception analysis, rights-reservation signal, transformations, exclusions, deletion path, and model revision. “Publicly accessible” is not a licence.

In the EU, the AI Act's GPAI copyright-policy and training-content-summary duties coexist with copyright law; they do not decide whether every included work was lawful. The summary is not necessarily a public row-by-row corpus manifest. Technical controls should implement the actual legal interpretation, including rights reservations where applicable, rather than inventing a universal opt-out rule.

Voluntary frontier policies: useful, revisable, and bounded

Frontier developers publish policies that link a capability threshold to an evaluation, a safeguard tier, and sometimes a safety case. These structures can make release reasoning explicit and can be incorporated into a statute or contract. California SB 53, for example, requires a covered large frontier developer to publish, implement, and update a frontier AI framework (California State Legislature 2025).

The underlying company documents remain voluntary self-governance except where a binding source incorporates a duty. A company policy can be revised by its author, internal leadership may retain the launch decision, and public evaluators may receive only time-bounded access. Anthropic's Responsible Scaling Policy, OpenAI's Preparedness Framework, and Google DeepMind's Frontier Safety Framework therefore deserve comparison as evidence systems, not treatment as law (Anthropic 2026; OpenAI 2025; Google DeepMind 2026).

The common pattern is still useful:

1. Define the harm pathway and capability threshold before the release decision.
2. Run an evaluation designed to elicit the capability under stated access and scaffolding.
3. Apply deployment and security safeguards when the threshold or uncertainty rule fires.
4. Write a safety case that connects evidence, assumptions, residual risk, and approval.
5. Preserve deviations, policy versions, reviewers, and the final decision.

The policy is evidence about governance. It is not proof that the threshold is complete, the evaluation elicited every capability, the safeguards will generalize, or the residual risk is acceptable.

Turn requirements into evidence

Model cards and datasheets are valuable documentation patterns (Mitchell et al. 2019; Gebru et al. 2021). They are not automatically the technical documentation, conformity assessment, impact assessment, post-market monitoring plan, or incident report required by a particular law. Reuse content, but do not treat artifact names as interchangeable.

The traceability chain should be explicit:

source provision and version
  -> applicability and classification rationale
  -> requirement and responsible actor
  -> technical or organizational control
  -> artifact and system revision
  -> reviewer, approval, retention, and authority access
  -> monitoring trigger and reporting clock

One control can support several requirements, and one requirement can need several controls. The map must preserve that many-to-many relationship. It should also record negative evidence: an exception relied upon, missing vendor evidence, an unresolved legal conflict, or a control that does not cover a new modality.

Incident routing deserves its own table because clocks are not interchangeable:

An event can trigger more than one row. The incident service should route by facts and jurisdiction, preserve awareness and discovery timestamps, and let the legal owner decide which clocks apply.

The legal register

Keep the register under version control and bind it to the release record:

legal_register:
  system_and_model_revisions: []
  intended_purpose_and_prohibited_uses: []
  markets_jurisdictions_and_effective_dates: []
  actors_roles_and_contractual_allocation: []
  legal_sources_status_and_versions: []
  classification_and_risk_category: []
  sectoral_and_horizontal_obligations: []
  data_sources_rights_and_retention: []
  required_controls_and_evidence: []
  assessment_registration_and_authority_contacts: []
  transparency_human_oversight_and_appeal: []
  monitoring_incident_and_reporting_clocks: []
  change_triggers_and_reclassification: []
  exceptions_conflicts_and_legal_owner: []
  last_review_next_review_and_approver: []

Store source snapshots or stable identifiers alongside the register. A dashboard that says “EU AI Act: green” without article, actor, use, date, evidence, and revision hides the question that matters.

Regression scenarios

Treat compliance controls like other production controls. Re-run classification and evidence checks for at least these cases:

• Market expansion: an existing service becomes available in a new jurisdiction.
• Role change: a reseller rebrands the system, or an integrator makes a substantial modification.
• Model swap: the serving alias moves to a new base model or provider without updating evidence.
• New intended use: a general assistant is integrated into employment, credit, education, health, or public-service decisions.
• GPAI designation: a model crosses the compute presumption or receives a Commission designation.
• Open-source condition: licence, distribution, monetization, or systemic-risk status invalidates an assumed exemption.
• Stale guidance: a control still cites withdrawn or superseded official guidance.
• Deadline transition: a provision becomes effective while the deployed revision remains unchanged.
• Withdrawn standard: certification or a contract still names an obsolete or withdrawn standard version.
• Incident clock: one event triggers privacy, AI safety, contractual, and sectoral reporting paths with different start times.
• Authority request: the organization must retrieve the exact logs, documentation, and unredacted evidence within scope.
• Retention conflict: an audit or litigation hold conflicts with a deletion request or minimization schedule.
• Transparency label: post-processing strips a machine-readable mark or required user notice.
• Human-oversight bypass: a product update removes the review or appeal path assumed by classification.
• Vendor evidence: an upstream provider stops supplying a required document or changes its contractual allocation.
• Jurisdiction conflict: one market requires disclosure that another contract or law restricts.

Every scenario should identify the detecting control, blocking behavior, evidence produced, escalation owner, and reapproval path. A warning with no release effect is not a regression test.

What's contested

Several boundaries remain unsettled, and the register should say so rather than converting uncertainty into a categorical answer.

• Which systems should bear fixed compliance costs? Broad documentation and assessment duties can improve accountability while favoring organizations able to absorb them. Scope exceptions can protect small actors while leaving consequential uses under-governed.
• Can compute stand in for capability? A compute threshold is observable but indirect. Algorithmic efficiency, fine-tuning, tool access, and system composition can move risk without moving the original training number in the same way.
• How much transparency is safe? Regulators and downstream providers need evidence, while public disclosure can expose personal data, trade secrets, security controls, or dangerous capability details. Redaction and regulator-access rules mediate rather than eliminate the conflict.
• What should independent assurance mean? Access, sampling, standard, competence, conflicts, remediation authority, and publication all affect the strength of an audit. Independence alone does not make a narrow test comprehensive.
• Who controls an open-weight system? Upstream documentation can travel with weights, but downstream fine-tuning, repackaging, and deployment can change intended purpose, safeguards, and legal role beyond the original provider's observation.
• When does copyright doctrine stabilize? Outcomes may continue to differ by jurisdiction, acquisition method, market evidence, modality, and remedy. Product design must preserve options while courts and legislatures resolve those questions.

Lower-layer constraint

Law reaches every lower layer through concrete design requirements. A data-rights analysis changes corpus admission and deletion in Chapter 6 and Chapter 59. Technical-documentation duties require lineage from Chapter 74. Human oversight and appeal require product and authorization paths from Chapter 56. Transparency and incident duties add runtime metadata, logging, and routing to Chapter 57 and Chapter 53. Confidentiality limits affect which evidence can leave the boundary described in Chapter 60. Retention and regulator-access duties change storage, backup, and retrieval in Chapter 65.

These constraints also have cost and latency consequences. A required review path, provenance mark, log, conformity process, or market-specific deployment adds work. Chapter 76 must price that work, but cost does not decide whether an applicable duty can be ignored.

Compliance must survive system change

A compliance memo describes a moment. A compliant operation maintains a chain from current facts and authoritative sources to classification, controls, evidence, review, monitoring, and reclassification. It knows which claims are legal conclusions, which are official guidance, which are standards, and which are voluntary promises.

The practical rule is simple: no system is “compliant” in the abstract. A named organization has evidence that a named revision, used for a named purpose in a named jurisdiction on a named date, satisfies identified requirements under identified sources. When any name or date changes, the claim reopens.