Como Verificar a Identidade de um Utilizador com o Claude
Verifique um utilizador dentro do Claude com prompts de linguagem natural: crie o link alojado, execute verificação de ID, vivacidade passiva, correspondência facial e análise de IP, e depois leia a decisão.
Principais pontos
- Este é um manual de operador: as palavras exatas a digitar no Claude, o que o requerente experiencia, como ler a resposta e o que fazer quando uma sessão precisa de revisão.
- O conector Model Context Protocol (MCP) da Didit permite que um operador autenticado utilize fluxos de trabalho e permissões existentes a partir do chat, sem escrever código.
- Um fluxo de trabalho controla quais verificações de Know Your Customer (KYC) são executadas. Listar os fluxos de trabalho encontra as opções; ler o fluxo de trabalho selecionado revela a sua configuração.
- O requerente completa as verificações configuradas numa página alojada da Didit. O Claude recupera e explica o resultado da Didit; não inspeciona o documento ou o rosto da pessoa.
- Em Revisão é uma transferência para julgamento humano, não outra forma de dizer Recusado. Peça ao Claude para separar as provas devolvidas das informações em falta antes que alguém altere o estado.
Não precisa de conhecer um esquema de interface de programação de aplicações (API) para ajudar um requerente na verificação de identidade. Precisa de uma conta Didit, de um fluxo de trabalho de verificação aprovado, do conector Didit ativado no Claude e de autoridade sob a política de revisão da sua organização. O resto pode acontecer em linguagem comum.
Este guia trata deliberadamente da pessoa que opera a conversa. Não repete a mecânica de criar-link-e-sondar já abordada em MCP para KYC e no guia do servidor KYC MCP. Mantenha essas referências abertas quando precisar de detalhes de ciclo de vida ou integração. Use esta página quando a questão prática for: “O que devo digitar, o que devo dizer ao requerente e o que faço com a resposta?”
Antes do requerente: estabeleça o espaço de trabalho correto
Adicione o conector Didit ao Claude e complete o início de sessão Didit. O endpoint alojado utiliza OAuth (Open Authorization) 2.1 com PKCE (Proof Key for Code Exchange), não uma chave de API. O Claude atua com o papel Didit do utilizador autenticado, por isso o operador já deve ter permissão para qualquer ação que solicite.
Comece cada nova conversa de operação tornando o âmbito visível:
Use Didit para me ajudar a verificar um requerente. Primeiro, chame didit_context_get. Diga-me qual organização e aplicação estão selecionadas. Não crie nem altere nada ainda.
Isto deteta o erro operacional mais fácil: trabalhar na aplicação errada quando uma pessoa pode aceder a várias. Se o Claude mostrar mais de uma opção, nomeie a organização e a aplicação que pretende usar antes de prosseguir.
Escolha um fluxo de trabalho sem adivinhar as suas verificações
didit_workflow_list lista os fluxos de trabalho disponíveis. Não devolve o gráfico completo do fluxo de trabalho nem a configuração. Use-o para encontrar o nome do fluxo de trabalho aprovado e o workflow_id, depois recupere o fluxo de trabalho selecionado explicitamente.
Liste os fluxos de trabalho de verificação na aplicação selecionada com didit_workflow_list. Mostre apenas o nome, workflow_id e estado de cada fluxo de trabalho. Não descreva as suas verificações ainda.
Depois de selecionar um, peça a configuração real:
Recupere o fluxo de trabalho WORKFLOW_UUID com didit_workflow_get. Se os seus passos ou ramificações exigirem detalhes de gráfico, chame também didit_workflow_get_graph com include_config: false. Depois, explique, em linguagem simples, o que o requerente deve fazer. Separe os passos visíveis para o requerente das verificações que são executadas em segundo plano. Não crie uma sessão.
Use didit_workflow_get para a configuração completa do fluxo de trabalho selecionado. Use didit_workflow_get_graph quando precisar dos seus nós, ramificações, condições ou passos de processamento de documentos; a sua configuração resumida padrão é suficiente para uma explicação do operador. Este padrão de dois passos impede o Claude de inferir um pacote apenas a partir de um rótulo de fluxo de trabalho.
Peça um link para um requerente
Depois de confirmar o espaço de trabalho e o fluxo de trabalho, a instrução do operador pode ser curta:
Crie uma sessão com didit_session_create usando workflow_id WORKFLOW_UUID e vendor_data customer-8421. Devolva o session_id e o url. Não envie o link nem altere qualquer outro registo.
A única entrada necessária para didit_session_create é workflow_id; vendor_data é uma referência de cliente opcional. A resposta inclui um url. Copie esse link alojado para o seu e-mail, suporte ou canal de integração aprovado. Criar a sessão não significa que o requerente tenha sido contactado.
Esse é todo o mecanismo de que este guia de operador precisa. Se estiver a implementar entrega automatizada, callbacks, webhooks ou polling, use os guias técnicos ligados em vez de transformar uma conversa de operador num tutorial de integração.
Diga ao requerente o que vai acontecer
O requerente abre uma página alojada da Didit no seu navegador; não precisa do Claude ou de uma conexão MCP. A experiência exata segue o fluxo de trabalho selecionado. Um pacote KYC completo configurado pode incluir captura de documento de identidade, vivacidade passiva, correspondência facial um para um e análise de protocolo de Internet (IP). Um fluxo de trabalho diferente pode conter menos verificações, verificações adicionais ou ramificações condicionais.
Peça ao Claude para redigir uma mensagem baseada apenas na configuração recuperada:
Escreva uma mensagem de quatro pontos para o requerente explicando o que verá depois de abrir o url. Use apenas a configuração do fluxo de trabalho selecionado. Mencione qualquer preparação de documento ou dispositivo que realmente exija. Não prometa aprovação, tempo de conclusão ou verificações que não estejam configuradas.
Uma boa mensagem do operador explica por que a pessoa recebeu o link, quais os passos visíveis que irá completar e onde pedir ajuda. Não deve expor o token de sessão interno, copiar dados pessoais para o chat ou descrever uma verificação de fundo como uma ação do requerente.
A Didit suporta mais de 220 países e territórios, mais de 14.000 tipos de documentos e mais de 48 idiomas. Esses números de cobertura descrevem a plataforma; o fluxo de trabalho selecionado e o documento do requerente ainda determinam os ecrãs reais disponíveis nessa sessão.
Peça um resultado em linguagem simples
Quando o requerente disser que terminou, não pergunte ao Claude se “passou”. Peça-lhe para recuperar a decisão registada e manter o estado separado das provas:
Chame didit_session_get_decision para a sessão SESSION_UUID. Explique o resultado a um operador de integração não técnico. Comece com o estado atual exato. Em seguida, liste apenas os resultados e campos do módulo configurado realmente devolvidos. Separe provas confirmadas, provas em falta, conflitos e itens que necessitam de julgamento humano. Não altere a sessão.
Esta formulação torna as alucinações mais fáceis de notar. A decisão contém a saída dos módulos configurados para esse fluxo de trabalho, não um conjunto universal de verificações de documento de identidade, vivacidade, correspondência facial, Anti-Branqueamento de Capitais (AML) e fraude. Se um módulo não foi executado ou um campo está ausente, a resposta deve indicá-lo em vez de preencher a lacuna.
Leia o estado como o estado atual da sessão:
- Não Iniciado ou Em Progresso significa que o operador deve esperar ou ajudar o requerente a completar o fluxo alojado.
- Em Revisão significa que as provas ou a lógica do fluxo de trabalho encaminharam a sessão para uma decisão humana.
- Aprovado ou Recusado é o estado de decisão atual. Ambos podem refletir automação configurada ou uma substituição manual de um revisor autorizado, por isso use as provas e o histórico de auditoria que as acompanham quando a política o exigir.
- Reenviado significa que os nós de fluxo de trabalho selecionados foram enviados de volta para outra tentativa; não é uma sessão nova e não relacionada.
A inferência do modelo é executada em sub-2 segundos p99, mas isso não é uma promessa sobre quanto tempo um requerente levará para capturar um documento, completar o fluxo ou esperar por revisão humana.
O que fazer quando a resposta é Em Revisão
Não traduza Em Revisão para “falhou” e não peça ao Claude para aprovar ou recusar no mesmo prompt que explica as provas. Primeiro, solicite um pacote de revisão apenas para leitura:
Esta sessão está Em Revisão. Chame didit_session_get_decision e didit_session_list_reviews. Não altere dados ou estado. Mostre a razão devolvida ou a prova que a desencadeou, as saídas do módulo configurado relevantes para ela, quaisquer informações conflitantes ou em falta, e o histórico de revisão ou estado anterior. Marque qualquer coisa não devolvida como desconhecida.
Em seguida, siga a política de escalonamento da sua organização. O revisor pode comparar os dados de identidade extraídos com as provas do documento, avaliar uma correspondência ou candidato a triagem, solicitar outra tentativa para nós de fluxo de trabalho que falharam exatamente, ou tomar uma decisão de estado autorizada. O Claude pode organizar o registo, mas não substitui o revisor ou a política de aceitação da organização.
Se estiver autorizado a documentar a revisão, mantenha a nota separada da decisão final:
Adicione este comentário com didit_session_add_review à sessão SESSION_UUID: “Escalado para revisão manual devido a [evidência observada].” Não passe new_status e não modifique os dados extraídos.
didit_session_add_review requer session_id, aceita um comment e pode opcionalmente alterar o estado. Omitir new_status torna a intenção clara aqui: registar a nota de revisão sem decidir o caso. Para correções, reenvio parcial, aprovação e procedimentos de recusa, use o guia de fila de revisão KYC com Claude dedicado.
Lista de verificação final do operador
- Confirme a organização, aplicação e referência do requerente antes de criar qualquer coisa.
- Liste os fluxos de trabalho primeiro, depois recupere a configuração ou o gráfico do fluxo de trabalho selecionado antes de descrever as suas verificações.
- Envie apenas o
urlalojado devolvido através de um canal de cliente aprovado. - Peça ao Claude para reportar as provas devolvidas, não para inferir módulos ausentes ou converter um estado numa história.
- Trate Em Revisão como uma transferência humana. Separe a investigação, a nota de auditoria, a correção de dados e o estado final em passos deliberados.
- Mantenha dados pessoais desnecessários, imagens de documentos e tokens internos fora da conversa.
O próprio servidor MCP é gratuito. Um pacote KYC completo configurado custa 0,33 $ e inclui verificação de documento de identidade, vivacidade passiva, correspondência facial e análise de IP. Cada funcionalidade inclui 500 verificações gratuitas por mês. A Didit serve mais de 2.000 empresas em produção e é infraestrutura para identidade e fraude.
Links de referência
- Visão geral do MCP — endpoint alojado e arquitetura
- Documentação das ferramentas MCP — nomes canónicos e esquemas
- Didit MCP no GitHub — código-fonte público com licença MIT
- Página de programadores Didit MCP — visão geral do produto
- Conectar Didit ao Claude — configuração do conector
Artigos relacionados
- A regra europeia sobre 'deepfakes' está em vigor e recai sobre a ferramenta, não sobre a fraude
- Inteligência Artificial em Ambos os Lados da Verificação de Identidade no Jogo Online
- A regra de identidade das stablecoins: emissão e resgate, não transações subsequentes
- O Egito assume o custo da renovação do KYC em vez de o passar ao cliente
- Unico e Didit: Verificação de Identidade Inovadora para PMEs no Brasil
- Didit vs. Onfido: Cobertura, Preços, Automação e Migração