AI has become markedly easier to build into digital products.
You no longer need a team of specialists to analyse documents, categorise text, generate content or let users search through large volumes of information. Many of these capabilities can be wired in through an API, and a prototype can often be built in relatively little time.
That opens the door to solutions that would have been expensive or unrealistic just a few years ago.
And it makes it tempting to start with the technology.
What are we trying to make better?
If a client asked me to build AI into an existing product, I'd start with the problem.
Do employees spend too long finding information? Does someone have to manually read and categorise hundreds of documents? Does support keep answering the same questions over and over? Is there a large amount of unstructured text that requires manual work?
Then we have something worth investigating.
It's the same approach I'd use for an app, a new CMS or an integration. First we need to understand the task. Only then can we choose the technology.
AI changes the range of what's possible. That order is the one I'd stick to.
AI can sit beneath the surface
The chat window has become the most visible image of AI. That's why so many ideas quickly end up as a text field where the user can "ask our AI".
Imagine instead a company with 20,000 documents. Employees spend time every day finding the right document, and then the relevant information inside it.
That's where AI could make the search better.
The user can still be met with an ordinary search field, a list of results and a few filters. Beneath the surface, AI can help understand the question, find relevant content or summarise the results.
The same applies to categorisation, handling enquiries, suggesting copy and a range of other tasks.
An AI feature can create real value without looking like AI at all.
What happens when it gets it wrong?
AI introduces a different kind of uncertainty than the one we normally work with in software.
Traditional code is typically deterministic. Given the same conditions, we expect the same result.
An AI model can produce something that looks convincingly correct, even when it's wrong.
That's why the consequence of a mistake matters at least as much as the model's accuracy.
If AI suggests a poor phrase for a product description, the user can edit it. If it miscategorises a document, the result can be presented as a suggestion awaiting approval.
If it instead forwards incorrect information to another system, or takes an action on the customer's behalf, the risk is a different one.
The same model can therefore be excellent for one task and unsuitable for another.
Maybe the AI should suggest – not decide
There's a real difference between:
"Here are the three documents I think are relevant."
and:
"Based on the documents, I've carried out this action."
In many products it makes sense to let the AI handle the time-consuming groundwork, and let a human make the final call.
The AI can read, sort, summarise and suggest. The employee checks the result.
If a task used to take 20 minutes and now takes two minutes to verify, that's already meaningful value created.
Full automation doesn't have to be the goal, then. The right boundary depends on the task, and on what happens when something goes wrong.
A flashy prototype is the easy part
One of the impressive things about current AI tools is how quickly you can get something working.
Take 50 documents, connect them to a model, build a simple interface. Before long, you can have a demo that answers questions about the material surprisingly well.
Then reality sets in.
- What happens with 100,000 documents?
- How fast does an answer need to arrive?
- What does each call cost?
- How do we measure quality?
- What do we log?
- How do we detect if the model starts producing worse results?
- And what does the product do when the service behind the model is unavailable?
This is where a demo turns into software that has to work every day.
AI has made it very fast to prove that an idea can work. Making it stable, economically sound and operable is still part of product development.
What data should the model have access to?
An AI feature is rarely better than the material it has to work with.
If it's meant to answer questions about a company's documents, we need to decide which documents it's allowed to see, how they're made available, and who's allowed to ask about what.
There's a difference between public product descriptions and internal documents containing customer information.
That affects the architecture.
Where is the data processed? What gets stored? What information is sent to an external provider? How do we handle user permissions? And what happens when a document is edited or deleted in the original system?
AI can absolutely be part of sensitive, business-critical workflows. It just requires that data and access are treated as part of the solution from the start.
Some problems have a simpler solution
AI is particularly interesting when a task has previously been hard to describe with ordinary rules.
Understanding the meaning of a text, finding patterns across documents, or formulating an answer from unstructured information are good examples.
Other tasks are already very precise.
If a system needs to find all unpaid invoices from the last 30 days, a database query can deliver a fast, predictable answer.
If support spends time answering the same question repeatedly, the cause might also be that the answer is hard to find on the website. In that case, better structure or search may be more valuable than putting a chatbot on top.
What matters is which solution removes the problem with the least unnecessary complexity.
Start with the smallest useful task
I'd rarely start with the ambition of automating an entire process.
Find one narrow task.
Something people spend noticeable time on today. Something whose result can be evaluated. And ideally something where a mistake can be caught before it has serious consequences.
Build that part, and use real data.
If an employee normally spends ten minutes finding and summarising information from five documents, that's a fairly good starting point. If AI can help do it in two minutes with the same or better quality, we have something concrete to measure.
From there, we can decide whether the solution should grow.
It's cheaper to discover the limitations there than after building an entire AI platform around an idea.
So should we have AI?
Maybe.
I use AI myself every day, and the technology has already changed my own workflow. Tasks can be solved faster, more ideas can be tried, and things that used to require a lot of manual work can be automated in new ways.
That makes AI worth investigating.
But it doesn't change the order I'd work in.
Understand the problem. Find out what actually needs to get better. Try the smallest solution that can show whether the idea holds up. Then choose the technology that fits the task.
The question isn't whether we can build AI into the product.
We probably can.
The question is whether the product gets better for it.
I help assess which problem an AI solution actually needs to solve, where it belongs in the architecture, and when a simpler solution is the right call.
