AI control plane

The AI control plane is the set of services that decide what an AI request is allowed to do and produce the evidence of that decision. The control plane carries identity verification, payload classification, policy lookup, and per-decision audit writing. The data plane is the request path itself: the caller, the gateway, the LLM endpoint. The control plane gives the data plane its rules at request time and consumes the per-decision records the data plane emits.

How an AI control plane is composed

The control plane has four working parts. The identity provider issues verified subject claims (JWT, SSO session, mTLS certificate, workload identity token). The classification model labels the prompt and completion content. The policy decision point evaluates the verified subject, the route, the classification, and the policy version, and returns pass or block with a reason code. The audit writer persists a signed per-decision record to a store with independent write-path access from the calling application. EU AI Act Article 12 traceability obligations and NIST AI RMF action lineage both expect this separation between deciding and recording, since an application that records its own decisions also defines what it remembers.

Why the data plane stays thin

The gateway in the data plane terminates TLS, forwards the decision request to the control plane, and applies the verdict. Keeping the data plane thin holds enforcement latency under 50 ms in the published DeepInspect benchmark and gives operators a single place to change policy. A policy update at the control plane takes effect at the next request; the gateway code does not change. The Fannie Mae Lender Letter LL-2026-04 requirement to produce per-decision evidence on August 6, 2026 sits on the control plane's audit store, not on application logs.

Related reading

  • AI Inline Enforcement Architecture: Where the Policy Decision Sits and What It Has To Commit

    AI inline enforcement runs the policy decision in the request path, before the model API call returns to the calling application. The architecture places a deterministic policy decision point between the application identity and the model endpoint and commits a per-decision audit record before the response forwards. This piece walks through the architectural components, the decision-time data shape, the failure modes the implementation has to handle, and the regulatory profile that the inline placement satisfies (EU AI Act Article 12, NIST AI agent identity and authorization Pillar 2 and Pillar 3, Fannie Mae LL-2026-04, DORA Article 6).

  • Identity-Aware AI Gateway Architecture: How Inline Enforcement Binds Decisions to Users and Agents

    An identity-aware AI gateway sits at the AI request boundary, attaches verified identity context to every model API call, evaluates per-route and per-role policies, and commits a per-decision audit record before the model response returns to the calling application. The architecture closes the post-authentication gap that most enterprise AI deployments have inherited from the credential-pooling pattern used by SDKs and proxy frameworks. This piece walks through the architectural building blocks, the call path, the audit primitives, and where the identity-aware gateway sits relative to existing IAM, API gateway, and DLP infrastructure.

  • AI Audit Logs: The Format Spec That Survives EU AI Act, DORA, and Fannie Mae Review

    AI audit logs that survive regulatory review carry a specific set of fields the EU AI Act Article 12, DORA Article 19, Fannie Mae LL-2026-04, NIST AI RMF, and HIPAA all expect on the same record. The fields cover identity, decision provenance, model identity, policy state, and integrity metadata. The format has to support per-record retrieval and per-series replay. The write path has to sit outside the application so the application cannot modify the record. This piece walks through the field-level format specification, the integrity model, the storage characteristics, and the deployment pattern that produces records the regulator and the customer auditor will accept.