Solução de Identidade com IA Agente

Isso porque o KYC/IDV tradicional responde bem apenas a uma pergunta: a identidade dessa pessoa foi verificada no momento da cadastro? Ele não responde de forma confiável quem ou o que está agindo no momento, se esse agente ainda está sob o controle do cliente ou se o comportamento atual corresponde a um uso legítimo. Essa lacuna se torna perigosa quando agentes de IA, automação programada e fraudes com assistência humana podem operar por meio de uma conta previamente verificada. Para um vice-presidente de segurança de produtos ou chefe de identidade, a verdadeira questão não é substituir o KYC, mas ampliá-lo para um modelo contínuo de “Conheça seu Agente” (Know Your Actor). São necessários controles que classifiquem o tipo de agente em tempo real, detectem quando o comportamento muda de conduzido por humanos para automatizado, distingam a automação delegada da atividade hostil de bots e apliquem políticas diferentes no login, nas alterações de conta, nos pagamentos, nos saques e na recuperação. O ponto crítico é que a fraude agora ocorre após o cadastro, não apenas durante ele.

Você não resolverá isso com um único sinal. A abordagem prática é a classificação em camadas. Comece com a verificação de identidade na fase de cadastro e, em seguida, acrescente sinais no nível da sessão, como inteligência de dispositivo, indicadores de navegador e emulador, velocidade, padrões de navegação, entropia de interação, biometria comportamental, características de uso de API e contexto da transação. Para casos de uso aprovados de agentes de IA, exija artefatos de delegação explícitos, como autorização tokenizada, permissões com escopo definido, janelas de validade e restrições no nível da ação. Para automações suspeitas, procure padrões que os seres humanos não conseguem manter bem em grande escala: tempos altamente consistentes, caminhos de navegação anormais, reutilização distribuída de dispositivos, comportamento de repetição, sequências de interação de baixo atrito ou incompatibilidades entre a identidade declarada e o comportamento observado. O objetivo não é desafiar todos da mesma forma. Trata-se de classificar a jornada por níveis de risco para que pessoas de baixo risco sejam aprovadas com o mínimo de atrito, agentes delegados conhecidos operem dentro da política e atores desconhecidos ou evasivos sejam submetidos a verificações mais rigorosas, tenham sua taxa limitada ou sejam bloqueados.

Uma arquitetura viável possui cinco camadas. Primeiro, comprovação de identidade: verificação de documentos, biometria, verificações em bancos de dados, triagem de sanções e quaisquer controles KYC/KYB exigidos. Segundo, detecção de atores: determinar se a sessão atual parece ser conduzida por humanos, por bots, assistida por agentes ou híbrida. Em terceiro lugar, risco comportamental e contextual: avaliar a confiabilidade do dispositivo, a reputação da rede, a geovelocidade, anomalias comportamentais, a integridade da sessão, a intenção da transação e os padrões históricos da conta. Em quarto lugar, orquestração de políticas: aplicar regras e modelos que determinem quando permitir, reforçar, limitar, exigir novo consentimento ou encaminhar para revisão manual. Quinto, auditabilidade: registre quais sinais foram utilizados, como a decisão foi tomada, quais permissões existiam e por que uma ação foi aprovada ou negada. Isso é importante porque o problema raramente é a falta de um único controle. Trata-se da falta de orquestração entre os controles. Se suas equipes não conseguem explicar a classificação de atores, a autoridade delegada e a lógica de intensificação em cada etapa da jornada, então sua arquitetura ainda está otimizada para um mundo exclusivamente humano.

Trate a delegação como um problema de identidade e autorização de primeira ordem, e não como um recurso adicional. Se um agente de IA pode agir em nome de um usuário, é preciso saber quem o autorizou, o que ele tem permissão para fazer, em que condições, por quanto tempo e como essa autoridade pode ser revogada. Na prática, isso significa consentimento explícito do usuário, permissões delimitadas, limites de transações e ações, reautenticação robusta para eventos de delegação sensíveis, credenciais ou atestados por agente e trilhas de auditoria claras que vinculem cada ação do agente a um usuário verificado e a um registro de autorização. Você também deve separar o acesso de leitura do acesso de gravação e as ações de baixo risco das de alto risco. Um cliente pode, razoavelmente, permitir que um agente colete dados da conta, mas não que altere detalhes de pagamento ou inicie uma retirada sem verificação reforçada. O ponto crítico aqui é a governança: a maioria das equipes consegue imaginar experiências úteis para os agentes, mas não possui um modelo de controle duradouro para comprovar que essas ações foram autorizadas.

Os órgãos reguladores ainda esperam que haja responsabilização, mesmo que a ação inicial tenha sido desencadeada por um software. Sua estrutura de controle deve preservar os principais resultados de conformidade: identidade verificada, tomada de decisão baseada em risco, rastreabilidade, explicabilidade e escalonamento justificável. Isso significa documentar não apenas quem é o cliente, mas também quem ou o que agiu em seu nome, qual autoridade existia, quais sinais influenciaram a decisão e se uma revisão humana foi acionada. Para as equipes de combate à lavagem de dinheiro, fraude e privacidade, a preocupação não é se os agentes de IA são permitidos em teoria; é se você pode defender as decisões durante uma auditoria, contestação, análise de SAR ou reclamação do cliente. Crie sistemas que permitam a retenção de evidências, registros de decisões, registros de consentimento, controle de versões de políticas e históricos no nível das ações. Se um agente alterar informações da conta, transferir fundos ou enviar dados de cadastro, você deve ser capaz de reconstruir a cadeia de eventos sem ambiguidades. A conformidade é comprometida quando identidade, autoridade e histórico de ações estão desconectados.

O step-up deve ser acionado por uma combinação de incerteza quanto ao agente, sensibilidade da ação e gravidade da anomalia. Acione-o quando a classificação do agente não estiver clara, quando o comportamento mudar repentinamente de um uso humano normal para padrões semelhantes à automação, quando uma conta confiável tentar uma ação de alto risco a partir de um novo ambiente ou quando um agente delegado exceder seu escopo ou velocidade normais. Momentos sensíveis geralmente incluem recuperação de conta, redefinições de senha ou autenticação multifatorial (MFA), alterações de pagamentos, adição de beneficiários, grandes transferências, saques de criptomoedas, alterações fiscais ou de perfil e qualquer coisa que possa alterar irreversivelmente a titularidade ou o fluxo de fundos. O erro que muitas equipes cometem é tratar a autenticação como binária: conectado ou não. Em ambientes com agentes, o reforço de segurança deve ser contextual e progressivo. Você pode exigir primeiro verificações passivas, depois uma nova verificação biométrica, em seguida a aprovação explícita do usuário e, por fim, uma revisão humana caso o risco permaneça não resolvido. O modelo correto protege ações críticas sem forçar todos os clientes a passar pelo mesmo fluxo pesado.