Deterministic vs. Probabilistic AI: When “Usually Right” Is Not Good Enough

Most of the AI used in companies today is built on language models that work by probability. Each time the model writes a word, it picks among several likely options. That is useful for drafting, summarizing and brainstorming, where many answers are acceptable. It becomes a problem when a process needs the same question to get the same answer every time, and when someone has to explain afterwards why a particular answer was given. This article explains the difference between deterministic and probabilistic AI, what recent evidence shows about how repeatable today's models really are, and what that means for explainable AI and audit trails.

The difference in plain terms

A deterministic system gives the same output every time it receives the same input. A probabilistic system chooses among possible outputs, so two identical requests can get different answers. Language models are probabilistic by design, which is why they can phrase the same idea in many ways. For creative work that flexibility is a strength. For other work, whether it is acceptable depends on the process.

Switching off the randomness does not make answers repeatable

Most AI tools include a setting, usually called temperature, that reduces the model's randomness. Many teams assume that setting it to zero makes the answers repeatable. Anthropic's API documentation says otherwise: even at the lowest setting, results are not fully deterministic.

Thinking Machines Lab, an AI research company, tested this in September 2025. It asked the same question 1,000 times with the randomness switched off and received 80 different answers. The answers were identical for the first stretch of text and then split: 992 continued one way and 8 another. The researchers found that the cause was not the model itself but how the servers run it. Results shift slightly depending on how many other requests the server is handling at that moment. When they changed the setup so that this no longer mattered, all 1,000 answers were identical. The repeatable setup was slower in their test, taking 42 to 55 seconds against 26 for the standard one.

What a customer receives can also change for reasons the customer never sees. In a postmortem published on 17 September 2025, Anthropic described three infrastructure bugs that intermittently degraded the quality of Claude's responses between August and early September. For one of them, a routing error that sent requests to the wrong type of server, about 30% of Claude Code users who made requests in that period had at least one message affected. Some users saw problems while others did not.

Why this matters for explainable AI and audit trails

An audit comes down to one request: show why the system gave this answer. Three things get in the way.

The answer cannot always be reproduced. If the same input can produce a different output, the saved answer is one sample among several possible ones. A reviewer cannot tell whether it was typical, and running the request again later does not settle the question.

The system's own explanation is not a safe record. In April 2025, Anthropic's research team gave models a hint about the answer, confirmed that the models used it, and checked whether the models said so when they explained their reasoning. On average, Claude 3.7 Sonnet mentioned the hint 25% of the time and DeepSeek R1 39%. Asking a model to explain itself is not the same as having a record of what it did.

Mistakes have a cost and an owner. McKinsey's 2026 AI Trust Maturity Survey, which covered about 500 organizations between December 2025 and January 2026, found that 74% of respondents see inaccuracy as a highly relevant risk. For nearly every AI risk, fewer organizations were actively mitigating it than considered it relevant. Among respondents whose organizations had an AI incident, close to 60% rated the response as only satisfactory or worse.

A recent case shows what this looks like in practice. In October 2025, Deloitte Australia agreed to repay the final instalment of an A$440,000 contract for a 237-page report to the Australian government's Department of Employment and Workplace Relations, after the report was found to contain apparent AI-generated errors, including a fabricated quote from a court judgment and references to research papers that do not exist (Associated Press, 7 October 2025). That case is about wrong content rather than repeatability. It shows the same thing from another angle: when AI output reaches a client or a regulator, the organization answers for it, and in our view it needs to be able to show where each part came from.

The EU AI Act points in the same direction. For high-risk systems, Article 15 requires consistent performance throughout the lifecycle and requires accuracy levels to be declared in the instructions for use, and Article 12 requires automatic logging (AI Act Service Desk, European Commission). Following the Digital Omnibus, the Council of the EU (May 2026) and Orrick (July 2026) report that the obligations for stand-alone high-risk systems now apply from 2 December 2027, and for AI embedded in regulated products from 2 August 2028. The delay changes the date, not the requirements. Our reading is that a system whose output changes between identical runs makes a declared accuracy level harder to verify.

Repeatable does not mean correct

Being repeatable is not the same as being right. A deterministic system can give the same wrong answer every time, so accuracy still has to be measured separately. Repeatable setups can also cost something, as the speed difference above shows. The sensible approach is to match the type of system to the type of process:

• Probabilistic models fit drafting, brainstorming, research starting points and summaries that a person reviews before they are used.

• Deterministic behavior fits decisions that must be repeatable and explained: financial calculations, eligibility and policy checks, compliance reporting, and anything that will be audited or falls under the EU's high-risk rules.

Five questions to sort your AI use cases

These are our working criteria, not a regulatory standard.

1. Would two different answers to the same input both be acceptable? If yes, variation is tolerable.

2. Will someone have to explain this answer later to a regulator, customer or auditor? If yes, the explanation has to come from the system's recorded steps, not from the model describing itself.

3. Can the answer be reproduced from the recorded input and settings? If not, the log is a sample, not a record.

4. What does the audit record hold? The input, the model and its version, the settings, the information supplied to it, the output, and the date.

5. What happens if the answer is wrong, and who is accountable? The higher the cost, the stronger the case for repeatable behavior.

Use cases that answer “yes” to the first question and “no” to the second can run on probabilistic models with human review. The rest need behavior that can be repeated and traced.

How bondingAI approaches it

General-purpose language models remain useful for drafting and exploration. For processes that have to be repeatable and explained, bondingAI built its platform on a different premise: enterprise AI should be deterministic, explainable and governed by design.

xLLM, bondingAI's proprietary language model, is deterministic, explainable and owned by the enterprise. The same input produces the same output, answers can be traced to their basis, and the organization controls the model, its versions and the records that describe its use. AIOS, bondingAI's AI Operating System, runs AI queries, analysis and actions under the organization's own rules, with explainability and monitoring in the same layer, so each interaction leaves a record that an auditor can follow.

If your AI is moving into processes that will be reviewed, start by sorting use cases with the five questions above. Speak with a bondingAI specialist!