Deterministic vs Probabilistic: Where Should AI Actually Be Used?
We have become rather good at demonstrating what AI can do. The more useful architecture question is what it should do.
A familiar proof of concept gives a language model a file and asks it to understand the format, apply rules, calculate values, decide what happens next and produce a report. The result may look impressive. But putting all those responsibilities into a prompt can leave us with a service that is expensive to run, difficult to test and harder to explain when something goes wrong.
The issue is not whether AI is capable of helping. It is whether we are using it for work that would be better handled by software we already know how to build.
Different work calls for different tools
Deterministic software is suited to work we can specify precisely: parsing a documented file format, calculating totals, applying approved thresholds, enforcing permissions or moving a case between defined states. Its behaviour can be tested and reproduced under controlled conditions. That does not mean the rules are always right, but it does mean we can inspect and correct them.
Probabilistic AI earns its place when we need to interpret language, recognise patterns, extract meaning from varied documents or deal with incomplete evidence. A model can provide a useful observation or recommendation without becoming the authority for the final outcome.
Human judgement still matters where evidence is disputed, exceptions require discretion or consequences demand accountability. A person approving an AI suggestion must be able to examine the evidence and challenge the result, not simply click a button.
What that looks like in practice
Take financial assurance. A transaction file with a documented structure should be parsed by a versioned parser. Calculations and policy thresholds belong in controlled code. AI might then interpret an ambiguous merchant description or supporting receipt. A reviewer considers any material exception and records the decision.
This is a hybrid design, but it need not become a complicated network of microservices. Those responsibilities can live inside one well-structured application. The important thing is that interpretation does not quietly become authorisation.
Design for the consequence, not the label
A reversible, low-volume experiment may be perfectly well served by a constrained model with independent validation. A payment release, access-control decision or safety-critical process requires a much stronger boundary. The right answer depends on risk, volume, lifecycle cost and the consequences of error.
Do not remove AI from the solution. Remove from AI the responsibilities it should never have been given.
The full position paper sets out a decision framework, common architectural anti-patterns, a controlled hybrid reference architecture, testing considerations and a worked Financial Assurance example. It also includes guidance on applying the approach across Microsoft 365, Power Platform and Azure.