Automatización de workflows

Si su equipo dedica tiempo a revisar documentos manualmente — comprobando campos, validando datos, haciendo screening de nombres — Omni puede automatizar gran parte de ese trabajo. Esta guía le ayuda a pensar cómo convertir sus Procedimientos Operativos Estándar (SOPs) existentes en workflows de Omni.

Identificar oportunidades de automatización

No todos los procesos son aptos para la automatización. Busque estas señales de que su proceso manual de revisión está listo para Omni:

Señal	Por qué importa
Verificaciones repetitivas	Los mismos pasos de verificación se aplican a cada documento
Criterios consistentes	Las decisiones de aprobación/rechazo siguen reglas definidas, no juicios subjetivos
Alto volumen	Su equipo procesa decenas o cientos de documentos por día/semana
Riesgo de error humano	El cansancio o la inconsistencia generan problemas no detectados
Inputs estructurados	Los documentos siguen un formato predecible (facturas, certificados de registro, formularios)

Procesos habituales que Omni puede automatizar

Verificación de facturas — Comprobar montos, fechas, detalles del proveedor, totales de partidas
Onboarding de proveedores — Validar documentos de registro empresarial y hacer screening contra listas AML
Revisión de formularios de compliance — Verificar que los campos requeridos estén presentes y sean válidos
Validación de registros empresariales — Extraer y cruzar datos de la empresa
Revisión de contratos — Verificar términos clave, fechas e información de las partes
Verificación de documentos de empleados — Validar certificaciones, licencias o documentos de identidad presentados

Omni funciona mejor con procesos que tienen reglas claras y documentables. Si su proceso de revisión depende mucho de juicio subjetivo o conocimiento institucional que no puede documentarse, puede que convenga automatizarlo de forma parcial en lugar de total.

Mapear su SOP a un workflow de Omni

Siga estos cinco pasos para convertir un proceso manual en un workflow de Omni.

Documente su proceso manual actual

Antes de construir nada en Omni, anote exactamente cómo su equipo maneja actualmente la revisión:

Quién realiza la revisión?
Qué documentos reciben?
Qué revisan en cada documento?
Qué decisiones toman (aprobar, rechazar, escalar)?
Adónde van los resultados después de la revisión?

Esto se convierte en su línea base. Traducirá cada punto a la configuración de Omni.

Identifique los documentos de entrada

Liste cada tipo de documento que se envía para revisión. Sea específico:

Es un PDF de factura? Un certificado de registro empresarial escaneado? Una hoja de cálculo?
Hay múltiples documentos por caso, o solo uno?
Los documentos necesitan cruzarse entre sí?

Omni admite JPG, PNG, PDF, TXT, DOC, DOCX, XLS, XLSX, BMP, TIFF, WEBP, CSV, HTML y MD. Hasta 5 items por folder. Si un caso involucra más de 5 documentos, agrupe documentos relacionados en múltiples folders dentro del mismo profile.

Defina criterios de pass/fail

Para cada verificación que realiza su equipo, anote los criterios exactos:

Qué hace que un documento sea aceptable? (p. ej., “Todos los campos requeridos están presentes y el total coincide con las partidas”)
Qué hace que un documento sea rechazado? (p. ej., “La fecha de la factura está en el futuro” o “El registro empresarial está vencido”)
Qué desencadena la escalación a un revisor senior? (p. ej., “El screening AML devuelve una coincidencia” o “Campos clave son ilegibles”)

Estos criterios se convierten en la lógica de decisión de su policy de Omni.

Escríbalo como una policy en lenguaje natural

Combine las verificaciones y criterios de los pasos anteriores en una declaración de policy estructurada. Use pasos numerados y lenguaje explícito.Plantilla:

Review the submitted [document type] by performing the following checks:
1. Extract [list of fields] from the document
2. Verify that [specific condition]
3. Check that [another condition]
4. [Additional verification steps]

Decision criteria:
- APPROVE if all checks pass and all required fields are present
- REJECT if [specific failure conditions]
- FLAG for manual review if [ambiguous conditions]

Consulte la Guía de redacción de policies para ejemplos detallados y buenas prácticas.

Defina qué datos necesita extraer

Decida qué datos estructurados necesitan sus sistemas downstream de cada revisión. Esto se convierte en su output schema.Pregúntese:

Qué campos espera su sistema backend?
Necesita los valores extraídos en bruto, o solo el resultado pass/fail?
La salida debe incluir las razones de la decisión?

Diseñe el JSON output schema para que coincida exactamente con estos requisitos.

Ejemplos del mundo real

Estos ejemplos muestran cómo los procesos de revisión manual se traducen en workflows de Omni.

Ejemplo 1: Revisión de facturas

Antes: proceso manual

Un miembro del equipo de finanzas abre cada PDF de factura y verifica manualmente:

Que el nombre del proveedor y el número de factura estén presentes
Que la fecha de factura sea razonable (no en el futuro, no mayor a 90 días)
Que los montos de las partidas sumen el total indicado
Que los cálculos de impuestos sean correctos
Que no haya números de factura duplicados en el sistema

Tiempo por factura: 5-10 minutos. Tasa de error: ~3% (errores de cálculo no detectados, duplicados pasados por alto).

Después: workflow de Omni

Policy:

Verify the submitted invoice document by:
Extracting vendor name, invoice number, invoice date, line items, subtotal, tax, and total amount
Verifying all required fields are present and non-empty
Validating that the invoice date is not in the future and not older than 90 days
Checking that the sum of line item amounts equals the stated subtotal
Verifying that tax is calculated correctly based on the subtotal
Approve if all checks pass; reject if amounts do not match or required fields are missing; flag for manual review if date is borderline

Engines: Text Verifier - Glove (extraer y validar todos los campos)Output schema:

{
  "invoice": {
    "vendorName": "string",
    "invoiceNumber": "string",
    "invoiceDate": "string",
    "lineItems": ["string"],
    "subtotal": "number",
    "tax": "number",
    "totalAmount": "number"
  },
  "validation": {
    "allFieldsPresent": "boolean",
    "dateValid": "boolean",
    "amountsMatch": "boolean",
    "taxCorrect": "boolean"
  },
  "decision": {
    "result": "APPROVE | REJECT | MANUAL_REVIEW",
    "verificationStatus": "verified | pending_review | rejected",
    "reasons": ["string"]
  }
}

Resultado: El tiempo de revisión baja de 5-10 minutos a segundos para facturas sencillas. El equipo solo maneja los casos marcados manualmente.

Ejemplo 2: Onboarding de proveedores

Antes: proceso manual

Cuando se incorpora un nuevo proveedor, un oficial de compliance:

Revisa el certificado de registro empresarial buscando nombre de la empresa, número de registro y fecha de constitución
Verifica el documento de identidad del representante
Busca manualmente el nombre del representante en bases de datos AML/sanciones
Cruza los datos de la empresa entre documentos
Registra los resultados en una hoja de cálculo

Tiempo por proveedor: 20-30 minutos. Cuello de botella: la búsqueda AML es lenta y la consulta manual es propensa a errores.

Después: workflow de Omni

Policy:

Verify vendor onboarding documents by:
Extracting company name, registration number, incorporation date, and representative name from the business registration certificate
Screening the representative's name against AML/sanctions watchlists
Cross-validating the representative name between the business registration and any submitted identity documents
Checking that the business registration is not expired
Approve if no AML matches found, all fields are consistent, and registration is valid; reject if AML screening returns a high-risk match; flag for manual review if AML returns a partial match or fields are inconsistent

Engines: Text Verifier - Glove + AML Search - PersonOutput schema:

{
  "company": {
    "name": "string",
    "registrationNumber": "string",
    "incorporationDate": "string",
    "representativeName": "string"
  },
  "amlScreening": {
    "screened": "boolean",
    "matchFound": "boolean",
    "riskLevel": "string",
    "matchDetails": "string"
  },
  "validation": {
    "fieldsConsistent": "boolean",
    "registrationValid": "boolean"
  },
  "decision": {
    "result": "APPROVE | REJECT | MANUAL_REVIEW",
    "verificationStatus": "verified | pending_review | rejected",
    "reasons": ["string"]
  }
}

Resultado: El screening AML es automático e instantáneo. Los casos limpios se aprueban automáticamente. El oficial de compliance se enfoca solo en los proveedores marcados.

Ejemplo 3: Verificación de documentos de compliance

Antes: proceso manual

Un equipo de compliance revisa documentos regulatorios presentados:

Verifica que todas las secciones requeridas estén presentes (encabezado, firma, fechas, números de licencia)
Comprueba que las fechas de vencimiento estén en el futuro
Confirma que el documento está dirigido a la entidad correcta
Valida que los números de referencia coincidan con los registros internos

Tiempo por documento: 10-15 minutos. Riesgo: documentos vencidos ocasionalmente se filtran durante períodos de alto volumen.

Después: workflow de Omni

Policy:

Review the submitted compliance document by:
Extracting the document type, issuing authority, issue date, expiration date, license number, and entity name
Verifying that all required sections are present: header, body, signature block, and dates
Checking that the expiration date is in the future
Validating that the entity name matches the expected entity
Approve if all sections are present, the document is not expired, and entity names match; reject if the document is expired or missing required sections; flag for manual review if the entity name is a partial match

Engines: Text Verifier - Glove (validar completitud y corrección de campos)Output schema:

{
  "document": {
    "type": "string",
    "issuingAuthority": "string",
    "issueDate": "string",
    "expirationDate": "string",
    "licenseNumber": "string",
    "entityName": "string"
  },
  "validation": {
    "allSectionsPresent": "boolean",
    "notExpired": "boolean",
    "entityNameMatch": "boolean"
  },
  "decision": {
    "result": "APPROVE | REJECT | MANUAL_REVIEW",
    "verificationStatus": "verified | pending_review | rejected",
    "reasons": ["string"]
  }
}

Resultado: Los documentos vencidos se detectan automáticamente. Los revisores solo manejan casos límite donde los nombres coinciden parcialmente o las secciones son ambiguas.

Diseñar output schemas efectivos

Su output schema determina qué datos estructurados obtiene de cada análisis. Diséñelo pensando en sus sistemas downstream. Todo output schema debería incluir estos tres bloques:

Bloque	Propósito	Campos de ejemplo
Datos extraídos	Valores en bruto obtenidos de los documentos	`vendorName`, `invoiceNumber`, `registrationDate`
Resultados de validación	Pass/fail por verificación con razones	`amountsMatch`, `dateValid`, `fieldsConsistent`
Decisión	Veredicto final y estado de routing	`result`, `verificationStatus`, `reasons`

Si omite el bloque de decisión, tendrá que escribir su propia lógica de decisión basada en los resultados de validación en bruto. Incluir un bloque de decisión permite que el agente de IA tome la decisión final basándose en los criterios de su policy.

Routing con `verificationStatus`

Cada respuesta de análisis incluye en el nivel superior un verificationStatus asignado por el sistema: verified, pending_review o rejected. Ramifique sus integraciones basándose en ese enum.

Si su output schema define un campo con el mismo nombre dentro del bloque de decisión, ese es un valor definido por el usuario y es independiente de este veredicto del sistema. Consulte GET /analyses/:analysisId para la distinción completa.

verificationStatus	Acción recomendada
`verified`	Aceptar automáticamente y registrar en sus sistemas
`pending_review`	Enviar a una cola humana con los hallazgos de IA y datos extraídos
`rejected`	Denegar o cerrar el caso según su policy

Este enfoque significa que Omni no reemplaza completamente a su equipo de revisión. Aprueba automáticamente los casos directos y envía los ambiguos o fallidos a la cola correcta con contexto.

Monitoree la frecuencia con que aparece cada estado y compare con los resultados manuales. Ajuste el lenguaje de la policy o su output schema cuando las tasas de pending_review o rejected se desvíen de las expectativas.

Patrón de implementación

if verificationStatus == "verified":
    → auto-accept, record in system
elif verificationStatus == "pending_review":
    → send to reviewer queue with AI findings highlighted
else:  # rejected
    → denial flow or manual escalation per policy

Integre esta lógica en su backend después de recuperar los resultados del análisis de la Omni API.

Medir el éxito

Después de desplegar un workflow de Omni, monitoree estas métricas para medir el impacto:

Métrica	Cómo medir	Objetivo
Reducción del tiempo de revisión	Tiempo promedio por caso antes vs. después	Reducción del 50-80% para casos auto-aprobados
Tasa de error	Porcentaje de decisiones incorrectas (compare resultados de Omni con verificaciones manuales puntuales)	Igual o menor que la tasa de error manual
Throughput	Casos procesados por día/semana	Aumento significativo por el procesamiento automático
Tasa de escalación	Porcentaje de casos enviados a revisión humana	Debería disminuir con el tiempo a medida que refina las policies

Enfoque de despliegue recomendado

Piloto con un solo workflow

Elija su proceso de revisión de mayor volumen y más basado en reglas. Cree un workflow de Omni para él y ejecútelo en paralelo con su proceso manual durante 1-2 semanas.

Compare resultados

Verifique las decisiones de Omni contra las decisiones manuales de su equipo. Busque discrepancias e investigue si Omni o el revisor humano tenía razón.

Refine la policy

Basándose en la comparación, ajuste el lenguaje de su policy, output schema o umbrales de puntuación. Pequeños cambios suelen producir mejoras significativas.

Expanda gradualmente

Una vez validada la precisión, deje que Omni maneje el proceso de punta a punta. Luego pase a automatizar procesos de revisión adicionales.

Primeros Pasos

Plantillas de Flujo de Trabajo (Próximamente)

Automatización de workflows

Identificar oportunidades de automatización

Procesos habituales que Omni puede automatizar

Mapear su SOP a un workflow de Omni

Ejemplos del mundo real

Ejemplo 1: Revisión de facturas

Ejemplo 2: Onboarding de proveedores

Ejemplo 3: Verificación de documentos de compliance

Diseñar output schemas efectivos

Routing con `verificationStatus`

Patrón de implementación

Medir el éxito

Enfoque de despliegue recomendado

Siguientes pasos

Crear un workflow

Guía de redacción de policies

​Identificar oportunidades de automatización

​Procesos habituales que Omni puede automatizar

​Mapear su SOP a un workflow de Omni

​Ejemplos del mundo real

​Ejemplo 1: Revisión de facturas

​Ejemplo 2: Onboarding de proveedores

​Ejemplo 3: Verificación de documentos de compliance

​Diseñar output schemas efectivos

​Routing con verificationStatus

​Patrón de implementación

​Medir el éxito

​Enfoque de despliegue recomendado

​Siguientes pasos

Crear un workflow

Guía de redacción de policies

Identificar oportunidades de automatización

Procesos habituales que Omni puede automatizar

Mapear su SOP a un workflow de Omni

Ejemplos del mundo real

Ejemplo 1: Revisión de facturas

Ejemplo 2: Onboarding de proveedores

Ejemplo 3: Verificación de documentos de compliance

Diseñar output schemas efectivos

Routing con `verificationStatus`

Patrón de implementación

Medir el éxito

Enfoque de despliegue recomendado

Siguientes pasos