Deterministic policy
A deterministic policy is a rule that returns the same decision for the same input every time. Given a verified subject, a route, a payload classification verdict, and a policy version, the decision point returns pass or block with a fixed reason code. Stochastic alternatives (model-based safety filters, sampled refusal behaviors, temperature-driven moderation) return different verdicts for the same input across calls. The Stanford Trustworthy AI / AIUC-1 Consortium briefing measured refusal behaviors of model-level guardrails degrading significantly under targeted fine-tuning and adversarial pressure; that variance is what makes them stochastic.
Why determinism is the regulator's expectation
EU AI Act Article 12 requires automatic recording of events to ensure traceability. Traceability assumes that a regulator who replays the input gets the same outcome the system originally produced. A model-based filter that returned a block on March 14 and a pass on May 2 for the same prompt has no defense at audit time, since the regulator cannot reconstruct why the second decision differed from the first. A deterministic policy carries a version hash in the audit record; the version hash points to the exact rule that decided, and replaying the input against that version produces the original outcome.
How a deterministic policy composes
The rule body reads from a small input set: the verified subject and its role claims, the route, the classification verdict and its category labels, the time of day (if the rule has temporal scope), and the policy version. The rule body produces pass or block plus a reason code. Compound rules (route-and-role-and-classification) compose by AND/OR over single-field predicates, and the final verdict is the boolean reduction. The per-decision audit record stores the inputs, the version hash, and the outcome, which is what makes the decision replay deterministic.
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).
- 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.