Dois casos fictícios e IA Builder no banco inteiro

Os casos do Banco Ipê e da Trilha são fictícios, montados só com material público e com o mapa do BIAN 14.0 como referência funcional. Nenhum dos dois descreve a arquitetura interna de um banco real. Isso importa porque o exercício aqui é técnico: separar registro, decisão, contrato, evento e responsabilidade operacional.

No Banco Ipê, o problema é comum: a política de crédito está escrita dentro da esteira. Mudar um corte de score exige versão nova do sistema. O core de empréstimos funciona e fica. O objetivo é mudar a política sem tocar no contrato nem no core.

Na Trilha, a dor é outra. Cinco módulos vivem no mesmo código e no mesmo banco: cadastro, conta pré-paga, Pix, antifraude e financeiro. O mapa mostra dezessete domínios, mas isso não significa criar dezessete microsserviços. Significa enxergar as costuras antes de escolher a ordem do corte.

A lição de fechamento é simples: BIAN não decide por você. Ele reduz ambiguidade. A decisão continua sendo sua, com risco, sequência e custo de operação na mesa.

O heatmap do Ipê preserva o que não precisa mudar: Session Dialogue, Party Lifecycle Management, Credit Risk Models, Customer Credit Rating, Consumer Loan e Disbursement. Compra o que não diferencia: Document Services, Correspondence e Collateral Asset Administration. Constrói onde a política e a experiência importam: Customer Offer e Underwriting. A esteira legada é aposentada no fim, não no começo.

O fluxo alvo fica mais legível. Customer Offer orquestra e guarda só o estado da oferta. Customer Credit Rating, no padrão Monitor, responde o score com versão do modelo. Underwriting decide com política versionada fora do código. Consumer Loan, no padrão Fulfill, cria o contrato no core por um adaptador. Disbursement, no padrão Transact, libera de forma idempotente. Financial Accounting, no padrão Track, lança.

O caminho oficial v14 usado no caso é POST /Underwriting/Evaluate. O cabeçalho Idempotency-Key e o campo PolicyVersion são do caso, não do BIAN. Essa distinção evita um erro silencioso: tratar uma convenção local como se fosse semântica oficial.

A migração segue cinco fases: fachada no pedido, eventos espelho, decisão em sombra, novo decide quando a divergência está explicada, esteira desligada. Sombra aqui quer dizer decidir em paralelo sem efeito no cliente, para comparar decisão antiga e nova antes de trocar o dono da resposta.

A Trilha tem um monólito com cadastro, conta pré-paga, Pix, antifraude e financeiro no mesmo código e banco. O mapeamento em v14 fica assim: cadastro usa Party Reference Data Directory, Party Lifecycle Management e Party Authentication. Conta usa Current Account, Position Keeping e Issued Device Administration. Pix usa Payment Order Initiation, Payee Management, Payment Orchestration, Payment Confirmation, Payment Rail e Payment Settlement. Antifraude usa Fraud Evaluation, Fraud Diagnosis e Fraud Resolution. Financeiro usa Financial Accounting e Regulatory Reporting.

A ordem do corte não vem do número de domínios. Vem do risco. Primeiro cadastro, porque todos escrevem nele. Depois antifraude, porque tem dono e ritmo próprios. Depois financeiro, porque recebe eventos sem tocar no fluxo do cliente. Pix fica por último, porque é fluxo de 24 horas e tolera menos experimento.

Antes de cada corte, entram eventos espelho com nomes claros: PartyReferenceDataDirectory.Reference.Updated, CurrentAccount.AmountBlock.Initiated, CurrentAccount.DebitandCredit.Executed, PaymentOrderInitiation.OrderInitiation.Initiated e FraudEvaluation.Models.Evaluated. Essa forma é minha, usando domínios e qualifiers oficiais para dar disciplina ao contrato.

A Lei 12.865/2013, art. 12, muda o desenho: recursos em conta de pagamento são patrimônio separado. Para a arquitetura, o saldo do cliente tem um dono só e nenhum serviço novo mantém saldo paralelo.

O laço de IA Builder fecha o curso porque ele força uma disciplina: a IA rascunha, o código valida, o arquiteto decide. O arquiteto pede o mapeamento. O agente busca nas fichas v14 indexadas com versão fixada. Ele propõe domínio, padrão e trecho da ficha. O validador usa lista fechada: fora da lista rejeita; obsoleto rejeita e devolve o substituto anunciado quando existe, como Payment Order para Payment Confirmation; novo sem status passa marcado como novo. Depois vem checagem de grounding, e a decisão entra no ADR.

Amazon Bedrock Guardrails, no contextual grounding check, mede duas coisas: grounding, se a resposta está apoiada na fonte, e relevância, se responde à pergunta. O limiar é configurável de 0 a 0,99. Ele precisa de fonte, pergunta e conteúdo. Pega justificativa inventada, mas não pega nome certo de versão errada se a fonte indexada for a errada. Também não decide escopo de norma.

Os modos de falha da parte 2 são práticos: cenário oficial com linha de vida obsoleta, falso amigo como Suitability Checking, nomes parecidos com status diferentes como Direct Debit e Direct Debit Collection, domínio inventado para conceito local como KYC, boleto ou conta-salário.

LGPD art. 20 trata revisão de decisão automatizada, inclusive perfil de crédito. Circular 3.978 art. 44 lembra que análise de lavagem não se terceiriza. A IA apoia o analista, com trilha. Ela não substitui responsabilidade.