There is a lot of pressure on businesses to "add AI" right now, and most of it is the wrong way round. The question is never "where can we use AI?" It is "what specific, repeatable task is costing us time, and would a model do it reliably?" Start from the technology and you get a demo. Start from the work and you get something that pays for itself. Here is how we decide.
The question worth asking first
When a client asks us to add an AI feature, our first question is: what does it replace? If the answer is a manual step a person currently does, and that step can be described precisely, and the cost of getting it wrong is manageable, there is likely a case. If the answer is vaguer, if the feature is meant to make something "feel smarter" without a specific workflow behind it, the case is much harder to make.
This is not reluctance to build. It is a recognition that language models are genuinely good at a handful of things and unreliable at others, and the difference between a useful feature and an expensive liability is usually whether you picked the right task.
Where AI reliably pays off
Retrieval over your own documents. A model with access to a company's own material (product specs, past proposals, support histories, policies) can answer questions that would otherwise need a person to search and synthesise across many files. The accuracy depends as much on the quality of the retrieval layer as on the model itself, but the pattern is well understood and well suited to professional services and any business where knowledge is spread across a lot of documents.
Routing and classification. Deciding which category an incoming request belongs to, or which team should handle it, is a task models do reliably when the categories are well defined and a person reviews the edge cases. This works in support queues, document intake and lead qualification. The model handles the common cases; people handle the rest. The economics are clear, because classification time is a direct cost and reducing it without adding errors has a measurable return.
First-pass summarisation within a workflow. Turning a long document into a structured summary that feeds a downstream step, a brief, a report section, a data extraction, is high value when the output is checked. The model does not need to be perfect. It needs to be faster than a person at a first pass, with a review step before anything consequential goes out.
Where it does not
Open-ended generation in regulated contexts. A model generating client-facing content in financial services, legal or healthcare without a tight review process is a liability, not a feature. The output can be plausible and wrong in ways that are hard to catch at volume. We have declined to build this when asked, and explained why.
Replacing a judgement call that carries weight. Models are not decision-makers. They produce outputs a person with authority can use as input to a decision. If a feature is positioned as making the decision, that positioning is the problem, regardless of how accurate the model looks in testing.
Domains where the training data is thin. A model asked to reason about highly specific knowledge that did not appear in its training will produce confident, wrong answers. The confidence is the risk. We test behaviour on the actual content a feature will encounter before recommending the approach.
How we approach an AI feature
We start with the workflow, not the technology. We identify the step that is slow, expensive or error-prone. We check whether the inputs to that step are consistent enough for a model to handle. We design a review layer proportional to the cost of an error: light where mistakes are cheap, strict where they are not. Then we build a narrow version and measure it against the current baseline before widening scope.
We have done this in our own products, not just for clients. The AI coach in our Kinta Fit app answers using a user's real training and nutrition data rather than generic advice, which is exactly the "retrieval over your own data" pattern applied to a real workflow. Building it ourselves keeps us honest about what actually works on a phone, in production, with real data.
Data, privacy and funding
The moment an AI feature touches customer data, where that data goes matters. Features can be built with EU hosting and clear data boundaries, and we are upfront about what data a feature uses and where it travels. For Irish businesses, AI scoping and projects can sometimes be supported through Enterprise Ireland AI vouchers and related schemes, so it is worth checking what is currently available before you commit.
The short version
The AI features worth building are the ones where the workflow improvement is clear before anyone writes a line of code. If you cannot name the manual step it replaces, it is probably not ready to build yet.
If you have a concrete, repeatable task that might be worth automating, that is exactly the conversation we like to have. See AI integration, or book a demo.