A facilities management client once walked us through their new "AI-powered" predictive maintenance dashboard with real pride. Sensors on the chillers, a slick front end, alerts that fired before a breakdown. We asked how it decided something was about to fail. The answer, after a bit of digging, was a spreadsheet of thresholds someone had typed in three years earlier: if vibration reads above X, raise a ticket. Useful, sometimes. Not learning anything. Not AI, whatever the pitch deck said.
Artificial intelligence is software that improves at a task by learning from data, rather than by following instructions someone wrote out in advance. That single distinction, learned versus written, does more work than any longer definition we could give you. Everything else, the layers, the categories, the hype, sits on top of it.
We build data and AI systems at Shipshape Data, and the most common confusion we run into is not technical, it is definitional. Clients arrive having been told three contradictory things by three vendors, and the word "AI" has been stretched to cover a lookup table, a spreadsheet macro, a genuinely trained model and a chatbot, all in the same slide deck. This guide sets out what AI actually means, how machine learning and deep learning nest inside it, what current systems are good at and where they still fall over, the main categories of application you will actually meet in a business, and how to tell a real AI use case from a rules engine wearing a nicer badge.
What we actually mean by "AI"
Artificial intelligence is the broad field: any system that performs tasks we would normally say require intelligence, from playing chess to reading an invoice to recommending a film. That field is old. The term was coined in 1956, at a summer workshop at Dartmouth, and for most of its history "AI" meant hand-written rules: if this, then that, coded by a person who had thought hard about the domain. Expert systems in the 1980s diagnosed illnesses this way. A lot of fraud detection still runs this way today, and there is nothing wrong with that, provided nobody calls it learning.
The bar keeps moving
There is a well-worn joke in the field that AI is whatever hasn't been done yet. Optical character recognition was AI until it worked reliably, then it became "just OCR". Chess engines were AI until Deep Blue beat Kasparov in 1997, at which point people decided that was brute-force search, not real intelligence. The pattern repeats. Once a capability ships and becomes boring, we reclassify it as ordinary software. It is worth knowing this happens, because it means the definition you are working with should describe the mechanism, not the mystique.
One word, several very different things
So when someone says "AI" they might mean a hand-coded rules engine, a statistical model that learned patterns from historical data, or a large neural network that generates text and images. All three get called AI in commercial conversation. Only the second and third actually learn anything, and they learn in quite different ways, which is where the nesting comes in.
How machine learning and deep learning sit inside it
Picture three circles, each one smaller and sitting fully inside the last. AI is the outer circle: anything that performs an intelligent-seeming task. Machine learning is the middle circle: the subset of AI that learns its rules from data instead of having them written by a person. Deep learning is the inner circle: the subset of machine learning that uses many-layered neural networks to do that learning. Every deep learning system is machine learning. Every machine learning system is AI. The reverse is not true in either direction, and a lot of marketing copy depends on nobody checking.
Machine learning: rules discovered, not written
A traditional program is a person's logic, translated into code. A machine learning model is different: you show it examples, inputs paired with the correct outputs, and it works out the relationship itself. Show it ten thousand past loan applications with the outcomes attached, and it derives which factors predicted default, weighted the way the data actually supports, not the way a person guessed. The short version is this: the model is discovering a pattern, and a rules engine is only ever repeating one it was told.
Most machine learning that runs in businesses today is not the flashy kind. It is a gradient-boosted tree scoring credit risk, a regression model forecasting demand, a classifier sorting support tickets. Unglamorous, reliable, and often the right tool, because it needs less data and less compute than what comes next, and it tells you which features drove the answer.
Deep learning: the same idea, with more layers
Deep learning is machine learning built from neural networks with many stacked layers, each one transforming what came before. What matters here is what those extra layers buy you: the ability to learn directly from raw, messy, unstructured input, an image, a sentence, a sound wave, by turning it into the kind of numerical representation our guide to embeddings covers, rather than a person first deciding which features matter. That is genuinely new capability. It is also why deep learning needs far more data and far more computing power than a gradient-boosted tree scoring the same loan applications, and why it is frequently the wrong tool for a problem a simpler model would solve just as well, at a fraction of the cost and with an answer you can actually explain to a regulator.
What these systems can actually do well
Strip away the branding and modern AI is very good at two related things: finding patterns across more data than a person could hold in their head, and, more recently, working with human language and images at something close to human fluency.
Pattern recognition at volume
A model can compare a new transaction against millions of past ones and flag the one that does not fit, in milliseconds, all day, without getting tired on the night shift. It can spot a subtle correlation between three sensor readings and a failure eighteen days later, a relationship no engineer would think to check by hand. This is the genuinely dependable part of the field. It is statistics done at a scale a person cannot match, not judgement, but scale on its own is worth a great deal.
Language, suddenly, generally
The newer capability is large language models handling open-ended text: drafting, summarising, answering questions against a document, holding something like a conversation. Five years ago this required a narrow model built for one job. Today one model does a passable job at most of them, which is the single biggest shift the field has seen in a decade, and it is the reason "AI" now means something different in a boardroom than it did in 2019.
Where these systems still fall over
None of this amounts to understanding, and the gap matters more than the marketing suggests.
No sense of cause, only correlation
A model trained on ice cream sales and drowning incidents will find they rise together and has no way of knowing that summer causes both. It cannot ask "why", only "what usually goes with what". Feed it a genuinely novel situation, one with no precedent in its training data, a new regulation, a product line that has never existed before, a market shock, and it will still produce an answer. That answer is a best guess dressed as a fact, and the model has no internal signal telling it the ground has shifted.
Confidence has nothing to do with correctness
A model does not know what it does not know, and it will tell you the wrong answer in exactly the same tone as the right one.
This is the practical danger. A person who is unsure hedges, or asks a colleague, or flags the case for review. A model asked a question it cannot answer well still produces fluent, confident output, because fluency is what it was trained to produce. Large language models in particular will invent a plausible-sounding fact rather than say "I don't know", and the invented fact reads exactly as convincing as the true one. This is not a bug that gets patched out with the next release. It is close to the mechanism itself.
Data hunger and the messy middle
Every one of these systems is only as good as what it learned from, and most businesses discover, usually partway through a project, that the data they assumed was there is incomplete, duplicated, or scattered across systems that do not agree with each other. This is where a large share of AI projects actually stall, not on the modelling, on the unglamorous work underneath it.
The pattern is depressingly consistent. A team picks a use case, buys a licence, hires someone with the right title, and only then discovers that the customer records live in four systems under four different spellings, or that the sensor data everyone assumed was being logged was in fact overwritten every ninety days. None of that is an AI problem. It is a plumbing problem, and it surfaces at the worst possible moment, halfway through a project someone already announced internally.
The main jobs businesses actually hire AI to do
Away from the hype, most enterprise AI work sorts into a handful of categories, and it helps to name them plainly instead of by vendor buzzword.
Prediction and forecasting
Demand next quarter, a machine's remaining useful life, a customer's likelihood of leaving. This is the oldest and most proven category, and it is where a modest, well-understood model usually beats an elaborate one.
Classification and tagging
Sorting incoming things into buckets: is this transaction fraudulent, which department should this ticket go to, does this image contain a defect. Fast, well-suited to automation, and forgiving of the occasional wrong call as long as a person reviews the edge cases.
Generation
Producing new text, images, code or summaries rather than sorting existing items. This is the newest and fastest-moving category, and the one where "it sounds right" and "it is right" diverge most dangerously, because fluent prose is exactly what these models are built to produce whether or not the content behind it is accurate.
Retrieval and conversation
Systems that let a person ask a question in plain language and get an answer pulled from the business's own documents, rather than from the model's general training, a pattern our guide to retrieval-augmented generation covers in more depth. Genuinely useful, and only as trustworthy as the underlying retrieval, which is why a poorly indexed document store produces a confidently wrong answer just as easily as a well-indexed one produces a right one.
Optimisation and automation
Routing, scheduling, pricing, workflow decisions made continuously rather than by a person checking a dashboard. Often the least visible category and, in our experience, one of the most valuable, because it removes the manual step entirely rather than merely advising a human who still has to act on it. A truck route recalculated every morning by a person with a whiteboard does not scale past a certain fleet size. The same decision made by a model that has learned from six months of delivery times does, and nobody notices it happening.
Most real deployments blend two or three of these categories rather than picking one cleanly. A support system might classify an incoming ticket, retrieve the relevant policy document, and generate a draft reply, three different jobs stitched into one interaction. Knowing which piece is doing which job matters when something goes wrong, because the fix for a bad classification is not the same as the fix for a bad retrieval.
The rules engine wearing an AI badge
Back to that maintenance dashboard. We would not put a number on how many products marketed as "AI-powered" contain no machine learning at all, because we have not counted and we do not trust anyone who says they have. What we can tell you is that we run into conventional software wearing the badge often enough that we now ask the training-data question on every vendor call, before we ask about price.
A rules engine is not a bad thing. If-then logic is transparent, cheap to build, easy to audit, and entirely appropriate for a problem with clear, stable rules a person can write down. The trouble starts when it is sold as something it is not, because a rules engine cannot improve as conditions change. It does not notice a new failure pattern nobody coded for. It does exactly what it was told, competently, forever, and calling that "learning" sets an expectation the product will never meet.
How to tell the difference before you commit budget
A handful of direct questions clears this up faster than any amount of vendor slide.
Ask what it was trained on
A genuine machine learning product can tell you, at least in outline, what data it learned from and roughly how much of it. If the honest answer is "it follows the logic our engineers configured", you are looking at rules, and that may be exactly what you need, provided it is priced and pitched as such.
Ask what happens when the pattern changes
A real model retrains, or is designed to be retrained, as the world moves. A rules engine needs someone to open the configuration and edit a threshold by hand. Neither is wrong. Only one of them is learning.
Ask to see it be wrong
Every trained model makes mistakes; that is the nature of probabilistic output. A vendor who cannot show you a case where their system got it wrong, and how that failure was caught, is either hiding something or has not tested it against enough real cases to know. This matters more the more the decision affects a person's life, a loan, a diagnosis, a job application, and it is worth pressing on before signature rather than after.
Where to start
Start with the problem, not the technology. Write down the decision you want improved, name what a right answer looks like, and check honestly whether you hold enough historical examples of that decision being made correctly for a model to learn from. If the logic is simple, stable and fully understood, a rules engine done properly will outperform a model built to solve a problem that did not need one. If there is a genuine pattern buried in data nobody has connected yet, that is where the field earns its name.
Either way, the foundation underneath matters more than the label on top: clean, connected, well-understood data first, model second. If you are trying to work out which category your problem actually falls into, or you have been sold something as AI and are not sure it deserves the name, talk to us.