We integrate AI into business applications where it removes real work from a person. We do not add it so that a system can be described as an AI system. That distinction sounds obvious and is, in practice, the whole of the decision.
Where it genuinely helps
- Extracting structured data from documents that arrive in inconsistent formats
- Classifying and routing incoming work that a person currently sorts by hand
- Drafting repetitive text that a person then reviews and approves
- Surfacing relevant records from a large set faster than a search form allows
What these have in common is that a person was already doing the task, the task was tedious, and a human remains in the loop where the output matters.
Where it should stay out
Anywhere the output is a figure that must reconcile. Anywhere the decision has clinical, financial or legal consequence without review. Anywhere the organisation would be unable to explain, after the fact, why the system did what it did.
Operational systems are judged on being correct and explicable. An approximate answer delivered confidently is worse than no answer in most of the contexts we work in.
Design the review step first
When we integrate AI into a workflow, the review mechanism is designed before the capability is. Who checks the output, how quickly, what they see when they disagree, and what happens to the record afterwards. If a workable review step cannot be designed, that is a strong signal the automation does not belong there.
Data handling is not an afterthought
Business systems frequently hold clinical, financial and personal data. What leaves the organisation, where it is processed and what is retained are questions that must be answered before integration, not discovered during a security review. In several engagements the correct answer has been that certain data does not leave at all — which constrains the design and is worth knowing early.
The measure we apply is simple: did this remove work a person was actually doing? If the honest answer is no, it should not ship.