The real problem comes before the model question
When a team says it wants to add AI, the first question is often which model to use. A more useful question is which piece of work makes people wait, copy the same facts or make the same decision repeatedly. Without that friction in view, AI only makes an unclear workflow faster and harder to inspect.
Map the workflow before automating it
Start with a small map: where a signal enters, who owns it, which state may change and when the work must move to another person. It does not need elaborate vocabulary. It needs to be clear enough that a new teammate can point to the evidence, the inference and the action with consequences.
- Separate verified facts from model inference.
- Name the person responsible for every state transition.
- Record why a suggestion was accepted or rejected.
- Keep a safe state to return to when source data is wrong.
Where should AI sit?
In many products, AI is most useful just before a decision: summarising a long request, grouping related signals or suggesting a few options that can be checked. It should not become the final source of truth by itself. An order status, an access grant, a match lineup or a payment needs a clear confirmation path outside the model.
Design an observable loop
A useful suggestion is more than generated prose. The interface should show which data was used, what is missing and which action the user will own after confirmation. These small traces help the team notice when a prompt, a data source or a business rule starts drifting away from the others.
- Show the relevant source or fields behind a suggestion.
- Separate preview from the button that performs an action.
- Keep the minimum input and output trace needed for review.
- Set a time and permission boundary for each task.
Do not measure AI by surprise
A demo that delights for a few minutes says little about a system used for weeks. Better questions are how long the work takes, how often it needs correction, when it reaches an experienced person and whether an incident can be explained. Those questions force the product to serve a workflow instead of a model leaderboard.
Good AI does not take the decision away; it makes a sound decision easier to see and check.
Conclusion
Starting with the workflow creates a healthy boundary: the model may propose, the system may validate and a person decides where the consequence belongs. With that boundary in place, changing a model or provider remains a manageable technical change rather than a product rewrite.