Levando IA à produção em 5 grandes bancos sem esperar 12 meses por compliance — Al Chen, Cisco

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Shipping AI Into 5 Major Banks Without a 12-Month Compliance Wait — Al Chen, Cisco · Canal: AI Engineer · 17:18 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Governança e regulação de IA, Infraestrutura e hardware de IA, Privacidade e proteção de dados

Resumo

Al Chen descreve os desafios para levar aplicações de IA à produção em bancos, onde segurança, compliance e resiliência exigem mais do que protótipos funcionais. Ele apresenta três pilares: gestão de vulnerabilidades com evidências de remediação, recuperação de desastres com verificações de integridade dos dados e prevenção de vazamentos de informações sensíveis. O caminho até a produção também depende de processos internos, como aprovação para obter imagens e disponibilidade de GPUs. A principal recomendação é mostrar o trabalho e as evidências para construir confiança com as equipes de segurança e compliance.

Pontos-chave

Aplicações voltadas aos clientes de bancos enfrentam exigências de produção muito diferentes das de protótipos ou ferramentas internas.
Gerenciar CVEs exige considerar diferentes versões de imagens, ferramentas de varredura, políticas e prazos de remediação de cada banco.
Atualizar a versão de um pacote não basta: é preciso testar se a vulnerabilidade realmente deixou de ser explorável na aplicação.
A recuperação de desastres deve verificar a correção e a atualidade dos dados, não apenas confirmar que os backups foram executados.
A replicação entre regiões envolve decisões sobre residência de dados e jurisdições.
Informações pessoais ou sensíveis podem aparecer no raciocínio dos LLM as a judge, mesmo quando estão ocultas na interface.
Uma estratégia para reduzir vazamentos é não persistir o raciocínio de certos juízes ou usar outro juiz com entradas redigidas.
Atrasos na implantação também decorrem de desafios organizacionais, como aprovações para imagens, GPUs e revisões de segurança.
Construir confiança com bancos exige apresentar evidências e resolver problemas dos clientes, em vez de apenas pedir que confiem no fornecedor.

Capítulos

Início	Capítulo	Resumo
00:01	Por que a produção em bancos exige evidências	Al Chen compara as exigências de compliance à correção rigorosa de uma prova e explica por que aplicações bancárias reais levam tempo para chegar à produção.
02:04	Gestão de CVEs e testes de remediação	A palestra aborda as diferenças entre bancos na gestão de vulnerabilidades e propõe testar se um exploit ainda funciona após a atualização.
06:46	Recuperação de desastres e integridade dos dados	Al Chen descreve um fluxo de backup e restauração entre regiões e destaca a necessidade de verificar os dados e respeitar sua residência.
09:53	Proteção de dados sensíveis nos juízes de LLM	O palestrante mostra como PII e MNPI podem aparecer no raciocínio dos juízes e apresenta opções para controlar o que é persistido ou exibido.
13:06	Confiança, processos internos e lições finais	A conclusão destaca que reduzir o tempo até a produção depende de evidências, infraestrutura preparada e alinhamento com os processos humanos das instituições.

Citações

Não basta dizer que atualizamos o pacote para uma versão específica. Temos que fornecer evidências de que o exploit realmente não está mais na aplicação. — 06:46

O importante é a correção dos dados, não apenas marcar uma caixa e confirmar que o backup e a restauração foram executados. — 08:51

A maioria dos fatores que prolongam o prazo é menos técnica e mais relacionada a desafios humanos e organizacionais internos. — 14:11

Mostrar o trabalho é a verdadeira alavanca para acelerar o compliance ao trabalhar com um banco. — 14:42

Conceitos e entidades

Al Chen (pessoa): Palestrante que compartilha práticas para implantar IA em bancos.
Cisco (empresa): Empresa associada a Al Chen no título da palestra.
ClickHouse (ferramenta): Plataforma de banco de dados citada no contexto de replicação e recuperação entre regiões.
Altinity (empresa): Empresa que mantém o projeto open source ClickHouse backup.
ClickHouse backup (ferramenta): Projeto open source mencionado para fazer backup e restauração de dados do ClickHouse.
Harbor (ferramenta): Ambiente citado para executar tarefas e testes de agentes em sandboxes e contêineres.
Sysdig (ferramenta): Ferramenta de varredura citada para identificar CVEs em imagens.
Wiz (ferramenta): Ferramenta de varredura citada para identificar CVEs em imagens.
Prisma (ferramenta): Ferramenta de varredura citada para identificar CVEs em imagens.
CVE (conceito): Identificador de uma vulnerabilidade de segurança conhecida que pode exigir avaliação e remediação.
data residency (conceito): Requisito relacionado ao local onde os dados e registros são armazenados.
PII (conceito): Informações de identificação pessoal que podem precisar ser ocultadas ou protegidas.
MNPI (conceito): Informações materiais não públicas, tratadas na palestra como dados sensíveis.
LLM as a judge (conceito): Uso de um LLM para avaliar o desempenho de um agente e produzir uma pontuação e uma explicação.

Tradução completa (pt-BR)

00:01 [música] >> Quando eu estava na 10ª série, tive um professor de matemática, o Sr. Huff, que era notoriamente rigoroso nas nossas provas de matemática. Ele nos fazia escrever as respostas até a quarta casa decimal, caso você chegasse à resposta por sorte ou acaso. E a maior parte da pontuação da questão

00:31 vinha, na verdade, da demonstração que você escrevia para mostrar como chegou à resposta. Quando comecei a trabalhar com software de observabilidade de IA, percebi que a maioria dessas equipes de compliance e risco com quem trabalho todos os dias é meio como o Sr. Huff, mas com um orçamento de compliance de vários milhões de dólares. E quero que saibam que implementar agentes de IA em bancos leva muito, muito tempo. E o motivo é

01:02 a produção, palavra-chave. Não estou falando de protótipos em desenvolvimento ou staging, nem mesmo de agentes RAG internos para aumentar a produtividade dos funcionários, sabe, internamente. Estou falando dos aplicativos que milhões de clientes desses bancos usam todos os dias. Os mesmos que você usa quando entra no site ou no aplicativo móvel do seu banco. E esses são os casos de uso que importam. Na minha equipe, estamos na linha de frente da implantação não só do nosso software, mas também de processos de engenharia nos

01:32 maiores bancos do mundo. E quero compartilhar alguns dos problemas que nossos clientes nos trazem e as estratégias que usamos para ajudar a reduzir o tempo até a produção de um ano para algumas semanas. Então, primeiro, vamos ver como o SaaS de IA padrão é implantado em um banco. Spoiler: não funciona. Há tráfego de saída para a internet, e informações confidenciais podem acabar vazando.

02:04 Quando você implanta IA on-premises em um banco isolado da internet, o fluxo é um pouco mais complicado. Hoje vou abordar três pilares. O primeiro é o pipeline de build propriamente dito: como os bancos puxam imagens do nosso software para o cluster deles. Se uma região falhar no meio de uma solicitação, qual é o plano de resiliência de dados? E, por fim, uma das partes mais importantes: como garantir que nenhuma informação confidencial vaze para

02:34 os funcionários internos do banco nem para fora da VPC do banco. A velocidade de compliance e as CVEs andam juntas. Nenhuma plataforma que se preze deixa de ter um plano para lidar com esse primeiro obstáculo de compliance: vulnerabilidades e exposições comuns. Vou explicar por que esse processo é complicado. Primeiro, você pode pegar uma CVE e pesquisar nos sites da NVD, da CISA ou do MITRE. Mas, na

03:06 realidade, na nossa plataforma, como na maioria das plataformas, há várias imagens, e cada imagem tem várias CVEs. E não estou tentando corrigir CVEs para apenas um banco, mas para vários bancos. Então, precisamos criar um sistema e um processo para isso. A complicação é que nossos bancos usam versões diferentes das nossas imagens, cada uma com seu próprio conjunto de CVEs. Além disso, os bancos usam ferramentas de varredura diferentes, que geram um relatório sobre quais CVEs estão presentes. E também têm políticas específicas

03:39 sobre quais CVEs estão realmente nas imagens, qual é o nível de gravidade e qual é o SLA para o prazo de correção. Nossas imagens dependem de muitos projetos open source, e esses projetos contêm muitas dependências transitivas com CVEs que nossa equipe de engenharia não consegue corrigir. Então, nossa equipe está sempre consultando as notas de versão de muitos desses projetos open source, porque precisamos dar uma explicação detalhada às equipes de segurança desses bancos

04:10 sobre por que não podemos corrigir as vulnerabilidades e por que dependemos dos mantenedores desses projetos open source. Depois de identificar as CVEs que sua equipe — a equipe de engenharia — consegue corrigir, há várias maneiras de fazer isso. Você pode atualizar a versão do pacote para uma mais recente ou reconstruir sua imagem com base na imagem Docker base. Mas também existe a complicação de alguns bancos dizerem: “Queremos usar a versão 3.8 do pacote.” Só que outro banco pode dizer: “Espera aí. Essa versão é alta demais. Tem

04:41 muitas CVEs. Quero usar uma versão mais antiga desse pacote.” Então, diante de tudo isso, seu software ainda precisa funcionar. Uma solução que você pode usar é criar uma skill. Temos uma skill que faz boa parte do trabalho pesado, incluindo a geração de relatórios e a pesquisa interna. O resultado é uma tabela organizada que informa à nossa equipe de engenharia quais CVEs precisamos corrigir e também

05:12 fornece explicações às equipes de segurança do banco sobre o que podemos ou não corrigir por causa dessas dependências transitivas. A maioria dessas ferramentas de varredura, como Sysdig, Wiz e Prisma, só verifica se o pacote foi atualizado para uma versão específica. Mas isso não diz absolutamente nada sobre se aquela exploração ainda está ou não no código da sua aplicação. E

05:42 então, como testar isso de fato? Uma solução é criar uma tarefa no Harbor. É algo parecido com criar um harness ou um ambiente para um agent experimentar. Nessa tarefa do Harbor, você tem instruções para o agent, um ambiente que contém as imagens Docker reais da sua aplicação e testes que pode executar com o agent para verificar se ele passou. A instrução aqui é sobre uma CVE desse serviço, desse pacote. E digo ao agent: a versão 2.6.2 desse

06:15 pacote supostamente corrige a CVE. Quero que você escreva uma exploração usando a versão antiga para verificar se essa nova versão ainda é vulnerável. Depois, escreva um teste para ver se a exploração funcionou ou não. Com o Harbor, você pode executar vários contêineres Docker ou sandboxes do Harbor, do Modal ou do Daytona, tudo em paralelo, e ter várias tentativas para ver como o agent se saiu em diferentes testes. E o que estou tentando dizer aqui é

06:46 que não basta dizer que atualizamos o pacote para uma versão específica. Precisamos apresentar evidências de que a exploração realmente não está mais no código da aplicação. O segundo pilar, recuperação de desastres, não é uma prática opcional de manutenção da infraestrutura para um banco. A complicação é que a principal plataforma de banco de dados usada por ferramentas de observabilidade de IA, inclusive por algumas das empresas que patrocinam esta conferência,

07:17 não tem um serviço gerenciado de failover entre regiões nem de replicação de dados. Alguém sabe de qual plataforma de banco de dados estou falando? Não é esta. Com Redis e Postgres, há failover gerenciado entre regiões, mas essa plataforma de banco de dados não oferece isso. ClickHouse é uma plataforma de banco de dados incrível, mas até na documentação sobre resiliência de dados eles destacam que não há um serviço gerenciado de failover entre regiões. Isso significa que os bancos ficam meio que por conta própria

07:48 para resolver essa situação de recuperação de desastres. Um padrão simples que você pode adotar é ter o ClickHouse em uma região primária, um job que faz backup para um bucket e, depois, outro job que restaura esse bucket em uma região de recuperação de desastres. Nessa região, você pode ter vários pods com réplicas desses dados. Todo esse procedimento depende do ClickHouse backup, um projeto open source mantido pela Altinity, que é concorrente do

08:21 ClickHouse justamente na gestão desse failover de dados entre regiões. Nesse procedimento, o ClickHouse backup compartilha logs que mostram se o backup e a restauração ocorreram, para que você possa obter uma tabela organizada. Mas esse status não diz nada sobre seus dados naquele momento. Um disco com problema, um nó com problema, uma migração com problema, atraso na replicação: todos esses problemas podem fazer seus dados

08:51 ficarem desatualizados, ou seja, diferentes de como estavam quando esse job foi executado. Então, você pode ir além e verificar as contagens de linhas entre as tabelas, executar uma verificação para ver se as réplicas dentro de uma região convergiram. A conclusão é que o importante é a integridade dos dados, e não apenas marcar uma caixa e verificar se o job de backup e restauração foi executado. Assim como acontece com as CVEs, não basta atualizar a versão e presumir que a exploração desapareceu. É preciso fazer essas verificações adicionais. E um ponto a destacar para qualquer um dos

09:22 arquitetos que estão criando esse tipo de backup e restauração dentro do seu cluster é que vocês também estão tomando uma decisão sobre residência de dados, gostem ou não. Quando vocês replicam para um bucket, o bucket não se importa se está no Oregon ou na Virgínia. A residência de dados, porém, se importa com onde esses registros individuais são armazenados. Então, uma solução é replicar apenas os IDs e os metadados das suas traces e dos seus dados

09:53 para diferentes regiões. Mas os dados centrais das traces ficam armazenados em uma região e não saem dela por causa de certas leis jurisdicionais. O último pilar é que a maioria dos bancos pensa que não está vazando nenhuma informação sensível para seus funcionários internos nem para seus usuários fora da VPC, mas pode haver portas laterais abertas. E isso aparece na forma de PII

10:24 e MNPI sendo ocultados. Há muitas estratégias diferentes para isso. Vocês podem ocultar informações no nível do SDK, no nível do gateway, usando vários middlewares. E, na prática, isso pode aparecer na interface do usuário como algumas informações de clientes, informações sensíveis, ocultadas. Mas e os juízes que vocês estão usando? Desafio todos vocês a analisar os system prompts dos juízes de LLM e verificar as traces para ver se elas contêm PII ou MNPI no raciocínio desses

10:56 juízes. Aqui está um system prompt para um juiz simples. Ele gera uma pontuação e uma explicação de quão bem o agent executou determinada tarefa. Mas há uma linha aqui no prompt que parece inofensiva, porque vocês querem que o revisor humano consiga verificar se o agent fez um bom trabalho e foi preciso. Isso pode ter permitido que o juiz vazasse e deixasse de ocultar PII ou MNPI.

11:29 Então, a interface do usuário continua parecendo boa, mas, no backend, o raciocínio do LLM as a judge pode revelar novamente informações de clientes e informações sensíveis. Uma estratégia para isso é fazer com que o juiz ainda leia os dados brutos das traces, mas sem persistir o raciocínio desse juiz. A pontuação, porém, vocês querem que persista — ela é importante para evals —, e isso sempre aparece na interface do usuário. Mas, nesse outro ramo, como vimos, o raciocínio ainda pode vazar PII.

12:01 Mas, no código da aplicação, vocês podem ter uma verificação que informa ao agent que esse registro não contém informações sensíveis e, portanto, pode persistir na interface do usuário. Assim, vocês ficam com uma pontuação e o raciocínio para esse registro. E, se essa verificação der negativo, ou seja, se o registro contiver informações sensíveis, basta suprimir esse raciocínio na interface do usuário. A maioria dos bancos com que trabalhamos quer ver o raciocínio dos LLM as judges sobre essas informações sensíveis. E uma melhoria adicional que vocês podem acrescentar a

12:32 esse fluxo é ter um segundo LLM as a judge cuja entrada tenha sido ocultada para remover as informações sensíveis. Assim, vocês podem confiar que a saída do juiz está limpa e exibi-la na interface do usuário. A conclusão aqui é que não há custo zero para evitar vazamentos e garantir a soberania dos dados. Neste caso, o custo é executar outra chamada de LLM na mesma solicitação.

13:06 Então, uma maneira de conseguirmos construir confiança com essas equipes de segurança e compliance é não simplesmente dizer: “Confiem em nós, aqui está a resposta”. Precisamos mostrar as evidências e o trabalho que nos levaram à resposta. Muitos fornecedores vão dizer: “O nosso tempo de deploy em produção é de algumas semanas”, mas não dizem que não verificaram esse prazo levando em conta a infraestrutura de vocês, a postura de segurança e as particularidades do cluster específico de vocês.

13:37 E, portanto, alguns sinais que observamos para reduzir esse tempo até a produção dizem respeito, na verdade, a ter muitos processos definidos: como baixar imagens de um registry, ter GPUs providenciadas e prontas para executar inference. Esse cronograma se estende por alguns meses quando há revisões formais de segurança ou quando vocês estão criando um gateway de LM personalizado ou uma configuração de RBA. E o cronograma se estende ainda mais quando vocês nem sequer têm um processo de aprovação para baixar imagens para o

14:11 seu registry, nem um plano para obter e adquirir GPUs. Percebi que a maioria desses sinais que prolongam o cronograma tem menos a ver com aspectos técnicos e mais com desafios e alinhamentos internos, humanos e organizacionais nos bancos. Mas ainda são fatores importantes a resolver. Então, o tema de hoje é mostrar o trabalho. Essa é a verdadeira

14:42 alavanca que vocês têm para acelerar o compliance ao trabalhar com um banco. E quando os nossos bancos, quando um dos nossos clientes, nos procura e diz: “Ei, nossos clientes estão tendo problemas”, esses problemas passam a ser problemas da minha equipe. E dividimos esses problemas em frentes de engenharia, workflow e trabalho humano e organizacional. O objetivo é automatizar o máximo possível, mas são esses problemas que me tiram o sono. E quero garantir que nossos concorrentes

15:13 não se esforcem mais do que nós nem sejam mais espertos do que nós em nenhum desses aspectos. E eu diria que vocês não querem ser apenas mais um fornecedor; querem realmente resolver os problemas dos seus clientes. E eu diria que a maior lição que aprendi trabalhando com esses bancos e equipes de segurança é que há muito em jogo. Contas correntes, hipotecas, cartões de crédito. Nestas situações, acertar as respostas até a quarta

15:44 casa decimal é importante. E há uma razão para muito do software nesses bancos ser antigo e desatualizado. Mas a linha entre software legado, processos bancários antigos e inovação se move um pouco a cada dia, e isso acontece graças a todos vocês. Então, acho que todos vocês estão explorando diferentes frameworks de agent e criando com novos harnesses, experimentando o Jev. E eu diria que, para aqueles poucos de vocês que

16:16 se importam com os desafios lentos, tediosos, burocráticos, metódicos, confusos, humanos e organizacionais dentro de um banco, não há nada como implantar IA no setor de serviços financeiros, porque há muito em jogo. E, sim, se quiserem avaliar seus próprios deploys em relação a esses pilares, é só entrar em contato. Hoje, falei de apenas três pilares, mas

16:48 vocês sabem, há uma lista completa de verificação para produção que usamos e que dá base a esses pilares. Voltando à minha prova de matemática da 10ª série, uma das melhores partes dessas provas era que, depois, eu e meus amigos íamos à mesa do almoço e tentávamos anotar de memória todos os problemas de que nos lembrávamos da prova. Então, usávamos aquele tempo para conversar: “Ei, foi assim que abordamos a resolução deste problema e daquele outro”. Isso me permitia pensar em diferentes abordagens e maneiras diferentes

17:18 de resolver esses problemas. E conferências como esta são um pouco como aquela mesa do almoço de quando eu estava na 10ª série, porque quero aprender com todos vocês como estão resolvendo os problemas dos seus clientes. Muito obrigado. >> [aplausos]

Transcrição original

[00:01] [music] >> 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

[00:31] 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

[01:02] 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

[01:32] 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.

[02:04] 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

[02:34] 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

[03:06] 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

[03:39] 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

[04:10] 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

[04:41] 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

[05:12] 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

[05:42] 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

[06:15] 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

[06:46] 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,

[07:17] 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

[07:48] 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

[08:21] 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

[08:51] 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

[09:22] 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

[09:53] 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

[10:24] 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

[10:56] 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.

[11:29] 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.

[12:01] 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

[12:32] 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.

[13:06] 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.

[13:37] 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

[14:11] 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

[14:42] 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

[15:13] 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

[15:44] 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

[16:16] 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

[16:48] 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

[17:18] 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]