Start with an employee decision
Servicing knowledge sits in procedures, correspondence, case notes, transaction records and vendor platforms. AI can make it easier to use if the institution knows which material is authoritative, who may access it and how an answer is evaluated.
Henna83 recommends starting with a bounded employee task, such as finding an approved procedure. Define what the assistant may answer, when it must clarify or escalate, and which source version governs. A demonstration with a few documents does not establish production readiness.
Three decisions come first: approve the knowledge boundary, establish access and update controls, and define a representative test set. Connect them to the workflow owner and the consequence of a wrong response.
Begin with a charter and inventory, then a controlled evaluation. Do not extend authority into borrower-facing actions or automated decisions before the institution establishes the relevant controls and approvals.
Know what the system may use, what it may do and how the institution will judge the result.
Ambition is increasing; controls need definition
KPMG's 2026 survey of 200 U.S. banking executives found that 80% expected significant AI disruption over three to five years [1]. This measures expectations, not deployed value or mortgage-servicing success.
NIST's Generative AI Profile is a companion to the voluntary AI Risk Management Framework [2]. It informs risk identification and evaluation. It is not certification, a safe harbor or a substitute for the institution's governance.
Regulation X contains applicable loss-mitigation procedural requirements [3]. A knowledge tool touching those workflows needs approved sources and escalation rules. This paper does not interpret borrower eligibility or authorize automated treatment.
Pair ambition with a knowledge operating model. Ownership, versioning, permissions and evaluation become delivery workstreams. Cost and value should be measured for the specific workflow, including verification effort and specialist review.
An expectation of disruption is a reason to prepare, not evidence of use-case readiness.
Five readiness boundaries
Authority: distinguish approved procedures from drafts, archives and informal notes. Retain effective dates and owners. Answers should cite the source used.
Access: preserve client-approved permissions through ingestion and retrieval. Consolidating an index must not give a user access to restricted material. Test access at retrieval.
Context: match product, investor and event timing to the correct procedure. Missing context should trigger clarification or referral, not a plausible general answer.
Evaluation: test routine questions, ambiguity, missing information, stale versions and restricted content. Establish quality and escalation criteria before measuring the pilot.
Operation: name knowledge and technical owners. Define refresh, change approval, incident handling and withdrawal. An unsafe source or behavior needs a prompt correction route.
The boundaries are connected. A correct answer from a prohibited source is still a failure. A cited answer from an obsolete version may also fail. Evaluate the whole workflow rather than a language model in isolation.
Technical context: retrieval-augmented generation can supply approved source context to a model, but retrieval does not itself guarantee authority, access or correctness. Evaluate the retrieval boundary and the generated response separately. Keep document identifiers, effective dates and citations. Establish how updates remove obsolete material from the active index. Prompt injection, inappropriate disclosure and unsupported answers require representative tests and an incident response route.
Exhibit: bounded-use-case readiness
This original Henna83 canvas makes decision authority explicit. Missing controls remain unresolved items rather than low scores offset by a good demonstration.
| Boundary | Decision | Evidence |
|---|---|---|
| User and action | Who uses it; what may they do? | Approved charter |
| Knowledge | Which versions are authoritative? | Inventory and approvals |
| Permissions | How is access enforced? | Design and negative tests |
| Evaluation | Which failures block release? | Representative test set |
| Escalation | When is a person required? | Workflow tests |
| Run state | Who updates and withdraws it? | Support and change process |
Using the canvas: select one task and define release-blocking failures before running the evaluation. Include authorized and unauthorized users, current and stale sources, missing context and requests outside scope. Review test failures by cause. A language-quality improvement should not obscure a permissions failure. Retain evidence for the exact model, retrieval configuration and source versions evaluated.
Evaluate source access, citations, context and escalation together.
Worked example: procedure retrieval
Illustrative scenario, not a deployed client solution. An employee asks which procedure applies to an event. The tool returns a cited approved passage and its effective date.
A test question lacks information that determines the appropriate procedure. Desired behavior is clarification or referral. A confident answer for the wrong scenario fails even if it is well written.
Another test includes a superseded procedure retained for historical investigation. The retrieval design prevents it from governing a current answer while preserving authorized archive use. Negative access tests confirm that restricted case material is not exposed.
Measure verified task completion and grounded answer quality against a baseline. Track inappropriate responses and escalations separately. Faster responses do not establish value if employees spend more time verifying them or material errors increase.
The controlled learning cycle improves the knowledge boundary before increasing authority. An expansion requires new sources, permissions and evaluation coverage, not simply a larger index.
Questions for the CIO and operations leader: Which source governs? Can access be enforced at retrieval? Which answers require escalation? How is stale knowledge withdrawn? What changes before the tool gains more authority?
Prepare a controlled pilot
Select one task, approve the charter and inventory sources. Label superseded content and confirm owners. Establish permission enforcement before indexing sensitive material.
Agree release criteria and build tests for routine, unknown, wrong-context, stale and restricted questions. Review failures with workflow and control owners.
For a limited pilot, define monitoring, feedback, updates and withdrawal. Track task completion, error types, escalation outcomes and freshness. Financial benefit claims require a baseline and adopted workflow.
Henna83 connects AI strategy to data foundations, ownership, controls and delivery. Use the Data Discovery & Readiness Kit to establish the inventory, then discuss a bounded workflow through Let's talk.
Measurement detail: define groundedness, appropriate escalation and task completion with observable criteria. Track restricted-content exposure separately as a material control failure. Compare end-to-end time including human verification, not response-generation time alone.
References
[1] KPMG LLP. Banking Leaders' Prepare for Anticipated Disruption from AI and Cyber Investments Increase: KPMG Survey. June 17, 2026. https://kpmg.com/us/en/media/news/2026-banking-technology-survey.html
[2] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. July 26, 2024; NIST AI 600-1. https://doi.org/10.6028/NIST.AI.600-1
[3] Consumer Financial Protection Bureau. 12 CFR 1024.41: Loss mitigation procedures. Current online regulation checked October 10, 2026. https://www.consumerfinance.gov/rules-policy/regulations/1024/41/