What configuration language does the policy use?

The deployment pattern supports YAML and JSON as the primary input formats, with optional Rego expressions for advanced conditional logic the YAML schema does not capture. The choice between formats is operational: YAML for human-readable policies the team reviews regularly, JSON for machine-generated policies that originate from a governance UI or a code generator, Rego for the small percentage of rules that need imperative evaluation. The gate evaluates all three to the same in-memory representation.

How does the policy handle exceptions for emergency operations?

The policy schema supports incident-driven temporary rules that override the default rules for a defined window. An incident response can lift the data classification denials for a specific role under a documented incident identifier; the temporary rule references the incident, expires on a defined timestamp, and reverts automatically. The audit records produced under the temporary rule reference both the standard policy version and the temporary rule, which preserves the reviewer's ability to reproduce the decision and to identify the incident context.

What happens when the policy version in the gate is older than the version in version control?

The gate pulls policy versions from version control on a configurable cadence (default 5 minutes) and caches the active version in memory. A change in version control takes effect when the gate pulls the new version, which is bounded by the cache TTL. The audit record references the version that was active at the moment of the decision. The lag between version control and the gate is documented in the deployment configuration and is bounded by the cache TTL, so the reviewer can reconstruct which version was active at which time.

Can the policy be evaluated against historical decisions?

The policy as code in version control supports historical evaluation. A reviewer takes a past audit record, looks up the policy version the record references, retrieves the policy from version control at that version, and replays the decision against the policy. The replay produces the same outcome the gate produced at the time, which is the reproducibility property the audit obligation depends on. The pattern is the same as replaying a change against a past commit in any version-controlled system.

How is the signing key for the audit records managed?

The signing key lives in the audit store's KMS or HSM. The gate signs the record at commit time using the key the audit store holds. The corporate operator does not have direct access to the key; the access path is the audit store's API, which the operator interacts with through the compliance review interface. The key rotation pattern uses the same rotation cadence the corporate KMS or HSM runs for other signing keys, and the records produced under each key version validate against the key version the record references.

AI Policy as Code: The Declarative Pattern That Makes Enforcement Auditable

AI policy as code expresses the rules that govern AI usage in a declarative configuration format checked into version control, evaluated at the AI request boundary, and versioned per decision in the audit record. The pattern is the AI extension of the policy-as-code model that infrastructure-as-code, OPA, and Kubernetes admission controllers have already proven at enterprise scale. The shift from policy as documents to policy as code matters at the AI request layer because the EU AI Act Article 12 obligation, the NIST AI RMF Govern function, and the Fannie Mae LL-2026-04 disclosure mandate all expect the policy that governed each AI decision to be reproducible after the fact. A document does not satisfy that expectation. A declarative configuration version-controlled per decision does.

I want to walk through what the policy actually contains, how the gate evaluates it, and how the audit record references it.

What the policy expresses

The AI policy expresses the rules that govern who can call which models against which data classifications for which use cases under which conditions. The expression covers identity, role, model class, data classification, use case, quota, and conditions (time of day, project membership, incident status).

The rule shape captures the four inputs the gate evaluates per request: subject (who), action (what model and use case), data classifications (what classes are permitted, redacted, or denied), and quota (how much). The conditions field adds context the gate factors in. The audit field specifies how the per-decision record is treated.

The policy is a configuration object the gate reads. It is not a document a human reads at incident review. The human reads the policy through the version control history and the audit records that reference the policy version.

How the gate evaluates the policy

The gate runs three evaluation steps per request. The first is identity resolution: the gate verifies the SSO assertion, the OIDC bearer, or the workload identity certificate the caller supplies and resolves the verified identity against the policy's subject field. The second is rule matching: the gate finds the rule or rules in the policy that match the resolved identity, the requested model class, the detected data classifications, and the use case the caller declared. The third is decision composition: the gate combines the matched rules into a single per-decision outcome (permit, redact, deny) and writes the audit record.

The evaluation is deterministic. Given the same request, the same identity context, and the same policy version, the gate returns the same outcome on every replay. The deterministic property is the architectural answer to the EU AI Act Article 9 risk management requirement that controls perform as intended across the lifecycle.

Rule conflicts are resolved by the policy's conflict-resolution clause. The standard pattern is most-specific-wins for permits, most-restrictive-wins for denies, and an explicit fallback when no rule matches. The fallback defaults to deny to satisfy the fail-closed posture.

Version control and the per-decision reference

The policy lives in version control. Every change goes through the same review process the rest of the corporate code base does: branch, change request, peer review, merge. The version control history captures who changed which rule when, what the prior rule said, and what the new rule says. The change history is the policy's evolution record.

Every decision the gate makes references the policy version in effect at the moment. The audit record carries the version identifier. The compliance reviewer reads the record, looks up the policy version, and reproduces the decision the gate made. Reproducibility is the property the audit obligation expects.

The reference is the property that distinguishes policy as code from policy as documents. A document captures the policy at one moment. The policy as code captures the policy at every moment a decision was made, because every decision references the version. The audit reviewer can answer "what was the policy when this decision was made" by reading the record.

What the audit record contains beyond the decision

The audit record carries the verified identity, the role and authorization context, the model class the caller targeted, the data classifications detected, the policy version in effect, the rules that matched, the decision outcome, the timestamp, and a tamper-evident signature. The record commits to a write path the application has no access to.

The signature is the integrity property. The audit store holds a signing key. Every record commits with a signature from the key. The compliance reviewer trusts the record by trusting the signature chain. A record without a signature is not admissible as evidence. A record with a signature that does not validate has been tampered with after commit.

The signature is part of what makes the policy-as-code pattern survive the regulator's scrutiny. The reviewer can verify that the record was produced at the time it claims, by the gate it claims, against the policy version it references. The record cannot be rewritten after the fact without breaking the signature.

How the pattern integrates with the existing change-control process

The AI policy lives in the same repository the corporate infrastructure-as-code lives in. The change-control process the corporate environment runs (peer review, approval gates, CI/CD pipelines, staged rollout, post-deployment validation) applies to the AI policy without modification.

The deployment pattern uses staged rollout. A change to a rule first deploys to a dry-run environment where the gate evaluates the change and logs the decision it would have made without enforcing it. The team reviews the dry-run logs, validates that the rule behaves as expected, and promotes the change to enforcement on a percentage ramp (10%, 50%, 100%). The pattern catches false denies before they affect production traffic.

The rollback pattern uses version control. A rule that produces unexpected denies rolls back to the prior version through a revert commit. The gate reads the new version on the next decision. The audit records produced under the prior version remain valid; the records produced under the rolled-back version remain valid as well. The version control history captures the rollback.

What the 2026 compliance set expects from the policy layer

EU AI Act Article 9 risk management expects documented controls that perform as intended across the lifecycle. The policy as code is the documented control. The version control history is the lifecycle evidence. The August 2, 2026 deadline applies.

Article 12 logging expects the records to be reproducible. Policy as code with per-decision version references is the reproducible pattern. Article 19 specifies the content (timestamps, input data, identity of natural persons, retention floor of six months). The audit record the policy gate writes satisfies the content requirement structurally.

NIST AI RMF Govern function expects accountability for policy. The version control history captures the accountability (who changed what when, with what approval). Manage function expects incident response evidence. The audit record is the evidence. ISO 42001 clauses 8.2 and 8.3 expect operational controls that produce evidence on demand. The policy gate is the operational control.

Fannie Mae LL-2026-04, effective August 6, 2026 per the Cooley legal analysis, expects lenders to produce evidence of how AI tools handled specific decisions. The policy-as-code pattern produces the evidence per decision. Texas TRAIGA, effective January 1, 2026, expects operators to maintain records of AI system operation in consequential-decision contexts. The audit records satisfy the requirement.

Where most enterprises are exposed

Most enterprise AI deployments today govern AI usage through documents (a one-page acceptable use policy, a quarterly review of who uses what model, a training session for new joiners). The documents do not feed an enforcement gate. The enforcement happens, when it happens at all, through ad-hoc application code that the application developer wrote against the policy as they understood it at the time.

The pattern produces three failures that compound. The first is inconsistent enforcement across applications: each application reads the policy differently. The second is unreproducible decisions: the policy at the moment of a past decision is not recoverable, because the application code at that moment is not preserved alongside the decision record. The third is unauditable change history: the document is updated through edits without a structured change log, and the reviewer cannot tell what the policy was when a specific decision was made.

The architectural answer is to move the policy to code and the enforcement to a gate that reads the code. The cost of the migration is recoverable through the standard change-control investment the corporate environment already runs.

DeepInspect

This is what DeepInspect provides at the AI request boundary. DeepInspect evaluates a policy-as-code configuration on every request. The policy lives in the corporate version control. The gate reads the policy version in effect at the moment of each request. The decision references the version. The audit record carries the reference.

The policy schema supports identity, role, model class, data classification, use case, quota, conditions, and audit metadata. The schema is documented and version-controlled. The gate validates new policy versions against the schema before accepting them.

Enforcement overhead runs under 50 milliseconds end-to-end in internal DeepInspect testing. The policy evaluation step is dominated by the classification step that runs alongside it; the policy evaluation itself is a deterministic rule match against an in-memory representation of the policy.

The deployment pattern uses dry-run mode for policy changes, percentage-based rollout for enforcement, and the same change-control process the corporate infrastructure-as-code already runs.

If your AI policy lives in a wiki page and your enforcement happens in application code, book a demo today.