AI Governance 7 September 2026

Deterministic Policy or LLM-as-Judge: Which One Can You Defend to an Examiner?

Use an LLM as a judge for policy decisions and it will read the request, weigh the context, and return a verdict — but not reliably the same verdict on the same facts, which is why it belongs in the advisory seat rather than the deciding one. A deterministic policy engine decides; the model informs. That split is the short answer. It is also, deliberately, the boring answer. The rest of this piece is the argument for it, taken in the order an examiner would test it: what each construction is, what an approval has to consist of, where the risk concentrates, and what an explanation is worth when it comes from the system being examined.

LLM-as-a-judge for policy decisions

An LLM as a judge for policy decisions means handing a written policy and a proposed action to a language model and asking it to rule: allow or refuse, compliant or not. As a pattern it is legitimate and widely used for evaluation — scoring outputs, triaging review queues, grading samples after the fact. The narrow question is whether that ruling should be the final authority over an action that then executes against a live system. It should not, and the reason has nothing to do with model quality. The verdict is not reliably repeatable.

This is not an intuition; it has been measured. Lee, Hong and Thorne examined exactly this in Evaluating the Consistency of LLM Evaluators (November 2024), studying self-consistency under repeated sampling and consistency across scoring scales, and their analysis concluded that "strong proprietary models are not necessarily consistent evaluators." That is a careful, limited finding, and it is sufficient for the argument here: a judge that does not dependably agree with itself is a judge whose individual rulings cannot carry authority on their own.

The distinction that matters is between evaluation and authorization. For offline evaluation, inconsistency is a statistics problem — you sample several runs, aggregate, and report a distribution. Authorization does not get that luxury. One action happens once, produces one decision, and leaves one record. You cannot aggregate a refund that went out, and you cannot re-sample your way out of a decision someone is now disputing.

Deterministic AI policy engine

A deterministic AI policy engine is the opposite construction. Policy is written down as fixed rules, every request is evaluated the same way, and identical input produces an identical decision. The decision arrives with the rule that produced it attached. Change happens through versioned edits to the rules, which means "what did our policy say on the day this happened" is a fact you retrieve, not a guess you reconstruct from memory and commit messages.

Determinism stops being an engineering taste and becomes a regulatory argument the moment explainability is asked for. Singapore's FEAT principles, published by MAS on 12 November 2018 — and explicitly non-prescriptive; the document says of itself, "This set of Principles is not intended to be prescriptive" — ask that firms be able to give data subjects, on request, "clear explanations on what data is used" to make AIDA-driven decisions and how that data affects the outcome, and that use of AIDA in decision-making be "approved by an appropriate internal authority." Neither ask is exotic. Both are structurally easy for a rule set and structurally awkward for a sampled verdict: a rule set can be read, explained, and put before an internal authority ahead of use, while what a model judge will decide next week is not knowable this week.

That framing — the decision layer as a distinct, defensible thing rather than a property smeared across the application — is the same argument made at length in what AI decision governance is and why it is the missing layer in enterprise AI. The deterministic engine is simply the version of that layer you can take into a difficult meeting.

Can an LLM approve a transaction?

Mechanically, yes. Nothing stops you wiring a model's output to the execute path, and some teams have. The examiner's question is different: not whether the model can emit the word "approve," but what the approval consists of once emitted. An approval that survives review carries three things — the authority under which it was granted, the rule that granted it, and enough of the decision context to reconstruct it later.

Measure an LLM approval against that list. The verdict is a sample from a distribution conditioned on the prompt and the context, so the same facts can draw a different ruling on another run. The model behind it can be updated, after which the guard behaves differently even though your written policy never changed. And the rationale that comes with the verdict is generated alongside it, not extracted from a rule that existed beforehand. None of these properties disqualifies the model as an advisor. All three disqualify it as the record of authority.

The workable division of labour follows directly. The model does what only a model can do: read the unstructured parts, extract, score, flag, recommend. The rules decide, and they draw the line above which a person must approve. Nothing is lost in this arrangement — the model's recommendation is captured as an input alongside the decision, so its judgement is on the record without ever being the record.

AI making its own guardrail decisions risk

The risk in letting AI make its own guardrail decisions is concentration, not carelessness. When the guardrail is the same kind of system as the thing it guards, their failures correlate. A judge model reads the same attacker-influenced text the acting agent read, so an instruction smuggled into a document can address them both at once — the control fails in the same moment, from the same cause, as the thing it was controlling.

The quieter version of the risk is drift. A guardrail built on a model changes behaviour when the model changes, and no policy edit, review, or approval marks the transition. Then someone asks the standard question — was this control operating effectively during the period under review — and a sampled control has no good answer, because it cannot be re-run to demonstrate what it would have decided. A control you cannot re-run is a control you can only assert.

Assertions are precisely what examination is designed not to accept. The point of examining a control is to test it independently of the people vouching for it, and a deterministic rule invites that test: here is the rule, here is the input, run it yourself. A model judge refuses the test by construction. That, more than any single wrong verdict, is what makes the self-governing arrangement hard to defend.

Explainable AI authorization decisions

Explainable AI authorization decisions require decision-level explanation, which is a smaller and more useful thing than model interpretability. You do not need to explain the model to defend a decision. You need to explain the decision: the input as it stood, the rule version that evaluated it, the outcome, and any human whose approval was part of the path.

A deterministic decision explains itself in that exact shape. The explanation is a derivation — re-run the rule on the recorded input and it reproduces the outcome, which means the explanation can be checked by someone who does not trust you. A generated explanation cannot offer that. When the judge is a model, the rationale is more output from the system under examination: testimony, not a trace. It may be accurate. The problem is that its accuracy has to be taken on faith, and faith is the one thing an examination is structured to remove.

The two halves of that distinction — explanation as artefact versus explanation as narrative — run through the tooling landscape as well, which is mapped in more detail in this comparison of AI transparency tools for explainability and accountability, and in the broader AI governance archive on this site.

What this means if you have to produce evidence

None of the following requires buying anything. It requires deciding which construction sits at the point of decision before anyone asks you to defend it.

List the decisions that are consequential. Anything that moves money, changes an entitlement, deletes a record, or reaches a customer goes on the list. Everything else can keep whatever arrangement it has.
For everything on the list, write the policy as rules. Keep the model's opinion as an input to the rule, never as the rule. If a rule cannot be written, that is a finding in itself — it means the decision is currently being made by something no one can state.
Version the rules. The question you will actually be asked is retrospective: what did the policy say when this specific action was allowed. Answering it requires the rule set to have a history.
Record the decision at the moment it is taken — input, rule version, outcome, approver if there was one — and make the record tamper-evident. The honest standard is not that a record cannot be changed; it is that a change cannot happen without being detected.
Rehearse the examination. Pick one allowed action from last month. Using only your records, reproduce the decision. If the reproduction needs the engineer who built the system in the room, you have logs, not evidence.
Map what you built to the framework language your reviewers use. The NIST AI RMF material on this site collects the pieces relevant to that mapping.

Crelis sits on the deterministic side of this argument, and says so publicly. It is an independent runtime authorization and evidence layer for AI agents: before an agent's action executes, GREENLIGHT evaluates it to a decision — allow, require human approval, escalate, or block — and the trust layer writes a tamper-evident record of that decision. The public FAQ states the position this article argues: "The final decision is never made by an AI model. It is made by fixed, deterministic rules — so the same request always gets the same answer, and every answer can be explained." The product page puts the same commitment in one line — every consequential AI action passes through "one authoritative, deterministic evaluation" before it can execute. Crelis is patent-pending and runs in shadow mode first with design partners.

Crelis is patent-pending. It holds no SOC 2, ISO 27001 or ISO 42001 certification, and claims none.