Shipping AI Into 5 Major Banks Without a 12-Month Compliance Wait — Al Chen, Cisco

17:423 min readAI Engineer10/20/2026Computing/Software · Management · Internet Technology

Key Takeaway

Deploying AI applications into major banks requires moving beyond checkbox compliance by establishing automated verification harnesses, robust cross-region data replication pipelines, and strict LLM trace sanitization.

Highlights

  • Deploying production AI agents into major banks reduces compliance timelines from one year down to a couple of weeks through systematic engineering processes.

  • ClickHouse lacks a managed service for cross-region failover and data replication, requiring custom backup and restore pipelines via open-source tools like ClickHouse Backup.

  • Standard container scanning tools only check package version numbers rather than verifying whether security exploits remain active in application code.

  • Harbor tasks run parallel Docker and Daytona sandboxes to test whether specific package version upgrades actually neutralize known exploits in codebases.

  • LLM judges used for evaluating agent traces often output system prompt reasoning that inadvertently leaks unredacted personally identifiable information to user interfaces.

Timeline

  1. Compliance Velocity and Common Vulnerabilities

    Compliance teams operate with strict risk thresholds, evaluating software images against multiple scanning tools with unique vulnerability policies. Because open-source dependencies introduce unfixable security alerts, engineering teams must supply detailed explanations for unpatched items. Standard vulnerability scanners only detect version bumps rather than actual exploit removal, necessitating isolated agent testing environments that simulate exploits across multiple parallel container trials.

    • Banks maintain rigid policies and custom SLAs for managing common vulnerabilities and exposures across software image versions.
    • Open-source projects contain transient dependencies with security vulnerabilities that internal engineering teams cannot directly remediate.
    • Automated harbor tasks use parallel sandboxes to verify whether package updates actually remove code exploits.
  2. Disaster Recovery and Data Residency

    Financial infrastructure demands rigorous disaster recovery standards despite database platform limitations. Backup and restore jobs managed through open-source tools require secondary validation steps, such as cross-table row counts and replica convergence checks, to ensure data integrity. Furthermore, multi-region replication strategies must isolate core trace records within specific geographic jurisdictions to comply with local data residency laws.

    • ClickHouse requires manual implementation of disaster recovery workflows because it lacks native managed cross-region failover.
    • Data replication status checks do not guarantee data correctness against disk corruption, replication lag, or node failures.
    • Data residency regulations restrict raw trace data storage to single regions while allowing metadata and IDs to replicate.
  3. Sensitive Information Leakage Prevention

    While user interfaces successfully redact direct customer data, background LLM judges often expose sensitive information within their evaluation reasoning logs. Protecting against these side doors requires conditional persistence checks in application code to suppress unverified reasoning streams. Implementing a secondary evaluation pipeline with pre-redacted input guarantees that displayed judge outputs remain entirely free of private financial data.

    • LLM evaluation judges risk leaking sensitive customer information through unredacted system prompt reasoning displayed on user interfaces.
    • Application code checks can suppress judge reasoning outputs when records contain sensitive data.
    • Secondary evaluation judges processing pre-redacted inputs ensure clean, compliant outputs for user interface display.
  4. Organizational Alignment and Production Timelines

    Vendor deployment claims often underestimate the friction caused by internal bank bureaucracy, unapproved image registries, and GPU procurement hurdles. Overcoming these administrative delays depends on providing transparent evidence of security controls rather than abstract assertions. Ultimately, successful deployment bridges the gap between legacy financial infrastructure and modern AI capabilities through methodical engineering.

    • Formal security reviews and custom gateway configurations extend deployment timelines from weeks to several months.
    • Internal human and organizational challenges within financial institutions create the primary bottlenecks for AI adoption.
    • Demonstrating concrete evidence rather than relying on trust accelerates compliance approvals.

Description

Banks don't buy AI software until it survives their security and compliance review. Al Chen shares what it took to deploy inside five major banks without a year-long bottleneck. He covers the build pipeline, CVE remediation with agents writing and testing exploits, backup and restore verification, PII leaking through LLM judges, and why zero leakage and data sovereignty are never free. Chapters: - 00:00 Intro - 02:15 What banks check - 04:17 Fixing CVEs with agents - 08:30 Proving backup and restore - 10:33 PII leaking through LLM judges - 14:48 Making customer problems engineering problems - 16:56 Takeaways Al Chen — X: https://x.com/bigal123 | https://www.cisco.com Join us in SF for the second annual AIE CODE summit: https://aie.codes our last flagship summit of 2026. Applications live now!

Write about this video