How to Verify an AI Control Plane Vendor Never Receives Bank Customer Data

Define the claim before you test it

"The vendor never receives customer data" is too loose to test. Write it as a set of statements that a network engineer and an examiner would both read the same way.

Start with the data. Name the categories in scope: nonpublic personal information, account data, other personally identifiable information, and anything derived from them, such as embeddings, summaries or prompt fragments. Then name the boundary. In most cases it is your cloud account or virtual network, and the claim is that none of these categories, in any form, cross it toward the vendor or any service the vendor operates or calls.

Then cover every channel, not just prompts and responses. Customer data can travel in telemetry, error reports, crash dumps, license checks, update requests, support sessions and metadata fields such as user identifiers or free-text tags. A claim that covers only "model traffic" leaves most of these open.

Finally, write the claim into the contract. Third-party risk due diligence for community banks includes asking whether the contract specifies limits on the third party's use and retention of data, including customer data. The FTC has also said that companies must abide by their privacy commitments to customers however and wherever those commitments were made, including terms of service and promotional material. A written commitment gives you something to hold the vendor to. It does not replace testing.

Deployment model decides what you can verify yourself

The architecture determines whether verification is an inspection you perform or a report you receive. Where a vendor can supply only outputs or limited monitoring data, the bank's independent visibility is limited, and that gap has been recognized in discussions of vendor model risk. Self-managed deployment in your own cloud makes the claim testable because the traffic, the configuration and the logs sit in an environment you control.

• Traffic inspection: Self-managed: you can capture and inspect traffic in your own network. Vendor-hosted: customer data reaches the vendor by design, so you rely on its controls and reports.
• Egress control: Self-managed: you set the allow-list and block everything else. Vendor-hosted: the destination is the vendor, so egress control cannot show separation.
• Evidence custody: Self-managed: enforcement records are written to storage you own. Vendor-hosted: evidence is typically produced and held by the vendor.
• Retention and residency: Self-managed: you set region and retention in your own accounts. Vendor-hosted: you depend on the vendor's settings and attestations.
• Fourth parties: Self-managed: outbound calls from the software are visible and blockable. Vendor-hosted: downstream services are largely opaque to you.

Why redaction position matters

Egress controls show that nothing unexpected leaves. Redaction shows that what is permitted to leave contains no customer data. The two answer different questions, and the second only holds if the control sits where the data moves.

A review that happens after the fact, such as sampling logs weeks later, can find a leak but cannot stop one. Policy enforced in the execution path acts on each interaction or tool call before it completes: allow it, redact specific values, or block it. That makes the boundary a property of the running system rather than a periodic finding.

Encryption is a related but separate point. Encrypting customer information in transit over external networks is a named safeguard in the FTC Safeguards Rule, 16 CFR 314.3, along with access limited to authorized users and a risk assessment, where the rule applies to your institution. Encrypted traffic to a vendor is still traffic to a vendor. Encryption protects data in transit; only egress and redaction evidence shows that the data never went.

Examiner, third-party risk and model risk framing

Three review audiences will ask for related but different things, and one body of evidence can serve all of them.

Third-party risk teams work from the interagency third-party risk management guidance issued in June 2023, which, as of November 2026, is the reference point for questions on contract limits on a third party's use and retention of customer data. Your test results and contract language answer that directly.

Model risk teams apply due diligence, validation, ongoing monitoring and contingency planning to vendor models much as they do to in-house models. Where a vendor offers limited monitoring data or little visibility into its own components, record that as a model risk issue rather than an accepted gap.

Examiners and internal audit want proof that is current, not a snapshot. NIST's draft SP 800-239 argues that point-in-time auditing is insufficient for AI and calls for automated, real-time logging at every data touchpoint, with the ability to report on data residency, processing logs and administrative access. Because it is a draft, treat it as direction rather than a requirement. It still supports a practical rule: schedule the tests, and retain continuous records alongside them.

Where runtime enforcement fits

Trussed is the control, provenance and evidence infrastructure for consequential AI, built for regulated enterprises that must show what their AI was allowed to do and what it did. It supports self-managed deployment in the customer cloud, enforces policy in the execution path with allow, redact and block decisions, offers configurable retention and data residency, and produces audit-ready evidence from enforcement, mapped to frameworks including NYDFS and NIST. These map to the deployment, redaction, retention and evidence steps above.

Trussed has operated for more than 18 months in continuous production in a regulated enterprise, and insurance, a regulated financial sector, is where it is deepest. The same tests apply to it as to any vendor. Run them, keep the results, and let the evidence settle the question.