Inicia una identidad alojada sin poner documentos en un chat de IA

El problema: documentos en el canal equivocado

Cuando la incorporación de identidad pasa por un asistente de IA, el camino más fácil suele ser el peor: pedir al usuario que suba su documento o una selfie directamente a la conversación. Las transcripciones se guardan, comparten y revisan de maneras que el flujo de verificación no controla. La alternativa es un recorrido alojado. Tu servicio, o el asistente que actúa por él, solicita un enlace de verificación; la persona lo abre y completa allí los pasos de identidad y prueba de vida. El asistente nunca ve un documento ni un rostro. Tu decisión no es qué widget de cámara construir, sino qué pocos valores envía tu aplicación y en cuáles confía al leer el resultado. Definir bien ese límite desde el inicio mantiene las imágenes sensibles fuera de registros, prompts y tickets de soporte.

Lo que establece el contrato del producto

Según el contrato revisado, la tarea de identidad alojada recibe tres entradas: una referencia de autorización del sujeto, un UUID de solicitud estable y un modo explícito de prueba o pago. Ningún documento ni rostro debe entrar en el chat del asistente. La salida es una URL alojada, un estado de tarea y un estado de finalización autorizado. Las herramientas listadas son production_capabilities, start_identity_onboarding, get_production_verification y refresh_production_verification. Dos afirmaciones importan más. Primera: la persona, no el asistente, completa los pasos de identidad y prueba de vida. Segunda: Approved no otorga permisos en la aplicación; tus propias reglas deciden qué puede hacer una persona aprobada. El contrato también registra límites: la aceptación de una persona nueva que complete todo el recorrido alojado sigue pendiente, y las compras en línea requieren la aceptación del canal de pago. La ejecución comercial exige capacidades vigentes, autorización y una cotización aceptada. La documentación no es evidencia de una verificación real.

Escenario hipotético y salida esperada del fixture

Hipotético: un pequeño equipo SaaS incorpora a un vendedor. Su servicio registra la referencia de autorización, genera un UUID de solicitud y lo guarda antes de cualquier llamada, y elige el modo de prueba explícitamente. Luego pide iniciar el recorrido alojado. En el ejemplo sintético del contrato no se realiza ninguna solicitud a un proveedor real, y la salida esperada es exactamente: status pending, hosted_url null, verified false, automatic_business_approval false. Lee cada campo literalmente. status pending significa que la tarea existe pero ningún resultado es definitivo. hosted_url null significa que aún no hay enlace para mostrar, así que la interfaz no debe dibujar un botón roto ni inventar uno. verified false no es un rechazo; solo indica que la verificación no ha terminado. automatic_business_approval false confirma que ni siquiera una aprobación posterior activará por sí sola el acceso del vendedor. Es una ilustración sintética del contrato, no una aceptación real, y el permiso del fixture para ejecutarse no es un permiso de negocio.

Diseño de aplicación propuesto

Lo siguiente es nuestro diseño propuesto, no comportamiento implementado del producto. Persiste el UUID de solicitud junto con la referencia del sujeto antes de iniciar, para que un reintento reutilice la misma solicitud en vez de crear un segundo recorrido. Guarda el estado de la tarea como pending con un plazo local. Muestra la URL alojada a la persona solo cuando la tarea devuelva un valor no nulo, y envíala por tu propia interfaz, nunca pidiendo imágenes en el chat. Cuando la persona termine, lee el estado de finalización autorizado con get_production_verification en lugar de confiar en una redirección del navegador o en un mensaje del asistente. Mantén un paso de decisión de negocio separado: un Approved autorizado es una entrada más para tu política de vendedores, que verifica inquilino, usuario y la acción solicitada. Registra el UUID, el estado y el resultado, nunca el contenido de documentos.

Manejo de fallos

Planifica cada camino no ideal de forma explícita. Si hosted_url sigue en null, mantén la tarea en pending e informa a la persona que el enlace aún no está listo; no crees una nueva solicitud con otro UUID. Si nunca llega un callback, el patrón de recuperación local de los ejemplos anteriores expira la tarea pendiente al vencer el plazo; no consulta al proveedor, así que un refresh sobre la tarea original es un paso deliberado y autorizado. Los eventos del fixture solo aceptan callbacks sintéticos, no firmas reales, por lo que un fixture exitoso no dice nada sobre la verificación de firmas en producción. Si el estado es Declined o incompleto, regístralo y envíalo a revisión humana en vez de reintentar en silencio. Si alguien publica un documento en el chat de todos modos, no lo reenvíes; dirígelo al enlace alojado. Si falta el modo, rechaza el inicio en lugar de suponer prueba o pago.

Lista de aceptación

Antes de declarar esta integración lista para un piloto, confirma: la solicitud lleva una referencia de autorización del sujeto, un UUID guardado y un modo explícito; ninguna imagen de documento o rostro aparece en prompts, transcripciones o registros; el fixture devuelve status pending, hosted_url null, verified false y automatic_business_approval false; la interfaz maneja un hosted_url nulo sin enlaces muertos; los reintentos reutilizan el mismo UUID; la finalización se lee del estado autorizado, no de una redirección; Approved pasa por tus propias reglas de permisos y nunca concede acceso directamente; la recuperación expira localmente sin consultar al proveedor; y el registro del equipo indica que la aceptación de aprobación completa de personas nuevas sigue pendiente y que las compras dependen de la aceptación del canal de pago. Una lista superada demuestra que tu manejo es correcto, no que haya ocurrido una verificación real.

Revisar este producto

https://gridzen.ai/tools/hosted-identity/ · Revise entrada, salida y límites. El comando muestra el producto sin ejecutar solicitudes reales.

gridzen tools --product hosted-identity

Fuentes y alcance

https://gridzen.ai/tools/hosted-identity/ https://gridzen.ai/guides/current-capabilities/ Basado en las fuentes comprobadas y el ejemplo local; las reglas propuestas son recomendaciones de diseño, no comportamiento de producción demostrado. Redacción asistida por IA con revisión independiente.