AI use cases in plain language

I was once in an organisation that had collected thousands of use cases. The list was impressive and almost useless, because most of the rows were wishes: "improve reporting", "enhance customer experience", "leverage data". None of them shows what the machine is supposed to do, who reads the result, or what happens when the result is wrong.

Use case is a term everybody uses and few define. In this piece it means one thing: something is a use case only once you can write it as a single sentence with three parts. The machine does something tightly bounded, a person does something with the result, and an error has a known consequence. If any of the three is missing, it is an idea, not a use case.

Here are thirty actual cases in plain language, plus a section of their own on use cases in voluntary organisations. Some have been in use for years, some are new. Most are not chat and not even language models, and that is the most important observation in the piece. At the end are two things lists rarely cover: how you pick the few out of a thousand ideas, and what happens to the chosen one afterwards.

Home and ageing

An older person lives at home, and the machine watches that everything is as usual. A radar sensor mounted near the ceiling measures movement in the room: whether a person is moving and how. No camera image is produced at all, which is a deliberate choice. Within weeks the system learns the home's own rhythm: when the bed is left, how many times the bathroom is visited at night, how long the morning routine takes. It does not raise an alert because something happens but because the usual thing does not. It goes wrong when the rhythm changes for a legitimate reason: grandchildren came to stay, a cold started, a heatwave arrived. Then come false alerts, and false alerts are dangerous, because people become numb to them.

A fall is detected without anyone watching. The same radar, or an accelerometer on the wrist, detects a rapid falling motion and the stillness after it. This is pattern recognition, not understanding. The hardest case is not a heavy fall but a slow slide to the floor, which looks like nothing in particular to the sensor.

Medication is remembered, and a lapse becomes visible to somebody. A smart pill dispenser records whether a compartment was opened. The machine does not know whether the medicine was taken; it knows whether the lid was opened. The difference matters, and it is a good example of how easily the measure and the thing get confused.

Speech separates from the din. A modern hearing aid separates a voice from background noise with a small machine learning model trained on thousands of hours of audio. The same technique removes background noise from a phone call. Nobody calls this AI, because it has been around for a while.

In a collection of ten thousand photos, that one is found. A phone's image search understands the query "dog on a beach" without anyone having tagged anything. Images and words have been converted into the same numerical form, which lets them be compared. It goes wrong on rare things and dim pictures, and the result is then wrong with nothing to indicate that it is.

Health and care

A doctor's dictation becomes text. Speech recognition turns the dictation from an appointment into a record, and a language model organises it into fields. This is one of the clearest useful applications in healthcare, because record-keeping genuinely takes a lot of time and an error is noticed by whoever reads the text: the doctor, immediately.

Imaging findings are put in order. A model works through X-ray or MRI images and moves to the front of the queue the ones most likely to show something. The machine makes no diagnosis. It decides the order of viewing, which sounds modest but determines how quickly an urgent case reaches a radiologist.

An emergency department triage assessment gets a second opinion. A model computes a risk score from history and measurements, shown alongside the nurse's own assessment. If a system is intended for prioritising the urgency of emergency patients, it falls in principle under the high-risk systems of Annex III of the EU AI Act. The key high-risk obligations begin to apply to such systems on 2 December 2027, since the timetable moved in the summer of 2026. For design purposes that changes nothing about the requirement itself: a person must be able to override the machine, and the use must leave a trace.

A photograph is taken of a skin lesion. An image recognition model assesses whether the lesion is worth showing to a doctor. The most dangerous error is not a false alarm but false reassurance, which is why a decent application never says "this is nothing" but at most "this does not look urgent".

Forest, sea and emergency response

A missing person is searched for from the air. An uncrewed aircraft flies a search pattern and films the terrain with a thermal camera. A model works through thousands of frames and marks the ones with a person-sized heat source, screening out deer, sun-warmed rocks and vehicles. What is left for a person is a list of places to check, not a decision. Under dense tree cover the machine finds nothing and does not say it is hesitating either, so an empty result looks exactly like "there is nobody here".

One picture is built out of several sensors. This is called sensor fusion. A thermal camera picks out temperature differences in darkness too, but the contrast can weaken in rain or in a warm environment. An ordinary camera shows colour and detail in adequate light. Lidar, laser range-finding, measures distances and shapes but not usually colour or the visual detail of surfaces. Combined, they give an observation no single sensor produces alone. The same principle applies in searching for a missing person, in a self-driving vehicle and in maritime surveillance.

A vessel switches off its identification. Hundreds of vessels move in a sea area, and the system combines radar observations, vessels' own signals and satellite imagery into a single track. It surfaces the ones whose movement does not match what they say they are doing. This is anomaly detection, and its eternal problem is that the very case that ought to be noticed is the least represented in the training data.

A camera tower notices smoke before anyone calls. In forest fire surveillance, a plume and its direction are recognised in the camera feed. False alerts come from morning mist and dust, so the system is built to give a person an image to look at rather than to call the emergency number.

A search is made of the sea floor. In sonar imagery, an object of human size and shape is identified among the debris on the bottom. The work used to be done by watching tape for hours.

Everyday working life

A meeting leaves a record. Speech recognition turns the recording into text, and a language model makes a summary and a list of what was agreed. The summary may weight recurring themes rather than what mattered, so the most important sentence in the meeting can be dropped precisely because it was said once.

A purchase invoice reads itself. Image recognition reads the supplier, the amount, the VAT and the due date off a PDF invoice, and a small classification model proposes a posting based on how comparable invoices were posted before. No language model, no chat, and in use for years. A new invoice layout goes wrong quietly, so the uncertainty has to be shown rather than hidden.

Deviations are found in a draft contract. A model compares the contract received against the house template and marks the clauses that differ: limitation of liability, notice period, intellectual property. It does not say whether a deviation is good or bad. A lawyer says that, and their time now goes to the right clauses.

Internal search starts answering questions. Instead of returning three hundred documents, the system retrieves the most relevant passages and writes an answer from them, with sources. This is retrieval, and its most common hazard is managing the source material: if two versions of a guideline are in circulation and versions and access rights have not been handled, the model will write an equally fluent answer from either.

Translation is no longer a separate project. A guideline, a bulletin or a safety card is rendered into ten languages in a minute. Checking is needed when the text carries legal or safety content, and then the checker is worth naming in advance.

A pile of job applications is put in order. Here it is worth stopping. Assessing and screening job applicants falls in principle under Annex III high-risk use of the AI Act, and the key obligations begin to apply on 2 December 2027. Law aside, this is the use in which bias carries over from old decisions into new ones faster and more consistently than any human ever managed. A tool can summarise an application. Putting them in order is a different matter from summarising.

Voluntary organisations

This group is usually left off use-case lists entirely, even though it is where the benefit arrives fastest. The reason is simple: the work is done in the evenings, the people change, and nobody has time to learn a system. I wrote a playbook for one section of a sports club, and the use cases settled into two groups.

Freely usable are the uses where a person sees the result immediately and the reader corrects any error themselves: bulletins and social media posts, summarising meeting notes, induction guides for team managers and volunteers, tournament schedules and task lists, training material, condensing a federation's rules and guidance into something readable, and translations and plain-language versions for multilingual families. That last is a good example of something that used to be too laborious or too expensive for a volunteer organisation: few volunteers translate a season bulletin into four languages, but a machine does.

Requiring judgement are the ones where a decision follows from the result: weighing options in season planning, the content of grant and funding applications, assessments concerning players, and anything handling the data of minors. In these the machine's output is a draft, and a named person answers for the result.

For an association this division is in practice the whole governance model. It is the same idea as the three-basket model in the playbook, on a smaller scale: two labels, free and considered, and one of them written next to every use case.

Industry, agriculture and networks

A bearing's failure can be visible weeks in advance. Vibration and temperature data are compared with what the data looked like before previous failures. When the probability crosses a threshold, an alert follows. The threshold is a human decision: too sensitive and it cries wolf, too insensitive and it is late. The model gets confused when the process is changed, because it is comparing the present against a world that no longer exists.

A scratched part leaves the production line. A camera photographs every part, and an image recognition model tells an acceptable one from a defective one faster than a person can glance. The difficulty is not the recognition but that defects are rare in the data, and a new kind of defect is by definition one the model has not seen.

A calving is approaching. A movement sensor on a collar and a measure of rumination signal the change before it is visible in the barn. The same technique detects oestrus and the onset of illness. This is everyday agriculture, and it is not usually counted as AI.

A field is photographed from the air and sprayed precisely. A plant disease or a weed is recognised in the image, and pesticide is applied only where it is needed. The benefit is financial and environmental at the same time, which is rare.

A fault in the electricity network is anticipated. From partial discharges in a cable and the history of weather and load, a risk is computed for which part of the network fails next. The output is a maintenance plan, not an alert.

A municipality's streets are surveyed by driving. A camera on a refuse lorry's windscreen films the street, and a model identifies potholes, broken road signs and worn crossing markings. A survey that used to be done separately once a year now appears as a by-product.

Public services and school

The attachments to a permit application are checked before processing. Checking mandatory fields needs no AI; ordinary form logic does that. AI is needed for the free-form parts: is the attachment the right kind of statement, does the written description match what the application concerns. This is not decision-making but pre-checking, and that is exactly why it is easy to adopt: the machine does not settle the matter, it prevents a wasted round.

A pupil gets extra work at their own level. A model produces exercises and explains the same thing differently if the first explanation did not help. The teacher's work does not shrink here but shifts: from making ready material to choosing and checking it.

A pupil's need for support is surfaced in time. Absences and grades are combined into a prediction. Depending on the purpose this may be high-risk use: the classification depends on whether learning outcomes are being assessed, the learning process steered, or the pupil profiled. The most important question is still not technical but social: does the prediction label the pupil or get them help? The same model does either, depending on what is done with the result.

A citizen is answered in their own language. Guidance is translated and simplified, which is a question of accessibility before it is a question of efficiency.

Four things that recur in all of them

Looking at the list as a whole, the same four features come back regardless of whether it is a barn or an emergency department.

Most are not language models. Of the thirty cases, fewer than a third rest on a language model. The rest are image recognition, sensor data, anomaly detection and prediction models, some of which were in use long before anyone talked about AI.

The machine screens, a person judges what has consequences. In many working use cases the machine's job is to cut a thousand things down to the ten a person should look at. Not in all: a production line removes a defective part by itself, because the consequence of an error is cheap and fixable. The more serious the consequences of a decision, the more it matters that a person has a genuine opportunity to assess the result and intervene. An approval button alone is not such an opportunity.

The error is quiet. The machine does not usually announce that it is wrong. It gives an equally convincing result when wrong as when right, and an empty result looks the same as "nothing found". That is why the most important design question is almost always what happens when confidence drops.

The same technique is a different matter in a different use. Image recognition on a production line is an ordinary quality-control tool; used to identify a person in a public place it is legally a wholly different matter. Obligations follow the use, not the technology.

How you pick the few out of a thousand

Once a list is long enough, it stops helping. Four questions are enough to cut it down to something usable.

1. How much value does this produce? Frequency matters, because work repeated a hundred times a month accumulates benefit quickly. It does not settle it alone, though: the effort of a single run, the cost of an error and the cost of building it all count too. A rare but slow, expensive or safety-critical task may well be worth it.
2. Does somebody see the result, and would they notice an error? If the result passes straight on without anyone looking at it, the error is found only in the consequence.
3. What does an error cost? A wrong word in a bulletin gets corrected. A wrong treatment decision or a wrong payment does not undo itself.
4. Does the information needed exist, and are you allowed to use it? Most good ideas fall here: the information is in three systems, it is out of date, or there is no right to use it.

The first two say whether it is worth doing. The last two say what has to be done before doing it. And if the use case cannot be written as a single sentence on the pattern at the start of this piece, it is not yet worth attempting.

What happens to the chosen use case

Once a use case is chosen, its progress has been drawn on slides for ten years as the same five-stage circle:

1. The business problem. Definition, value, owner, priority.
2. Data. Availability, provenance, security, coverage, cleaning, enrichment, labelling, data flows.
3. Building the model. Feature selection, hyperparameters, tuning, comparing models.
4. Deployment and measurement. Measuring value, comparative trials, versioning, connecting it to how work is done.
5. Continuous learning and tuning. Managing bias, ground-truth data, monitoring.

The circle is not obsolete, but it proceeds differently depending on whether the model is trained in-house or a ready-made one is used.

When the model is trained in-house

This is still how the sensor, image and prediction cases in this piece are done: anticipating calving, predicting a bearing failure, quality control on a production line. The five stages hold there almost as they are, and that is why the circle is not to be thrown away. Stage two then means what it has always meant: collecting, labelling and cleaning material. Stage three really is building a model.

When a ready-made model is used

Here three points change.

Stage three is no longer building a model. In most use cases no model is trained at all; a ready-made one is chosen and what decides the quality is built around it: instructions, retrieval of the information needed, tools and limits. In place of feature engineering there is now the question of what is handed to the model. This is the prompt, retrieval or fine-tuning choice, and it takes the time that used to go to hyperparameters.

Access rights are now settled at run time too. The main question used to be what data may be fed to the model during training. That has not gone away, but a second one has arrived alongside it: in a retrieval-based system, every query has to settle which documents this particular user may see. That lands in access management rather than data architecture, and it is the most common security hole in retrieval systems.

The model can change underneath you. If you are on a supplier's updating service version, the same instruction can produce a different result from last month. If you are on a pinned version, that does not happen, but then updating is its own decision and its own round of testing. Whichever is chosen, choose it deliberately, because it determines how often the results have to be checked again.

Evaluation and monitoring

Evaluation earns its own stage on the slide. In classical machine learning there was often a labelled test set and a compact accuracy figure, but building those never came free: assembling the test set, choosing the right metric and making sure the result generalises beyond the test set have always taken work. In generative tasks evaluation is typically harder, because there can be several acceptable answers. Then you need a task-specific set of cases, automated checks and often human rating as well.

The practical minimum is a set of real cases with known good outcomes, run through after every change. Without that you cannot know whether a change improved things or made them worse, and then development is an exchange of opinions.

The old circle's most important lesson holds through all of this unchanged: it is a circle and not a line. And because starting an experiment now costs almost nothing, the failures have moved out of stage three. They happen now in stages one and four: nobody agreed what would be measured, and the result was not connected to the work people actually do.

More concrete descriptions of individual cases, at the level of what the machine does, what the person does and where it breaks, are on the examples page.