A recurring process gets built, or updated, or handed to someone new. At one of its steps, someone reaches for an AI tool, because it's open, it's fast, and it works well enough. The process completes. Nobody asks whether AI was the right method for that step, or whether a documented procedure would have handled it more reliably, more cheaply, and more auditably. The step gets assigned to AI, and the process moves on.
A process settles on AI at a given step for a simple reason: AI was open, fast, and easy to reach for when that step first needed handling. Whether it was actually the right method for the job is rarely asked.
The discipline for avoiding it borrows its shape from two well-established principles.
"Data protection by default," as the UK's Information Commissioner's Office explains under Article 25 of UK GDPR, means the conservative, privacy-preserving state is what happens automatically, and any broader use of personal data has to be a deliberate, justifiable choice.
"Secure by default," as CISA and its international partners define it, means a secure configuration is the baseline: built in, not optional, and anything beyond it requires a conscious decision. Both principles work the same way. The safe, appropriate state happens by default; the riskier option has to be chosen explicitly, with a reason.
"Deterministic by default" applies that same logic to how a business designs its processes. For any given step in a recurring process, the default choice should be a deterministic method: a documented procedure, a template, a fixed sequence of steps, a person or system that owns that step the same way every time it recurs. AI is the exception, chosen deliberately, for the steps that need what only AI can do. The right, appropriate choice happens automatically, and anything beyond that is earned.
Recognising Default-to-AI Patterns in Your Business
The pattern shows up across processes in recognisable ways, and none of them look like mistakes when they happen.
The clearest marker is a step that produces slightly different output each time the process runs. This happens because the output is being freshly generated by AI, so the result depends on how the request was phrased that day, or what context happened to get included. The output is fine. It needs a light re-check before the process moves on. That re-check becomes a standing part of the process, unremarked on, just something that has to happen.
The second marker is in the language used to explain the step: "We just run it through AI now." That sentence, offered as a complete explanation with no follow-up about why AI is the right method for that specific step, is usually a sign the decision was never made at all. The step went to AI because AI was available, not because anyone asked whether its flexibility was what that step needed.
The third marker is in the output itself. A process producing meaningfully different results run to run, at a step where that variation doesn't add value, deserves a closer look. So does a step where nobody in the business could explain, in a sentence, exactly how the output was produced or why it looks the way it does. A documented method can always be explained that way. AI output often can't, and that's a real cost when the step feeds into a client-facing decision.
The diagnostic question for any step currently handled by AI is whether a documented method, built once, could handle it just as reliably. If the honest answer is yes, that's a strong signal the step belongs on the deterministic side. That doesn't mean AI couldn't do it. The step doesn't need AI's flexibility, and relying on that flexibility for something that doesn't need it accumulates a re-verification cost every time the process runs.
Deterministic by Default: The Principle Defined
It would be easy to mistake this for scepticism about AI. It isn't.
A business can use AI constantly across its processes and still be operating "deterministic by default," provided every instance is a deliberate choice made because that step needed what AI is for, not a reflex baked into how the process happened to get built.
What AI is actually for, stated specifically: working with genuine ambiguity where the right output can't be fully specified in advance; drawing a coherent thread from messy, unstructured material (a pile of notes, a long transcript, scattered feedback across a dozen sources); generating a wider set of options than a person would think to produce alone; and finding patterns across more material than a person could reasonably review by hand. These are the steps where AI's flexibility is the point, not a side effect.
What deterministic handling is for: anything where the step has a correct or consistent answer that doesn't change run to run. A documented procedure produces the same, explainable output every time it's followed. A template removes the need to re-decide anything a previous decision already settled. A fixed automated sequence carries out the step the same way regardless of who's running the process that day. The value is that the same input reliably produces the same output, without re-verification, indefinitely.
The ICO's own clarification on data protection by default is the most useful parallel here. It doesn't mean data collection is switched off. It means only the necessary, appropriate amount happens automatically, and anything beyond that is a deliberate, justifiable choice. Deterministic by default doesn't mean AI is switched off either. It means only the AI use that's earned happens automatically, and everything beyond that runs on a fixed, repeatable method that doesn't need justifying.
CISA makes the same point about software directly: "The software industry needs more secure products, not more security products. Software manufacturers should lead that transformation." The parallel here is that the answer to inconsistent AI output isn't more careful prompting each time the process runs. It's a method designed into the process once, that doesn't need care applied to it on every recurrence.
Applying Deterministic by Default: Where AI Earns Its Place
To make the principle concrete, it helps to walk through a real process where it was applied from the outset. What follows is drawn from my own working practice.
The problem was familiar enough: a growing archive of published articles and a standing need to promote them on social media, without spending significant time on it each week. The solution was a set of automated processes (four in total, plus one shared sub-process) that handle the full cycle: selecting which article to promote, generating and approving post copy, scheduling and publishing posts, and restocking the queue when posts run low on a given article.
The first decision, before anything was built, was which step needed AI. Generating varied, engaging social copy from arbitrary article content is genuine synthesis. A fixed template would produce the same flat structure for every article, regardless of what made each one worth promoting. That step went to AI, with a permanent human review queue alongside it, from day one.
Practice 1: Build the Deterministic Version First (the "By Design" Half)
For every other step in the process, the first instinct was to build a deterministic rule. Which article to promote next runs on a simple selection logic: least recently promoted. Which approved post to use runs on a random pick from the approved pool for that article. Scheduling and publishing run on a fixed daily trigger. The low-stock notification fires when an article drops below a threshold. None of those steps needed AI's flexibility, so none of them got it. The pipeline's AI use was scoped to the one step that earned it before anything else was designed.
This is the "by design" half of the principle, the direct parallel to data protection by design: considered up front, not bolted on afterward. A deterministic method built into a process once pays for itself every time that process runs.
Practice 2: Name the AI Decision, Every Time (the "By Default" Half)
The decision to use AI for the copy-generation step was made deliberately: writing varied, engaging posts from arbitrary article content is genuine synthesis that a fixed template couldn't do well. A human review queue went in alongside it too, built to be permanent rather than a temporary bridge to remove once confidence was established. My own rough estimate, without having run the maths precisely, is that about 20% of what the agent generates gets rejected outright, around 50% gets edited before approval, and roughly 30% gets approved as written. That ratio hasn't changed the structure of the process. The review queue was designed to stay.
This is the "by default" half: choosing AI for a step is the less conservative option. It should be a nameable, deliberate choice, not what happens when nobody thought carefully about it. CISA's principle that the burden of security shouldn't fall solely on whoever's using a product, but should sit upstream with whoever designed it, translates directly: the burden of a process running reliably shouldn't fall on whoever happens to be running it that day. It should sit with whoever designed how the step works.
Practice 3: Watch for Processes Migrating Off Their Deterministic Version
The human review queue is what keeps AI confined to the one step it earned. Nothing downstream touches AI; only approved posts can be picked up by the scheduling process. That boundary was designed in from the start rather than needing to be enforced after the fact. The scheduling process itself ran in shadow mode for a week before going live, doing everything except actually posting, to confirm it was handling records correctly before any real content was at stake. That boundary needs revisiting occasionally, or the defaults drift back toward whatever's easiest.
Practice 4: Treat "Only AI Can Do This" as a High Bar, Not a Low One
The clearest illustration is what didn't go to AI. Deciding which article to promote next, and which approved post to use, could plausibly have been handed to an agent to judge. Both run on simple deterministic rules instead, because neither step needed AI's flexibility. Picking the least recently promoted article, then selecting randomly from its approved posts, are decisions a fixed rule handles perfectly, and handles the same way every time without needing review. AI was reserved for the one step that cleared that bar.
The Realities of Working This Way
The discipline takes more upfront effort than defaulting to AI on everything.
Building the deterministic version of a step means designing it once, deliberately, before it pays off. That's a real cost against the instant, no-setup convenience of running a step through AI. For a process that only runs a handful of times, the trade-off may not be worth making. The discipline earns its keep on recurring work: the onboarding sequence that runs with every new client, the reporting cycle that comes around each month, the operational task that repeats every week.
Not every step will be clearly deterministic or generative. Some sit in a grey area, benefiting from a hybrid: a fixed structure with an AI-assisted step for the variable part inside it. The pipeline described in the previous section has exactly that shape. The discipline isn't a strict either/or; it's asking the question for each step rather than skipping it.
The hardest part is sustaining the habit. Left to themselves, people default back to whatever's easiest, and that's usually AI. The principle only does anything if someone keeps asking the question, process by process and step by step. Declared once as a company-wide methodology and then left alone, it doesn't work.
This principle doesn't replace the question of which AI tools to adopt, how to govern them, and what risks they introduce. That's a separate conversation, and one that "Don't Let Urgency Drive Your AI Adoption" addresses directly. This principle assumes that conversation has already happened, that tools exist and are in use, and asks the next question: how does a given process decide, step by step, which of those tools earns its place?
Deterministic by Default in the Wider Organisation
Implementing this principle isn't something a business declares once and applies everywhere automatically. It means someone going through a specific recurring process and deciding, step by step, what stays deterministic and what earns AI's place there. Adopted at company level, it only means anything once it's implemented process by process, across the organisation.
That's also why it connects to operations and strategy work. Mapping which processes, and which steps within them, are currently defaulting to AI by habit rather than by design is exactly the kind of process-clarity work an operations review surfaces. Treating consistent, explainable process design as a real input to execution quality, rather than a detail to assume is already happening, is what strategy delivery work does with the principle once it's named. Building the habit, across a team, of asking which steps need AI and which need a method that hasn't been built yet, is the harder cultural piece that mentoring supports: it takes sustained attention rather than a single session.
This pattern has a name already: "Operational Debt," the structural cost of undisciplined processes and tooling decisions that accumulate without anyone consciously choosing them, until the workaround becomes simply how things are done. Here, the workaround is AI, chosen because it was available rather than because anyone decided it was the right method for that step.
The "deliberate" quadrant in "Future of Work: Beyond Human Delegation" established that AI can fill gaps left by having no team to delegate to, at the level of one person's task list. This principle sharpens and scales that discipline, applying it at process level rather than task level, whatever scale a process operates at. The question moves from which individual tasks to hand off, to how the steps inside a recurring process get designed from the start.
AI earns its place on the steps that need what it's good at: ambiguity, synthesis, option-generation, pattern-matching at scale. Everything else deserves a method built once, that works the same way every time. Deciding which is which, deliberately, process by process, is what the discipline asks of a business.
References
- Information Commissioner's Office (ICO), "Data protection by design and by default", UK GDPR Article 25 guidance.
- CISA, NSA, FBI and international partner agencies, Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software", April 2023 (expanded October 2023).
- Ady Coles, "Don't Let Urgency Drive Your AI Adoption", Mantage, 2026.
- Ady Coles, "Operational Debt", Mantage, 2026.
- Ady Coles, "Future of Work: Beyond Human Delegation", Mantage, 2026.
Ady Coles works with leadership teams to help strategy survive contact with reality. His focus is on strategy management and agile strategy delivery - designing the translation between intent and execution so that direction remains coherent as organisations move, grow, and adapt. He works as a fractional and advisory partner where clarity, judgement, and sustained alignment matter more than plans on paper.