AI Governance for Credit Unions Starts With Member-Data Routes

A lending specialist copies a member's income and account balance into an LLM to draft a call summary. She also includes delinquency notes. The browser shows one tidy text box. Behind it, an HTTPS request carries member information to a model endpoint through a vendor account with its own retention setting and access policy. AI governance for credit unions begins before that request leaves. The credit union needs an approved purpose and a named user. It also needs a permitted data class, an authorized destination, and a record of the decision. I would keep member information out of general-purpose chat tools until those five facts can be produced for an examiner.

TL;DR

• Put every AI use case in a register that names its owner and member-data classes. Record the model route and reviewer, with the evidence location in the same entry.
• Extend NCUA board oversight and risk assessment into prompts and responses. Apply service-provider supervision and reporting there too.
• Apply identity-aware policy to each authenticated HTTP model request, with separate controls for embedded vendor AI and local models.
• Test executed allow and block outcomes. Test review outcomes too, instead of treating an approved policy PDF as proof of operation.

NCUA safeguarding duties already provide the governance frame

The NCUA security-program rule and safeguarding guidelines apply to member information maintained by a federally insured credit union or on its behalf. Part 748 calls for a written security program. Appendix A directs the board or an appropriate committee to approve the program and oversee its operation, with specific responsibility assigned and management reports reviewed. It also calls for risk assessment and coordinated safeguards. Service-provider oversight and program adjustment are required, along with board reporting.

An LLM request fits that existing frame. A prompt may access or use member information, then transmit or expose it. The model provider or an AI-enabled service provider may process it on the credit union's behalf. Governance therefore needs more than a list of named chat products. Each record should describe the business activity and the information involved. It should also identify the calling application and exact service receiving the request.

The NIST AI Risk Management Framework adds a useful operating structure through its Govern, Map, Measure, and Manage functions. NIST describes the framework's first release as voluntary and use-case agnostic.

Part 748 remains the sector-specific anchor.

The use-case register has to follow the member information

Start with work, rather than brands. A credit union may use language models for policy research, contact-center summaries, collections correspondence, fraud-investigation notes, loan document review, or software development. Those activities carry different data and review obligations even when they reach the same provider.

For each use case, record the accountable executive and process owner. Add the member-information classes and approved input sources. Record the model and endpoint, along with the contractual account and retention configuration. Name the human reviewer responsible for the result. The entry should also state which outputs may influence member communications or operational decisions. A change in connector, model version, retrieval source, or downstream write permission triggers a fresh review. This gives the board a useful inventory. A spreadsheet row labeled Copilot says little about exposure.

A row labeled collections letter drafting, tied to account-history fields and a named API route, gives risk and internal audit something testable. AI model inventory management covers the route-level fields. NIST's Map function helps document context; the credit union still needs to connect that context to its member-information program.

Member-data policy belongs on the request path

The control decision happens when an authenticated employee or agent asks an application to call a model. The application should pass the originating identity and business context with the outbound HTTP request. The policy point can then evaluate the user's role and prompt classification against the use case and destination before forwarding the call.

Consider a contact-center assistant. A representative may summarize the current call through an approved endpoint. Full account credentials and authentication secrets trigger a block, as do another member's records. A lending workflow may permit extraction of fields for a reviewer and route a draft recommendation for human approval. The member-data rule stays attached to the request instead of relying on a training slide remembered at a busy desk.

The post-authentication gap matters here.

IAM establishes who entered the application. It also governs employment status and group membership. Session assurance remains part of that control. Request-layer authorization answers a narrower question: may this identity send this content to this model for this declared purpose now? AI policy enforcement at the HTTP layer explains that decision point.

Service-provider review needs route evidence

Appendix A to Part 748 directs credit unions to exercise due diligence in selecting service providers and require appropriate measures by contract. Credit unions must also monitor providers where indicated by the risk assessment. Apply that work to the exact AI service, rather than the vendor's corporate name alone.

Procurement should capture the contracted service tier, permitted processing, retention and training terms, subprocessors, region, incident notice, deletion process, and change-notification route. Security should verify the endpoint configured in production. The business owner should prove that the approved purpose matches actual use. A contract for one enterprise API provides little assurance when staff send the same data through personal browser accounts. Embedded AI deserves its own line in the register. A core banking, lending, contact-center, or document platform may call a model through a vendor-managed route that the credit union cannot redirect.

Ask the vendor for request-level identity fields and data handling. Also request an endpoint inventory and exportable activity evidence. Place compensating controls around permissions and source access.

The credit union's HTTP gateway governs only traffic routed through it.

Board reporting should show operation and exceptions

A quarterly AI slide should connect policy to events. Show approved use cases and material changes. Report blocked member-data transmissions by rule and business process. Include unresolved vendor evidence gaps and overdue reviews. Include a small sample of allowed requests with reviewer disposition. Avoid placing raw member information in the board packet; provide references to controlled evidence instead.

I prefer a one-page exception record over a green risk score. It should identify the employee or agent and the attempted model route. It should also show the detected information class and policy version. Record the outcome and the owner who closed the issue. A screenshot of a red block banner is useful visual evidence, but the underlying signed record carries the audit value.

Internal audit can sample those records against the use-case register and provider list.

The test asks if the policy operated for a real request and if an exception reached the assigned owner. The AI governance audit framework separates written control design from operating evidence. Board reporting then follows the same logic NCUA uses for the wider information-security program.

Controls around the gateway remain assigned

A credible program names adjacent owners. IAM teams manage user lifecycle and authentication strength. They also manage privileged groups and service identities. Endpoint controls govern browser access, unmanaged devices, clipboard paths, and local software. Vendor management handles contracts and subprocessor review. Model owners test output quality and member impact. They then check how behavior changes after an update. Legal and compliance interpret lending and privacy duties for each use case. They also cover records and consumer-protection duties.

The HTTP policy point covers customer-controlled LLM calls that pass through it. Native features inside vendor SaaS can bypass that point. Direct consumer websites may need secure web gateway or endpoint restrictions.

A model running locally avoids external transmission while retaining access and review requirements. Audit requirements also remain. Human approval stays with the credit union, especially where output informs a member-facing decision.

That division should appear in the architecture diagram. Draw the authenticated application and identity source, then the policy point. Add approved model endpoints and the evidence store, followed by the reviewer queue. Put dashed boxes around vendor-managed inference and local execution. The diagram then tells an examiner which requests carry independent decision records and where other evidence must come from.

DeepInspect

DeepInspect can support the routed request-control layer in a credit union's AI program. It sits inline as a stateless proxy between authenticated users or agents and HTTP-based LLM endpoints. The calling application supplies identity and use-case context.

DeepInspect evaluates that context with prompt classification and model destination. It also applies role and versioned policy before an allowed request reaches the endpoint. Each routed decision produces a signed, tamper-evident record that can feed exception review and internal-audit sampling.

DeepInspect leaves account lifecycle with IAM and direct browser restrictions with endpoint and web controls. It leaves vendor-managed embedded AI with the provider review. Member-facing output approval stays with the credit union. Book a technical deep dive at deepinspect.ai.