Every vendor demo now has an AI feature in it somewhere, and most of them do the same three things: summarise a document, draft a reply, or flag an anomaly in a spreadsheet. That is not a criticism. It is a sign the useful applications have narrowed to a short list, and the software worth paying for is the kind that picks from that list deliberately rather than bolting on a chatbot because the sales page needed one.
Key Takeaways
- The AI features that hold up in daily use are narrow and specific, built to remove one repetitive task, not marketed as a general intelligence layer over the whole product.
- Most organisations already use AI in at least one business function, but a majority of those same organisations report no meaningful bottom-line impact from it yet.
- Any AI feature that touches personal data has to be assessed against data protection law before it ships, not after a complaint arrives.
- Standardised risk management frameworks exist specifically because AI features fail in ways traditional software testing does not catch, particularly around bias and unpredictable output.
- A feature that cannot explain why it produced a given answer is a liability in regulated or safety-relevant business software, whatever else it does well.
The gap between the adoption headline and the impact finding is where most of the actual decisions sit, and it is worth understanding before signing off on a feature.
The features that survive contact with daily use
The AI additions that stick tend to share a pattern: they replace a specific, well-defined task a person was already doing manually, and they leave a human able to check the output quickly. Document summarisation for a support inbox. Drafting a first pass at a reply that a person still reads before sending. Flagging an outlier in a finance report for a human to investigate. None of these claim to make a decision on their own, and that restraint is exactly why they survive past the pilot stage.
Contrast that with features added because a competitor announced something similar. IBM’s own analysis of AI in business software points to a fairly narrow set of proven uses, coding assistance, document automation, support efficiency, rather than a sweeping transformation of every workflow at once. Stanford’s 2024 AI Index Report found much the same pattern at the level of whole organisations: corporate adoption kept broadening across business functions even as most of that adoption clustered around a handful of narrow, well-defined tasks rather than a general-purpose overhaul.
A hand pointing a pencil at a printed page of charts next to a laptop
Why adoption and impact keep diverging
Most organisations report using AI in at least one business function today. Fewer report it has moved the bottom line in any way they can point to. That gap is not a reason to avoid AI features, but it is a reason to be sceptical of a vendor pitch that treats “we have AI” as the whole argument. The businesses seeing real impact are the ones measuring a specific metric before and after the feature shipped, support ticket resolution time, document turnaround, error rate on a defined task, rather than treating adoption itself as the success measure.
An AI feature that cannot be measured against a specific task is decoration, not a business case.
This is also where procurement conversations go wrong. A feature list heavy on AI branding but light on a named, measurable job to be done is usually a sign the vendor has not decided what the feature is for either.
The compliance layer nobody can skip
Any AI feature that processes customer or employee data sits inside data protection law the moment it goes live, not as an afterthought once legal notices it. The UK’s Information Commissioner’s Office updated its detailed guidance on how AI systems have to be assessed for fairness and lawfulness under data protection rules in 2023, and it applies whether the AI feature was built in-house or bought from a vendor. The UK government’s own AI Opportunities Action Plan, published in January 2025, pushes the other direction, encouraging faster public and private sector adoption, which makes the compliance guidance the more important document to read closely rather than less, since the pressure to ship quickly hasn’t removed the obligations underneath it.
A man showing a woman a printed finance report at a small table
Beyond data protection, there is a broader question of whether the system behaves predictably. The US National Institute of Standards and Technology released its AI risk management framework in January 2023 precisely because AI features fail differently to conventional software: not through a crash, but through quietly biased or inconsistent output that traditional QA testing was never designed to catch. A business commissioning an AI feature should be asking, before it ships, how that specific failure mode gets tested for, not assuming a feature that works on a demo dataset will behave the same way on live customer data.
A developer viewing lines of code on a large desktop monitor
Building it properly rather than bolting it on
The organisations doing this well tend to treat an AI feature as they would any other business-critical component: scoped to a named problem, tested against real data before launch, and reviewed against data protection obligations as part of build, not after. That discipline is exactly what separates a feature that earns its place from one that gets switched off quietly within a year because nobody could point to what it actually improved.
This is the kind of build where working with app developers in the UK who have handled AI-integrated products for regulated or sensitive contexts pays off, because the compliance and testing questions surface earlier, when they are still cheap to answer. EP Assist, an AI-integrated web platform built for educational psychologists, is one example of that discipline in practice: the AI component had a single defined job, supporting the professional’s own assessment work rather than replacing their judgement, which kept the feature bounded to what it could reliably do well.
Frequently Asked Questions
How do you know if an AI feature is worth building into business software?
It should solve one specific, named task, and you should be able to define what “working” looks like before you build it, such as a measurable drop in handling time or error rate. If nobody can state the metric it is meant to move, that is a sign the feature is being added for its own sake.
Does adding AI to software automatically create a data protection risk?
Any AI feature that processes personal data is subject to the same data protection obligations as any other system handling that data, and the ICO has published specific guidance on how those obligations apply to AI. The risk exists whether the feature is described as “AI” or not; what matters is the data it touches.
Why do so many businesses report using AI without seeing a financial return?
Largely because the feature was adopted rather than measured. A chatbot or summarisation tool added because it seemed expected will not show up in any metric unless someone defined, in advance, what improvement it was meant to produce and tracked it.
Should every business feature explain its AI-driven output to users?
In regulated or safety-relevant contexts, yes, because an output nobody can account for is a liability the moment it is challenged. In lower-stakes contexts the bar is lower, but a feature that cannot be explained at all is harder to trust and harder to fix when it goes wrong.
Is it better to build an AI feature in-house or buy one from a vendor?
Neither route removes the need to test the feature against your own data and your own compliance obligations before launch. A vendor product still needs the same scrutiny a bespoke build would get, because the risk sits with how the feature behaves on your data, not with who wrote the code.