Scoping a first AI project: start with one workflow

A first AI project is easier to get right when it is small enough to judge. Many teams start from a technology, such as a language model they want to use. A more reliable starting point is one piece of work that someone does every week, and a clear idea of what "better" would look like for it.

Pick one workflow with an owner

A workflow is a task with a start, an end and a person who owns it: triaging incoming requests, checking supplier invoices against orders, forecasting next month's stock. It is narrow enough that you can describe what goes in, what comes out and who acts on the result.

A useful test is whether you can name the person who would use the output on a Monday morning, and say what they would do differently because of it. If you cannot, the scope is still too broad.

Define the decision before the model

Write down three things before any build work starts:

• Who uses the result, and at what point in their work.
• What a useful improvement looks like in terms they already measure, such as hours saved, fewer missed items or earlier warnings.
• What happens when the system is unsure or wrong, and who reviews those cases.

The third point is easy to skip. A system that sends uncertain cases to a person is usually more useful than one that is confidently wrong some of the time.

Check the data you already have

You do not need a data warehouse to begin. You do need examples of the work: past requests and how they were handled, historic orders, labelled images. Look at how many examples exist, how consistent they are and whether you are allowed to use them for this purpose. Permissions and privacy belong in this step, before anything is built.

Compare against a simple baseline

Before investing in a custom model, measure how well a simple approach does: a rule, a spreadsheet formula, last year's figure. If a custom model cannot clearly beat that baseline on your own data, it is worth knowing early and cheaply. If it can, you have a number that justifies the next stage.

Plan the handover at the start

A model that works in a demo still has to live in someone's working day. Decide early where the result will appear, how it will be monitored and who owns it once the project team steps back. Write down its known limits so the people who rely on it know when to trust it and when to check.

A short checklist

• One workflow with a named owner.
• A written definition of a useful result.
• A plan for uncertain or wrong outputs.
• Enough representative examples, with permission to use them.
• A simple baseline to beat.
• An agreed owner and monitoring plan after handover.

If you have a task in mind and want a second opinion on whether it makes a good first project, tell us about it. You can also read how we approach machine learning and natural language processing work.