1. The Compliance Illusion

Every legal-tech RAG platform shipping into the EU market in 2026 has an "Approve" button. The lawyer reads the AI-generated clause summary, clicks approve, and the output enters the workflow. The vendor's compliance documentation cites this interaction as satisfying EU AI Act Article 14 — "Human Oversight."

It does not.

Article 14 does not require a human to see the output. It requires the deployer to ensure that natural persons exercising oversight are enabled to "properly monitor" the high-risk AI system, "interpret" its output, and "decide not to use" it or to "intervene" on it. A binary approve/reject button over a fully-rendered response satisfies none of these conditions. The lawyer cannot monitor the inference process. The lawyer cannot interpret which claims are grounded and which are fabricated. The lawyer's only intervention mechanism — clicking "reject" — triggers a full regeneration with no guarantee that the same failure mode won't repeat.

This is the compliance illusion that is currently embedded in the architecture of nearly every legal-tech RAG system entering regulated markets. It is not a UI problem. It is a structural deficiency in the generation path — and it creates bilateral liability exposure that no amount of prompt engineering can resolve.

Warning

Bilateral Liability. The EU AI Act creates exposure for both the platform operator (as a deployer of a high-risk AI system under Articles 14–15) and the practising lawyer (under SRA Principle 2 / ABA Model Rule 1.1 / Codice Deontologico Forense Articles 9 and 12) simultaneously. A single fabricated citation that passes through the "approve" button and reaches a tribunal creates a compliance incident for the vendor's Article 15 (Accuracy) obligations and a professional conduct violation for the lawyer's duty of competence — regardless of whether the lawyer clicked "approve" in good faith.

This article breaks down why the standard approve/reject pattern fails under regulatory scrutiny, identifies the four specific compliance gaps it creates, and presents the deterministic architectural safeguards — entity masking, forced-intervention routing, in-flight NLI verification, and shadow AI telemetry — that convert human oversight from a UI fiction into a mechanistic, auditable compliance property.

The analysis draws on architectural patterns validated across multiple legal-tech RAG engagements and is grounded in the specific regulatory provisions that enterprise procurement teams evaluate during TPRM (Third-Party Risk Management) questionnaires.

2. The Regulatory Physics: What the EU AI Act Actually Requires

2.1 Article 14 — Human Oversight: The Three Conditions

Article 14(4) of the EU AI Act specifies that natural persons assigned to exercise oversight must be enabled to:

The gap is structural, not cosmetic. The approve/reject pattern was designed for human workflows where a senior lawyer reviews a junior's draft — a context where the reviewer has full domain expertise, can independently verify every claim, and operates under professional obligations to do so. When the "junior" is an LLM generating text at 80 tokens/second from a 6M-document corpus, the reviewer cannot independently verify the claims, cannot observe the generation process, and has no mechanism to intervene at a granular level. The supervisory model breaks.

2.2 Article 15 — Accuracy: The Measurement Gap

Article 15 requires that high-risk AI systems achieve "an appropriate level of accuracy" — and that this accuracy is "communicated to the deployer."

This creates a specific technical obligation: the platform must measure accuracy, not just assert it. A marketing claim of "sub-1% hallucination rate" based on aggregate benchmark scores does not satisfy Article 15 unless the deployer can verify the claim against their specific use case and the system provides ongoing accuracy telemetry — not just a one-time evaluation.

Our own engagements have documented systems marketed with sub-1% hallucination guarantees that exhibited 100% failure rates on structurally predictable query classes — systems that passed aggregate benchmarks while catastrophically failing on article-number collisions, cross-statute retrieval, and fabricated sub-clause traps. Aggregate accuracy is not accuracy. It is an average that conceals failure modes.

Article 15 compliance requires:

1. Per-query grounding verification — not post-hoc batch evaluation, but runtime verification of each generated claim against its source evidence.
2. Continuous accuracy telemetry — a live dashboard tracking hallucination rate, retrieval precision, and grounding coverage over time, accessible to the deployer.
3. Failure-mode documentation — explicit disclosure of known query classes where the system's accuracy degrades (e.g., shared identifier collisions, multi-statute ambiguity, temporal law conflicts).

2.3 Article 10 — Data Governance: The Ingestion Leak

Article 10 requires that training, validation, and testing datasets be "relevant, sufficiently representative, and to the best extent possible, free of errors." For RAG systems, the "dataset" is not the LLM's training data — it is the document corpus ingested into the vector database. This shifts the data governance obligation from the model provider to the platform operator.

The compliance implication is direct: if the ingestion pipeline stores unmasked PII, confidential client data, or privileged legal communications in the vector database, the system's data governance controls are deficient under Article 10 — regardless of whether the generation model itself is compliant.

This is where entity masking becomes a compliance requirement, not a privacy feature.

3. The Four Compliance Gaps in Standard Legal RAG Architectures

Based on our architectural assessments across multiple legal-tech RAG platforms, the following four gaps appear with near-universal frequency. Each gap maps to a specific regulatory provision and creates a specific failure mode that enterprise TPRM questionnaires are designed to surface.

Gap 1: No Per-Sentence Grounding Verification (Articles 14 & 15)

The Pattern: The platform generates a complete multi-sentence response, then either (a) ships it directly to the user with no verification, or (b) runs a post-hoc verification gate that evaluates the full response after generation.

The Failure Mode: As documented in our generation-tier case study, post-hoc verification creates a compliance-free zone between the first hallucinated token and the moment the gate fires. Contaminated tokens persist in the KV cache and condition all downstream generation. The gate catches the contamination after it has propagated through the entire output.

The Compliance Consequence: The deployer cannot satisfy Article 14(4)(b) — "properly monitor operation" — because the generation path has no observable intermediate states. The output is either fully approved or fully rejected. There is no mechanism for the deployer to identify which specific claims are grounded and which are fabricated.

The TPRM Question That Surfaces This:

Describe the runtime verification controls on the AI system's output. At what granularity are generated claims verified against source evidence? Provide sample audit logs demonstrating per-claim verification with source attribution.

Gap 2: No Entity Masking on the Inference Path (Article 10)

The Pattern: The platform ingests raw legal documents — contracts, briefs, advisory memoranda — into the vector database with entity names, financial figures, and privileged communications intact. The LLM receives unmasked chunks as context.

The Failure Mode: Associates see client-identifying information displayed by the AI system. The LLM's attention mechanism cross-contaminates entity information across unrelated matters when chunks from different clients occupy the same context window.

The Compliance Consequence: Even if the platform operator has a Data Processing Agreement (DPA) in place, the display of unmasked client data to associates who may not be authorised to view that specific matter creates an internal data governance failure. For law firms operating under client ethical walls, this is a conflict-of-interest breach — not merely a privacy incident.

This gap is so pervasive — and so straightforward to eliminate — that we open-sourced our standalone masking engine for legal text: legal-rag-mask. It automatically detects and replaces sensitive entities with consistent, categorised pseudonyms, and can be integrated into any RAG ingestion pipeline in under an hour. If your platform stores unmasked legal text in a vector database, this is the fastest path to closing the Article 10 gap.

The TPRM Question That Surfaces This:

How does the system prevent cross-matter data contamination in multi-tenant deployments? Describe entity isolation controls at the inference layer.

Gap 3: No Deterministic Clause Flagging & Forced Human Intervention (Article 14)

The Pattern: The platform generates contract language — including high-risk clauses involving indemnification caps, liability limitations, governing law selections, and warranty exclusions — and presents the complete output for approve/reject.

The Failure Mode: The lawyer clicks "approve" on a 15-paragraph output without independently verifying whether the indemnification cap in paragraph 9 matches the client's risk tolerance. The approve action is a blanket acceptance, not a clause-level review.

The Compliance Consequence: Article 14(4)(d) requires the user to be able to "intervene on the operation" of the AI system. Clause-level intervention requires clause-level visibility. A system that renders 15 paragraphs and offers one button provides no intervention granularity.

The TPRM Question That Surfaces This:

Does the system flag high-risk legal terms (indemnification, warranty, liability caps) for mandatory human review before document generation completes? Describe the flagging logic and the forced-intervention mechanism.

Gap 4: No Shadow AI Detection (Articles 14 & 15)

The Pattern: The platform provides AI-assisted legal research or drafting. Associates also have access to public LLMs (ChatGPT, Claude, Gemini) via personal devices or browser tabs. When the internal tool is slow, frozen, or produces unhelpful output, associates copy-paste content from public LLMs into the internal workflow.

The Failure Mode: The platform's audit trail records the associate's input as "human-authored" content that passed through the approve gate. The platform's accuracy telemetry does not flag externally-generated content. The firm's compliance controls have a blind spot: AI-generated text from an unmonitored, unaudited external source has entered a privileged legal workflow and been attributed to a human author.

The Compliance Consequence: Under Article 14, the deployer must be able to monitor the AI system's operation. Shadow AI usage creates an invisible second AI system operating outside all monitoring, verification, and audit controls. When an associate pastes a ChatGPT-generated paragraph into the internal tool and clicks "approve," the firm's compliance record shows a human-authored, human-approved output — but the actual provenance is an uncontrolled external LLM with no professional liability, no DPA, and no accuracy guarantee.

Under SRA Principle 2 (uphold public trust) and Principle 7 (act in the client's best interests), a solicitor who submits externally-AI-generated text as their own work product without independent verification is breaching professional conduct — and the firm's platform provided no mechanism to detect or prevent it.

The TPRM Question That Surfaces This:

How does the system detect and flag content pasted from external AI tools? Describe the anti-shadow-AI controls and the escalation workflow.

4. The Engineering Overhaul: Four Deterministic Compliance Safeguards

Each safeguard maps to a specific gap identified in §3 and is designed to convert human oversight from a passive UI checkbox into an active, mechanistic, auditable compliance property.

Safeguard A: Entity Masking Engine — Pre-Display Sanitisation

Gap Addressed: Gap 2 (Article 10 — Data Governance)

The Principle: The associate never sees raw entity data. The system masks all identifying entities before display and rehydrates them after human review and approval — ensuring that the lawyer's cognitive engagement is with the legal substance, not the client identity.

The Architecture:

flowchart LR
    subgraph Ingestion ["Ingestion Path"]
        direction TB
        D[Raw Document] --> P[NER Extraction<br/>spaCy + Custom Legal NER]
        P --> M["Entity Registry<br/>(Encrypted, Per-Matter)"]
        P --> C[Masked Chunks<br/>→ Vector DB]
    end

    subgraph Inference ["Inference Path"]
        direction TB
        Q[User Query] --> R[Retrieve<br/>Masked Chunks]
        R --> G[LLM Generation<br/>with Masked Context]
        G --> Display["Display to Associate:<br/>[Client_Entity_A] acquires<br/>[Target_Entity_B] for<br/>[Consideration_Value_1]"]
    end

    subgraph Rehydration ["Post-Approval Rehydration"]
        direction TB
        Display --> Approve{Associate<br/>Approves?}
        Approve -->|Yes| Rehydrate["Rehydrate Entities<br/>from Registry"]
        Rehydrate --> Final[Final Document<br/>with Real Names]
        Approve -->|No| Edit[Associate Edits<br/>Masked Draft]
    end

What the associate sees:

Why this matters for compliance:

1. Cross-matter contamination is eliminated. The LLM never receives unmasked entity names in its context window. Even if chunks from different matters are accidentally co-retrieved, the masked tokens carry no identifying information.
2. Ethical wall enforcement becomes architectural. The masking is not a UI layer that can be bypassed — it operates at the vector database level. The chunks stored in the index are pre-masked. There is no "view unmasked" toggle.
3. The Entity Registry is per-matter, encrypted, and access-controlled. Rehydration requires matter-level authorisation. An associate working on Matter A cannot rehydrate entities from Matter B — the registry enforces the wall.

The core NER extraction and pseudonymisation logic powering this safeguard is available as an open-source reference implementation: legal-rag-mask. It ships with pre-configured entity categories for legal text (parties, monetary values, dates, section references, jurisdiction markers), deterministic pseudonym generation for cross-document consistency, and a rehydration API for post-approval entity restoration. Drop it into your ingestion pipeline to close the Article 10 gap before your next TPRM review.

Safeguard B: Deterministic Red-Teaming & Forced Intervention Routing

Gap Addressed: Gap 3 (Article 14 — Granular Human Intervention)

The Principle: Before a generated document is presented for approval, a secondary deterministic classifier scans every sentence for high-risk legal terms and forces a hard UI gate — a mandatory human review — on flagged clauses. The associate cannot approve the document without explicitly acknowledging each flagged clause.

The Architecture:

A lightweight classifier (fine-tuned 8B or a rule-based spaCy pipeline) scans the generated output for a configurable lexicon of high-risk terms:

sequenceDiagram
    participant LLM as Generation Tier
    participant Clf as Clause Classifier
    participant UI as Associate Interface
    participant Log as Audit Trail

    LLM->>Clf: Document (15 paragraphs)
    Clf->>Clf: Scan trigger terms
    Note over Clf: 3 flags: ¶9, ¶12, ¶15

    Clf->>UI: Render with 3 hard gates
    Note over UI: ¶9: Indemnification<br/>¶12: Warranty<br/>¶15: Governing Law

    UI->>UI: Review ¶9
    UI->>Log: Indemnification confirmed
    UI->>UI: Review ¶12
    UI->>Log: Warranty confirmed
    UI->>UI: Review ¶15
    UI->>Log: Jurisdiction confirmed
    UI->>LLM: All gates cleared
    Log->>Log: Finalise review record

The compliance property this creates: The audit trail records not just that the associate approved the document, but which specific high-risk clauses they reviewed, what they confirmed against the client mandate, and when they confirmed it. This converts Article 14(4)(d) compliance from "the user had a button" to "the user made three documented, clause-level intervention decisions."

Safeguard C: In-Flight NLI Verification — Sentence-Level Grounding Assurance

Gap Addressed: Gap 1 (Articles 14 & 15 — Accuracy & Monitoring)

The Principle: Every factual claim in the generated output is verified against its source evidence during generation — before downstream tokens are conditioned on potentially fabricated content. This is not post-hoc validation. It is a real-time compliance control operating on the generation path.

This mechanism has been deployed and validated in production across our legal-tech engagements. The full architectural specification — including the KV cache truncation mechanism, the RadixAttention tree fork, and the three-state compliance machine — is documented in our generation-tier integrity case study.

The core loop (summary):

flowchart TD
    subgraph Generation ["In-Flight Generation Loop"]
        G["LLM generates<br/>sentence buffer"] --> A["8B NLI Auditor<br/>compares sentence<br/>against ColBERT<br/>sub-spans (~50 words)"]
        A --> V{Verdict?}
        V -->|ENTAILMENT| Lock["Lock KV cache state<br/>Stream verified text<br/>to user"]
        V -->|CONTRADICTION| Trunc["Truncate KV cache<br/>to last verified token<br/>Inject corrective prefix<br/>Resume generation"]
        V -->|NEUTRAL| Pass["Allow passage<br/>(no factual claim)"]
        Lock --> G
        Trunc --> G
        Pass --> G
    end

    Lock --> Log["Audit Trail:<br/>sentence verified,<br/>source sub-span hash,<br/>confidence score"]
    Trunc --> Log
    Pass --> Log

Key implementation details:

1. The auditor receives ~50-word sub-spans, not full 500-word chunks. ColBERT's token-level MaxSim scores extract the specific evidentiary sub-span that supports or contradicts the generated claim. This keeps the DeBERTa/MiniLM cross-encoder within its effective input window and provides precise audit provenance.

2. KV cache truncation eliminates contaminated state during inference. When the auditor detects a contradiction, the inference engine truncates the KV cache back to the last verified sentence and resumes with a corrective context prefix. This operation — available on self-hosted inference engines (vLLM/SGLang) but not on proprietary API endpoints — mechanically deletes the model's "memory" of the fabricated content.

3. The latency cost is ~120ms per rollback vs. 8–12 seconds for full regeneration.

$$\boxed{t_{\text{rollback}} + t_{\text{corrective}} \approx 120\text{ms} \quad \text{vs.} \quad t_{\text{full\_regeneration}} \approx 8{,}000\text{–}12{,}000\text{ms}}$$

4. The audit trail records every verification decision. Each sentence in the final output carries a structured log entry: verdict (entailment/contradiction/neutral), confidence score, source sub-span hash, and KV cache action. This log satisfies four compliance functions: decision traceability, anomaly detection, incident forensics, and continuous compliance monitoring.

Sample audit log entry (abridged):

{
  "sentence_index": 3,
  "text": "The indemnification obligation under Section 8.3 is capped at...",
  "verdict": "ENTAILMENT",
  "confidence": 0.92,
  "source_subspan": {
    "chunk_id": "contract-msa-v4-s8",
    "token_range": [142, 197],
    "subspan_hash": "sha256:a4f2c8..."
  },
  "kv_cache_action": "LOCKED",
  "latency_ms": 18.7
}

The compliance property this creates: Article 15 accuracy is no longer a marketing claim — it is a runtime measurement, produced per query, stored in a tamper-evident log, and available for deployer inspection. Article 14(4)(b) monitoring is satisfied because every sentence's grounding status is observable and recorded. The deployer does not need to trust the model — they can verify the audit trail.

Safeguard D: Anti-Shadow AI Telemetry & Log Diffing

Gap Addressed: Gap 4 (Articles 14 & 15 — Shadow AI Detection)

The Principle: The platform must detect when an associate pastes content from an external AI tool into the internal workflow. This is not surveillance — it is a compliance control that ensures the firm's audit trail accurately represents the provenance of its work product.

The Architecture:

flowchart TD
    subgraph Input ["Associate Input Analysis"]
        I[Associate pastes<br/>text into editor] --> Diff{"Text matches<br/>internal LLM<br/>generation log?"}
        Diff -->|Yes| OK["Provenance confirmed:<br/>internal generation"]
        Diff -->|No| Flag["⚠️ EXTERNAL CONTENT<br/>DETECTED"]
    end

    subgraph Escalation ["Compliance Escalation"]
        Flag --> Block["Block submission<br/>pending review"]
        Block --> Log2["Log: external content<br/>flagged, timestamp,<br/>associate ID,<br/>text fingerprint"]
        Log2 --> Notify["Notify compliance<br/>officer"]
    end

Detection mechanism: The platform maintains a generation log — a record of all text produced by the internal LLM for each session. When an associate submits or pastes text into the editing interface, the system computes a similarity fingerprint against the generation log.

If the submitted text does not match any internally-generated output for that session, it is flagged as externally-sourced. The system does not need to identify which external tool produced the text — only that it was not generated by the internal system.

The compliance property this creates: The firm's audit trail becomes provenance-aware. Every text element in the final document carries a provenance tag: internally generated and verified, human-authored, or externally-sourced (flagged). This converts the firm's compliance posture from "we have an approved AI tool" to "we have verified provenance for every claim in our work product."

5. The Compliance Verification Architecture: Making Accuracy Auditable

The four safeguards above produce a continuous stream of structured telemetry. This section describes how that telemetry is aggregated into the compliance artifacts that TPRM evaluators, ISO 42001 auditors, and EU AI Act conformity assessments require.

5.1 The Live Evaluation Dashboard

The platform exposes a real-time dashboard tracking four metrics:

This dashboard is not a development tool. It is a compliance artifact — designed to be shared with the deployer's compliance officer and presented during TPRM evaluations.

5.2 The Regulatory Crosswalk

Each safeguard maps to specific provisions across multiple regulatory frameworks:

This crosswalk is not theoretical. It is a pre-filled artifact — designed to be attached to a CAIQ (Consensus Assessments Initiative Questionnaire) or SIG Lite response and handed to a TPRM evaluator during the first compliance conversation.

6. The Unit Economics: Compliance Architecture as a Cost Reduction

A natural objection from engineering leadership: "This adds complexity and latency. We can't afford it."

The economics argue the opposite. Compliance architecture reduces the platform's OPEX — because the alternative (post-hoc verification on proprietary APIs) is structurally more expensive.

6.1 The Hallucination Tax (Recap)

As documented in our generation-tier case study, the standard post-hoc verification pattern creates a permanent per-query OPEX penalty — the Hallucination Tax:

$$C_{\text{tax}} = r \cdot C_{\text{gen}} + r \cdot T_{\text{out}} \cdot P_{\text{out}}$$

At a 20% hallucination rate on specialised legal queries (Stanford RegLab, Magesh et al. 2025):

$$\boxed{C_{\text{tax}} = \$0.0057 \text{ per query} = 22\%\text{+ permanent OPEX overhead on the generation path}}$$

6.2 The Compliance Architecture Cost Structure

The in-flight NLI verification (Safeguard C) replaces this tax with a fundamentally cheaper cost structure:

The entity masking engine (Safeguard A), the clause classifier (Safeguard B), and the shadow AI detector (Safeguard D) all run on local CPU inference — spaCy NER, rule-based pattern matching, and log diffing respectively. Their marginal compute cost is effectively zero.

The counterintuitive conclusion: building the compliance architecture is cheaper than not building it — because the alternative (post-hoc verification on proprietary APIs) carries a permanent, compounding OPEX penalty that the compliance architecture eliminates.

7. The Structural Prerequisite: Self-Hosted Inference

Every safeguard described in this article requires one architectural prerequisite: the ability to observe and control the generation state during inference.

This means self-hosted open models (Llama 3, Qwen, Mistral) deployed on dedicated GPU instances, fronted by an inference engine (vLLM, SGLang) that exposes the KV cache for selective truncation.

Proprietary API endpoints (OpenAI, Anthropic, Google) do not expose this control surface. They offer a request/response interface where the application sends a prompt and receives a completed response. The application cannot:

• Inspect the KV cache state during generation
• Selectively truncate tokens on contradiction detection
• Inject corrective context mid-generation
• Fork the attention tree at verified checkpoints

This is not a criticism of proprietary APIs. They are optimised for developer velocity and are the correct choice for general-purpose applications. But in regulated domains requiring inference-time compliance controls, the proprietary API boundary creates a structural ceiling on the granularity of human oversight that the architecture can provide.

Important

The open model transition is not about cost or model quality. It is about architectural access to the compliance control surface. A self-hosted Llama 3 70B with in-flight NLI verification produces a more compliant system than a proprietary GPT-4o with post-hoc validation — not because it is a better model, but because the inference engine exposes the state required for deterministic oversight controls.

The economics of self-hosting have shifted dramatically. With recent advances in open models (GLM 5.2, Kimi K3, Llama 3.1), the capability gap between open and proprietary models has narrowed to the point where the compliance benefits of self-hosting outweigh any residual quality differential for deterministic legal RAG tasks.

8. Lessons for Legal-Tech Builders

1. Human oversight is an architectural property, not a UI feature.

A button is not oversight. Article 14 requires the user to understand the system's limitations, monitor its operation, and intervene at a meaningful granularity. If the only intervention mechanism is accept/reject on a fully-rendered response, the architecture does not satisfy the provision — regardless of how the compliance documentation frames it.

2. Accuracy must be measured at runtime, not asserted from benchmarks.

Article 15 requires that accuracy be "communicated to the deployer." A marketing claim derived from a one-time benchmark evaluation does not satisfy this. The deployer needs continuous, per-query accuracy telemetry — hallucination rate, grounding coverage, retrieval precision — accessible via a live dashboard and backed by structured audit logs.

3. Entity masking is a compliance requirement, not a privacy feature.

For law firms operating under client ethical walls, unmasked entity data in the LLM's context window creates cross-matter contamination risk that violates professional conduct rules (SRA Principle 6, ABA Rule 1.6) — independently of any GDPR or data protection obligation. Masking must occur at the vector database level, not as a UI overlay.

4. Shadow AI is the compliance blind spot nobody is testing for.

Every firm with an internal AI tool and associates with browser access has a shadow AI problem. If the platform's audit trail cannot distinguish between internally-generated and externally-pasted content, the firm's compliance record is unreliable — and the platform is providing a false sense of provenance assurance.

5. The compliance architecture is cheaper than the alternative.

The Hallucination Tax — the permanent OPEX penalty created by post-hoc verification on proprietary APIs — compounds linearly with query volume. In-flight NLI verification eliminates 95% of the waste per hallucination event and reduces remediation latency by 100×. Building compliance controls is not an additional cost — it is the elimination of a structural inefficiency that most platforms don't know they're paying.

9. TL;DR

The EU AI Act's human oversight requirements (Article 14) cannot be satisfied by an "approve" button over a fully-rendered AI response. The lawyer cannot monitor the generation process, cannot identify which claims are grounded, and cannot intervene at clause level. Article 15's accuracy requirements cannot be satisfied by aggregate benchmarks that conceal catastrophic failure modes on predictable query classes.

Four deterministic safeguards convert compliance from a UI fiction into an auditable architectural property:

The compliance architecture is not an additional cost layer. It is a structural cost reduction — eliminating the 22%+ OPEX penalty (the "Hallucination Tax") that post-hoc verification on proprietary APIs creates. Building deterministic oversight controls is cheaper than not building them.

The only prerequisite is self-hosted inference — not for model quality, but for architectural access to the generation state that deterministic compliance controls require.