Trabalhar no BMO, um dos cinco maiores bancos do Canadá, e ao mesmo tempo ser alguém que acompanha de perto o espaço de desenvolvimento com IA me colocou em uma posição interessante. Me importo profundamente em usar ferramentas modernas para construir software melhor e mais rápido. E banco é um ambiente onde se espera que cada ferramenta, cada fluxo de dados e cada serviço externo passe por camadas de revisão de segurança, validação de compliance e avaliação de risco antes de tocar produção.
Essas duas realidades não são incompatíveis, mas reconciliá-las exige um olhar lúcido sobre onde estão as linhas e por quê. O que vem a seguir não é uma defesa da cautela enterprise nem uma reclamação sobre ela. É o que achei útil dentro das restrições.
A Restrição Fundamental: Confidencialidade de Dados
A coisa mais importante a entender sobre usar IA em bancos é que a restrição não é sobre ser anti-tecnologia. É sobre dados. Bancos detêm alguns dos dados pessoais e financeiros mais sensíveis que existem: números de conta, históricos de transação, perfis de crédito, finanças empresariais, informações pessoalmente identificáveis de milhões de clientes. Os frameworks que governam esses dados no Canadá, entre eles a PIPEDA e as diretrizes do OSFI, não são opcionais e não são abstratos.
Quando você cola código em uma ferramenta comercial de IA, esse código potencialmente contém contexto. Nomes de variáveis, endpoints de API, nomes de colunas de banco de dados, lógica de negócio que sugere estruturas de produto. Mesmo que você não esteja colando dados reais de clientes, pode estar revelando arquitetura confidencial do sistema. Essa é uma preocupação real, e digo isso como alguém que quer usar essas ferramentas o máximo possível.
O Que Você Não Pode Compartilhar com Ferramentas de IA
Aqui está minha lista prática de trabalho do que absolutamente não vai para nenhuma ferramenta de IA externa em contexto bancário:
- Qualquer dado real de cliente, mesmo amostras 'anonimizadas'. O risco de re-identificação é real
- URLs ou schemas de endpoints de API internos que não são documentados publicamente
- Nomes de tabelas e colunas de banco de dados de sistemas de produção
- Fluxos de autenticação, estruturas de token ou lógica de middleware de segurança
- Lógica de negócio que revela funcionalidades de produto não lançadas ou estratégias de precificação
- Workflows de compliance, implementações de trilha de auditoria ou código de relatórios regulatórios
- Qualquer coisa marcada como confidencial, proprietária ou interna no sistema de classificação da sua organização
- Código de repositórios com acesso restrito
Esta não é uma lista legal abrangente. Isso é trabalho da equipe de segurança da sua organização. Esta é minha heurística pessoal de operação. Quando tenho dúvida, removo contexto agressivamente antes de fazer o prompt.
O Que Você Pode Fazer com IA em Bancos
A lista acima parece limitante. A maioria dos problemas difíceis em desenvolvimento Angular enterprise não é específica de bancos. São problemas de escala, padrões, testes e arquitetura. E a IA é extremamente útil para todos esses.
- Gerar boilerplate para componentes, serviços e testes usando schemas genéricos ou anonimizados
- Explicar conceitos, padrões e APIs do Angular com os quais você tem menos familiaridade
- Debugar erros de compilação TypeScript colando mensagens de erro sanitizadas
- Refatorar lógica usando estruturas de dados abstratas (substituindo nomes de campos reais por genéricos)
- Escrever funções utilitárias: formatadores de data, validadores, transformadores de string. Não contêm dados sensíveis
- Revisar acessibilidade: padrões ARIA, navegação por teclado, gerenciamento de foco
- Rascunhar documentação, comentários ou descrições de PR a partir de código sanitizado
- Aprender sobre operadores RxJS, padrões de signals ou internos do Angular
A habilidade-chave é abstração. Fiquei bom em traduzir um problema real em uma versão estruturalmente equivalente mas neutra em dados do mesmo problema. Os detalhes específicos de banco vivem na minha cabeça e nos nossos sistemas internos. A IA me ajuda a resolver o desafio estrutural.
Um Exemplo Concreto de Abstração Segura
É assim que a abstração funciona na prática. O sistema abaixo foi inventado para este post, porque o real não é meu para publicar, mas o formato do erro é idêntico. Digamos que um componente consulta um endpoint de tempos em tempos e exibe um número da resposta, e eu quero ajuda com o padrão de reatividade. Esta é a versão que eu nunca enviaria:
// DON'T DO THIS
Here is our FleetStatusComponent that pulls from the /api/v2/fleet/summary endpoint.
It reads from fleetState.activeVehicles and needs to refresh every 30s...
[actual internal code pasted here]Em vez disso, abstraio completamente:
// DO THIS INSTEAD
I have an Angular component that polls a REST endpoint every 30 seconds and displays
a numeric value from the response. Using signals, I need to handle:
1. A loading state on initial fetch
2. A silent background refresh (no loading spinner on re-poll)
3. An error state that doesn't clear the last known good value
The endpoint returns { value: number; lastUpdated: string }.
What's a clean signal-based pattern for this?O segundo prompt me dá tudo que preciso para resolver o problema real e não revela nada sobre o sistema de onde ele veio. O desafio técnico é idêntico. Os dados são genéricos. Esse passo de tradução é a habilidade inteira.
Processos de Aprovação Enterprise para Ferramentas de IA
Além das preocupações com dados, o uso de IA enterprise passa por revisão de procurement e segurança. Se sua organização está avaliando uma ferramenta de IA, um plugin de IDE para assistência de código, uma assinatura enterprise de LLM, uma licença do GitHub Copilot Business, espere que esse processo leve meses, não dias. Envolve avaliações de segurança do fornecedor, acordos de processamento de dados, revisão de onde seus dados são armazenados e se são usados para treinamento, e aprovação de múltiplos stakeholders.
Isso é frustrante do ponto de vista de produtividade. Quando uma ferramenta passa pela revisão, a versão que você avaliou pode estar desatualizada. Também passei a respeitar por que esse processo existe. Uma violação de dados envolvendo a cadeia de ferramentas de desenvolvimento de um banco não é um cenário hipotético. Já aconteceu com instituições financeiras globalmente. A cautela é calibrada para o risco real.
Meu conselho para navegar isso: pressione cedo e forneça evidências. Se você quer uma ferramenta aprovada, construa um business case que inclua documentação de segurança, especificidades de caso de uso e instituições comparáveis que já a adotaram. Defensores internos que conseguem articular os controles de risco junto com o benefício de produtividade avançam mais rápido do que puro entusiasmo.
Ferramentas de IA Internas: O Caminho Melhor
A resposta real não é um jeito mais seguro de usar uma ferramenta comercial externa. É um modelo que roda onde os dados já estão. A versão gratuita está mais perto do que a maioria imagina. Modelos de pesos abertos servidos localmente com Ollama ou llama.cpp não custam nada além do hardware que você já tem, não fazem nenhuma chamada de rede, e são bons o suficiente para boilerplate, explicações e escrita de testes, que de qualquer forma são a maior parte do uso diário. Você consegue provar a ideia em um notebook antes de alguém assinar um contrato, e uma demo local funcionando é um argumento muito melhor numa conversa de procurement do que um slide.
A versão paga é a mesma ideia com as GPUs de outra pessoa e um contrato assinado: um deploy gerenciado dentro da sua própria tenancy de nuvem, onde prompts e outputs ficam dentro do perímetro da organização. Nos dois casos a troca é a mesma. Esses modelos são mais fracos que os de fronteira que você usa pessoalmente, e você pode dar a eles o contexto completo. Um modelo mais fraco com o problema real na frente dele vence um modelo mais forte para o qual você teve que abstrair tudo.
Se você pode influenciar a decisão, defenda o deploy que você controla em vez da assinatura que você não controla. A lacuna de capacidade diminui a cada poucos meses. A lacuna de compliance não.
Como a Produtividade Se Parece na Prática
Dadas todas as restrições, como é meu fluxo de trabalho real aumentado por IA no trabalho? No BMO, o time usa um assistente aprovado, o GitHub Copilot Business, que eu configurei com guardrails. Dentro desse setup, uso IA para aproximadamente essas coisas, aproximadamente nesta ordem de frequência:
- 1. Gerar boilerplate de componentes e serviços a partir de specs sanitizadas. É aí que a economia de tempo é mais óbvia
- 2. Escrever casos de teste a partir de comportamento descrito. O padrão de prompt orientado a cenários que uso me dá a maior parte dos casos de teste úteis sem nenhum código sensível
- 3. Explicar APIs desconhecidas ou internos do Angular que encontro em código existente
- 4. Rascunhar descrições de PR a partir de diffs sanitizados
- 5. Refatorar versões abstratas de problemas de performance. E depois aplicar o padrão manualmente ao código real
Eu não uso IA para: nada que toque autenticação, nada que exigiria compartilhar schemas internos, nenhuma tarefa onde o contexto em si é sensível. Para essas, trabalho da forma tradicional. Que ainda é perfeitamente rápida quando você tem mais de uma década de experiência.
Existe uma tensão óbvia em tudo isso e é a primeira coisa que um leitor atento deveria perguntar. Se nada interno vai para uma ferramenta de IA, o que um assistente de IDE está fazendo com o repositório aberto na frente dele? Não são o mesmo canal. O Copilot Business lê o workspace aberto sob contrato: prompts e sugestões não são retidos e não são usados para treinar modelos, e administradores podem excluir caminhos para que o assistente nunca os veja. Esse é um canal revisado e com registro. Uma janela de chat de consumo não é. A disciplina de abstração deste post é sobre o segundo canal e sobre tudo que o contrato não cobre. O primeiro é governado pela lista de exclusão de conteúdo e por quais repositórios têm a licença ligada, e se você não sabe o que está nessa lista de exclusão para o seu próprio repositório, é isso que você deve ir descobrir hoje.
O Lado Cultural: Atitudes dos Colegas
Uma coisa que eu não esperava é o quanto as atitudes em relação a ferramentas de IA divergem dentro de uma organização grande. Ceticismo é comum, às vezes sobre a qualidade do resultado e às vezes sobre risco de dados, e as duas versões são posições razoáveis defendidas por bons desenvolvedores. O que mais me surpreendeu é quanta gente trata isso como binário: ou a ferramenta está aprovada para tudo ou está proibida por completo. Não é nem uma coisa nem outra. A conversa útil só começa depois que essa suposição sai do caminho.
Tento sustentar uma posição específica: entusiasmado com a produtividade, rigoroso com as restrições e vocal por ferramental interno melhor. Não sou a pessoa dizendo aos colegas o que eles não podem usar. Sou a pessoa dizendo: é assim que se usa isso para que não vire seu problema daqui a seis meses.
O Que Eu Diria ao Meu Eu do Passado
Se pudesse dar um conselho a alguém entrando em uma grande instituição financeira com mentalidade favorável a IA: não chegue esperando encaixar seu fluxo de trabalho pessoal diretamente. As ferramentas que você ama fora do trabalho podem não estar aprovadas. Os dados que normalmente daria como contexto estão fora dos limites. Isso é real, e se ajustar leva tempo.
Mas as habilidades subjacentes de engenharia de prompts, saber o que perguntar e como estruturar a pergunta, são totalmente transferíveis. Você apenas as redireciona. Em vez de fazer prompt com contexto completo, você aprende a fazer prompt com abstrações precisas. Em vez de obter uma solução completa, você obtém um padrão estrutural que aplica com seu conhecimento interno. É um ritmo diferente mas não menos produtivo. Uma vez que você se ajusta.
A restrição não é inimiga da produtividade. A restrição é o parâmetro em torno do qual você projeta. Engenheiros fazem isso todos os dias.
Referências
- Ollama, para rodar modelos de pesos abertos localmente. https://ollama.com
- Azure OpenAI Service. https://azure.microsoft.com/en-us/products/ai-services/openai-service
- AWS Bedrock. https://aws.amazon.com/bedrock/
- PIPEDA. https://www.priv.gc.ca/en/privacy-topics/privacy-laws-in-canada/the-personal-information-protection-and-electronic-documents-act-pipeda/