It is easy to get lost in what AI could do. A more useful question is narrower: what does your team do repeatedly that is slow, boring and shaped by rules or patterns? That is where AI earns its place first.
This article covers the kinds of tasks where AI works well today, the kinds where it doesn't, and what separates a useful AI feature from a demo.
Good first uses
The tasks that suit AI best share three traits: they are repeated often, they have a clear input and output, and there is a way to check whether the answer was right.
- Answering questions from your own documents: policies, SOPs, manuals, past proposals. This is usually built as retrieval-augmented generation (RAG), where the system first finds the relevant passages and then answers from them, with references.
- Pulling fields out of documents: invoice numbers, dates, amounts, names from forms and contracts, written straight into your system.
- Forecasting a number you already track, such as demand, sales or workload, from your own history.
- Tagging, sorting and searching images or documents, such as routing incoming requests to the right team.
Where AI is the wrong tool
AI is a poor fit when the rules are already clear and fixed. If the logic can be written down as "if this, then that", ordinary software or automation will be cheaper, faster and fully predictable. AI is also a poor fit where a wrong answer is costly and there is no way to check it, or where there is simply no data to learn from.
AI or automation?
Many problems people bring to AI are really automation problems. This is a quick way to tell them apart.
- Fixed rules, structured data → automation (routing, approvals, notifications, syncing systems).
- Unstructured text or images, patterns that are hard to write as rules → AI (reading documents, answering questions, classifying).
- Both → automation for the flow, AI for the one step that needs judgement on messy input, with a person reviewing uncertain cases.
What makes an AI feature useful in practice
Most of the work in a real AI feature is not the model. It is getting the right data to it, putting the result where people already work, and deciding what happens when the model is unsure.
- Grounding: answers come from your own sources, and show which source they used.
- A fallback: when confidence is low, the case goes to a person instead of guessing.
- Integration: the feature lives inside the system people already use, not in a separate tab.
- Measurement: accuracy is checked against real examples before launch and monitored after, because data and documents change.
- Access control: the assistant can only see what the person asking is allowed to see.
An example: a document assistant
One of the projects on our work page is an enterprise knowledge assistant: a system grounded in an organisation's own documents that retrieves the relevant passages and answers from them, with the monitoring needed to keep it accurate over time. The value comes less from the language model than from the retrieval, the references and the checks around it.
Questions to answer before you start
Five questions settle most of the risk in an AI project before any model is chosen. If the answers are vague, the project usually is too.
- What exactly is the task? "Answer questions about our return policy" is a task; "use AI for customer service" is not.
- Where does the knowledge or data come from, and who keeps it up to date?
- How will we know an answer is right? Collect a set of real examples with known correct answers before building anything.
- What happens when the system is unsure or wrong? Decide who reviews uncertain cases and how they are flagged.
- Who is allowed to see what? An assistant over company documents must respect the same permissions as the documents themselves.
What it costs to run, not just to build
AI features have running costs that ordinary software doesn't. Hosted language models are usually priced per request or per amount of text processed, so a feature used heavily costs more each month than one used rarely. Documents have to be re-processed when they change. Accuracy has to be checked periodically as data and documents drift.
None of this is a reason not to build, but it belongs in the plan from the start, alongside a simple measure of whether the feature is still earning its keep.
How to start
Begin with one small, well-defined task. Collect real examples of inputs and correct outputs, build a quick prototype against them, and measure how often it is right before connecting it to anything important. If it passes, integrate it properly with access controls and a fallback; if it doesn't, you've learned that cheaply.
Our AI & machine learning service follows that path. In manufacturing, for example, a natural first task is searching across SOPs, drawings and work instructions.
