New ID_Check v2.6.11 — a new ID recognition engine improves OCR for Korean documents, PII masking is now set from the dashboard, and submissions can be searched by custom fields (cf1–cf3). See what's new →
New ID_Check v2.6.11 — a new ID recognition engine improves OCR for Korean documents, PII masking is now set from the dashboard, and submissions can be searched by custom fields (cf1–cf3). See what's new →
Guía paso a paso para crear su primer workflow de Omni desde cero.
Esta guía recorre la creación de un workflow en el dashboard de Omni. Un workflow define la lógica de verificación — la policy, los engines y el formato de salida — que Omni aplica cada vez que ejecuta un análisis.
Crear un workflow involucra cuatro pasos en el dashboard. Cada paso se construye sobre el anterior.
1
Paso 1: Información básica
Comience dando a su workflow un nombre y una descripción opcional.
Nombre — Una etiqueta corta y descriptiva para el workflow (p. ej., “Revisión de facturas”, “Verificación KYB de proveedor”). Así identificará el workflow en el dashboard y en las respuestas de la API.
Descripción — Un resumen breve de lo que hace este workflow. Es solo para referencia de su equipo y no afecta cómo Omni procesa los documentos.
Paso 1: Ingrese un nombre y una descripción para el workflow.
Use convenciones de nombres que reflejen el tipo de documento y el propósito de verificación. Por ejemplo: “Factura - Validación de montos” o “KYB - Registro empresarial”. Esto facilita gestionar múltiples workflows en un proyecto.
2
Paso 2: Definición de policy
Escriba una policy en lenguaje natural que describa qué debe verificar Omni. Este es el núcleo de su workflow: le indica al agente de IA qué revisar, qué extraer y cómo tomar decisiones.Su policy debe incluir:
Los tipos de documentos que espera
Los pasos de verificación específicos (qué revisar)
Los criterios de aprobación/rechazo (qué constituye una aprobación vs. un rechazo)
Ejemplo de policy:
Verify the submitted invoice by:1. Extracting the vendor name, invoice number, date, and total amount2. Checking that all required fields are present and non-empty3. Validating that the invoice date is not in the future4. Cross-checking that line item totals match the stated total amount5. Approve if all checks pass; reject if any critical field is missing or amounts do not match
Paso 2: Escriba su policy de verificación en lenguaje natural. Opcionalmente puede subir documentos de policy.
Las policies vagas producen resultados vagos. Sea específico sobre qué documentos esperar, qué campos verificar y cuáles son sus criterios de aprobación. Consulte la Guía de redacción de policies para buenas prácticas detalladas.
3
Paso 3: Selección del modelo de IA
Elija el modelo de IA que usará el workflow.
Modelo
Proveedor
Descripción
Gemma4 12B
ARGOS
Modelo open-source alojado por ARGOS
Claude Sonnet 4.5 (Bedrock)
AWS
Modelo de IA más reciente de Anthropic
Paso 3: Elija el modelo de IA que usará el workflow.
Aquí no se eligen los engines de verificación. Se seleccionan automáticamente a partir de la policy, y puede ver cuáles quedaron asociados en engines de GET /workflows/:workflowId. Para saber qué hace cada engine, consulte Engines.
4
Paso 4: Output Schema
Defina la estructura JSON de los resultados que desea recibir. Esto le indica a Omni exactamente qué formato devolver después del análisis: nombres de campos, tipos de datos y estructura.Ejemplo de output schema:
Use la pestaña Field Builder para añadir campos visualmente, o JSON Schema Input para editar el schema como JSON. La guía de escritura de schema al final del paso resume las reglas de Draft-07 y las restricciones de Omni (ver Output Schema).
Paso 4 — Field Builder: defina campos, tipos y descripciones. Use JSON Schema Preview para validar.
Paso 4 — JSON Schema Input: edite el JSON Schema Draft-07 directamente; se mantiene sincronizado con el Field Builder.
Recomendamos un bloque decision con un campo de resultado, verificationStatus y un array de razones. El sistema no impone esta estructura, y el campo es definido por el usuario — independiente del verificationStatus de nivel superior que asigna el sistema. Alinear el enum con el del sistema (verified / pending_review / rejected) simplifica el routing downstream. Consulte la documentación de Output Schema para más detalles.
Después de completar el Paso 4, Omni muestra una confirmación con su playbook ID y un resumen de acciones del playbook.
Alinee la terminología entre policy, nombres de Item y output schema JSON
Cuando use términos técnicos u objetivos de verificación específicos (como tipos de documento), utilice la misma redacción en los tres lugares siguientes.
Capa
Qué mantener consistente
Policy
Nombres de documentos y etiquetas de objetivos en su policy en lenguaje natural
Nombre del Item
El nombre que da a cada documento al añadirlo a un profile (p. ej., el campo name al crear o subir un Item vía la API)
JSON output schema
Nombres de campos, descripciones y cualquier texto contextual que haga referencia a esos documentos o verificaciones
Por ejemplo, si la policy dice que revisará un certificado de registro empresarial, registre el Item con la misma etiqueta (p. ej., el término equivalente que su equipo usa de forma consistente en coreano o inglés), y use ese mismo término en el output schema donde describe la validación de ese documento. Esa alineación ayuda al agente a conectar de forma confiable la policy, los archivos subidos y los resultados estructurados.En un JSON output schema definido por el cliente, mantenga alineadas también las descripciones y el contexto de valores específicos. Por ejemplo, si un campo como document_validation es true, la descripción asociada debe referirse al mismo tipo de documento (p. ej., registro empresarial) y aclarar qué significa “información suficiente” (nombre de la empresa, dirección, representante y otros campos esperados en ese documento).
En tiempo de ejecución, cada vez que añada un Item, establezca item.name (o el campo name del Item en la API) para que coincida con la redacción de la policy y la terminología usada en su JSON output schema. Si estos divergen, el agente puede mapear incorrectamente documentos y campos.
Data Objects — los nombres de Item que se muestran aquí (p. ej., certificado de registro empresarial) deben coincidir con su policy y output schema.
Una vez completados los cuatro pasos, su workflow está listo para usarse. Puede abrirlo desde la lista de workflows para gestionar profiles y análisis, o revisar policy, engines y output schema desde la vista de configuración del workflow.
Detalle del workflow — profiles, cantidad de análisis y Workflow modification.
Configuración del workflow — definición de policy, engines seleccionados y JSON output schema (después de la creación o mediante edición).
Haga polling del estado de los items hasta que todos los documentos cargados alcancen el estado ACTIVE. Esto significa que el OCR y la extracción de texto se completaron.
curl -X GET "https://client-omni-api.argosidentity.com/v1/profiles/{profileId}/items/status" \ -H "x-api-key: your-api-key-here"
Haga polling cada 1 segundo con un timeout de 60 segundos. No dispare el análisis hasta que todos los items estén en ACTIVE.
4
Disparar el análisis
Ejecute el análisis. Omni aplica automáticamente su policy, engines y output schema.
curl -X POST "https://client-omni-api.argosidentity.com/v1/profiles/{profileId}/analyze" \ -H "x-api-key: your-api-key-here"
5
Recuperar resultados
Obtenga los resultados estructurados que coinciden con su output schema.
curl -X GET "https://client-omni-api.argosidentity.com/v1/profiles/{profileId}" \ -H "x-api-key: your-api-key-here"
Para el flujo API completo con ejemplos detallados de solicitud/respuesta, consulte la Guía de inicio rápido.
Si su caso de uso coincide con una de las plantillas de workflow (KYB, factura, AML, compliance), empiece por allí y personalice. Es más rápido que construir desde cero.
Pruebe con documentos reales
Después de crear un workflow, ejecute algunos profiles de prueba con documentos reales para validar que su policy y schema produzcan los resultados esperados. Ajuste según sea necesario.
Itere sobre su policy
Su primer borrador de policy puede no ser perfecto. Revise los resultados del análisis, identifique dónde la IA malinterpretó su intención y refine el lenguaje de la policy. Pequeños cambios en la redacción pueden mejorar significativamente la precisión.
Mantenga los output schemas alineados con sus sistemas
Diseñe su output schema para que coincida con lo que su backend o sistema de compliance espera. Esto elimina la necesidad de transformaciones de postprocesamiento.
