Verificación de identidad de usuario con Claude

Puntos clave

• Esto es un manual para el operador: las palabras exactas para escribir en Claude, lo que experimenta el solicitante, cómo leer la respuesta y qué hacer cuando una sesión necesita revisión.
• El conector del Protocolo de Contexto del Modelo (MCP) de Didit permite que un operador con sesión iniciada utilice flujos de trabajo y permisos existentes desde el chat sin escribir código.
• Un flujo de trabajo controla qué verificaciones de Conozca a su Cliente (KYC) se ejecutan. Listar los flujos de trabajo encuentra las opciones; leer el flujo de trabajo seleccionado revela su configuración.
• El solicitante completa las verificaciones configuradas en una página alojada por Didit. Claude recupera y explica el resultado de Didit; no inspecciona el documento o el rostro de la persona.
• En Revisión es un traspaso para el juicio humano, no otra palabra para Rechazado. Pida a Claude que separe la evidencia devuelta de la información faltante antes de que alguien cambie el estado.

No necesita conocer un esquema de interfaz de programación de aplicaciones (API) para ayudar a un solicitante a través de la verificación de identidad. Necesita una cuenta de Didit, un flujo de trabajo de verificación aprobado, el conector de Didit habilitado en Claude y autoridad bajo la política de revisión de su organización. El resto puede ocurrir en lenguaje ordinario.

Esta guía trata deliberadamente sobre la persona que opera la conversación. No repite la mecánica de crear-enlace-y-consultar ya cubierta en MCP para KYC y la guía del servidor KYC MCP. Mantenga esas referencias abiertas cuando necesite detalles de ciclo de vida o integración. Utilice esta página cuando la pregunta práctica sea: “¿Qué debo escribir, qué debo decirle al solicitante y qué hago con la respuesta?”

Antes del solicitante: establezca el espacio de trabajo correcto

Agregue el conector Didit a Claude y complete el inicio de sesión de Didit. El punto final alojado utiliza OAuth (Autorización Abierta) 2.1 con PKCE (Proof Key for Code Exchange), no una clave API. Claude actúa con el rol de Didit del usuario que ha iniciado sesión, por lo que el operador ya debe tener permiso para cualquier acción que solicite.

Comience cada nueva conversación operativa haciendo visible el alcance:

Use Didit para ayudarme a verificar a un solicitante. Primero, llame a didit_context_get. Dígame qué organización y aplicación están seleccionadas. No cree ni cambie nada todavía.

Esto detecta el error operativo más fácil: trabajar en la aplicación incorrecta cuando una persona puede acceder a varias. Si Claude muestra más de una opción, nombre la organización y la aplicación que desea utilizar antes de continuar.

Elija un flujo de trabajo sin adivinar sus verificaciones

didit_workflow_list enumera los flujos de trabajo disponibles. No devuelve el gráfico completo del flujo de trabajo ni la configuración. Úselo para encontrar el nombre del flujo de trabajo aprobado y el workflow_id, luego recupere el flujo de trabajo seleccionado explícitamente.

Liste los flujos de trabajo de verificación en la aplicación seleccionada con didit_workflow_list. Muestre solo el nombre, workflow_id y estado de cada flujo de trabajo. No describa sus verificaciones todavía.

Después de seleccionar uno, solicite la configuración real:

Recupere el flujo de trabajo WORKFLOW_UUID con didit_workflow_get. Si sus pasos o ramas requieren detalles del gráfico, también llame a didit_workflow_get_graph con include_config: false. Luego explique, en lenguaje sencillo, lo que el solicitante debe hacer. Separe los pasos visibles para el solicitante de las verificaciones que se ejecutan en segundo plano. No cree una sesión.

Utilice didit_workflow_get para la configuración completa del flujo de trabajo seleccionado. Utilice didit_workflow_get_graph cuando necesite sus nodos, ramas, condiciones o pasos de procesamiento de documentos; su configuración resumida predeterminada es suficiente para una explicación del operador. Este patrón de dos pasos evita que Claude infiera un paquete simplemente a partir de una etiqueta de flujo de trabajo.

Solicite un enlace para un solicitante

Una vez que haya confirmado el espacio de trabajo y el flujo de trabajo, la instrucción del operador puede ser breve:

Cree una sesión con didit_session_create utilizando workflow_id WORKFLOW_UUID y vendor_data customer-8421. Devuelva el session_id y la url. No envíe el enlace ni cambie ningún otro registro.

La única entrada requerida para didit_session_create es workflow_id; vendor_data es una referencia de cliente opcional. La respuesta incluye una url. Copie ese enlace alojado en su correo electrónico aprobado, soporte o canal de incorporación. La creación de la sesión no significa en sí misma que se haya contactado al solicitante.

Ese es todo el mecanismo que necesita esta guía para el operador. Si está implementando entregas automatizadas, callbacks, webhooks o sondeos, utilice las guías técnicas vinculadas en lugar de convertir una conversación de operador en un tutorial de integración.

Diga al solicitante lo que sucederá

El solicitante abre una página alojada por Didit en su navegador; no necesita Claude ni una conexión MCP. La experiencia exacta sigue el flujo de trabajo seleccionado. Un paquete KYC completo configurado puede incluir captura de documentos de identidad, prueba de vida pasiva, coincidencia facial uno a uno y análisis de Protocolo de Internet (IP). Un flujo de trabajo diferente puede contener menos verificaciones, verificaciones adicionales o ramas condicionales.

Pida a Claude que redacte un mensaje basado únicamente en la configuración recuperada:

Escriba un mensaje de cuatro puntos para el solicitante explicando lo que verá después de abrir la url. Utilice solo la configuración del flujo de trabajo seleccionado. Mencione cualquier documento o preparación de dispositivo que realmente requiera. No prometa aprobación, tiempo de finalización o verificaciones que no estén configuradas.

Un buen mensaje del operador explica por qué la persona recibió el enlace, qué pasos visibles completará y dónde pedir ayuda. No debe exponer el token de sesión interno, copiar datos personales en el chat ni describir una verificación de antecedentes como una acción del solicitante.

Didit admite más de 220 países y territorios, más de 14,000 tipos de documentos y más de 48 idiomas. Esas cifras de cobertura describen la plataforma; el flujo de trabajo seleccionado y el documento del solicitante aún determinan las pantallas reales disponibles en esa sesión.

Solicite un resultado en lenguaje sencillo

Cuando el solicitante diga que ha terminado, no pregunte a Claude si “aprobó”. Pídale que recupere la decisión registrada y mantenga el estado separado de la evidencia:

Llame a didit_session_get_decision para la sesión SESSION_UUID. Explique el resultado para un operador de incorporación no técnico. Comience con el estado actual exacto. Luego, liste solo los resultados de los módulos configurados y los campos realmente devueltos. Separe la evidencia confirmada, la evidencia faltante, los conflictos y los elementos que necesitan juicio humano. No cambie la sesión.

Esta redacción hace que la alucinación sea más fácil de detectar. La decisión contiene el resultado de los módulos configurados para ese flujo de trabajo, no un conjunto universal de verificaciones de documentos de identidad, prueba de vida, coincidencia facial, Anti-Lavado de Dinero (AML) y fraude. Si un módulo no se ejecutó o un campo está ausente, la respuesta debe indicarlo en lugar de llenar el vacío.

Lea el estado como el estado actual de la sesión:

• No Iniciado o En Progreso significa que el operador debe esperar o ayudar al solicitante a completar el flujo alojado.
• En Revisión significa que la evidencia o la lógica del flujo de trabajo ha dirigido la sesión a una decisión humana.
• Aprobado o Rechazado es el estado de decisión actual. Cualquiera de los dos puede reflejar la automatización configurada o la anulación manual de un revisor autorizado, así que use la evidencia adjunta y el historial de auditoría cuando la política lo requiera.
• Reenviado significa que los nodos del flujo de trabajo seleccionados se enviaron de nuevo para otro intento; no es una sesión nueva y no relacionada.

La inferencia del modelo se ejecuta en menos de 2 segundos p99, pero eso no es una promesa sobre cuánto tiempo tardará un solicitante en capturar un documento, completar el flujo o esperar la revisión humana.

Qué hacer cuando la respuesta es En Revisión

No traduzca En Revisión como “fallido” y no pida a Claude que apruebe o rechace en la misma indicación que explica la evidencia. Primero, solicite un paquete de revisión de solo lectura:

Esta sesión está En Revisión. Llame a didit_session_get_decision y didit_session_list_reviews. No cambie datos ni estado. Muestre la razón devuelta o la evidencia desencadenante, los resultados de los módulos configurados relevantes para ello, cualquier información conflictiva o faltante, y el historial de revisión o estado anterior. Marque todo lo que no se devuelva como desconocido.

Luego, siga la política de escalamiento de su organización. El revisor puede comparar los datos de identidad extraídos con la evidencia del documento, evaluar una coincidencia o un candidato de detección, solicitar otro intento para los nodos del flujo de trabajo que fallaron exactamente o tomar una decisión de estado autorizada. Claude puede organizar el registro, pero no reemplaza al revisor ni la política de aceptación de la organización.

Si está autorizado a documentar la revisión, mantenga la nota separada de la decisión final:

Agregue este comentario con didit_session_add_review a la sesión SESSION_UUID: “Escalado para revisión manual debido a [evidencia observada].” No pase new_status y no modifique los datos extraídos.

didit_session_add_review requiere session_id, acepta un comment y puede cambiar el estado opcionalmente. Omitir new_status aclara la intención aquí: registrar la nota de revisión sin decidir el caso. Para correcciones, reenvío parcial, aprobación y procedimientos de rechazo, utilice la guía de la cola de revisión de KYC con Claude.

La lista de verificación final del operador

• Confirme la organización, la aplicación y la referencia del solicitante antes de crear cualquier cosa.
• Liste los flujos de trabajo primero, luego recupere la configuración o el gráfico del flujo de trabajo seleccionado antes de describir sus verificaciones.
• Envíe solo la url alojada devuelta a través de un canal de cliente aprobado.
• Pida a Claude que informe la evidencia devuelta, no que infiera módulos ausentes o convierta un estado en una historia.
• Trate En Revisión como un traspaso humano. Separe la investigación, la nota de auditoría, la corrección de datos y el estado final en pasos deliberados.
• Mantenga los datos personales innecesarios, las imágenes de documentos y los tokens internos fuera de la conversación.

El servidor MCP en sí es gratuito. Un paquete KYC completo configurado cuesta $0.33 e incluye verificación de documentos de identidad, prueba de vida pasiva, coincidencia facial y análisis de IP. Cada función incluye 500 verificaciones gratuitas por mes. Didit sirve a más de 2,000 empresas en producción y es infraestructura para la identidad y el fraude.

Enlaces de referencia

• Descripción general de MCP — punto final alojado y arquitectura
• Documentación de herramientas MCP — nombres y esquemas canónicos
• Didit MCP en GitHub — código fuente público con licencia MIT
• Página de desarrolladores de Didit MCP — descripción general del producto
• Conectar Didit a Claude — configuración del conector