The two get used almost interchangeably in marketing, which is exactly why the line matters: one follows instructions someone wrote in advance, and the other infers its own output from data. That difference decides how each one should be managed, tested, and trusted.
Key takeaways
Rather than reach for a marketing definition, start from the one place a Canadian statute defines the term. Ontario’s Employment Standards Act, 2000 defines artificial intelligence as “a machine-based system that, for explicit or implicit objectives, infers from the input it receives in order to generate outputs such as predictions, content, recommendations or decisions that can influence physical or virtual environments.” (Ontario, Requirements related to publicly advertised job postings) The load-bearing word is “infers.” An inference is not a lookup and not a fixed instruction — it is the system working out an output from patterns in data, which is exactly what separates this from ordinary automation.
That statutory language does not actually sit inside the Act’s own text — section 8.1 defers it entirely, saying “artificial intelligence” “has the meaning set out in the regulations” (ESA, 2000, s.8.1), and it is O. Reg. 476/24 that supplies the wording quoted above, at section 2(1). (O. Reg. 476/24, s.2(1)) The same regulation limits how far the disclosure duty this definition supports actually reaches: “Part III.1 of the Act does not apply to an employer that employs fewer than 25 employees on the day the publicly advertised job posting is posted”. (O. Reg. 476/24, s.1)
Traditional automation runs on rules a person wrote in advance: if a specific condition is met, do a specific, predetermined action. A mail-merge, a spreadsheet macro, an assembly-line sensor that stops a conveyor when a part is misaligned — all of these are automation. Feed the same input in twice and you get the identical output every time, and a person can trace, line by line, exactly why. Nothing about automation, in this sense, infers anything from data it was not explicitly told how to handle; it executes instructions rather than generating them.
Because an AI system’s output is inferred rather than fully specified in advance, it cannot be risk-managed the way ordinary automation is — by reading the code and confirming it does what it says. This is precisely why the US National Institute of Standards and Technology built a dedicated AI Risk Management Framework, organized around four functions: GOVERN, MAP, MEASURE, MANAGE. (NIST, AI RMF Core) Canada’s own privacy commissioners point directly to this US framework as the place to go for validating an AI tool: their joint principles tell organizations to “evaluate the validity and reliability of the generative AI tool for the intended purpose”, adding that “tools must be accurate throughout the intended lifecycle of the tool and across the variety of circumstances in which they are used”, with a footnote pointing readers to the NIST framework for more detail. (OPC, Principles for responsible, trustworthy and privacy-protective generative AI) NIST is a United States agency, not a Canadian one — it is cited here only because a Canadian regulator names it as the relevant reference, and any AI-specific claim sourced to NIST should carry that label.
The NIST framework’s own definition of accuracy is worth sitting with, because it shows why automation and AI are evaluated so differently. Accuracy is defined as “closeness of results of observations, computations, or estimates to the true values or the values accepted as being true”, and the framework adds that “accuracy and robustness… can be in tension with one another” in AI systems. (NIST, AI Risks and Trustworthiness) Automation does not have an “accuracy rate” in this sense — it either executed its rule correctly or it had a bug. An inferring system can execute exactly as designed and still be wrong some percentage of the time, because its output was never a certainty to begin with. That single difference is why testing an AI tool means measuring its error rate against real cases, not just checking that the code runs.
A finance team uses two tools side by side. The first flags an invoice for review whenever the vendor name does not match any entry in the approved-vendor list — a fixed rule, checkable in one line: is this string on this list, yes or no. The second flags an invoice as “unusual” based on a model trained on past spending patterns, weighing amount, timing, vendor history and a dozen other signals it was never given an explicit threshold for. The first is automation: predictable, fully traceable, and either right or buggy. The second is AI under Ontario’s own statutory definition: it infers a judgment from the input rather than checking it against a fixed list, and it can be wrong in ways nobody wrote into the code on purpose — which is exactly why it needs the validation and monitoring the sources above describe, and the first tool does not.
NIST’s framework organizes AI risk management into GOVERN, MAP, MEASURE and MANAGE, and none of the four applies meaningfully to the fixed-rule invoice check above — there is nothing to govern beyond confirming the list is current, and nothing to measure beyond whether the code runs. The inferring tool is a different story: GOVERN means someone owns the decision to use it on live invoices at all; MAP means understanding what “unusual” actually means to the model and where it might be wrong; MEASURE means tracking its error rate against invoices a human later confirmed were fine or genuinely fraudulent; and MANAGE means deciding, on that evidence, whether the tool should keep flagging invoices unsupervised or be pulled back to a review queue. (NIST, AI RMF Core) Automation never needs this cycle because its behaviour was never in question to begin with — only its correctness was, and correctness is a one-time check, not an ongoing one.
It depends what is generating its replies. A chatbot that only matches a typed phrase to a pre-written script is automation; one that generates a novel response by inferring from the conversation is AI under Ontario’s own statutory definition.
Yes, and most real tools are a mix — a fixed rule routes the request, and an AI model handles the part that requires inference, such as classifying an image or drafting a reply within that routed flow.
Because automation can be verified by reading the rule it follows, while an AI system’s output has to be tested against real cases and monitored over time — the NIST framework Canada’s privacy regulators point to exists specifically for that reason.
Related: chatbot vs AI agent vs assistant, what a workplace AI policy should cover, and connecting AI to the systems you already automate.
A short call is enough to work out what a specific tool actually does before you write a policy or a risk process around it.
