AI Vendor Risk for Credit Unions Is a Per-Request Control Problem

A lending employee sends a member's pay stub summary and debt history to a model provider to draft an underwriting note. The request travels over HTTPS, the provider processes member information, and the credit union's core system records none of it. Appendix A to 12 CFR Part 748 expects a federally insured credit union to exercise service-provider diligence, require safeguards by contract and monitor providers when its risk assessment calls for it. AI vendor risk credit unions is operational at the individual request, because that is where the approved relationship meets actual member data.

I want to connect NCUA's vendor expectations to model traffic, show where periodic review loses visibility, and define the evidence that a board committee or examiner can use.

TL;DR

• Part 748 tells credit unions to perform service-provider diligence, contract for safeguards and monitor providers according to risk.
• The security programme must adjust as technology, threats and outsourcing arrangements change, which brings new model routes into scope.
• A provider review covers the company; request evidence shows which employee or agent sent which class of member data.
• Inline policy can block, redact or route a request before the provider receives it and preserve the decision for examination.

Part 748 makes vendor oversight continuous

Appendix A to Part 748 sets out the information-security expectations for member information. Its service-provider section tells each credit union to exercise appropriate diligence when selecting providers and to require appropriate safeguards by contract. Where the credit union's risk assessment indicates monitoring, it should review audits, test summaries or equivalent evaluations of provider performance.

The next section requires the institution to monitor, evaluate and adjust its programme as technology changes, threats shift and business arrangements evolve. Outsourcing appears explicitly in that list. The annual board report also addresses service-provider arrangements alongside risk assessment, testing results and security violations.

These provisions turn AI vendor review into a cycle. A procurement assessment establishes the provider's control posture. Contract terms set the conditions. Ongoing monitoring checks the provider's performance. Internal request evidence then shows how the credit union used the service. AI governance for credit unions describes the policy structure. Vendor oversight needs the traffic record underneath it.

The provider relationship begins with the data path

NCUA's guidance on evaluating third-party relationships gives examiners a framework for planning, diligence and controls. It says the work depends on the credit union's risk profile and the type of vendor relationship, with the critical nature of the service and regulatory changes among the minimum considerations.

A model provider can enter the relationship in several ways. An approved workspace is the obvious route. A loan-origination vendor may add summarization. A collections agent can call an LLM through an integration, while a contact-centre employee uses a browser chat product. Each route sends a different slice of member information under a different identity and contract.

The vendor inventory should therefore identify the endpoint, calling application, business owner, allowed use, member-data classes, retention setting, model version policy and contractual safeguards. The physical detail I would ask an examiner to look for is simple: can the credit union print one page that shows the arrow from the authenticated employee to the model endpoint, including the system that records the decision?

Periodic assurance misses individual use

A provider's audit report can show that its access control and change-management processes operated during a period. It cannot show that a mortgage officer sent a particular member's income, account balance and delinquency history on a Tuesday morning. That fact exists inside the credit union's use of the service.

Shared credentials make the gap worse. An application token identifies the loan platform while hiding the employee who initiated the workflow. A model usage dashboard may retain prompt content, which creates another sensitive repository, or expose only aggregate counts, which leaves the institution unable to reconstruct the request. Shadow AI in credit unions covers the discovery side of this problem.

My opinion is that annual vendor review is a comfortable hiding place for an operational blind spot. A binder can be complete while member data still leaves through an unrecorded model call. The review and the request record do different jobs, and the credit union needs both.

The record must answer a member-level inquiry

Part 748 defines member information around records containing nonpublic personal information about a member maintained by or for the credit union. The same rule's cyber-incident definition includes substantial unauthorized exposure of sensitive data and specifically recognizes incidents caused by a cloud provider or another third-party data host.

A useful AI decision record captures the authenticated employee or agent, role and branch or business unit, calling application, provider endpoint, model version, member-data classification, policy version, enforcement result, timestamp, and integrity reference for request and response. It also needs a stable member or case reference when policy permits one, because an inquiry begins with the affected account rather than the person who happened to make the call.

Retention should follow the credit union's own incident, complaint and recordkeeping schedules. Access to the evidence needs separation from the lending or contact-centre application that created the request. The general audit design is covered in AI audit trail requirements by regulation.

Inline policy connects diligence to use

The contract can prohibit training on member data and set retention terms. An inline control decides if a specific request complies before the data reaches the provider.

A policy might allow public product-copy requests to an approved model, redact member identifiers in a call-summary workflow, and route underwriting material to a private endpoint covered by the credit union's approved arrangement. It can reject an unknown model alias or a browser route outside the inventory. Every outcome produces evidence, including blocked attempts.

This is where the NCUA duty to adjust the programme is concrete. Newly enabled AI may create a new hostname or API route. Discovery flags it, risk staff classify the use, and policy places it on an approved route or closes it. The connection between identity and authorization matters because authentication only says who called. The post-authentication gap explains the missing decision about what that caller may send in this request.

DeepInspect

DeepInspect is a stateless proxy on authenticated HTTP traffic between a credit union's users or agents and LLM endpoints. It evaluates identity, application, member-data classification, approved provider and model route before transmission. The policy result can permit, redact, block or route the request to a private endpoint.

Each decision creates a signed audit record containing the caller, role, application, data classification, destination, model version, policy version, outcome and timestamp. The records give vendor management, security and examination teams a shared view of actual use. DeepInspect covers the AI request boundary. Contract negotiation, member-notice decisions, incident reporting and the board's oversight duties are with the credit union.

Book a demo today.