LLM Governance for Credit Unions: Controlling Embedded Core Processor AI

Start with the control boundary

Core processors are adding LLM-powered features such as member service assistants, document summarization, fraud and dispute workflows, and developer tooling. The credit union licenses these platforms but does not build them, yet it remains accountable to its board and to NCUA examiners for member data handling, model risk, and third-party risk.

Third-party risk reviews and model risk practices were designed for static software and traditional models. They assess the vendor at a point in time. They do not show what a generative model did in a specific interaction. That gap is why the useful question is not whether the vendor is trustworthy in general, but which parts of each feature the credit union can govern directly.

NIST describes governance in the AI RMF as a cross-cutting function that is continual over an AI system's lifespan, not a one-time onboarding step. NIST describes the framework as voluntary, so present it to the board as a recognized framework the credit union has chosen to adopt. Sort every control into one of three groups and record the grouping explicitly.

• Enforced directly by the credit union: Controls applied to traffic the credit union routes: data access limits, redaction, blocking of disallowed actions, human approval, and the resulting decision records.
• Dependent on vendor commitments: Model hosting, model provider choice, training-data use, retention in the vendor environment, and change notification. These are handled through due diligence and contract terms.
• Evidenced only by vendor attestation: Anything the credit union cannot observe or independently record. Treat it as residual risk and tie it to audit rights and reporting obligations.

What due diligence and contracts must cover

Document the legal and regulatory requirements that apply to each AI use, consistent with AI RMF Govern 1.1, and have counsel confirm supervisory expectations before they go into policy. Then use the vendor relationship for everything the credit union cannot observe.

The questions to put to the core processor are practical. Where is each feature hosted, and which model provider is used? Are member data or prompts retained, or used for training? Can the credit union disable or scope each feature? What interaction-level records (prompts, outputs, policy decisions, redactions, human approvals) can the vendor provide, in what format, and for how long? How will the vendor notify you of model, provider or feature changes so they can be re-reviewed in your monitoring cycle?

Turn the answers into contract terms: audit and evidence rights, change notification, retention commitments, and a stated position on training use of member data. Where a feature is closed and vendor-hosted, these terms are the control. Record the residual risk and the compensating measures, such as disabling the feature for higher-risk workflows, and have the accountable owner approve them. Because the vendor's model or provider can change after onboarding, schedule re-review rather than relying on the initial assessment.

Define policy and enforce it at runtime where you can

Where the credit union routes model, agent or tool-call traffic, write policy per feature on two questions: what data may the model see, and what actions may it take? Each policy resolves to one of four outcomes. Allow the interaction. Redact specific member data before it reaches the model or before the output reaches the user. Block the request or tool call. Escalate to a human for approval before the action proceeds.

Keep the rules concrete. For example, account numbers may be redacted from document summarization inputs, while any tool call that modifies a dispute record requires human approval. Policy written this way can be tested and can be shown to an examiner, which a general statement that the model is used responsibly cannot.

The tradeoff is scope. Runtime enforcement only applies to traffic that passes through the enforcement point. It does not tell you how a vendor trains a model, where the vendor stores data internally, or what happens in a feature you cannot route. Treat runtime enforcement as a complement to due diligence and contracts, not a replacement for them.

Where Trussed fits, and where it does not

Trussed enforces policy in the execution path across models, agents, tools, MCP servers, AI sites and coding assistants. It applies allow, redact, block, rate limit, and escalate for human approval to individual interactions and tool calls. Enforcement happens at runtime, not reviewed after the fact, and that enforcement generates continuous audit-ready evidence, mapped to frameworks including NIST. It can be deployed self-managed in the customer cloud, with configurable retention and data residency, which supports keeping evidence under the credit union's control.

The limit is the traffic path. Trussed can enforce policy only where the credit union can route model, agent, or tool-call traffic through it. For a closed, vendor-hosted feature that the credit union cannot route, it cannot enforce policy or capture interaction-level evidence, and those risks stay with vendor commitments, contract terms, and attestation. Trussed does not provide transaction-level governance across tasks and agents, model lineage, or end-to-end tracing of agentic workflows.

Use the inventory to decide where this applies: developer tooling and any agent or tool-call traffic you control are the likelier candidates, while closed assistants inside the core platform depend on what the vendor commits to provide.