Implementar IA em um banco não é um problema de engenharia — Paden Gayle, Applied AI Engineers

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: Deploying AI Inside a Bank Is Not an Engineering Problem — Paden Gayle, Applied AI Engineers · Canal: AI Engineer · 15:05 · Assistir no YouTube

Tópicos: Aplicações empresariais de IA, Avaliação e benchmarks de IA, Engenharia de software com IA, Governança e regulação de IA

Resumo

O vídeo argumenta que implementar IA em um banco depende menos de resolver um desafio técnico isolado e mais de descobrir, desde a primeira semana, quem toma as decisões sobre dados, risco, fornecedores e auditoria. A proposta é mapear responsáveis e aprovações, observar o fluxo de trabalho real e transformar a necessidade em uma especificação que possa ser corrigida pelos responsáveis. O sistema deve começar com a menor autoridade capaz de gerar valor, ampliando sua autonomia apenas com evidências e controles adequados. Avaliações, registros e planos de resposta a falhas devem fazer parte da operação desde o início.

Pontos-chave

A demonstração pode funcionar e o modelo pode estar adequado, mas o sistema ainda não será lançado se as decisões de segurança, dados, risco e auditoria não tiverem responsáveis.
Na primeira semana, identifique quem controla cada conjunto de dados, quem aprova seu uso e quem será responsável pelo sistema após o lançamento.
Mapeie dependências e aprovações enquanto o projeto ainda é fácil de alterar; transforme responsáveis não identificados em tarefas atribuídas a pessoas.
Quando não há uma especificação pronta, observe o fluxo real de trabalho, redija uma proposta e reduza o escopo com a participação do sponsor e dos responsáveis pelos controles.
Comece pela menor versão útil que se encaixe nos controles existentes, como preparar um rascunho para revisão de um analista antes de qualquer envio.
A autonomia pode avançar de sugerir e redigir para agir com aprovação ou agir dentro de limites previamente aprovados; cada nível exige controles e evidências diferentes.
Para cada falha, defina como ela será detectada, qual será a alternativa de segurança e quem será responsável pela resposta.
Registre dados, uso previsto, falhas, controles e resultados por segmento, além dos prompts, da versão do modelo, da configuração, da saída e da ação do revisor.
Uma média pode ocultar falhas graves em grupos específicos; apresente resultados por segmento e restrinja usos com evidência insuficiente.
Um checklist de cinco respostas até sexta-feira ajuda a identificar decisões pendentes, mas não prevê se o projeto será aprovado.

Capítulos

Início	Capítulo	Resumo
00:00	Por que a demonstração não chega à produção	O palestrante apresenta o problema e mostra como dúvidas de segurança, dados, risco e auditoria podem impedir o lançamento.
02:39	Discovery como parte da engenharia	A equipe deve identificar os responsáveis pelos dados e pelas decisões, tornar dependências visíveis e levar as perguntas às pessoas certas.
05:47	Observar o fluxo e reduzir o escopo	O método de observar, redigir e reduzir ajuda a criar uma especificação concreta e uma primeira versão que os responsáveis possam revisar.
08:21	Definir a autonomia e os limites de ação	O sistema deve começar com a menor autoridade útil, com revisão humana e controles proporcionais às consequências de possíveis erros.
11:28	Avaliações, falhas e evidências operacionais	O palestrante propõe definir respostas a falhas, manter registros e avaliar resultados por segmento para apoiar revisões.
13:32	Checklist da primeira semana e próximos passos	Cinco respostas ajudam a identificar pendências até sexta-feira; a conclusão é que a equipe deve encontrar as pessoas responsáveis antes de se comprometer com a entrega.

Citações

Discovery é engenharia. — 02:39

Quero sair com nomes, decisões ou próximas conversas. — 05:16

Começo pela menor autoridade que resolve o problema. — 08:21

A demonstração funcionou. O modelo estava bom. Ainda assim, não foi lançado. Então, o que fazemos? Vamos encontrar as pessoas. — 14:34

Conceitos e entidades

Paden Gayle (pessoa): Palestrante apresentado no título como Applied AI Engineers.
Bloomberg (empresa): Empresa onde o palestrante trabalhou em equipes de infraestrutura de negociação e plataforma de dados.
Google (empresa): Empresa onde o palestrante trabalhou com segurança e deploy.
Accenture (empresa): Empresa em que o palestrante começou sua carreira na área de consultoria.
O’Reilly (empresa): Editora para a qual o palestrante afirma estar escrevendo um livro sobre deploy engineering.
Discovery (conceito): Processo de identificar responsáveis, decisões, evidências e dependências antes de definir a implementação.
Autonomia de sistemas de IA (conceito): Níveis de autoridade que vão de sugerir ou redigir até executar ações dentro de limites aprovados.
Evidence pack (conceito): Conjunto de registros sobre uso previsto, dados, falhas, controles e resultados que apoia a revisão do sistema.
Avaliação por segmento (conceito): Análise de erros e controles em grupos distintos de dados para evitar que uma média esconda resultados fracos.
Revisão humana (conceito): Etapa em que uma pessoa verifica as evidências e o rascunho antes de decidir se uma ação será submetida.

Tradução completa (pt-BR)

00:00 Olá e sejam bem-vindos. Hoje vamos falar sobre implementar IA dentro de um banco e por que isso não é um problema de engenharia. Antes de entrarmos nesse assunto, quero me apresentar. Meu nome é Payeyton Gail. Trabalhei em muitas áreas diferentes. Comecei na consultoria, na Accenture. Depois fui para a Bloomberg como engenheiro de software, onde trabalhei em uma equipe de infraestrutura de negociação e em uma equipe de plataforma de dados. Depois, trabalhei na Google com segurança e deploy. E, neste momento, sou o primeiro funcionário em tempo integral de uma startup e estou escrevendo um livro sobre engenharia de deploy para a O’Reilly.

00:30 Neste exemplo, o sistema analisa documentos de clientes e prepara rascunhos de exceções para um analista. A demonstração mostra o workflow pretendido, e todos conseguem ver por que ele seria útil. Então a equipe de segurança pergunta: certo, qual ambiente vai hospedá-lo? Os responsáveis pelos dados perguntam quem autorizou esse uso dos documentos, e alguém da área de risco pergunta quem vai revisar uma exceção incorreta antes que ela chegue ao próximo sistema. São perguntas razoáveis, certo? Cada pergunta pode mudar o que temos permissão para construir. A equipe já investiu em um projeto, embora várias pessoas responsáveis por esse projeto nunca o tenham visto. Então, neste caso, a demonstração

01:02 funcionou. O modelo estava bom. No entanto, mesmo assim, não foi lançado. Agora quero mostrar como descobrir essas decisões na primeira semana, para que você possa projetar um sistema com um caminho viável até a produção. Esses quatro rótulos representam decisões das quais seus deploys dependem. Para cada uma, quero uma pessoa que consiga explicar a decisão, as evidências de que precisa e o próximo passo. Então, vamos começar pelos dados. Dados: quem é responsável pela fonte, quem pode conceder acesso e quem pode aprovar o uso no workflow. Essas responsabilidades podem caber a pessoas diferentes, mas conseguir consultar um conjunto de dados não

01:33 resolve todas as questões sobre como a aplicação pode usá-lo. Quanto ao risco de modelo, encontre alguém que possa dizer qual revisão se aplica ao uso pretendido. Pergunte como foi uma submissão anterior. Descubra quem será responsável pelo sistema depois do lançamento e quais evidências essa pessoa precisará manter. Para o risco de terceiros, trace a cadeia real de dependências. Inclua o provedor do modelo, os acordos de hospedagem e seu papel no serviço operacional. Descubra quais relações já foram analisadas e quais mudanças propostas exigem outra decisão. Para auditoria, pergunte a alguém, certo?

02:06 Para auditoria, pergunte de que informações alguém precisaria para reconstruir uma ação importante. Qual entrada foi usada? Qual configuração gerou a saída? O que o revisor viu? E quem aprovou a ação? Essas são as perguntas que afetam os registros que você precisa capturar desde o início. Agora imagine obter essas respostas depois de construir o sistema inteiro: um limite de deploy, um fluxo de dados ou uma ação talvez tenha que mudar. O caminho útil é envolver essas pessoas e trazê-las para o projeto desde o começo. As responsabilidades delas nos ajudam a identificar o sistema que podemos realmente operar.

02:39 E, aqui, a descoberta é a engenharia. Agora queremos falar sobre o que é essa descoberta e quem precisamos encontrar para entender exatamente o que temos de construir. Você deve considerar que cada conjunto de dados tem um responsável. O trabalho que fiz na equipe de plataforma de dados da Bloomberg tornou isso algo concreto para mim. Construir infraestrutura para um LLM significava entender quais conjuntos de dados podiam ser usados e quem podia aprovar esse uso. A ideia que queremos transmitir é que cada conjunto de dados tem um responsável. Meu trabalho na equipe de plataforma de dados da Bloomberg tornou isso algo concreto para mim. Construir uma

03:11 infraestrutura para um LLM significava entender quais conjuntos de dados podem ser usados e quem pode aprovar esse uso. Leve isso em conta em cada deploy bancário. Na verdade, em qualquer deploy. Portanto, antes de projetar a recuperação, encontre a pessoa responsável por cada fonte. Confirme o uso permitido e o ambiente em que o processamento pode de fato começar. Se essas respostas mudarem, seu projeto muda junto. Imagine que a chave neste slide represente uma permissão real com uma pessoa responsável de verdade. Devemos conseguir identificar essa pessoa para saber exatamente de onde essa chave precisa vir.

03:43 Ao começar a definir o escopo de uma arquitetura, muitas das perguntas que você talvez tenha podem ser respondidas consultando o organograma. Leia primeiro a linha de cima. Os documentos entram no modelo e um analista revisa a saída. Provavelmente, você consegue esboçar esse sistema em poucos minutos. Agora leia a linha logo abaixo. Os documentos têm um responsável pelos dados. O serviço do modelo precisa de um responsável pela plataforma. O workflow do analista precisa de alguém que possa confirmar os requisitos de risco pertinentes. E o último nome ainda tem um ponto de interrogação. Esse ponto de interrogação é uma dependência. Projetamos um workflow sem encontrar a pessoa que pode nos dizer se o uso pretendido é

04:15 aceitável e quais evidências serão exigidas. Então, eu analisaria este diagrama com um patrocinador ou alguém em quem confie e tentaria descobrir: certo, quem é responsável pelos documentos? Essa pessoa já foi informada sobre esse uso? Quem pode nos ajudar a chegar ao revisor adequado? Depois, confirmaria as respostas diretamente com essas pessoas. O mapa real terá mais relações do que este. Um componente técnico pode depender de várias aprovações. Algumas decisões abrangem o sistema inteiro. O objetivo é tornar essas dependências visíveis enquanto ainda é fácil alterar o projeto. Um responsável não identificado se transforma em uma tarefa específica, com uma pessoa responsável por resolvê-la.

04:46 É assim que a descoberta começa a transformar incerteza em um plano de implementação. E, com isso, talvez você comece a se perguntar: certo, Peyton, que tipo de pergunta devo fazer? Então, aqui estão algumas perguntas que eu levaria para uma conversa de descoberta. Onde os dados ficam e quem pode aprovar o acesso de leitura? Quem barrou um projeto semelhante antes e por quê? Quais controles existentes poderiam cobrir esse workflow e quem é responsável por eles? Onde isso vai rodar em produção e quem são os administradores desse

05:16 ambiente? Quem assina a revisão de risco pertinente e o que essa pessoa já assinou antes? Com qual obrigação o patrocinador está pessoalmente preocupado e quem pode explicá-la? Repare no que quero obter ao final. São nomes, decisões ou próximas conversas. Se alguém disser que a segurança vai ficar bem, pergunte quem vai realmente analisar o projeto e quando você poderá se reunir com essa pessoa. Depois, feche o ciclo. Envie a cada responsável uma breve descrição do uso proposto e confirme o que precisa de você. Até sexta-feira, as pessoas de cujas decisões o deploy depende devem saber que o projeto existe. Isso dá à definição do escopo um ponto de partida muito mais sólido.

05:47 E, depois que tudo isso estiver feito e soubermos quem é responsável pelas decisões, posso definir o escopo do trabalho. Quando o cliente não consegue escrever ou fornecer a especificação, recorro a estas três coisas: observar, elaborar um rascunho e reduzir o escopo. Por exemplo, na Bloomberg, trabalhei em um sistema que processava fluxos de caixa. Esse trabalho precisava fechar. Isso me deu um ponto de partida concreto. Então, comecei acompanhando. Por exemplo, na Bloomberg, trabalhei em um sistema que processava fluxos de caixa. O trabalho precisava fechar, e isso me deu um ponto de partida concreto. Acompanhe o fluxo e as pessoas responsáveis por ele. Uso essa

06:18 abordagem quando um patrocinador quer usar IA no processo de integração de clientes. Sente-se com um analista, observe quais sistemas ele abre, onde faz um julgamento e quando pede permissão. Pergunte o que acontece quando falta um documento. Anote a sequência real. Esse é o começo da sua especificação. Agora imagine que estamos construindo o assistente para exceções em documentos. Este é um exemplo hipotético, mas eu ainda apresentaria estas três linhas ao patrocinador. Uma: revisar os documentos. Duas: preparar os rascunhos das exceções. E três: o analista envia. Depois, tornaria cada linha específica. A quais documentos o analista pode

06:49 ter acesso? Esse acesso foi aprovado para este processamento? O que o modelo deve produzir? Pode ser um trecho destacado, um formulário preenchido em rascunho ou ambos. E quem verifica o rascunho? E quem o envia? Para a primeira versão, suponhamos que a saída seja uma exceção destacada e um formulário preenchido em rascunho. O analista verifica a fonte, edita o formulário e o envia. Esse é o limite dentro do qual alguém pode fazer correções. Eu também proporia um critério de sucesso. Por exemplo, reduzir o tempo de revisão sem aumentar os erros e as interpretações equivocadas. Ainda precisamos concordar sobre como medir isso em comparação com o

07:20 no fluxo de trabalho atual, porque, de novo, esse é o ponto principal. É uma proposta até chegarmos a um acordo. Leve o rascunho ao patrocinador e aos responsáveis pelos controles. Eles podem riscar um tipo de documento. Podem mudar o revisor ou simplesmente rejeitar o resultado de vez. Cada correção nos dá uma decisão em torno da qual podemos construir. Então, quando o fluxo de trabalho estiver completo, o escopo se torna uma série de perguntas de aprovação. Agora, vamos expandir nosso sistema hipotético um passo de cada vez. Primeiro, ele resume um documento que o analista já tem. Ainda vamos confirmar

07:50 se o acesso existente cobre esse uso. Em seguida, ele lê dados de um segundo sistema. Agora há outro caminho de dados, e alguém precisa aprová-lo. Depois disso, ele prepara uma resposta que será vista por um cliente. Quem verifica o conteúdo e quais revisões se aplicam ao uso que podemos fazer? Por fim, ele envia uma resposta automaticamente. Quem é responsável por essa ação? O que acontece se ele enviar algo errado? E como podemos interromper o processo e recuperá-lo? Esses são os quatro escopos diferentes de engenharia. As revisões aplicáveis dependem da instituição e do caso de uso. Então, eu

08:21 confirmaria isso com as pessoas responsáveis por essas decisões. Depois, pergunto qual incremento gera valor útil hoje. Eu poderia preparar um rascunho dentro do fluxo de trabalho atual do analista para resolver uma parte suficiente do problema? Se sim, comece por aí. Confirme se o controle existente realmente se aplica e construa a menor versão útil, ou o MVP, com um caminho de aprovação confiável. Isso me leva à autonomia. Começo com o mínimo de autoridade necessária para resolver o problema e, então, pergunto qual tarefa pode ser comprovada como evidência para dar mais autoridade ao sistema. Quando eu trabalhava com fluxos de caixa na Bloomberg,

08:52 eu pensava bastante em automação. Cada etapa automatizada precisa de um controle, e alguém é responsável por um número. Levo essa disciplina para a IA. Encontre a ação consequente, identifique quem é responsável por ela e decida o que acontece quando o sistema erra. Por exemplo, em um fluxo de trabalho hipotético de exceções, o envio é essa ação. Um analista que revisa o rascunho precisa das evidências da fonte e de incertezas visíveis para fazer um julgamento de verdade. Um botão de revisão só ajuda se a pessoa puder realmente verificar o trabalho. Então, ao pensar em autonomia, quero que vocês leiam a escala de baixo para cima.

09:22 “Sugere” significa que o analista recebe uma recomendação e escolhe o que fazer com ela. “Prepara um rascunho” significa que o sistema prepara algo que o analista verifica e envia. Esse é um passo em destaque. “Age com aprovação” significa que uma pessoa autoriza cada ação antes que ela aconteça. “Age” significa que o sistema opera dentro de limites que já foram aprovados. Cada passo muda as consequências de um erro. No entanto, também muda quais controles precisam funcionar e qual revisor precisa ser convencido. Eu começaria pelo nível mais baixo que gera valor. Depois, reuniria evidências a partir daí. As revisões estão levando os analistas a substituir os rascunhos? Quais falhas

09:53 continuam se repetindo? As pessoas conseguem se recuperar quando algo dá errado? Use essas observações para tomar a próxima decisão sobre autoridade. Um modelo não se torna mais capaz por si só. Responda à pergunta: quanta autoridade esse fluxo de trabalho específico deve conceder a ele? Agora, vamos tornar isso concreto com o mesmo assistente hipotético de exceções. Suponha que o pedido inicial seja um agent que lê documentos de clientes, decide quais estão fora da política e registra exceções automaticamente. Nesse projeto, o julgamento do modelo pode se tornar uma ação operacional sem que um analista verifique cada caso. Agora, mantenha o modelo

10:26 e mude o limite da ação. Ele destaca uma provável exceção, aponta para a fonte relevante e prepara um formulário como rascunho. O analista verifica as evidências, corrige o formulário e decide se vai enviá-lo. Acompanhem essa sequência no slide. Modelo, humano, envio. Vou levar esse projeto às pessoas que encontramos durante a descoberta. Esse uso pode se encaixar no fluxo de trabalho atual do analista? O acesso aos dados aprovado cobre o processamento? Quais controles se aplicam? E de quais evidências os revisores precisam? A revisão humana não garante aprovação nem determina, por si só, uma categoria regulatória. Ainda precisamos

10:57 confirmar o uso pretendido e as revisões necessárias. A pergunta útil é se essa versão que prepara rascunhos resolve o suficiente dos problemas para ser lançada primeiro. Se resolver, podemos reunir evidências sobre erros, substituições e recuperação enquanto operamos dentro desse limite. A próxima decisão sobre autoridade poderá se basear no que aconteceu no uso real. Isso torna a avaliação parte do plano operacional. E isso nos leva à nossa quarta promessa: uma avaliação que a equipe de risco possa usar como evidência — o que, na prática, significa as avaliações pelas quais ela é responsável. No Google, a pergunta para a qual eu

11:28 precisava de uma resposta era: o que acontece quando o sistema falha, quem percebe, o que é interrompido, quem assume a responsabilidade e quanto tempo levará para voltar a funcionar? Em uma implantação de IA, quero o mesmo relato concreto, certo? O uso pretendido, um modelo de ameaças, os modos de falha e um plano de resposta. Mostre-me os controles funcionando quando o modelo erra. Identifique a pessoa que recebe o alerta e pode interromper o fluxo de trabalho. Isso nos dá uma maneira prática de avaliar nosso exemplo. Então, voltando ao nosso ótimo exemplo, o assistente hipotético de exceções. Se ele inventar uma

12:00 exceção, o analista verifica a passagem na fonte e rejeita o rascunho. Se a extração produzir um texto ilegível, interrompa o processo e solicite um arquivo legível. Se ele deixar passar exceções, casos offline direcionados ajudam a revelar essa fraqueza. Eles não detectam todos os casos não identificados em produção. Mantenha o trabalho afetado sob revisão manual. Para cada falha, identifique o caminho de detecção, a alternativa de contingência e a pessoa responsável. Registre essas decisões em um pacote de evidências. Esses cinco arquivos completam a revisão. Uso pretendido: registre os usuários, os limites e as ações proibidas. Linhagem dos dados:

12:30 registros de cada exemplo, da fonte e da aprovação de uso; modos de falha: registre a detecção e a alternativa de contingência; resultados por segmento: registre a cobertura e os erros; controles: registre as revisões, os limites, as regras de interrupção e os responsáveis. Com tudo isso, geramos as evidências a cada execução da avaliação. Junto com elas, preservamos os prompts de entrada, a versão do modelo, a configuração, o resultado e a ação do revisor, o que nos permite reconstruir a decisão histórica. Chamar o modelo novamente mais tarde pode produzir uma resposta diferente. Por isso, preservamos o que realmente aconteceu. Um

13:01 revisor pode então consultar esse registro de apoio. Agora, podemos dar uma olhada para ver exatamente o que está sendo usado para organizar esse resultado no quarto arquivo. Para um fluxo de trabalho hipotético, eu separaria documentos limpos, digitalizações, exceções raras e novos tipos de documento. Mediria os erros e o comportamento dos controles em cada grupo e, em seguida, daria destaque ao resultado mais fraco. Uma média pode ocultar uma lacuna grave em um segmento. Se houver poucas evidências para um grupo, diga isso e restrinja esse uso até que haja o suficiente. Isso informa aos revisores o que os resultados

13:32 sustentam. E também nos traz de volta às decisões da primeira semana. Para fechar tudo até sexta-feira, quero cinco respostas. O responsável pelos dados está envolvido e ciente deste projeto? O ambiente de produção e seus administradores estão identificados? O patrocinador consegue descrever o fluxo de trabalho sem dizer “IA”? O menor escopo útil pode se encaixar nos controles existentes, confirmados com seus responsáveis? Sabemos quem assina a avaliação de risco e o que aconteceu com a pessoa que assinou da última vez? Use essas respostas como uma heurística de planejamento. Quatro ou cinco respostas afirmativas

14:03 indicam um caminho confiável para o lançamento. Três significam que decisões pendentes precisam de responsáveis e prazos. De zero a duas significam que essas decisões precisam ser resolvidas antes de se comprometer com a entrega, o que pode incluir reduzir o escopo ou até redefini-lo. Essa pontuação não prevê a aprovação, mas indica onde devemos concentrar a próxima semana. E aqui está o que eu levaria para essas próximas conversas. Para concluir, quero que as pessoas saiam daqui com a ideia de que a descoberta é a engenharia. Elabore a especificação e depois reduza o escopo. Dê ao sistema apenas a autoridade de que precisa. Monte o pacote de evidências na primeira sprint. A demonstração funcionou. O modelo estava bom. Mesmo assim, não foi lançado. Então, o que fazemos? Vamos encontrar as pessoas. Obrigado por acompanharem esta apresentação comigo. Meu nome é Peyton Gail. Sou engenheiro fundador de implantação e estou escrevendo um livro sobre FTE para a O’Reilly. E adoraria conversar sobre FTE e tudo relacionado a isso. Se tiver interesse, você pode me encontrar no LinkedIn, ou no meu site, painting.com, onde estão todas as minhas informações. Obrigado novamente por assistir hoje e, sim, estou ansioso

14:34 empacotar na primeira sprint. A demonstração funcionou. O modelo estava bom. Mesmo assim, não foi lançado. Então, o que fazemos? Vamos encontrar as pessoas. Obrigado por acompanhar esta apresentação comigo. Meu nome é Peyton Gail. Sou engenheiro fundador de implantação avançada e estou escrevendo o livro sobre FTE para a O’Reilly. E sim, adoro conversar sobre FTE e tudo relacionado a isso. Se tiver interesse, você pode me encontrar no LinkedIn, ou acessar meu site, painting.com, onde estão todas as minhas informações. Mais uma vez, obrigado por assistir hoje e, sim, espero

15:05 por isso.

Transcrição original

[00:00] Hello and welcome. Today we will be talking about deploying AI inside of a bank and how it is not an engineering problem. Before we get into that, I want to introduce myself. My name is Payeyton Gail. I worked across many different fields. So I started off at consulting at Accenture. Before moving over to Bloomberg as a software engineer where I worked on a trade infrastructure team and a data platform team. Then afterwards I would be at Google working on security and deployment. And right now I am a founding FTE at a startup and writing the book on for deploy engineering with O’Reilly.

[00:30] In this example, the system reviews client documents and drafts exceptions for an analyst. The demo shows the intended workflow and everybody can see why it would be useful. Then security asks, okay, which environment will host it? The data owners ask who agreed to this use of documents and someone from risk asked who will review a wrong exception before it reaches the next system. Those are reasonable questions, right? Each question can change what we are allowed to build. The team has already invested a design while several people responsible for that design have never seen it. So in this case, the demo

[01:02] worked. The model was fine. However, it still did not ship. I want to now show you how to uncover those decisions in week one so you can design a system with a credible route into production. These four labels represent decisions your deployments depend on. For each one, I want a person who can explain the decision, the evidence they need, and the next step. So, let’s start with data. Data, who owns the source, who can grant access, who can approve using this in the workflow. Those responsibilities may belong to different people, but being able to query a data set does not

[01:33] settle every question about how the application may use it. For the model risk, find a person who can tell you which review applies to the intended use. Ask what a previous submission looked like. Learn who will own the system after launch and what evidence that owner will need to maintain it. For third party risk, draw the actual dependency chain. Include the model provider, the host arrangements, and your role in the operating service. Find out which relationships have already been reviewed and which proposed changes require another decision. For audit, ask someone, right?

[02:06] For audit, ask what someone would need to reconstruct a consequential action. Which input was used? Which configuration produced the output? What did the reviewer see? And who approved the action? Those are the questions that affect the records you need to capture from from the beginning. Now imagine getting those answers after you built the whole entire system, a deployment boundary, a data path or action that may have to change. The useful move is to bring these people in and bring them into the design early. Their responsibilities help us identify the system we can actually operate.

[02:39] And here discovery is the engineering. So now we want to talk about what discovery is and who we need to really find out to understand what exactly we need to build. So you want to think every data set has an owner. The work I did at Bloomberg on the data platform team made this concrete for me. So building infrastructure for for an LLM meant understanding which data sets could be used and who could approve that use. The idea we want to get across is that every data set has an owner. My work at Bloomberg on the data platform team made this concrete for me. Building an

[03:11] infrastructure for an LLM meant understanding which data sets can be used and who could approve that use. Carry that into each bank deployment. Honestly, any deployment. So before designing retrieval, find the person accountable for each source. Confirm the allowed use and the environment where the processing can actually start to happen. If those answers change, your design changes with them. Imagine the key on this slide stands for a real permission with a real owner. We should be able to name that owner to know where exactly this key needs to come from.

[03:43] When starting to scope out an architecture, a lot of the questions you may have can be answered by looking at the or chart. Read the top row first. Documents go into the model and an analyst reviews the output. You can probably sketch that system in a few minutes. Now read the row underneath it. The documents have a data owner. The model service needs a platform owner. The analyst workflow needs someone who can confirm the relevant risk requirements. And the last name still has a question mark. That question mark is a dependency. We have designed a workflow without finding the person who can tell us whether its intended use is

[04:15] acceptable and what evidence will be required. So I would walk through this diagram with a sponsor or someone you trust and figure out, okay, who owns the documents? Have they heard about this use? Who can help us reach the appropriate reviewer? Then I would confirm the answers directly with those people. The real map will have more relationships than this. A technical component may depend on several approvals. Some decisions span the entire system. The point is to make those dependencies visible while the design is still easy to change. An unnamed owner becomes a specific task with a person responsible for resolving

[04:46] it. That is how discovery starts turning uncertainty into an implementation plan. And given that you may start to ask yourself, okay, Peyton, what sort of question should I be asking? So here are some of the questions I would bring to a discovery call. Where does the data live and who can approve reading it? Who has stopped it in a similar project before and why? Which existing controls could cover this workflow and who owns them? Where will this production run and who are the administrators for that

[05:16] environment? Who signs the relevant risk review and what have they signed before? What obligation is the sponsor personally worried about and who can explain it? Notice what I want to leave with. It’s either names, decisions, or next conversations. If someone says security will be fine, ask will actually review the design and when you can meet them. Then close the loop. Send each owner a short description of the proposed use and confirm what they need from you. By Friday, the people whose decisions the deployment depends on should know the project exists. That gives scoping a much firmer starting

[05:47] point. And once all that is done and we know who owns the decisions, I can scope the work. When the customer cannot write or give out the spec, I rely on these three things. Shadow, draft, and shrink. For example, at Bloomberg, I worked on a system that handled cash flows. That work had to reconcile. That gave me a concrete place to start. So, it started with following. For example, at Bloomberg, I worked on a system that handled cash flows. The work had to reconcile and that gave me a concrete place to start. Follow the flow and the people responsible for it. I use that

[06:18] approach when a sponsor wants AI for onboarding. Sit with an analyst, watch which systems they open, where they make a judgment, and when they ask for permission, ask what happens when a document is missing. Write down the actual sequence. That is the beginning of your specification. Now, imagine we are building the document exception assistant. This is a hypothetical example, but I would still put these three lines in front of the sponsor. One, review the documents. Two, draft the exceptions. And three, analyst submits. Then I would make each line specific. Which documents can the

[06:49] analyst access? Is it access approved for this processing? What should the model produce? And that’ll be a highlighted passage, a draft form or both. And who checks the draft? And also who submits it? For first version, suppose the output is a highlighted exception and a draft form. The analyst checks the source, edits the form and submits. That is the boundary someone can correct. I would also propose a success criteria. So either less review time with no increases and misconceptions. We still need to agree on how to measure that against the

[07:20] current workflow because that again right is the whole point. It is a proposal until we have an agreement. Take the draft to the sponsor and the control owners. They can cross out a document type. They can change the reviewer or they could just, you know, flat out reject the output. Each correction gives a decision we can build around. So once the workflow is complete, scope becomes a series of approval questions. So now let’s grow our hypothetical system one step at a time. First, it summarizes a document that the analyst already has. We will still confirm

[07:50] whether that existing access covers its use. Next, it reads from a second system. Now, there’s another data path and somebody needs to approve it. Next, after that, it drafts a response that a customer will see. Who checks the content and which will review the applies that we can use. Finally, it sends a response automatically. Who owns that action? What happens if it sends something wrong? And how do we stop it and recover it? Those are the four different engineering scopes. The applicable reviews depend on the institution and the use case. So I would

[08:21] confirm them with people who own those decisions. Then I ask which increment creates the useful value today. Could I draft inside the analyst’s current workflow to solve enough of the problem? If so, start there. Confirm that the existing control really fits and build the smallest useful version or the MVP with a credible path of approval. That brings me to autonomy. I start with the least authority that the problem solved then ask what task can be proven as evidence to give the system more. So when working on cash flows at Bloomberg

[08:52] I thought about automation a lot of the time. So every automated step needs a control and somebody owns a number. I carry that discipline into AI. So find the consequential action name its owner decide what happens when the system is wrong. So for example in a hypothetical exception workflow the submission is that action. An analyst reviewing the draft needs the source evidence and visible uncertainty to make a real judgment. A review button only helps if the person can actually check the work. So when thinking about autonomy, I want you to read the ladder from bottom up.

[09:22] Suggest means the analyst receives a recommendation and chooses what to do with it. Draft means the system prepares something the analyst checks and submits. That is a highlighted step. Acts with approval means a person authorizes each action before it happens. Acts means the system operates within limits that have already been approved. Each step changes the consequences of an error. However, it also changes which controls must work and which reviewer needs to be convinced. I would start at the lowest step that creates value. Then collect evidence from there. Are the reviews overriding the drafts? Which failures

[09:53] keep recurring? Can people recover when something breaks? Use those observations to make the next authority decision. A model does not become more capable by itself. Answer how much authority this particular workflow should give it. So now let’s make that concrete with the same hypothetical exception assistant. Suppose the initial request is an agent that reads client documents, decides which ones fall outside of policy, and files exceptions automatically. In that design, the model’s judgment can become an operational action without an analyst checking each case. Now keep the model

[10:26] and change the action boundary. It highlights a likely exception, points to the relevant source, and prepares a draft form. The analyst checks the evidence, corrects the form, and chooses whether to submit. Follow that sequence on the slide. Model, human, submit. I’ll take that design to the people we found during discovery. Can this use the analyst existing workflow? Does the approved data access cover the processing? Which controls apply? And what evidence do the reviewers need? Human review does not guarantee approval and it does not determine a regulatory category on its own. We still have to

[10:57] confirm the intended use and the required reviews. The useful question is whether this drafting version solves enough of the problems to ship first. If it does, we can collect evidence about errors, overrides, and recovery while operating within that boundary. The next decision about authority can draw on what happened in real use. That makes the evaluation part of the operating plan. And that brings us to our fourth promise. An evaluation the risk team can use for evidence, which really just means the ones they’re responsible for managing. At Google, the question I

[11:28] needed answered was what happens when the system breaks, who notices, what stops, who takes responsibility, how long will it take to bring back up. For an AI deployment, I want the same concrete account, right? The intended use, a threat model, the failure modes, and a response plan. Show me the controls working when the model gets something wrong. Name the person who receives the alert and can stop the workflow. That gives a practical way to evaluate our example. So going back to our lovely example, the hypothetical exception assistant. If it invents an

[12:00] exception, the analyst checks the source passage and rejects the draft. If extraction produces unreadable text, stop and request a clean file. If it misses exceptions, targeted offline cases help expose that weakness. They do not detect every live miss. Keep affected work under manual review. For each failure, name the detection path, the fallback, and its owner. Put those decisions in an evidence pack. These five files make the review complete. Intended use, record users, boundaries and prohibited actions. Data lineage,

[12:30] records, each example source and use approval, failure modes, records detection and fallback, results by segment, record coverage and errors controls, record reviews, thresholds, stopping rules and owners. So with all of this, we generate the evidence with each evaluation run. alongside it preserve the input prompts model version configuration output reviewer action that lets us reconstruct the historical decision. Calling the model again later may produce a different answer. So we preserve what actually happened. A

[13:01] reviewer can then expect that supporting record. So now we can take a look to see like what exactly is being used to organize that result which is in the fourth file. For a hypothetical workflow, I would separate clean documents, scans, rare exceptions, and new document types. Measure the errors and control behaviors in each group, then lead with the weakest result. An average can hide a serious gap in one segment. If a group has a little evidence, say so and restrict that use until you have enough. This tells reviewers what the results

[13:32] support. And it also brings us back to our week one decisions. Now, just rounding everything up by Friday, I want five answers. Is the data owner engaged and aware of this project? Are the production environment and its administrators named? Can the sponsor describe the workflow without saying AI? Can the smallest useful scope fit existing controls confirmed with their owners? Do we know the risk signer and what happened to the person that signed last time? Use those answers as a planning heristic. Four or five yeses

[14:03] suggest a credible path to ship. Three means unresolved decisions need owners and dates. Zero to two means resolve this decisions before committing to delivery, including possibly shrinking scope or even redefining scope. This score does not predict approval, but it does tell us where to spend the next week. And here is what I would carry into these next conversations. So to wrap this up, what I want people to walk away with is that discovery is the engineering. Draft the spec, then shrink it. Give the system only the authority it needs. Build the evidence

[14:34] pack in sprint one. The demo worked. The model was fine. It still did not ship. So what do we do? We go find the people. Thank you for going through this presentation with me. My name is Peyton Gail. I am a founding for deployed engineer writing the book on FTE for O’Reilly. And yeah, love to talk about FTE and everything related to it. If that’s of interest, you can find me on LinkedIn or my website painting.com has all of my information. Thank you again for watching today and yeah looking

[15:05] forward to