Most real workflows are neither pure automation nor pure AI. The useful question isn’t which one a process uses — it’s which specific steps follow a fixed rule and which ones need judgment a fixed rule can’t capture.
Key takeaways
Traditional automation — scheduled jobs, screen-scraping, robotic process automation — runs on fixed rules: if a file lands in this folder, copy these three fields into that system, every time, the same way. It doesn’t interpret anything. That is a feature, not a limitation: a deterministic rule is auditable, predictable, and cheap to run, and none of that changes just because “AI” is fashionable.
The seam appears the moment the input stops being uniform enough for a rule to cover every case. A form with the same ten fields in the same order is automatable outright. A free-text email that might mention a renewal date, a complaint, or nothing relevant at all is not — there is no finite list of if-it-says-X-do-Y rules that covers open-ended language, which is exactly the kind of task generative AI is built to handle. See the Cyber Centre’s own framing: generative AI “can create unique content in many forms” where traditional systems are limited to recognizing patterns in existing content.
Statistics Canada’s Q2 2026 business-use survey asks about a long list of specific AI applications, and the reported figures line up with this seam reasonably well. What the survey calls robotics process automation — the closest category to fixed-rule automation on the list — sits at the bottom, around 5% of AI-using businesses, up only slightly from about 4% a year earlier. Data analytics and text analytics, both squarely judgment-and-interpretation tasks, sit at roughly 37% and 35% respectively — several times higher. Read carefully: this doesn’t prove causation between task type and adoption rate, and the same release is honest that most Canadian businesses aren’t using AI in any form at all yet. Its companion release on expected future use records 66.7% of businesses with no plans to adopt AI at all, most citing simple irrelevance to what they do rather than any concern about the technology. The same line has a tax dimension: CRA’s SR&ED glossary excludes “routine data collection…carried out for supporting normal business operations” from eligibility, reserving the credit for work resolving genuine technological uncertainty — the same fixed-rule-versus-judgment line, drawn by a different authority. See Treadstone Law on SR&ED eligibility.
The same StatCan release reports that among businesses that used AI in the last 12 months, 44.4% made changes to training or staffing practices because of it — 32.0% provided AI-related training to existing employees, and among businesses with 100 or more employees, 30.2% brought in external consultants or vendors specifically for this. That figure is a useful reality check on the idea that inserting an AI step into an automated process is a purely technical swap. Deciding where the fixed rule ends and judgment begins, and building the validation that sits between the two, is a design decision that Canadian businesses are visibly staffing and training for, not one they’re treating as a drop-in replacement for the automation that was already there.
In practice, a well-designed pipeline rarely picks a side. Plain automation handles triggering, scheduling, moving files, and logging — the parts that are genuinely fixed-rule. AI is inserted specifically at the point where something has to be read, classified, or drafted from unstructured input. The output of that judgment step then goes back into ordinary automation to route, file, or record it. Treating either half as capable of doing the other’s job is where these projects tend to go wrong: pure automation can’t read a messy document, and using an AI model to do something a fixed rule already handles perfectly well is needless cost and needless unpredictability.
An invoice-intake process: plain automation watches a shared inbox and triggers as soon as a new attachment lands — a fixed, deterministic step. An extraction step then reads the document itself. Microsoft’s own Document Intelligence documentation describes exactly this kind of tool as a cloud-based service that “uses machine-learning models to automate…data processing in applications and workflows,” with named capabilities for layout and field extraction and its own confidence scoring on what it extracted. That extraction step is the AI part: vendor name, amount and date pulled from a document that doesn’t arrive in one fixed layout. Once extracted, automation takes back over — posting the record to a ledger automatically when the vendor matches an approved list, and routing anything that doesn’t match, or that the extraction step flagged as uncertain, to a person instead of guessing.
Compare that with a business that receives invoices from the same five vendors every month, always in the same fixed template. There, the extraction step buys almost nothing — a plain automation rule that reads fixed cell positions on a known template handles it more cheaply and more predictably than a machine-learning model would. The difference between the two businesses isn’t size or sophistication; it’s whether the input is actually varied enough to need judgment at all. Reaching for an AI step where a fixed rule already works is the mirror image of the more common mistake — it adds cost and unpredictability without solving a problem the fixed rule didn’t already have.
Related: for what “connecting” the two halves of that pipeline actually means, see what an integration does, in plain terms; for the document-reading step in more detail, see how AI reads a document and acts on it.
Not in the traditional sense — RPA scripts a fixed sequence of steps against a predictable input and doesn’t generalize to input it wasn’t built for. Statistics Canada lists it as its own category, separate from the machine-learning and generative-AI categories on the same survey, which reflects that distinction.
Generally not beyond a small number of fixed layouts it was explicitly built to expect. The moment the layout, wording or format varies enough, that is the seam where an extraction step built for varied input takes over.
Only the AI step carries that risk, and it’s manageable by design — see why AI agents need guardrails for the specific limits that keep a judgment step from acting on a low-confidence result.
There’s no shortcut past looking at the actual input: if a finite, exhaustive list of rules genuinely covers every case that arrives, a rule is cheaper and more predictable. The moment real examples turn up that no reasonable-length rule set would have anticipated, that step is a candidate for AI rather than automation.
The mechanics of connecting an extraction step to the automation around it, in practice.
