Desenvolver vs. Comprar: Agentes de IA para Operações de Risco Reguladas

Última atualização: Setembro de 2026

Desenvolver internamente ou comprar soluções de agentes de risco de IA quase sempre é debatido sob o ponto de vista de custo, e essa é a pergunta errada para começar. Um protótipo que lê um alerta, busca o histórico do cliente e escreve uma recomendação de decisão pode ser criado em uma semana, e, assim que sua equipe o vê funcionar, comprar parece o mesmo que pagar por algo que você já provou que é capaz de fazer. O que o protótipo não mostra é a parte que nunca acaba: a avaliação contínua, o desvio que você precisa detectar, as alterações manuais feitas por analistas que você precisa registrar, a documentação que precisa sobreviver à saída de quem a escreveu e uma estrutura regulatória que mudou em abril e mudará novamente. Essas obrigações existem em ambas as opções. A decisão é sobre quem será o responsável por cada uma delas daqui a três anos.

TL;DR

• O protótipo não é a questão central da sua decisão. Desenvolver um agente é barato se comparado a mantê-lo funcionando em uma fila de alertas regulamentada.

• Seis obrigações duram muito mais que o protótipo: avaliação contínua, detecção de desvio, registro de alterações de analistas, documentação de risco de modelos, mudanças regulatórias e suporte de plantão. A compra transfere algumas delas. Mas nunca transfere todas.

• A obrigação que mais define a escolha é o desafio independente. Se você desenvolver o agente, a equipe que o criou não pode ser a mesma a questioná-lo com credibilidade.

• O desenvolvimento interno é a escolha certa mais vezes do que o site de um fornecedor costuma admitir, e a preocupação de ficar preso a um sistema proprietário (lock-in) ao comprar é um problema real, e não uma mera formalidade de compras.

• Esta página não traz números de custos para nenhuma das opções, porque não existe um valor confiável. Cada afirmação de custo aqui é estrutural: identifique a obrigação e, depois, quem é o responsável por ela.

Quem mais defende a compra também sabe desenvolver internamente

O argumento mais forte que ouvimos este ano contra o desenvolvimento interno de um agente de risco veio de um diretor de gestão de fraudes em uma empresa global de pagamentos, cuja equipe passa o tempo todo criando a própria infraestrutura de dados.

Quando os colegas insistem para que ele desenvolva internamente, ele argumenta contra. "Eles tentam me convencer de que devemos construir nós mesmos, e eu faço o possível para convencê-los do contrário", disse ele, "porque somos muito bons em certas coisas. Somos ótimos em mover dados, é isso que fazemos. Movemos dinheiro, que são apenas dados, APIs, orquestrações e tudo mais. Desenvolvemos esse tipo de coisa o tempo todo para todas as nossas áreas."

A objeção dele é sobre competência, não capacidade. Ele sabe exatamente no que sua equipe é boa e o que foge do escopo dela. Ele também já desenvolveu internamente: a infraestrutura de prevenção à fraude que ele opera hoje é uma camada de orquestração desenhada por sua própria equipe, e funciona. A maior parte do que explicamos a seguir vem da experiência dele, pois um sistema próprio que funciona ensina muito mais sobre o custo real do desenvolvimento do que um projeto que falhou.

O que "desenvolver vs. comprar" significa especificamente para um agente de risco

Um banco deve desenvolver internamente ou comprar agentes de risco de IA? Desenvolver internamente significa assumir a responsabilidade pelo agente e por tudo o que vem depois dele: o programa de avaliação, o monitoramento, o histórico de alterações, a documentação do modelo, o plantão de suporte e a resposta que você dará a um auditor que questionar o motivo de uma decisão ter sido tomada daquela forma. Comprar significa transferir algumas dessas obrigações para um fornecedor e manter o resto — e nenhum fornecedor assume tudo. Em um setor regulado, a decisão real não é se os seus engenheiros conseguem construir a ferramenta. É saber o nome da pessoa que responderá por cada obrigação daqui a três anos e se ela ainda conseguirá justificar essas decisões.

Essa mudança de perspectiva é importante porque a versão corporativa genérica de "desenvolver vs. comprar" (aquela escrita para uma ferramenta de processamento de documentos ou um assistente de suporte) foca apenas no custo de desenvolvimento e no tempo de lançamento no mercado. Um agente de risco atua em decisões que a sua instituição precisa defender. O custo que realmente define a escolha é o custo de defender essa decisão repetidamente, por anos, sob regras que ainda estão sendo escritas.

Há algo que deixamos de fora aqui de propósito. Os critérios e métricas pelos quais você deve avaliar um agente são uma etapa anterior e um assunto à parte: veja como avaliar um agente de risco de IA. Esta página parte do princípio de que você já sabe como é um bom desempenho e está apenas decidindo quem vai construir a solução.

O que o protótipo não mostra

Um protótipo prova que o agente consegue gerar uma boa recomendação uma vez. A produção exige que ele continue gerando boas recomendações em dezoito meses, e que você consiga provar como chegou a elas. É aí que surgem seis obrigações que não aparecem durante uma demonstração comercial.

Avaliação contínua. A avaliação que validou o protótipo foi pontual, com uma amostragem selecionada. A avaliação em produção é um programa contínuo, com um responsável, uma frequência definida, um conjunto de dados de teste que se mantém representativo conforme seu volume muda, e um registro de cada resultado.

Detecção de desvios. Os padrões de fraude mudam, o perfil dos seus clientes muda, e um agente ajustado com os dados do ano passado deixa de funcionar bem silenciosamente. Detectar isso é uma tarefa; decidir o que acontece quando o desvio é detectado e quem pode pausar o agente é outra tarefa bem mais difícil. Escrevemos sobre o funcionamento disso separadamente em monitoramento de agentes de IA para detecção de desvios.

Registro de alterações manuais. Quando um analista discorda do agente e altera a decisão, essa discordância é o sinal mais valioso que o sistema gera. Mas isso só serve como sinal se for registrado como um evento com um motivo justificado. Se for registrado apenas como uma edição de campo comum, você perde essa informação.

Documentação de risco de modelos. Histórico de versões, decisões de treinamento, resultados de avaliações, limitações conhecidas e a justificativa para cada alteração. O teste real é saber se a documentação ainda responde às dúvidas depois que o engenheiro que criou o agente saiu da empresa.

Mudança regulatória. Em 17 de abril de 2026, o Federal Reserve, o FDIC e o OCC emitiram juntos novas diretrizes sobre gestão de risco de modelos (SR 26-2 no Federal Reserve, Bulletin 2026-13 no OCC e FIL-15-2026 no FDIC). A carta do Fed afirma que ela "substitui a carta SR 11-7" e o pronunciamento conjunto de 2021 sobre o risco de modelos para sistemas BSA/AML. Qualquer item na sua documentação de governança que ainda mencione as normas antigas precisa ser reescrito. Os órgãos reguladores também informaram que planejam solicitar informações sobre o uso de IA pelos bancos, algo que ainda não aconteceu. Isso mudará o cenário novamente quando for lançado.

Plantão de suporte. Um agente que trabalha em uma fila de alertas ao vivo é infraestrutura de produção. O telefone de alguém vai tocar às 3h da manhã se o sistema parar de responder, e essa pessoa precisa conhecer tanto o sistema quanto o impacto de risco de deixá-lo fora do ar.

Abaixo está a mesma lista em formato de tabela de decisão. O exercício útil aqui não é apenas ler, mas escrever o nome de um responsável em cada célula considerando a realidade da sua instituição.

Nenhuma linha desta tabela fica vazia em nenhuma das opções. Esse é o ponto central.

A obrigação decisiva: desafio independente

As diretrizes atualizadas mantêm o conceito de "desafio eficaz" e são bem específicas sobre quem pode realizá-lo. O documento SR 26-2 descreve isso como "a análise crítica conduzida por especialistas objetivos que avaliam o risco do modelo e realizam as alterações apropriadas ao longo de todo o ciclo de vida do modelo", executada por "indivíduos com a especialização adequada para realizar um questionamento crítico e objetivo, independência suficiente para manter a objetividade, além de relevância e influência organizacional para realizar qualquer mudança".

Pense nisso como três condições: especialização, independência e autoridade para realmente mudar algo. Agora, aplique isso ao desenvolvimento próprio. As pessoas que conhecem o agente bem o suficiente para questioná-lo são as mesmas que o criaram, o que quebra a condição de independência. Sendo assim, desenvolver um agente internamente exige contratar e alocar tanto a equipe que o cria quanto a equipe que o audita, sob diretorias diferentes, com conhecimento suficiente para debater com os desenvolvedores e autoridade para pará-los se necessário. A compra não elimina essa obrigação, mas coloca a especialização e a independência em organizações distintas por padrão, o que é muito mais fácil de comprovar para a auditoria.

Duas ressalvas importantes, pois esse argumento pode ser exagerado. As diretrizes revisadas deixam a IA generativa e os agentes de IA fora do seu escopo direto: o boletim do OCC afirma que "modelos de IA generativa e agentes de IA são novos e evoluem rapidamente. Portanto, não estão no escopo destas diretrizes", e a norma SR 26-2 confirma que as regras se aplicam a "modelos estatísticos e quantitativos tradicionais e modelos de IA não generativos e não baseados em agentes". O "desafio eficaz" é, portanto, uma boa prática que vale a pena adotar, não uma regra obrigatória para o seu agente. As diretrizes também dizem que as regras devem ser "mais relevantes para organizações bancárias com mais de US$ 30 bilhões em ativos totais", e "mais relevante para" não significa "aplicável apenas a".

A revisão regulatória também restringiu a definição de modelo para "um método, sistema ou abordagem quantitativa complexa que aplica teorias estatísticas, econômicas ou financeiras para processar dados de entrada em estimativas quantitativas". Uma área de risco que roda um motor de regras, um modelo de pontuação e um agente agora tem três componentes em três lugares diferentes dentro de um mesmo framework de governança. Não dá para assumir que uma única estrutura de controle atende a todos os três, e esse trabalho de mapeamento é seu, independentemente de quem escreveu o código. Nosso artigo detalhado sobre governança está em governando agentes de risco de IA.

O custo real de desenvolver internamente, segundo quem já fez

Ao ser questionado sobre a dificuldade de fazer a orquestração internamente, a resposta do diretor de fraudes foi direta: "é mais desafiador do que eu imaginava".

Ele explicou exatamente onde está a dificuldade, e não é no modelo de IA em si. "O desafio é o enriquecimento dentro dessa camada de orquestração, devido ao volume de trabalho necessário para enriquecer dados, ou seja, trazer dados de várias fontes para uma única plataforma de decisão. Com certeza há grandes desafios aí." Em seguida, vale citar a fala dele na íntegra, pois é uma visão realista e não um relato de fracasso: "Não é nada que não possa ser resolvido com recursos e tempo, mas essas são duas coisas difíceis de conseguir."

Essa é a realidade dos custos de desenvolvimento de agentes de IA em uma área de risco. Não é impossível. Mas exige uma dedicação constante de dois recursos escassos, enquanto a demanda por novas análises não para de crescer. Pergunte a ele quando o sistema unificado estará pronto e a resposta é uma brincadeira com um fundo de verdade: "temos um ponto único de integração para todos os nossos processos internos que espero ver funcionando antes de eu morrer. Somos uma empresa grande, que cresceu muito por aquisições. Então, provavelmente temos umas 30 plataformas diferentes na fila esperando para serem integradas ao sistema unificado de fraudes."

Comprar também não livra você do trabalho de organização de dados. Um diretor de P&D em uma plataforma global de pagamentos, listando os maiores desafios de uma implementação ativa, colocou a carga de dados históricos em segundo lugar: "a carga de dados históricos, que é algo mais estratégico do que tático no momento." Um agente que analisa o relacionamento com o cliente precisa do histórico desse relacionamento, e mover esses dados é um trabalho estratégico em qualquer uma das opções.

Uma nota sobre o custo total de propriedade (TCO). Esta página não apresenta valores de custos. Não existe um número único e confiável que possamos publicar para estimar o custo de desenvolvimento ou manutenção de um agente de risco interno. Se um fornecedor apresentar uma planilha pronta de TCO de IA para ajudar na sua decisão, questione a origem de cada dado e as premissas usadas. A maioria desses modelos de custo é criada de trás para frente para chegar ao resultado que o fornecedor deseja mostrar.

Quando desenvolver internamente faz sentido

Desenvolver internamente é frequentemente a melhor opção, e cinco situações tornam essa escolha óbvia.

O agente é o seu produto principal, ou inseparável dele. Se as suas regras de risco são o que os clientes compram, ou são o que viabiliza a sua precificação, terceirizar isso significa terceirizar a sua margem de lucro.

Você já gerencia muito bem a sua camada de dados e o agente é apenas um pequeno complemento. Essa é a situação do diretor de fraudes mencionado, e é o argumento mais forte para o desenvolvimento interno. A parte cara de um agente de risco é ter dados limpos, enriquecidos e atualizados em um só lugar. Se você já resolveu essa parte, o trabalho restante é pequeno, e pagar um fornecedor para refazer algo que já funciona é desperdício de dinheiro.

A concentração de fornecedores é o próprio risco que você está gerenciando. Se uma parte crítica das suas decisões de risco já passa por um provedor externo, adicionar outra dependência a esse mesmo parceiro é uma decisão de concentração de risco antes de ser uma decisão tecnológica, e deve ser avaliada por quem gerencia riscos de terceiros.

Nenhum produto atende ao seu fluxo e a diferença é estrutural. Produtos inovadores, regras regulatórias muito específicas ou jornadas de clientes fora do comum geram requisitos que os produtos de prateleira dos fornecedores não vão cobrir. O teste aqui é avaliar se o que falta é apenas uma funcionalidade ou se a estrutura necessária é totalmente diferente. Se for apenas uma funcionalidade, vale conversar com o fornecedor. Se a estrutura for diferente, desenvolva internamente.

Você tem equipe para auditar o projeto de forma independente. Se você não puder fazer isso, a sua escolha não é entre desenvolver ou comprar. É entre ter um desenvolvimento interno que você consegue defender para os reguladores e outro que você não consegue.

O problema de ficar preso ao fornecedor (lock-in) na prática

O argumento mais forte contra a compra veio do mesmo diretor de fraudes, e merece ser lido em suas próprias palavras em vez de resumido.

"Eu olho para o risco além do risco de fraude. Também preciso considerar o risco de fornecedores e a exposição ao mercado. Para mim, era fundamental manter o controle sobre as conexões reais do sistema, garantindo que nenhum fornecedor fosse implementado de forma a não poder ser substituído. Se você integra todos os seus sistemas a um único fornecedor, você fica preso. Não há como mudar de rumo rápido. Você acaba em um casamento indesejado com um parceiro externo."

Perguntado diretamente sobre o que a empresa dele acharia de adotar uma plataforma como a nossa, ele foi bem claro: "Do ponto de vista de negócios, é uma decisão de alto risco."

Ele tem razão, e a resposta honesta não é negar isso. É criar um teste contratual antes de assinar. Como funciona o processo de saída? Você consegue extrair seus dados, histórico de avaliações e alterações de analistas de forma simples, por conta própria, sem precisar contratar um serviço extra do fornecedor? As conexões do sistema são suas, de forma que trocar um componente não exija refazer toda a estrutura? Existe uma obrigação contratual de entrega da documentação do modelo? Um fornecedor que não responde a essas perguntas por escrito é exatamente o parceiro que ele descreveu.

A resposta estrutural para isso é que a camada de agentes não precisa controlar todo o sistema. Os agentes da Oscilar podem rodar integrados à nossa plataforma completa ou como uma camada independente sobre a sua estrutura atual, o que mantém a orquestração e as conexões onde elas já estão. Isso não elimina o risco de fornecedor, mas muda o custo de substituição dele, que é o que o diretor de fraudes busca proteger.

A solução híbrida: o caminho que a maioria das instituições escolhe

A maioria das equipes de risco em setores regulados não escolhe apenas desenvolver ou comprar. Elas ficam no meio do caminho, e as boas soluções híbridas compartilham uma característica: a divisão segue as obrigações reais do processo, e não as divisões do organograma.

Três formatos são comuns: Comprar a camada de inteligência e manter as conexões de dados, que é parecido com o que o diretor de fraudes criou, mas com a camada de decisão comprada pronta em vez de desenvolvida internamente. Comprar para as filas de alertas comuns e desenvolver para o fluxo exclusivo, o que funciona muito bem quando uma parte do negócio é única e o restante segue o padrão do mercado. Comprar a plataforma e desenvolver a avaliação internamente, mantendo o controle sobre a validação do funcionamento do agente dentro da própria instituição.

O modelo híbrido também tem custos. Dois modelos de governança significam duas documentações, duas rotinas de avaliação e uma divisão de responsabilidades que precisa ser muito bem definida. Áreas sem dono são onde os incidentes costumam acontecer. O que torna o modelo híbrido seguro e justificável é a capacidade de apontar, para cada obrigação da tabela anterior, de qual lado da linha ela está e por quê.

Como conduzir essa decisão

O melhor método que já vimos não foi uma planilha de pontuação complexa. O responsável pela avaliação de desenvolvimento vs. compra para a área de crédito e cobrança em uma fintech organizou a decisão em três documentos simples.

1. Uma especificação do projeto interno. "Um documento de requisitos detalhando o que seria necessário para que as nossas ferramentas internas atendessem às nossas necessidades específicas."

2. Um documento de comparação com o mercado. "Tudo o que os fornecedores já entregam pronto", listado ao lado das mesmas necessidades especificadas.

3. Uma comparação de alocação de recursos. "Quanto da nossa equipe interna precisamos para desenvolver tudo o que está na nossa lista de desejos versus quanto vai custar apenas assinar um contrato e integrar uma solução que já tem tudo isso pronto?"

E então, a frase que deve mudar a sua forma de planejar isso sobre a comparação de custos: "Não acho que essa discussão de custos seja a mais difícil. O mais complexo é responder à pergunta: já temos 20 ferramentas diferentes, por que precisamos da ferramenta número 21?"

A discussão de custo é a parte fácil. A parte difícil é a consolidação. Se você está defendendo a compra, a maior parte da sua preparação deve focar em mostrar por que isso não será apenas mais um sistema isolado: quais ferramentas atuais ele vai substituir ou integrar, em qual tela o analista vai trabalhar e como será o dia a dia dele após a mudança. Uma recomendação de compra baseada apenas em preço perderá força diante da objeção de "mais uma ferramenta", e com razão.

Outros dois pontos para planejar: o processo de avaliação da compra tem etapas claras que você pode exigir de qualquer fornecedor, funcionando como um bom teste para saber se eles têm experiência prática: preparação dos dados, teste histórico (backtest) com seus alertas antigos, execução em modo de teste (shadow) paralelo ao trabalho dos analistas e uma apresentação dos resultados antes de colocar qualquer coisa em produção. Exija essas quatro fases. Além disso, saiba quem é o público-alvo da decisão. Na mesma conversa que tivemos: "Nossa equipe técnica prefere comprar a desenvolver. Só precisamos alinhar essa recomendação com a diretoria." A equipe técnica geralmente já tomou a decisão. O que eles precisam agora é de argumentos sólidos que convençam a diretoria, o que exige um documento diferente de uma simples análise técnica.

Onde esse modelo de decisão falha

Quatro limites importantes para tudo o que foi dito acima:

Esta página não apresenta valores de custos. Essa é uma limitação real, não por discrição. Qualquer análise de desenvolvimento vs. compra precisa de números reais, e os seus terão que vir do planejamento de pessoal da sua própria empresa, não de um artigo de internet.

O único resultado prático que podemos citar é específico. Um banco em produção mostra 92% de concordância do agente de IA com a equipe de analistas nas decisões de alertas, e uma redução de 75% no tempo de análise por caso. Esse é o resultado de uma implementação real em uma área de risco específica e não deve ser usado como uma promessa de resultado para outras instituições.

Nenhuma das opções resolve a definição dos critérios de sucesso. Decidir o que significa um agente "funcionar bem" e quais dados comprovam isso é uma tarefa que deve ser feita antes de decidir entre desenvolver ou comprar, e não fica mais fácil em nenhuma das duas escolhas.

A escolha de desenvolver versus comprar também não é permanente. O limite entre as duas opções muda conforme sua estrutura de dados evolui, novos produtos são lançados e pessoas mudam de cargo ou saem da empresa. Encare a decisão como algo reversível e planeje o processo de saída desde o início, independentemente do caminho escolhido.

Perguntas frequentes

Um banco deve desenvolver internamente ou comprar agentes de risco de IA?

Desenvolva internamente quando o agente for inseparável do seu produto principal, quando sua estrutura de dados já for forte o suficiente para que o agente seja apenas um pequeno complemento, quando a concentração de fornecedores for um risco crítico sob gestão, ou quando o fluxo de trabalho for estruturalmente único. Compre quando precisar de avaliações, monitoramento e documentação prontos para auditoria mais rápido do que conseguiria estruturar com equipe própria, e especialmente se não tiver recursos para uma equipe de auditoria independente da equipe de desenvolvimento. De qualquer forma, as obrigações regulatórias continuam sendo suas.

Como avaliar o desenvolvimento vs. compra para uma solução de IA?

Escreva três documentos: a especificação técnica do projeto interno, um documento comparativo com o que cada fornecedor já entrega pronto e uma comparação direta de alocação de equipe e custos. Depois, responda ao desafio da consolidação de ferramentas, pois um argumento de compra baseado apenas em custo costuma falhar diante da objeção de que a empresa já tem sistemas demais.

Quando uma equipe deve desenvolver um agente de IA em vez de comprar?

Desenvolva quando você já domina a parte difícil. O trabalho caro em um agente de risco é o enriquecimento e a integração de dados de várias fontes em uma única plataforma de decisão; uma equipe que já resolveu isso gastará muito pouco desenvolvendo apenas a camada de inteligência por cima. Desenvolva também se a diferença entre suas necessidades e os produtos do mercado for estrutural, e não apenas uma funcionalidade ausente.

Quanto custa desenvolver um agente de risco de IA internamente?

Não há um valor de mercado de referência, e esta página não traz estimativas de preço. O que os especialistas relatam é o perfil do custo: enriquecimento de dados de várias origens, fila de projetos internos que não diminui e uma demanda contínua de horas de engenharia. Um diretor de fraudes que desenvolveu um sistema interno estimou a data de conclusão de todas as integrações como "algum momento antes de eu morrer".

O que precisa ser mantido depois que o protótipo funciona?

Seis pontos essenciais: avaliação contínua, detecção de desvios com plano de ação, registro de alterações manuais como dados estruturados, documentação de risco de modelos que continue útil após a saída dos autores, acompanhamento de mudanças regulatórias e escala de plantão técnico. Nenhum desses itens aparece em uma demonstração comercial, mas todos precisam de um responsável desde o primeiro dia de operação real.

Quem é o responsável pela documentação de risco de modelos se desenvolvermos o agente internamente?

Você, totalmente, incluindo o histórico de versões, resultados de avaliações, limitações conhecidas e justificativas de mudanças. Se comprar, o fornecedor envia as especificações do modelo e você cuida de como encaixá-las na sua governança. O teste ideal em ambos os casos é saber se a documentação responde de forma clara às perguntas de um auditor após a saída de quem a escreveu.

Um agente de risco de IA comprado pode funcionar integrado aos sistemas de risco que o banco já possui?

Sim, e vale a pena confirmar isso em contrato antes de fechar o negócio. Os agentes da Oscilar podem rodar como uma camada independente sobre a infraestrutura que você já tem ou como parte da nossa plataforma unificada. Assim, comprar a camada do agente não exige que você troque seu sistema de orquestração ou os parceiros atuais. A pergunta fundamental para qualquer fornecedor é se as conexões de dados continuarão sob seu controle.

Como funcionam a revisão humana, a auditabilidade e a governança de desempenho do agente em cada opção?

Em ambas as opções, a governança é de responsabilidade da instituição. A posição oficial da Oscilar é de que os agentes nunca encerram ou escalam alertas de forma autônoma; cada recomendação é revisada e confirmada por um analista humano antes de qualquer ação, com um histórico completo de auditoria mostrando os dados de entrada, o raciocínio do agente e a decisão final. Se desenvolver internamente, você precisará construir esse mesmo histórico de auditoria por conta própria, garantindo que o regulador veja exatamente onde as decisões humanas são tomadas.

Por onde começar

Pegue a tabela de obrigações acima e escreva o nome de um responsável em cada célula para as duas colunas, pensando na realidade da sua instituição. Esse exercício leva uma tarde e costuma definir a decisão, pois uma das colunas geralmente apresentará linhas que ninguém consegue preencher. Essa será a sua resposta, muito mais realista do que qualquer simulação de custos.

Duas etapas seguintes: se você ainda não sabe quais métricas usará para avaliar o desempenho do agente, essa definição deve vir primeiro e é tratada em outro artigo. E quais metas de acerto um projeto piloto precisa atingir antes de ser aprovado é outra decisão importante, que abordaremos em breve.

Se a coluna de compra for a que apresenta mais dúvidas, a forma mais rápida de resolvê-las é pedir para o fornecedor executar as quatro fases com seus próprios dados: preparação, teste histórico, modo shadow e apresentação de resultados. Veja como os agentes de risco da Oscilar são desenhados para rodar integrados aos analistas e sistemas que você já utiliza, e traga a tabela de obrigações para a nossa primeira conversa.