A talk by Al Chen of Cisco on deploying AI software inside five major banks by navigating their security and compliance review processes without a year-long delay. Topics include the build pipeline, CVE remediation with agents writing and testing exploits, backup and restore verification, PII leakage through LLM judges, and the costs of zero leakage and data sovereignty. # Video Identity Observations ## Source **Title:** *Shipping AI Into 5 Major Banks Without a 12-Month Compliance Wait — Al Chen, Cisco* ## Intended Audience The speaker explicitly addresses a **technical practitioner audience**, not bank executives or end customers: > "one call out for any of the uh architects who are creating this kind of backup and restore within your cluster…" > "I challenge all of you to look at the system prompts for your LLM's judges and check the traces…" The closing frames the audience as builders exploring agent tooling: > "all of you're, you know, exploring different agent frameworks and building with, you know, new harnesses, playing with Jev." The setting is a **conference** ("conferences like this are kind of like that lunch table"), suggesting an AI-engineering event audience rather than a general public channel. ## Claimed Scope - **Self-description of role/team:** "In my team, we're on the front lines of deploying not only our software, but also engineering processes into the largest banks in the world." - **Claimed expertise domain:** Production AI deployment at regulated financial institutions — "playing agents AI within banks takes a long long time… I'm not talking about prototypes in dev or staging." - **Stated talk thesis:** "the theme for today is showing your work. That is the real lever that you have on compliance velocity when working with a bank." - **Offered engagement:** "if you all want to score your own deployments against um these pillars, just just reach out. I only discussed three pillars today, but… there's a whole production checklist." ## Observable Presentation Patterns (demonstrated, not claimed) - **Vendor positioning with differentiation:** acknowledges competitors and explicitly frames trust-building as evidence-based — "we're not just saying trust us, here's the evidence and the work." - **Named technical stack specificity:** ClickHouse, Sysdig, Wiz, Prisma, Redis, Postgres, Altinity, harbor/modal/Daytona sandboxes — indicating deep practitioner-level content rather than surface-level marketing. - **Narrative framing device:** the "Mr. Huff" 10th-grade math teacher anecdote opens and closes the talk, reinforcing the "show your work / fourth decimal place" motif. - **Humility about the human element:** "these signals that push the timeline out are less technical and more about internal human and organizational challenges." ## Caveat This is a single conference talk; the "channel identity" evidence here reflects the speaker's professional presentation at an event, not necessarily a personal content channel's typical output. No metadata beyond the title was supplied. # Delivery Observation — Al Chen, "Shipping AI Into 5 Major Banks Without a 12-Month Compliance Wait" ## Overall Communication Style The delivery is a **narrative-framed technical talk**: a personal anecdote opens and closes the presentation, and the middle is organized around an explicitly numbered structure ("three pillars"). The speaker combines storytelling with dense, implementation-level detail. ## Recurring Linguistic Patterns ### 1. "Showing your work" as a unifying motif The central phrase of the talk, introduced via the opening story and restated as the theme: > "So, the theme for today is showing your work. That is the real lever that you have on compliance velocity when working with a bank." It recurs in near-identical phrasing across sections: > "We have to show the evidence and the work on how we arrived at the at the answer." > "Getting your answers down to the fourth decimal place matters in these situations." ### 2. "It says nothing about…" / "not just… but actually" A repeated rhetorical move contrasting surface-level checks with deeper verification: > "But, it says absolutely nothing about whether or not that exploit is actually still in your application code." > "But this status says nothing about your data at this point in time." > "It's about data correctness, and not necessarily just checking a box and seeing if the backup and restore job ran." ### 3. Direct audience challenge A single but memorable device: > "I challenge all of you to look at the system prompts for your LLM's judges and check the traces…" ### 4. Casual hedged openers Frequent use of "you know," "I would say," "kind of like," and "um/uh" throughout — e.g., "And I would say that you don't want to just be another vendor," "it's kind of like Mr. Huff." ## Teaching Habits - **Bookended personal anecdote**: The 10th-grade math teacher ("Mr. Huff") opens the talk and returns explicitly at the end ("Going back to my 10th grade math test… conferences like this are kind of like that uh lunch table"). - **Explicit signposting**: "I'm going to walk through three pillars today. Number one is…", "the second pillar, disaster recovery…", "the final pillar…" - **Rhetorical questions as transitions**: "Anyone happen to know what database platform I'm talking about?"; "And so, how do you actually test for that?" - **Concrete naming of tools/vendors**: Sysdig, Wiz, Prisma, ClickHouse, Redis, Postgres, Altinity, Modal, Daytona — grounding abstractions in specific products. - **Spoiler framing**: "Uh spoiler alert, it doesn't work." used to set up the standard SaaS deployment section. - **Parallel callback structure**: "Similar to the CVs, you can't just bump the version and assume the exploit's gone." ## Vocabulary Register - Heavy domain-specific vocabulary: **CVE, egress, air-gapped, VPC, failover, data residency, MNPI, PII, transient dependencies, compliance velocity**. - Repeated key terms across sections: *evidence*, *remediate/remediation*, *leak/leakage*, *pillar*, *compliance velocity*. - Conversational connectors soften technical density: "hold wait, hold on," "worth their salt," "up to themselves." ## Speech Flow Characteristics - **Self-corrections and restarts are frequent**: "the the bank's VPC," "the the slow, the boring…", "the for this record," "not having a not having a story." - **Sentence-level repetition for emphasis**: "I'm not talking about prototypes in dev or staging… I'm talking about the applications that these banks millions of customers use every single day." - Endings of sections often land on a stated "takeaway": "The takeaway here is…", "And the takeaway here is…" ## Confidence Notes - The bookended anecdote, three-pillar structure, and "showing your work" motif are strongly supported by multiple occurrences. - The "it says nothing about…" pattern appears three times — likely stable, but the count is modest. - Filler density ("uh/um/you know") is high throughout, but this is a single transcript from one talk; whether it is habitual for this speaker outside this setting cannot be determined from this evidence. # Video Observation Record: Shipping AI Into 5 Major Banks Without a 12-Month Compliance Wait — Al Chen, Cisco ## Speaker Identification - **Speaker:** Al Chen, identified only via the video's curated title metadata (Cisco). No explicit self-introduction appears in the transcript; the transcript evidence establishes he works on a team "deploying not only our software, but also engineering processes into the largest banks in the world," in an AI observability context. ## Framing Narrative Chen opens with a 10th-grade math teacher anecdote (**Mr. Huff**) requiring answers to the fourth decimal place, where "most of the credit for the question was actually from the proof that you wrote." He maps this to compliance and risk teams: > "they're kind of like Mr. Huff, but with a multi-million dollar compliance budget." He closes by returning to this metaphor, framing the talk's theme as **"showing your work"** — providing evidence for claims rather than asserting trust. ## Scope Claim - The talk concerns **production** deployments at banks, not prototypes, dev/staging environments, or internal RAG agents. - Claimed outcome: reducing **time to production from a year down to a couple weeks** (stated as their team's practice, presented as achievable, not as a universal guarantee). ## Three Pillars of On-Prem AI Deployment at Air-Gapped Banks Chen contrasts standard SaaS AI ("spoiler alert, it doesn't work" — outbound egress risk) with on-prem deployment and identifies three pillars: **(1) build pipeline, (2) disaster recovery/data resiliency, (3) prevention of sensitive information leakage.** ### Pillar 1: Build Pipeline and CVE Management **Claim:** Compliance velocity and CVEs "go hand in hand"; every credible platform needs a plan. **Stated complications:** - Multiple images, each with multiple CVEs; remediation needed across **multiple banks**, not one. - Banks run **different versions** of images, each with unique CVEs. - Banks use **different scanning tools** (he names **Sysdig, Wiz, Prisma**) with different policies on severity levels and remediation SLAs. - Open-source **transient dependencies** contain CVEs his engineering team cannot remediate, requiring detailed written explanations to bank security teams. - Conflicting bank requirements: one bank demands version 3.8 of a package; another insists that version has too many CVEs and wants an older one — while the software still must function. **Solution described:** A script that performs research and reporting, outputting a table of what to fix and explanations for what cannot be fixed. **Key critique of scanning tools:** > "they just check to see if the package has been bumped to a specific version. But, it says absolutely nothing about whether or not that exploit is actually still in your application code." **Agent-based verification:** He describes a "harbor task" — a harness giving an agent instructions, a Docker-image environment, and tests. The instruction: version 2.6.2 supposedly remediates a CVE; the agent must write an exploit against the older version, test whether the exploit still succeeds on the new version, and run trials in parallel (Harbor, Modal, or Daytona sandboxes). > "it's not enough just to say we bumped the package version up to a specific number. We have to provide the evidence to show that the exploit is no longer actually in the application code." ### Pillar 2: Disaster Recovery **Claim:** DR "is not like optional infra hygiene for a bank." **Stated complication:** The main database used by most AI observability tools — which he identifies as **ClickHouse** (after a rhetorical guessing game) — has **no managed failover across regions or data replication**, which he says ClickHouse's own resiliency docs acknowledge. Redis and Postgres, by contrast, have managed cross-region failover. **Pattern described:** ClickHouse in a primary region → backup job to a bucket → restore job to a DR region with replica pods, relying on **ClickHouse backup**, an open-source project maintained by **Altinity**, whom he notes is "a competitor to ClickHouse" in managed failover. **Key qualification:** The backup/restore status table "says nothing about your data at this point in time" — bad disks, bad nodes, bad migrations, and replication lag can make data stale. Recommended extra checks: row-count comparison between tables and replica-convergence checks. > "it's about data correctness, and not necessarily just checking a box... Similar to the CVEs, you can't just bump the version and assume the exploit's gone." **Data residency callout:** Architects implementing backup/restore are "making a decision around data residency, whether you like it or not." A possible pattern: replicate only IDs and metadata across regions while core trace data stays in one region due to jurisdiction laws. ### Pillar 3: Preventing Sensitive Information Leakage **Claim:** Banks may believe they leak nothing, but "there may be side doors that are open" via unredacted **PII/MNPI**. **LLM-as-judge risk:** He issues a challenge to the audience to inspect their judges' system prompts and traces. A seemingly innocuous prompt line — asking the judge to include explanation so a human reviewer can verify — "potentially may have allowed the judge to leak and unredact PII or MNPI." The UI looks clean, but the judge's persisted reasoning may contain unredacted data. **Strategies described (with tradeoffs):** 1. Judge reads raw traces but **reasoning is not persisted**; only the score persists (needed for evals). 2. An application-code check determines whether a record contains sensitive information — if clean, score + reasoning persist; if not, reasoning is suppressed from the UI. 3. He notes most banks they work with **want to see** the judge's reasoning on sensitive records, so an upgrade: a **second LLM-as-judge** operating on redacted input, whose (presumably clean) output can be shown. **Explicit cost acknowledgment:** > "having zero leakage and data sovereignty is not free. In this case, it's the cost of running another LLM call on the same request." ## Time-to-Production Signals Chen's stated factors that shorten or lengthen deployment timelines: - **Shorter:** established image-pull processes; GPUs sourced and ready for inference. - **Pushed out a couple of months:** formal security reviews; custom LLM gateway; RBAC configuration. - **Pushed out further:** no approval process for pulling images into the registry; no GPU procurement story. His stated observation: > "most of these signals that push the timeline out are less technical and more about internal human and organizational challenges and alignments at the banks." ## Customer-Relationship Position - When a customer reports problems, "those problems now become my team's problems," broken into engineering, workflow, and human/organizational work streams. - Trust-building claim: "we're not just saying trust us... We have to show the evidence and the work." - Critique of other vendors: many claim a few-weeks deployment time "but what they're not saying is they didn't check that time against your infrastructure, your security posture, and the nuances about your specific cluster." - Stated aspiration: "you don't want to just be another vendor, you want to actually be solving your customers' problems." - Competitive framing: he wants to ensure competitors "don't outwork us and don't outsmart us" on those vectors. - Closing offer: audience members can reach out to score deployments against the pillars; he notes he only covered three pillars and there is a fuller "production checklist." ## Overarching Thesis > "showing your work. That is the real lever that you have on compliance velocity when working with a bank." ## Qualifications and Tensions to Preserve - The "couple weeks" timeline is presented as something his team achieves with customers, contingent on organizational readiness signals — not a guarantee for all banks. - He explicitly frames banks' old software as rational given the stakes ("There's a reason why a lot of the software within these banks is old and outdated") while also describing the "line between legacy software and... innovation" as moving daily. - He acknowledges limits of his team's control: transient dependencies they cannot remediate; DR largely left to banks given ClickHouse's lack of managed failover; and that the hardest blockers are organizational, not technical. - The talk is delivered at a conference where he notes some sponsoring companies use the database he critiques — he names ClickHouse and its limitation directly despite this context. # Speaker & Provenance Record — "Shipping AI Into 5 Major Banks Without a 12-Month Compliance Wait — Al Chen, Cisco" ## Speakers & Roles - **Al Chen (Cisco)** — **Sole speaker / conference presenter**. Delivers the entire talk as a first-person narrative about his team's work deploying AI observability software into major banks. Identity and role are established by the video title ("Al Chen, Cisco") and corroborated in the transcript ("In my team, we're on the front lines of deploying... into the largest banks in the world"). - **Audience** — Present but non-speaking; `[applause]` transcript marker and direct address ("I challenge all of you...") indicate a **conference talk setting**. - **No interviewer, moderator, or guest speakers** appear in this transcript. > Setting: Conference/developer talk (references to "this conference," "conferences like this are kind of like that lunch table"). ## Referenced Sources & Third Parties - **Referenced tools/projects/companies (explicit in transcript):** - CVE databases: **NVD, CISA, MITRE** - Scanning tools: **Sysdig, Wiz, Prisma** - **ClickHouse** — cited as lacking managed cross-region failover (speaker attributes this to ClickHouse's own data resiliency docs) - **ClickHouse backup** — open-source project maintained by **Altinity**, described as "a competitor to ClickHouse" - **Redis, Postgres** — cited as having managed cross-region failover - Agent/harness tooling: **Harbor**, **Modal**, **Daytona** sandboxes - **Third-party claims (attributed to speaker, not independently verified):** - Some "companies sponsoring this conference" use the same database platform lacking managed failover. - ClickHouse docs call out no managed cross-region failover. - LLM-as-judge system prompts may un-redact PII/MNPI via persisted reasoning. ## Promotional Elements — FLAGGED - **Self-promotional segment:** Closing call to action — *"if you all want to score your own deployments against these pillars, just reach out"* — references a **production checklist** the speaker's team uses, not shared publicly in the talk. - **Employer promotion:** The talk promotes the speaker's company's deployment practices and customer relationships ("we're not just saying trust us... we have to show the evidence"). - **Acknowledged sponsorship context:** References to "companies that are sponsoring this conference" indicate an industry-sponsored event. ## Availability & Access Limits - **Slides/visuals not provided:** Talk references diagrams (egress flow, backup/restore table, judge system prompt examples) that are described but not present in transcript. - **Production checklist not shared** — mentioned as available via direct outreach only. - **No comments section or external links** available in the source material. - **No curated metadata supplied** beyond the title; speaker identity rests on the title's attribution. ## Uncertainty Notes - Speaker's exact job title at Cisco is not stated in the transcript; only team affiliation ("my team") and employer (Cisco, per title). - "Five major banks" figure appears only in the title, not explicitly quantified in the transcript (speaker says "largest banks in the world" and "multiple banks"). \>\> Uh when I was in the 10th grade, I had a math teacher, Mr. Huff, who was uh notoriously brutal on our math tests. He would uh make us write our answers down to the uh fourth decimal place in case you happen to get to the answer by luck or by chance. And most of the credit for the question was actually from the proof that you wrote to show how you got to the answer. And when I first started playing AI observability software, uh I realized that most of these compliance and risk teams that I work with every day, they're kind of like Mr. Huff, but with a a multi-million dollar compliance budget. And I would let you know that playing agents AI within banks takes a long long time. And the reason is because that keyword production. I'm not talking about prototypes in dev or staging or even like internal rag agents to increase, you know, internal employee productivity. I'm talking about the applications that these banks millions of customers use every single day. The same ones you use when you log into your bank's website or mobile app. And those are the use cases that matter. In my team, we're on the front lines of deploying not only our software, but also engineering processes into the largest banks in the world. And I want to share some of the issues that our customers bring to us and the strategies we use to help reduce the time to production from a year down to a couple weeks. So, let's take first take a look to see how standard SaaS AI gets deployed at a bank. Uh spoiler alert, it doesn't work. There's outbound egress to the internet and sensitive information can potentially be leaked out. Within when you deploy on prem AI at an air-gapped bank, the flow is a little more complicated. I'm going to walk through three pillars today. Number one is the actual build pipeline. How our banks pull images from our software into their cluster. If a region fails mid-request, what is the data resiliency plan? And then finally, one of the most important parts is how do you ensure no sensitive information leaks out to internal bank employees and outside of the the bank's VPC. Compliance velocity uh and CVEs go hand in hand. And no platform worth their salt does not have a plan for how they address this first compliance hurdle, which is common vulnerabilities and exposures. I'm going to walk you through why this process is complicated. So, number one, you can take one CVE and you can research on the NVD, CISA, or MITRE websites. But, in reality, our platform, most platforms, you have multiple images and each image has multiple CVEs. And I'm not trying to remediate CVEs for one bank, but rather for multiple banks. So, we have to create a system and process around this. And the complication there is that our banks are on different versions of our images, each with their own unique CVEs. On top of that, banks utilize different scanning tools, which output a report on what CVEs are present. Furthermore, they have specific policies around what are the actual CVEs in the images, what the severity level is, and then what the SLA is for time to remediation. Our images rely on many open-source projects and those projects contain many transient dependencies which have CVEs that our engineering team cannot remediate. So, our team is we're constantly looking into the release notes for a lot of these open-source projects cuz we have to provide a detailed explanation back to the security teams at these banks on why we cannot remediate and why we're dependent on these open-source project maintainers. So, once you've identified the CVEs that your team your engineering team can actually remediate there's multiple ways of remediation. You can bump the package version up to a higher version or rebuild your image against the base Docker image. But, then we also have this complication of certain banks saying we want to be on version 3.8 of the package. But, another bank might say hold wait, hold on. That version is too too high. There's too many CVEs. I want to be on an older version of that package. So, given all of this your software still has to work and function. And so, one solution that you can use is creating a scale. So, we have a scale that does a lot of the heavy heavy lifting and reporting and the internal research as well. And the output is a nice kind of table format that has tells our engineering team what CVEs we have to fix and also provides explanations back to our security teams from the bank on what can we cannot fix due to these transient dependencies. Most of these scanning tools Sysdig, Wiz, Prisma they just check to see if the package has been bumped to a specific version. But, it says absolutely nothing about whether or not that exploit is actually still in your application code. And so, how do you actually test for that? So, one solution is creating a harbor task and this is kind of like creating a harness or a world for your for an agent to try things out. And so within this harbor task you have instructions for the agent, you have an environment which contains the actual docker images for your application, and then tests that you can run against the agent to see if they passed. The instruction here is a CVE for uh this service, this package. And the instruction I tell the agent is 2.6.2 of this package supposedly remediates the CVE. I want you to go and write an exploit based on the older version to see if this new version still has that exploit. Then write a test to see if that exploit actually passed or not. And then with harbor you can run a bunch of docker containers or um harbor uh modal or Daytona sandboxes, run these all in parallel, and you have a bunch of trials to see how the agent performed over various trials. And the What I'm trying to say here is that it's not enough just to say we bumped the package version up to a specific number. We have to provide the evidence to show that the exploit is no longer actually in the application code. Uh the second pillar, disaster recovery, is not like optional infra hygiene for a bank. The complication here is that the main database platform most AI observability tools use, including some of the companies that are sponsoring this conference, there's no managed service for failover across regions and data replication. Anyone happen to know what database platform I'm talking about? It isn't this So, with Redis, Postgres, there's managed failover across regions, but this one database does not have that story. ClickHouse is an amazing database platform, but even in their data resiliency docs they call out that there's no managed service managed failover across regions. So this means the banks are kind of up to themselves to to figure out that disaster recovery situation. So a simple pattern that you can employ is you have ClickHouse in a primary region, a job that backs up to a bucket, and then another job that restores that bucket to a DR region. Within that region, you might have multiple pods that have replicas of that data. This whole procedure relies on ClickHouse backup, which is an open-source project maintained by Altinity, who they themselves are a competitor to ClickHouse in terms of managing this data failover across regions. It's uh so with this procedure, they ClickHouse backup shares logs on whether or not the backup and restore happens, so you can get this nice table. But this status says nothing about your data at this point in time. A bad disk, a bad node, um bad migration, replication lag, these are all issues that can cause your data to become stale, that is different from when this job actually ran. So you can go the extra step in checking the row counts between tables, uh running a check to see if the replicas within a region have converged to each other. And the takeaway here is that it's about data correctness, and not necessarily just checking a box and seeing if the backup and restore job ran. Similar to the CVs, you can't just bump the version and assume the exploit's gone. You have to do these extra checks. And uh one call out for any of the uh architects who are creating this kind of backup and restore within your cluster is that you're also making a decision around data residency, whether you like it or not. When you're replicating to a bucket, the bucket doesn't care if it's in Oregon or Virginia. Data residency, however, cares about where those individual records are stored. So, one solution is you can replicate just the IDs and the metadata around your traces and your data into different regions. But, then the actual core trace data, that's stored within one region and doesn't leave that region because of certain jurisdiction laws. Uh the final pillar is most banks think that they are not leaking any sensitive information to their internal employees, their users outside of their VPC, but there may be side doors that are open. And this comes in the form of PII MNPI being redacted. And there's many different strategies for this. You can redact information at the SDK level, at the gateway level, using various middleware. And what this looks like in practice is on the UI, you might have some customer information, sensitive information is redacted. But, what about the judges that you're using? I challenge all of you to look at the system prompts for your LLM's judges and check the traces to see if those traces with the reasoning from those judges contain any PII or MNPI. Here's a system prompt for a simple judge. It outputs a score and explanation on how well the agent performed for a given task. But, there's one line here in the prompt, which is seemingly innocuous because you want the human reviewer to be able to verify if the agent did a good job and was accurate. This just potentially may have allowed the judge to leak and unredact PII or MNPI. So, your UI still looks good, but then on the back-end your LLM as LLM as judges reasoning may un-redact customer information and sensitive information. So, one strategy for this is you can still have your judge read the raw trace data, but the reasoning for that judge is not persisted. The score, however, you want that score it's for good good for evals, that always persists through the UI, but then on this other branch the reasoning, as we saw, can still leak PII. But in your application code, you can have a check that tells the agent this record does not contain sensitive information and therefore can persist to the UI. So, now you have a score plus the reasoning for the for this record. And then if that check comes back negative, it does have sensitive information, then you just suppress that reasoning from the UI. Most of the banks we work with, they want to see the LLM as judges reasoning on this sensitive information. And the extra upgrade you can add to this flow is you have a second LLM as a judge where the input has is redacted of sensitive information and therefore you can have confidence that the output from the judge is clean and then you can have that show up in the UI. The uh takeaway here is that having zero leakage and data sovereignty is not free. In this case, it's the cost of running another LLM call on the same request. So, one way we're able to build trust with these security and compliance teams is that we're not just saying trust us, here's the answer. We have to show the evidence and the work on how we arrived at the at the answer. And many vendors will tell you, you know, we're our deployment time to production takes a few weeks, but what they're not saying is they didn't check that time against your infrastructure, your security posture, and the nuances about your specific cluster. And so certain signals that we look for in terms of shortening that time to production is really just having a lot of processes set up in terms of, you know, how you pull images down from an from a registry, having GPUs sourced and ready to go for running inference. That timeline gets pushed out a couple months when you have formal security reviews, or you're building a custom LM gateway or RBA configuration. And then that timeline gets pushed even further out when you don't even have an approval process for pulling images down to your your registry, and not having a not having a story around sourcing and procuring GPUs. Now, I found that most of these signals that push the timeline out are less technical and more about internal human and organizational challenges and alignments at the banks. Uh but still important factors to figure out. So, the theme for today is showing your work. That is the real lever that you have on compliance velocity when working with a bank. And when our banks, when one of our customers come to us and tell us, "Hey, our customers are having problems." Those problems now become my team's problems. And we break those problems down into uh engineering, workflow, and human and organizational work streams. The goal is to automate as much as possible, but those problems are the ones that keep me up at night. And I want to ensure that our competitors don't outwork us and don't outsmart us on any of those vectors. And I would say that you don't want to just be another vendor, you want to actually be solving your customers' problems. And I would say the biggest lesson I've learned from working with these banks and security teams is that there's so much at stake. Checking accounts, mortgages, credit cards. Getting your answers down to the fourth decimal place matters in these situations. And there's a reason why a lot of the software within these banks is old and outdated. But the the line between legacy software and old banking processes and innovation is moving a little bit every day and it's because of all of you. So I think all of you're, you know, exploring different agent frameworks and building with, you know, new harnesses, playing with Jev. And I would say for the few of you who care about the the slow, the boring, the bureaucratic, the methodical, the messy human and organizational challenges within a bank, there's nothing like deploying AI within the financial services sector because there's so much so much at stake. And yeah, if you all want to score your own deployments against um these pillars, just just reach out. I only discussed three pillars today, but um you know, there's a whole production checklist that we use to uh that underpins these pillars. Going back to my 10th grade math test, one of the best parts about those tests were afterwards we me and my friends we, you know, go to the lunch table and we'd try to scribble down all the problems we remembered from the test. And then we use that time to talk about, "Hey, here's how we approached solving this problem and that problem." And it allowed me to kind of think about different approaches and different ways to solving these problems. And conferences like this are kind of like that uh lunch table back from when I was in 10th grade because I want to learn from all of you on how you're solving your your problems for for your customers. Thank you very much. \>\> \[applause\]