FinTechOct 14, 202612 min de leitura

Automação com IA para sinistros, tickets e documentos de KYC nos seus próprios servidores: o que um COO deve perguntar a uma empresa antes de assinar

Processamento de documentosAutomação de back officeSetores reguladosQuem constrói

Oito perguntas para fazer a uma empresa que se oferece para automatizar com IA sinistros, tickets ou documentos de KYC nos seus próprios servidores, e como testar as respostas dela.

Antes de assinar com uma empresa que se oferece para automatizar com IA sinistros, tickets de suporte ou documentos de KYC nos seus próprios servidores, pergunte como o sistema dela vai se encaixar no trabalho que o seu back office faz hoje. Boas respostas vêm com números tirados de uma amostra dos seus próprios documentos, como quantos documentos ainda vão precisar ser conferidos por uma pessoa e quanto vai custar operar o sistema por mês. Se uma empresa apresentar números antes de ver os seus documentos, pergunte em quais documentos eles foram medidos.

A resposta curta: peça à empresa que mostre, em uma amostra dos seus próprios documentos, o que o sistema dela faz com um documento que não consegue ler e quantas horas semanais de trabalho da equipe vai exigir a conferência das respostas dele. Depois pergunte como a acurácia dele será comparada com a dos seus funcionários, como ele dá conta do seu dia de maior movimento, quanto custa operá-lo por mês e quem percebe quando os seus documentos ou o modelo mudam. Antes de assinar, garanta por escrito o que vai ser seu e quem vai operar o sistema depois que a empresa sair.

Quais dos nossos documentos a empresa deve ver primeiro?

Comece perguntando quais dos seus documentos a empresa quer ver. Uma empresa que já fez esse trabalho costuma pedir um mês dos documentos que você realmente recebe, incluindo as digitalizações e as fotos de celular, as trocas de e-mails com vários anexos, os formulários que voltam preenchidos pela metade e os casos que os seus funcionários passam para um supervisor. Ela também pergunta quais campos importam para você, como a data do sinistro em um aviso de sinistro ou a data de validade em um documento de identidade, e o que acontece hoje quando um deles é lido errado.

Antes da primeira reunião, extraia do seu próprio sistema um mês de documentos e ordene-os pelo tempo que o seu time levou com cada um, porque é nos documentos mais demorados que se deve testar uma empresa. Conte quantos há de cada tipo e anote quais deles um supervisor teve de decidir.

Envie a cada empresa da sua lista curta uma descrição por escrito desses documentos, com as contagens. Documentos reais vão apenas para a empresa que você escolher para um diagnóstico pago, um primeiro contrato curto em que ela testa o sistema dela nos seus próprios servidores antes de você assinar o contrato principal. A maioria dos números abaixo sai desse diagnóstico.

O que acontece com um documento que o sistema não consegue ler?

Todo back office tem documentos em que o sistema vai falhar, como uma foto tirada em ângulo ou um extrato bancário com um layout novo. Cada um deles precisa acabar nas mãos de uma pessoa que possa decidir.

Escolha três dos seus piores documentos para o diagnóstico e peça à empresa que explique, passo a passo, o que acontece com cada um, da chegada até a pessoa que decide. Anote qualquer etapa que a empresa não consiga descrever e volte a ela antes de assinar.

Em uma boa resposta, o documento vai para uma fila de revisão, uma lista de documentos que uma pessoa designada do seu time vai tratando. Essa pessoa vê a página com o campo duvidoso marcado, e nada chega ao seu sistema de sinistros ou de KYC até que ela decida.

A empresa também deve explicar como o sistema distingue um documento que não consegue ler de um documento que leu errado. O segundo tipo é mais difícil de pegar, porque uma data ou um valor errado parece qualquer outro valor e passa, a menos que algo o verifique.

Quantas horas de trabalho da equipe vai exigir a conferência das respostas do sistema?

Pegue cinquenta documentos da sua amostra e cronometre quanto tempo o seu time gasta hoje com cada um. Durante o diagnóstico, pergunte à empresa quanto desse tempo a revisão ainda vai tomar nos mesmos cinquenta documentos. A diferença é o tempo que o sistema economiza, antes dos custos de operação. Se a diferença for pequena, compare-a com o tempo de que os seus funcionários vão precisar para aprender uma ferramenta nova.

O sistema vai mandar uma parcela dos documentos para revisão, e essa parcela define de quantos funcionários você precisa. A empresa deve estimá-la antes de você assinar o contrato principal, para as primeiras semanas e para alguns meses depois, quando os erros mais comuns já tiverem sido corrigidos. Sem esses números, você não consegue planejar a carga de trabalho do seu time depois do lançamento.

A revisão deve ser feita pelas pessoas que tratam esses documentos hoje, porque elas sabem como é uma resposta correta. A empresa deve mostrar a você a tela que elas vão usar, com a página e o campo marcado lado a lado, e dizer quanto tempo leva, em média, uma revisão.

Como saber se o sistema é tão preciso quanto os nossos funcionários?

Peça a dois dos seus funcionários que anotem as respostas corretas de cinquenta documentos da sua amostra sem conversar entre si. Onde eles discordarem, o seu time ainda não tem uma resposta acordada, e o sistema não pode ser pontuado nesses documentos. Combine como esses casos serão decididos antes de os testes começarem.

As empresas costumam informar a acurácia como um único percentual para o sistema inteiro. Uma nota útil é dada para cada campo, como uma data ou um valor, e para cada tipo de documento. As notas devem vir do seu conjunto de teste: documentos da sua amostra com respostas corretas escritas pelos seus próprios funcionários, que a empresa não usou enquanto ajustava o sistema. Os seus funcionários também erram, então meça-os nos mesmos documentos para ver com o que o sistema está sendo comparado.

Uma boa resposta fixa a nota de corte, a nota mínima que o sistema precisa atingir, antes de o preço ser acordado. Ela diz quais campos o sistema pode preencher sozinho depois de atingir essa nota e quais campos sempre vão para uma pessoa. Defina a nota de corte a partir do que um erro custa para você, como um sinistro pago duas vezes ou uma conta aberta para a pessoa errada, e entregue-a à empresa por escrito.

O que acontece no nosso dia de maior movimento?

Alguns dias trazem muito mais documentos do que outros, como o fim do mês ou a manhã seguinte a uma tempestade. Um sistema que dá conta em um dia comum pode ficar para trás em um dia assim.

Encontre nos seus próprios registros o dia de maior movimento do último ano, com o número de documentos, e peça à empresa que explique como o sistema dela teria lidado com ele. Os servidores são seus, então pergunte também o que seria preciso para aumentar a capacidade em um dia assim e quanto tempo isso levaria.

A resposta deve dizer quantos documentos por hora o sistema consegue receber nos servidores que você vai disponibilizar e quem é acionado quando há documentos esperando há mais de uma hora. Os documentos devem esperar em ordem, com os tipos urgentes primeiro, e alguém do seu lado deve conseguir devolver um tipo de documento ao tratamento manual. Nenhum documento é descartado nem repassado sem conferência para zerar a fila de pendências mais rápido.

Quanto vai custar operar o sistema por mês?

Os custos de operação se somam ao preço da construção e duram enquanto o sistema estiver funcionando. Nos seus próprios servidores, eles têm pelo menos quatro partes:

os servidores que rodam o modelo
as pessoas que monitoram o sistema e tratam os alertas dele
o tempo que os seus funcionários gastam com a revisão
o trabalho de manter o sistema atualizado quando os modelos e os documentos mudam

Peça a cada empresa uma estimativa mensal com as premissas por escrito: documentos por mês, páginas por documento, quantos de cada tipo e os servidores que ela prevê. Depois compare as premissas com o seu volume real. Se uma empresa informar um custo de operação sem premissas, peça que ela as coloque por escrito antes de comparar o número dela com o de outras empresas.

O contrato deve listar o que a mensalidade de suporte da empresa cobre depois do lançamento, por exemplo, se a adaptação do sistema a um novo formato de documento está incluída ou é cobrada à parte.

Este artigo não traz preços, porque o custo depende do seu volume e dos seus servidores. Cada empresa deve calculá-lo a partir dos seus próprios números.

Quem percebe quando os nossos documentos ou o modelo mudam?

Depois do lançamento, os seus documentos vão mudar, por exemplo quando um banco parceiro reformula os extratos dele ou quando uma nova linha de produtos traz um formulário novo. O modelo também pode mudar, quando sai uma versão mais nova ou quando o software que o roda nos seus servidores deixa de dar suporte à antiga.

Quando o modelo mudar, o sistema deve ser pontuado de novo no seu conjunto de teste, campo por campo, antes da troca, e você deve poder reverter a troca. Combine com antecedência quem paga cada um desses testes.

Se, numa terça-feira, todos os extratos de um banco começarem a ir para revisão, ou se um campo for lido errado durante uma semana, os painéis dos servidores continuarão sem mostrar nenhum erro. Para pegar isso, alguém do seu lado deve verificar toda semana que parcela de cada tipo de documento vai para revisão, e a empresa deve dizer o que faz quando essa parcela muda.

O que passa a ser nosso no final, e quem opera o sistema depois que a empresa sair?

No fim do projeto, você deve ter tudo o que é necessário para operar e alterar o sistema sem a empresa. Isso significa o código, os prompts (as instruções escritas que o modelo segue), o conjunto de teste com as respostas corretas, os scripts que pontuam o sistema e a documentação. Coloque essa lista no contrato, junto com os componentes reutilizáveis da empresa, cada um identificado pelo nome, e o que você pode fazer com eles.

Depois pergunte quem opera o sistema do seu lado. A empresa deve descrever a função e o que essa pessoa precisa saber, e o treinamento deve estar concluído antes do lançamento. Se a resposta for “nós vamos operar o sistema para você”, pergunte o que acontece quando o contrato terminar e quanto custa a transição.

O AI Act da UE se aplica ao nosso sistema?

O artigo 4 do AI Act da UE é aplicável desde 2 de fevereiro de 2025. Na redação atual, dada pelo Regulamento (UE) 2026/1744, de julho de 2026, ele exige que os fornecedores e os responsáveis pela implantação de sistemas de IA adotem medidas para apoiar o letramento em IA dos seus funcionários e de outras pessoas que operam e usam os sistemas em nome deles. Ele não exige de nenhuma pessoa um nível específico de letramento em IA.

O AI Act lista alguns usos como de alto risco, entre eles avaliar a capacidade de crédito de pessoas físicas, exceto para detectar fraude financeira, e a avaliação de riscos e a precificação em seguros de vida e de saúde. Para esses usos, o artigo 26 acrescenta obrigações para a empresa que implanta o sistema e, pela alteração de 2026, elas se aplicam a partir de 2 de dezembro de 2027. A supervisão humana fica então a cargo de pessoas com “as competências, a formação e a autoridade necessárias”, e a empresa monitora o sistema em funcionamento. Os logs gerados pelo sistema são guardados por pelo menos seis meses quando estão sob o controle da empresa, a menos que outra lei determine o contrário.

Bancos, seguradoras e outras instituições financeiras sujeitas à legislação de serviços financeiros da UE cumprem a obrigação de monitoramento seguindo as regras de governança interna que já seguem, e guardam os logs junto com a documentação que essas regras já exigem.

Se o seu sistema se enquadra nessas regras é uma questão para os seus advogados, e este artigo não é assessoria jurídica. Treinar os seus funcionários e nomear a pessoa que opera o sistema do seu lado ajuda em qualquer caso.

Quais respostas indicam que a empresa nunca fez isso antes?

A empresa apresenta um número de acurácia sem ter visto nenhum dos seus documentos
A empresa diz que o modelo “lida bem com casos atípicos” e não sabe dizer para onde vai um documento ilegível
O plano não tem fila de revisão, ou deixa a revisão para os seus funcionários sem nenhuma estimativa de horas
Ninguém na empresa sabe dizer o que acontece quando chegam mais documentos do que o sistema consegue processar
O custo mensal de operação vem sem os volumes e os servidores que ele pressupõe
O treinamento dos seus funcionários começa depois do lançamento, ou nem acontece

Onde a amBrain se encaixa?

O único projeto com modelo de linguagem que a amBrain descreve publicamente é este: “Levamos à produção uma integração de LLM dentro do perímetro de FinTech de um cliente: extração e normalização de avisos não estruturados de corretoras e de venues — eventos corporativos, alterações de instrumentos e de margem — em registros estruturados que o sistema de trading consome.”

Este artigo não é um estudo de caso, e o cliente não é nomeado. Ele não diz que a amBrain construiu um sistema para sinistros, tickets de suporte ou documentos de KYC. Não é divulgado onde o modelo rodava nesse projeto nem quais das práticas acima o projeto usou. Ele não traz preços nem prazos da amBrain.

A amBrain constrói software desde 2019. Ela descreve em uma linha como trabalha com os clientes: “Três formatos: entrega completa, time dedicado ou engenheiros embarcados no seu time.” Sobre propriedade, a frase dela é: “O cliente mantém a propriedade integral do produto e do código, exceto dos nossos componentes reutilizáveis.” Peça à amBrain a lista desses componentes, nome por nome, como você pediria a qualquer outra empresa.

Se a amBrain estiver na sua lista curta, envie a ela as mesmas perguntas por escrito que às outras empresas.

Perguntas comuns

O nosso piloto já funciona. Essas perguntas ainda se aplicam? Sim. Um piloto costuma mostrar que o sistema consegue ler parte dos seus documentos, e pouco sobre as outras perguntas acima. O artigo sobre projetos de IA turnkey, com link no topo da página, explica como pagar pelo trabalho que transforma um piloto em um sistema que o seu back office consegue operar
Rodar nos nossos próprios servidores significa que nenhum dado vai para um provedor externo de modelos? Só se todas as etapas rodarem lá. Peça à empresa que declare por escrito qual modelo roda onde e se alguma etapa chama um serviço externo, como um modelo hospedado ou um serviço de reconhecimento de texto
Quem do nosso lado deve participar dessas reuniões? A pessoa que comanda o back office hoje e alguém de TI que vai liberar os acessos da empresa e sabe o que os seus servidores aguentam

Tem um projeto assim na mesa?

Traga sua arquitetura atual e o modo de falha que preocupa você, e vamos analisá-lo juntos em meia hora.