Should you put AI in your internal tool?
"We could add AI" comes up in nearly every conversation about an internal tool. Sometimes it is an excellent idea. More often, a well-placed rule does the job better, for ten times less.
Where AI genuinely helps
Good use cases share one trait: a fuzzy input, and an output that tolerates imprecision.
- Free text to sort — incoming emails, requests, comments
- Extraction — pulling information out of a PDF or a poorly structured message
- A first draft — a reply, a summary, a rewrite
- Search — finding a document by meaning rather than exact wording
Where it is a bad idea
As soon as a result must be exact and reproducible, AI is the wrong tool. A price calculation, an invoice total, a validation rule, an access right: that gets coded, tested, and returns the same result every time.
The test is simple: if two identical runs must produce exactly the same result, it is not an AI problem.
Questions to ask first
- What happens when it is wrong? If the answer is "we lose two minutes", fine. If it is "we lose money or a client", you need human validation.
- Who reviews it? A suggestion approved with one click is useful. An automatic action nobody looks at is a risk.
- Where does the data go? Client, HR or financial data: you need to know which provider it passes through, and be able to say so.
- What does it cost per month? Multiply the unit cost by your real volume, not the demo's.
- What happens if the service goes down? A tool that becomes unusable because an external API is offline is not a reliable internal tool.
A sensible approach
Start small: one feature, one precise place, a button that suggests and a human who validates. Measure whether it actually saves time. Extend if it does, remove it if it does not — and that is not a failure, that is the point of a trial.
In short
AI is not a layer you add on top of a tool: it is a feature like any other. It has to answer an identified need, with a known cost and a fallback. The rest is decoration.