Runtime LoRA Loading With Admissibility Governance

Regulatory Framework

The regulatory landscape for adapter-based language model customization has tightened significantly. EU AI Act Article 26 places explicit obligations on deployers of high-risk AI systems: human oversight, input data governance, monitoring, logging, and the ability to demonstrate that the system in production matches the system that was conformity-assessed. When the deployment ingests a LoRA or QLoRA adapter at runtime, the adapter is part of the system in production, and the obligation to demonstrate conformity extends to the adapter's authority, training data lineage, and intended use. Article 50 transparency obligations and the General Purpose AI Code of Practice further constrain how adapter-modified outputs are disclosed.

In the United States, Executive Order 14110 directed federal agencies to manage model access, evaluation, and red-teaming in ways that presume controllable adapter inventories. NIST AI RMF 1.0 frames the GOVERN, MAP, MEASURE, and MANAGE functions in terms of artifact provenance and lifecycle controls that adapter distribution must satisfy. ISO/IEC 42001 codifies AI management system requirements that auditors will increasingly map to adapter-level evidence. Sectoral regulators add their own layer: HIPAA for health, FINRA and SEC guidance for finance, FERPA for education, GDPR Article 22 for automated decision-making in any sector touching EU data subjects.

The technical ecosystem has matured in parallel. HuggingFace PEFT is the dominant distribution mechanism for LoRA and QLoRA adapters. OpenAI's fine-tuning lifecycle exposes adapters as managed resources. Sigstore provides cryptographic signing for adapter artifacts. Model cards (Mitchell et al., now formalized in regulatory guidance) document intended use, training data, evaluation results, and known limitations. MLOps platforms (Weights and Biases, MLflow, Vertex AI, SageMaker) track training runs and artifact lineage. None of these supplies the runtime admission decision: which adapter applies to this inference, under this deployer's policy, for this consumer, in this jurisdiction.

Architectural Requirement

The structural requirement implied by this regulatory layer is that every adapter loaded at inference time must carry a verifiable lineage and an enforceable admissibility decision. The lineage must reach back to the training data the adapter was fit on, the base model version it was fit against, the evaluation suite it was certified by, the authority that signed the certification, and the intended-use scope the certification covers. The admissibility decision must be made at the runtime boundary, by the deployer, against a policy that the deployer can articulate and that an auditor can later reconstruct.

The admissibility decision is not a single boolean. It is a composition of conditions: is the adapter compatible with the base model currently loaded; is the adapter's certifying authority still in good standing; is the inference request inside the adapter's intended-use scope; does the consumer's policy permit the adapter's training data provenance; is the adapter's revocation status current; does the deployer have audit-grade logging configured for adapter-modified inferences. The composition must be evaluated at every inference, and the result must itself be a credentialed observation that flows into the deployer's monitoring pipeline.

The architecture must also accommodate a personal-layer carve-out. End users increasingly fine-tune adapters on their own devices and on their own data; the deployer's admissibility policy must distinguish between adapters issued under enterprise authority and adapters issued under personal authority, and must compose the two without leaking personal training data into the enterprise audit trail.

Why Procedural Compliance Fails

The dominant pattern in production LoRA deployment today is procedural compliance: the deployer maintains a registry of approved adapters, an internal review board signs off on new adapters before they enter production, and an MLOps platform tracks which adapter is loaded at any given time. This pattern is sufficient for a single-tenant deployment with a small adapter inventory and a homogeneous regulatory regime. It fails on the conditions that EU AI Act Article 26 and NIST AI RMF actually anticipate.

Procedural compliance fails the multi-tenant problem. When a SaaS deployer serves customers across regulatory jurisdictions, the admission decision for an adapter depends on which tenant's request is being served, and the procedural registry cannot encode that dependency without per-tenant manual configuration that drifts out of sync with the underlying policy.

Procedural compliance fails the revocation problem. When an adapter's certifying authority loses standing — the training data is found to have been scraped without consent, the evaluation suite is found to have been gamed, the upstream model card is found to have misrepresented intended use — the procedural answer is to email the operations team and ask them to remove the adapter from the registry. By the time the removal propagates, the adapter has continued to serve inferences for hours or days, and the audit trail is contaminated.

Procedural compliance fails the personal-layer problem. When end users bring their own adapters, the procedural registry has no mechanism for distinguishing personal from enterprise authority, and the deployer either rejects all personal adapters (foreclosing a major use case) or admits them without governance (creating an audit liability the regulator will eventually surface). Procedural compliance fails the cascade problem when an adapter depends on another adapter that depends on a base model whose security posture has changed; the dependency graph that the credential lineage represents has no procedural analog.

What AQ Primitive Provides

The llm-skill-gating primitive supplies a credentialed adapter artifact whose lineage, authority, dependencies, intended-use scope, and revocation status are intrinsic to the artifact rather than reconstructed from external systems. The primitive operates at the layer above PEFT distribution. PEFT distributes the technical artifact — weights, architecture description, training configuration. The governance primitive adds credentialed compatibility metadata, consumer-side sandbox certification, admissibility-gate routing at inference, cascade-deactivation on revocation, and personal-layer carve-out.

Compatibility metadata binds the adapter to the base model versions it was certified against, the evaluation suites it passed, the intended-use scope, and the training data provenance class. Sandbox certification is the consumer-side counterpart: the deployer evaluates the adapter inside a controlled environment against the deployer's own policy and issues a consumer credential that admits the adapter to production for the specific deployment context. The two credentials compose at inference time through the admissibility gate, which evaluates the composition against the consumer policy and emits a credentialed admission observation that flows into the deployer's monitoring pipeline.

Cascade-deactivation propagates revocation through the adapter dependency graph. When an upstream authority revokes a credential — a model card author retracts a claim, a training data provider revokes consent, an evaluation suite is found to have been gamed — every downstream adapter whose lineage traces to the revoked credential is automatically marked revoked, every active inference session that loaded the adapter is flagged, and the deployer's monitoring pipeline receives a credentialed revocation observation it can act on within seconds rather than days.

Personal-layer carve-out is structural rather than procedural. Adapters issued under personal authority compose with adapters issued under enterprise authority through a policy that the deployer articulates explicitly: which inference contexts admit personal adapters, what audit trail is generated for personal-adapter inferences, what isolation boundaries protect personal training data from the enterprise audit pipeline. The carve-out is part of the credential semantics, not part of an out-of-band procedural agreement.

Compliance Mapping

EU AI Act Article 26 deployer obligations map directly to the admissibility-gate output: the credentialed admission observation is the deployer's evidence of conformity for every adapter-modified inference. Article 50 transparency obligations map to the credential's intended-use scope, which the deployer can disclose to end users without exposing internal policy. The General Purpose AI Code of Practice obligations on systemic-risk model providers map to the cascade-deactivation behavior that propagates upstream revocations.

US EO 14110 model access controls map to the adapter credential authority graph: federal agencies and federal contractors can articulate adapter inventories whose admission is governed by enforceable credentials rather than procedural review boards. NIST AI RMF GOVERN maps to the credential authority configuration; MAP maps to the adapter intended-use scope; MEASURE maps to the admissibility-gate observation stream; MANAGE maps to the cascade-deactivation behavior. ISO/IEC 42001 AI management system requirements map to the same credential lineage.

Sectoral mapping follows the same pattern. HIPAA covered-entity obligations map to the personal-layer carve-out semantics that protect protected health information used in personal adapter training. FINRA and SEC supervision obligations map to the audit-grade lineage of every adapter-modified inference in financial services. GDPR Article 22 automated decision-making obligations map to the admissibility-gate observation that documents the basis for adapter-modified outputs that affect data subjects. Sigstore signing composes underneath as the cryptographic substrate; HuggingFace PEFT and OpenAI fine-tuning lifecycle compose underneath as the distribution substrate; the credential governance is the layer above.

Adoption Pathway

Adoption proceeds incrementally and additively. The first step is internal: a deployer wraps its existing PEFT pipeline with the credential primitive and replaces the procedural registry with intrinsic credential lineage. Existing adapters are reissued with credentials; new adapters are issued credentialed from the outset. The audit posture under EU AI Act Article 26 and NIST AI RMF improves immediately because the artifacts now carry their own provenance.

The second step is bilateral: the deployer accepts adapters from external authors under their credentials, and the admissibility gate composes the external author's credential with the deployer's policy. Independent adapter authors can publish artifacts that work across consumers without negotiating per-platform admission. The third step is multi-tenant: a SaaS deployer admits adapters under per-tenant policy, and the per-tenant admissibility decision is encoded in credential semantics rather than per-tenant procedural configuration.

The fourth step is the personal layer: end users contribute personally-trained adapters under personal authority, and the carve-out semantics let the enterprise deployer admit them under articulated policy. The fifth step is cross-deployer: a credentialed adapter issued by one deployer's authority composes with another deployer's policy without renegotiation, and the regulatory burden of cross-deployer adapter mobility shifts from procedural agreement to credential semantics.

The patent positions the governance primitive that the operationalization of PEFT requires for production-grade deployment beyond research and pilot use. The regulatory framework has been written. The procedural overlay has reached its limits. The architectural primitive that satisfies the framework at scale is the credentialed adapter artifact under admissibility governance.