UP2DATE decision guide. General guidance; it does not replace a review of your processes, systems and data.
1. Check whether rules already solve the problem
A calculation, a known approval threshold or a fixed routing rule is usually a candidate for deterministic software. Searching a small, well-structured source may only require better search and information organization.
AI becomes worth investigating where the input varies and useful work involves language, classification or extraction. Even there, compare it with a simpler baseline. A convincing demonstration does not establish that AI is the most reliable or economical approach.
2. Check the information before selecting a model
Identify the authoritative sources, who maintains them and who may access them. Conflicting policies or outdated documents make it difficult to judge an answer, regardless of the model.
Use approved, representative examples to explore the task. Agree data handling before sharing material. If access, ownership or quality is unresolved, address those issues before running a pilot with business data.
3. Define the consequences of getting it wrong
An incorrect draft that someone reviews is different from an automated action that changes a customer record or authorizes a transaction. Specify where human approval is needed, which actions are out of scope and how a user can escalate.
If the required error tolerance cannot be demonstrated, keep the task outside automation or narrow its scope. NIST’s AI Risk Management Framework offers a voluntary reference for considering trustworthiness across AI design, development, use and evaluation.
4. Make a pilot a test, not a presentation
Agree a representative evaluation set, success criteria, a non-AI baseline and a cost boundary before building. Include difficult cases and requests the system should decline or escalate.
Measure useful completion and review effort, not just whether an answer appears. Include integration, monitoring and human checking in the cost. Decide whether to proceed, narrow the task or stop; production needs its own access controls, operating responsibilities and release criteria.
Bring this to the first discussion
- A specific task and examples of acceptable and unacceptable outputs.
- Authoritative knowledge sources and the people responsible for them.
- Known data-access constraints and consequences of an error.
- A simpler alternative against which to compare a pilot.
A related project
The published BRD knowledge-chatbot project is a relevant example of AI in banking support. A similar initiative still needs its own knowledge boundary, permissions and evaluation; the case study is not evidence that every support task should be automated.
Read the published case study →Need to evaluate your own situation?
AI Opportunity & Readiness Assessment →The initial 30-minute conversation is free. Detailed analysis, architecture and a delivery roadmap are separate, scoped engagements.
Let’s talk
