Operar com um único fornecedor de biometria retira da operação dois ativos que só existem com concorrência ativa: dado de comparação em produção e posição real de negociação na renovação do contrato. Sem os dois, avaliação de desempenho e decisão de preço dependem do que o fornecedor atual escolhe reportar.

Esse texto explica quando a dependência de fornecedor único vira risco operacional, como estruturar a operação paralela, o que medir, qual é o esforço de engenharia esperado e como migrar a base de faces para o novo provedor.

Quando a dependência de fornecedor único vira risco operacional?

A dependência vira risco quando não há dado independente para contestar o que o fornecedor reporta. O risco raramente aparece em um incidente grave. Aparece em ajustes silenciosos: uma versão de SDK (kit de desenvolvimento do fornecedor) que altera o comportamento do liveness — detecção de vivacidade biométrica — sem aviso com antecedência suficiente; um aumento de preço na renovação porque não há alternativa ativa sendo testada; uma degradação de API que derruba a taxa de sucesso por algumas horas com SLA (acordo de nível de serviço) vago.

Cada evento desses é gerenciável isoladamente. O problema é que, sem dado de referência de um segundo fornecedor processando o mesmo tráfego, nenhum deles pode ser avaliado com precisão.

Gestor de fraude e time de produto enfrentam versões diferentes desse problema. Para fraude: diante de uma nova técnica de ataque, como avaliar se a proteção do fornecedor atual é suficiente ou se outro provedor oferece uma resposta mais eficaz? Para produto: se a taxa de rejeição subir dois pontos percentuais depois de uma atualização, como identificar se a causa foi o fornecedor ou uma mudança no fluxo?

Sem operação paralela, as duas perguntas dependem de dado fornecido pelo próprio fornecedor que está sendo avaliado.

O que um segundo provedor gera que redundância pura não gera?

A distinção importa para quem aprova orçamento. Redundância passiva — um fornecedor inativo esperando o primeiro falhar — é difícil de justificar porque não gera retorno enquanto o sistema funciona. Um segundo fornecedor ativo, mesmo recebendo uma fração do tráfego, gera o que redundância não gera: dado de comparação em condição real de produção.

Com tráfego paralelo, é possível responder perguntas que hoje dependem de benchmark de laboratório ou de word of mouth do mercado: qual é a diferença de taxa de rejeição entre os dois fornecedores no meu fluxo, com o meu público? Qual responde melhor a mudanças de iluminação ou de dispositivo? Qual tem tempo de resposta mais estável nos últimos 60 dias?

Esse dado muda a conversa de renovação de contrato. E muda a conversa interna sobre onde vale investir em otimização de fluxo.

Como estruturar a divisão de tráfego?

Existem três modelos. A escolha depende do objetivo imediato.

01

Divisão percentual fixa: uma parte do tráfego (10%, 20%, 30%) vai para o segundo fornecedor; o restante segue no primeiro. É o modelo mais simples de implementar e o mais comparável, porque os dois grupos passam pela mesma jornada. Para que a comparação seja válida, a divisão precisa ser randomizada no nível do request. Sem randomização, diferenças de perfil entre os grupos contaminam o dado.

02

Segmentação por produto ou fluxo: o segundo fornecedor atende uma linha de produto, uma vertical ou um fluxo específico. Um banco que usa biometria no onboarding e na autenticação pós-cadastro pode testar o segundo fornecedor só na autenticação. Reduz o risco de impacto em onboarding e gera dado em um fluxo com volume alto e comportamento distinto do cadastro.

03

Fallback sequencial: o primeiro fornecedor é o primário; o segundo só recebe o request se o primeiro retornar erro ou não responder dentro do timeout configurado. Esse modelo resolve o risco de disponibilidade, mas não gera dado de comparação de qualidade: os requests que chegam ao segundo fornecedor já são, por definição, os que o primeiro falhou em processar. O perfil de transação é diferente e a comparação fica comprometida.

Para quem quer dado de comparação, a divisão percentual fixa com randomização no nível do request é o ponto de partida mais limpo. Para quem quer resolver disponibilidade antes de qualquer outra coisa, o fallback é mais rápido de implementar.

O que medir durante a operação paralela?

O objetivo do período com dois fornecedores é gerar dado suficiente para tomar uma decisão antes do contrato do fornecedor atual entrar em renovação. As métricas que importam nesse contexto:

Taxa de sucesso na primeira tentativa (first attempt success rate): quantas transações chegam a um resultado conclusivo sem retry. Esse número é mais revelador do que a taxa de aprovação final, que pode ser mascarada por retries que o usuário abandona antes de completar.

Taxa de rejeição: quantas transações não chegam a resultado conclusivo. Em produção, isso precisa ser medido por segmento, porque a média agrega comportamentos muito diferentes. Uma taxa de rejeição de 4% pode esconder 12% em usuários acima de 60 anos com dispositivos de entrada.

Tempo de resposta no P90 e P99: o P50 é enganoso. O que importa é o que acontece nas transações mais lentas, onde o abandono é mais provável. Fornecedores com P50 parecido podem ter P99 muito diferentes dependendo da infraestrutura em horários de pico.

Disponibilidade e tempo de recuperação em incidentes: não é só uptime médio. É quanto tempo o fornecedor levou para comunicar e resolver cada degradação no período. Esse histórico precisa estar disponível no SLA ou em status page pública antes de assinar qualquer contrato.

Custo por transação conclusiva: o preço cobrado por request não reflete o custo real da operação. Requests inconclusivos consomem budget sem gerar resultado; o esforço de suporte durante a estabilização raramente entra no cálculo inicial.

Com três meses de operação paralela e volume suficiente por segmento, é possível comparar os dois fornecedores em cada um desses eixos com dado de produção real. Para ter uma referência concreta do que esse dado parece quando existe: o SDK Fortface registra 97,9% de sucesso na primeira tentativa, tempo médio de captura de 4,1s e processamento de backend em até 800ms.

Qual é o esforço de integração com um segundo fornecedor?

A maioria dos times de engenharia subestima o esforço de adicionar um segundo fornecedor porque trata o problema como uma troca de SDK. Não é.

O SDK é a parte mais rápida. O que consome mais tempo está ao redor: a lógica de roteamento que decide qual fornecedor recebe cada request, o sistema de coleta de métricas que registra o resultado de cada transação por fornecedor, os dashboards que tornam os dados comparáveis entre os dois, e os fluxos de retry e fallback que precisam funcionar mesmo quando um dos fornecedores está com latência elevada.

Para um time com experiência em integração de APIs biométricas, a estimativa realista é de quatro a oito semanas de engenharia para colocar o segundo fornecedor em tráfego paralelo com instrumentação adequada. Um SDK bem documentado e com suporte ativo na fase de integração reduz esse número. A ausência de uma camada de abstração no código existente aumenta.

O custo contínuo depois da integração depende principalmente de como o fornecedor entrega atualizações de modelo. Fornecedores que atualizam via configuração ou via API, sem forçar uma nova versão do app, reduzem o esforço de manutenção ao longo do tempo. Esse ponto precisa estar no contrato, não só na documentação técnica.

O que fazer com a base de faces?

A base de faces não é um entrave na decisão de adotar um segundo fornecedor. Dois caminhos técnicos resolvem a migração sem re-enrollment manual dos usuários, e quase todos os clientes têm imagens originais armazenadas.

O primeiro caminho é o tombamento em lote único: as fotos originais armazenadas são usadas para gerar um novo hash biométrico compatível com o novo provedor, em background, sem impacto na jornada do usuário.

O segundo é o enrollment progressivo via API: a cada nova transação ou login, o sistema registra o usuário automaticamente no novo provedor. A base migra dinamicamente, sem ação adicional do usuário e sem necessidade de processamento em lote.

A escolha entre os dois depende do volume de usuários ativos e do prazo disponível para a migração. Em ambos os casos, a portabilidade de imagens originais entre fornecedores exige verificação contratual e aprovação do DPO (Data Protection Officer) — a migração técnica é resolvível, mas a base legal precisa estar mapeada antes de qualquer movimento.

O que perguntar ao segundo fornecedor na avaliação?

Avaliar um segundo fornecedor é diferente de avaliar um primeiro. Quem já tem um fornecedor em produção tem referência real. A comparação deixa de ser abstrata.

Sobre performance em produção: qual é a taxa de rejeição medida em condição real, com qual volume e com qual perfil de usuário? Que parte desse dado está sob NDA e que parte é pública?

Sobre migração da base de faces: o fornecedor suporta tombamento em lote para gerar novo hash biométrico a partir das imagens originais? Também oferece enrollment progressivo via API? Qual é o processo e quais são os requisitos técnicos?

Sobre atualização de modelo: quando o modelo de liveness é atualizado, o cliente é notificado com qual antecedência? A atualização é aplicada de forma automática ou o cliente controla o timing?

Sobre histórico de incidentes: qual é o histórico dos últimos 12 meses? Qual foi o tempo médio entre a degradação e a comunicação, e entre a comunicação e a resolução? Esse dado está disponível em status page pública ou depende de solicitação ao suporte?

Sobre suporte na integração: existe equipe de engenharia dedicada para apoio na fase de integração? Com que SLA e até que etapa?

Fornecedores que não conseguem responder o histórico de incidentes dos últimos 12 meses com dado preciso estão dizendo algo sobre como operam. Esse silêncio é um dado.

O Fortface como segundo fornecedor

O Fortface disponibiliza dados de produção publicamente: 97,9% de sucesso na primeira tentativa, tempo médio de captura de 4,1s, processamento de backend em até 800ms e pontuação SUS de 95,5 — classificação A+ em usabilidade. O liveness é sem atrito, sem desafios de movimento, certificado iBeta Levels 1 e 2 e ISO/IEC 30107-3, com proteção contra ataques de apresentação e injeção. SDK disponível para Android, iOS, Web e Link Seguro, em produção em mais de 180 empresas.

Para times que estão avaliando um segundo fornecedor: solicitar conversa técnica com a equipe Fortface.

Para aprofundar

  • Soluções Fortface — como a Fortface aborda cada etapa da jornada de identidade

Perguntas frequentes

Quando não faz sentido ter um segundo fornecedor?
Quando o volume de transações é baixo o suficiente para que o custo de integração e manutenção supere o valor gerado pelo dado de comparação. Abaixo de determinado volume mensal — que varia por produto e por fluxo —, o período de operação paralela não gera amostra suficiente para comparação estatisticamente válida. Nesse caso, instrumentar melhor o fornecedor atual para coletar métricas detalhadas por segmento é mais eficiente do que adicionar um segundo.
Dois fornecedores custam o dobro?
O custo total não dobra porque o tráfego é dividido, não duplicado. Cada fornecedor processa sua fração do volume, não o volume inteiro. O preço por transação pode variar entre os dois, o que entra na conta de custo por transação conclusiva. O custo adicional fixo está na integração inicial, na manutenção de dois SDKs e na camada de roteamento. Esse custo precisa ser comparado com o valor gerado: alavancagem na renovação do contrato do fornecedor atual, dado para a decisão de migração e redução do risco de disponibilidade.
O segundo fornecedor precisa das mesmas certificações que o atual?
Depende do requisito regulatório da operação. A IN ITI 36/2026 exige liveness com detecção de imagens e vídeos manipulados para AR Eletrônica (Assinatura de Reconhecimento Eletrônico). Se a operação for regulada, os dois fornecedores precisam atender o mesmo requisito para que o tráfego paralelo seja válido naquele fluxo. Para fluxos sem exigência regulatória específica, as certificações entram como critério de avaliação, não como pré-requisito de elegibilidade.
Quanto tempo leva para ter dado confiável da operação paralela?
Depende do volume. Com pelo menos 10 mil transações por mês em cada fornecedor, três meses são suficientes para comparação de taxa de rejeição e taxa de sucesso com nível de confiança razoável. Com volume menor, o período precisa ser estendido ou o escopo da comparação precisa ser restrito a segmentos com comportamento mais homogêneo.
O que acontece com os dados biométricos na migração?
A migração técnica é resolvível: as fotos originais armazenadas são usadas para gerar um novo hash biométrico compatível com o novo provedor. O que precisa estar mapeado antes de qualquer movimento é a base legal. Dados biométricos são dados sensíveis sob a LGPD (Lei Geral de Proteção de Dados). A portabilidade de imagens exige cláusula contratual específica com ambos os fornecedores e aprovação do DPO. A ordem correta é: legal primeiro, técnico depois.