Regulatory-Aware LLM Adaptation

Regulatory Framework

Regulation (EU) 2024/1689, the EU Artificial Intelligence Act, entered into force on August 1, 2024 with a phased application schedule running through August 2027. The Act establishes a tiered risk classification: prohibited practices under Article 5, high-risk systems enumerated in Annexes I and III subject to the conformity assessment, transparency, data governance, human oversight, and post-market monitoring obligations of Articles 8 through 21, limited-risk systems with transparency obligations under Article 50, and minimal-risk systems. General-purpose AI model obligations under Articles 51 through 56 apply to providers of foundation models, with systemic-risk obligations attaching to models above defined compute thresholds. Conformity assessment for high-risk systems requires documentation, technical files, and post-market monitoring artifacts that survive supervisory authority inspection.

In the United States, Executive Order 14110 of October 30, 2023 directed agencies to issue guidance, and OMB Memorandum M-24-10 established federal-agency obligations for AI use including impact assessment, testing, and human oversight for safety-impacting and rights-impacting AI. While the subsequent Executive Order 14179 of January 2025 revoked EO 14110, the agency-level rules issued under OMB M-24-10 and successor guidance, the NIST AI Risk Management Framework (AI RMF 1.0 and the Generative AI Profile NIST AI 600-1), and sector-specific rules from the Federal Trade Commission, the Equal Employment Opportunity Commission, the Consumer Financial Protection Bureau, and the Department of Health and Human Services remain in force and continue to develop. The Food and Drug Administration's AI/ML-enabled device guidance — including the 2023 draft Marketing Submission Recommendations for a Predetermined Change Control Plan and the 2025 draft on Lifecycle Management — establishes that AI models in regulated medical devices may adapt only within a pre-cleared change control plan, with post-market surveillance attached.

The common thread across these regimes is that LLM behavior is not a single configured artifact but a sequence of adaptations across deployments, contexts, and time, and each adaptation carries regulatory consequence. The EU AI Act's high-risk obligations attach to the deployed system in its operating configuration; the FDA's predetermined change control plan governs which adaptations may occur without re-clearance; sector-specific rules attach liability to the behavior the system actually exhibited at the time of the regulated decision. Regulation has moved past the model artifact and onto the deployment-time configuration.

Architectural Requirement

A regulatory-aware LLM deployment must structurally produce, for every adaptation that affects regulated behavior, a verifiable record of what changed, under whose authority, against which pre-cleared scope, and with what pre-activation evaluation. The EU AI Act's Article 9 risk management, Article 10 data governance, Article 13 transparency, Article 14 human oversight, Article 15 accuracy and robustness, and Article 17 quality management obligations each presume a system whose adaptations are governable; the FDA's predetermined change control plan presumes a deployer who can demonstrate that each adaptation falls within the cleared scope; OMB M-24-10's testing and oversight obligations presume an agency that can produce evidence on demand.

The architectural property required is therefore an adaptation substrate independent of the underlying model. Each adaptation — a fine-tune, an adapter weight set, a retrieval configuration, a system-prompt revision, a tool-use policy — must be produced as a signed artifact bound to its authoring authority, must pass a sandbox pre-activation certification against the deployment's regulatory profile, must activate only when the runtime context matches the cleared scope, and must remain portable across model substrates so that vendor lock-in does not foreclose regulatory transfer of the system.

The requirement is structural rather than procedural because the regulatory artifacts the supervisory authority will inspect — technical files under EU AI Act Annex IV, predetermined change control plan filings with the FDA, agency AI use case inventories under OMB M-24-10 — are evidence of the system's adaptive behavior, not narrative about the deployer's process. A deployment that cannot produce signed adaptation artifacts on demand cannot satisfy the documentation obligations regardless of the maturity of its policy posture.

Why Procedural and Bolt-On Compliance Fails

The dominant deployment pattern treats LLM adaptation as a vendor-internal concern: prompts are updated through a console, fine-tunes are applied through a managed service, retrieval indexes are rebuilt by an opaque pipeline, and the deployer is expected to produce compliance evidence after the fact from logs that may or may not have captured the adaptation event. This pattern fails the regulatory standard in three structural ways. First, an adaptation handled inside the model service produces no artifact the deployer controls; the EU AI Act's Article 17 quality management obligations and Article 18 documentation retention obligations cannot be satisfied by reference to vendor-internal records the deployer cannot independently verify.

Second, sandbox pre-activation evaluation cannot be retrofitted to a deployment whose adaptations are applied silently. The FDA's predetermined change control plan presumes that each adaptation is evaluated against the cleared scope before it affects deployed behavior; an adaptation that activates without prior certification has, by definition, exceeded the cleared scope at the moment of activation. The same gap defeats Article 14 human oversight: the human cannot oversee an adaptation they did not see.

Third, vendor-internal adaptation is not portable. When a deployment must migrate across model substrates — for cost, performance, regulatory, or vendor-continuity reasons — the adaptation history collapses, and the regulatory profile must be re-established from scratch. Article 25's distribution and Article 26's deployer obligations both presume a system whose configuration can be carried forward; the bolt-on pattern produces a system whose configuration is hostage to a single vendor.

What The Spatial-Adaptation Primitive Provides

The Adaptive Query spatial-adaptation primitive supplies a runtime adaptation substrate that the deployer owns and that the regulator can inspect. Runtime signed artifacts produce, for every adaptation — fine-tune, adapter, retrieval configuration, system prompt, tool-use policy, safety filter — a cryptographically signed artifact bound to the authoring authority, the timestamp of authorship, the targeted deployment scope, and the regulatory profile under which the adaptation was authored. The artifact is the unit of adaptation; nothing affects deployed behavior unless it is expressed as an artifact, and every artifact carries its authority and scope structurally.

Sandbox pre-activation certification evaluates each artifact against the deployment's regulatory profile before the artifact is permitted to affect production behavior. The sandbox runs the deployment's evaluation suite — accuracy, robustness, safety, fairness, jurisdictional constraints — against the artifact in isolation, producing a certification record that the deployer can present as Article 9 risk management evidence, as FDA predetermined change control plan compliance, and as OMB M-24-10 testing evidence. An artifact that fails certification cannot activate; an artifact that activates carries its certification record forward.

Cross-model portability ensures that adaptation artifacts survive substrate migration. The artifact's regulatory profile, authority binding, and certification record are expressed in a model-independent form, so that migration from one foundation model to another preserves the deployment's regulatory posture rather than collapsing it. The substrate decouples the regulated behavior from the underlying model, satisfying Article 25 and Article 26 obligations across vendor transitions and protecting the deployer from vendor-continuity risk.

Regulatory-aware activation gates each artifact's runtime effect on the actual operating context: jurisdiction, user category, use-case classification, sector-specific rules. An artifact authored for high-risk Annex III deployment will not activate in a context that exceeds its cleared scope; an artifact authored for a non-EU jurisdiction will not activate when the user is identified as an EU resident under Article 2 territorial scope; an FDA-cleared adaptation will not activate outside the cleared indication. The substrate enforces scope structurally, so that Article 14 human oversight, Article 50 transparency, and FDA post-market surveillance obligations attach to the actual behavior the user encountered rather than to a hypothetical configuration.

Compliance Mapping

Runtime signed artifacts map directly to EU AI Act Article 11 technical documentation, Article 17 quality management system, Article 18 documentation retention, and Annex IV technical file content. Each artifact is the documentation unit that Annex IV anticipates, signed and retained as a structural property of the deployment. Sandbox pre-activation certification maps to Article 9 risk management, Article 15 accuracy and robustness, the AI Act regulatory sandbox provisions of Articles 57 through 63, and to the FDA predetermined change control plan's evaluation obligations.

Cross-model portability maps to Article 16 provider obligations and Article 26 deployer obligations across vendor transitions, to the NIST AI RMF Map and Manage functions, and to the agency AI use case inventory and impact assessment obligations under OMB M-24-10. Regulatory-aware activation maps to Article 14 human oversight, Article 50 transparency obligations, the territorial scope of Article 2, the sector-specific rules issued by U.S. agencies under their statutory authorities, and to FDA post-market surveillance under the lifecycle management framework.

Across the substrate, the General-Purpose AI Model obligations of Articles 51 through 56 — including the systemic-risk evaluation, incident reporting, and Code of Practice obligations — acquire the deployment-side artifact a foundation model provider's obligations alone cannot supply. The mapping is not a substitute for conformity assessment, FDA submission, or agency impact assessment, but it supplies the architectural property without which those processes are reconstruction rather than verification.

Adoption Pathway

Adoption proceeds at the artifact tier, the deployment tier, and the portfolio tier. At the artifact tier, every adaptation event is wrapped as a signed artifact with authority, scope, and regulatory-profile metadata; existing vendor-internal adaptations are exported into the substrate or retired. At the deployment tier, the sandbox certification suite is configured against the deployment's regulatory profile, and runtime activation gates are wired to the operating context signals — jurisdiction, user category, use-case classification — that the regulatory profile depends on.

At the portfolio tier, deployments across jurisdictions and sectors share the substrate so that a single adaptation can be authored once, certified for each profile, and activated where its scope is satisfied. The pathway aligns with the EU AI Act phased application schedule through August 2027, with FDA lifecycle management guidance maturation, and with the NIST AI RMF adoption cycle, allowing deployers to retire bolt-on compliance gaps incrementally rather than waiting for a regulatory inspection to force the issue.