Saltar al contenido principal
La policy es la parte más importante de un workflow de Omni. Le indica al agente de IA exactamente qué debe comprobar, cómo debe evaluar los documentos y cuándo debe aprobar o rechazar. Una policy bien redactada genera resultados precisos y consistentes. Una vaga produce resultados poco fiables. Esta guía cubre los principios de una redacción de policy eficaz, proporciona plantillas para casos de uso comunes y explica cómo el lenguaje de su policy influye en la selección de engines.

Qué hace buena a una policy

Las buenas policies comparten cuatro características:
CaracterísticaDescripción
EspecíficaIndica exactamente qué campos revisar y qué documentos esperar
EstructuradaUsa pasos numerados que siguen un orden lógico de verificación
DecisivaDefine criterios claros de approve/reject/flag
CompletaCubre todas las comprobaciones que realizaría su proceso manual
El NLP Workflow Generator de Omni analiza su policy para determinar qué engines activar y cómo orquestarlos. Cuanto más preciso sea el lenguaje, más precisa será la selección y ejecución de engines.

Plantilla de estructura de policy

Toda policy debería seguir esta estructura de cuatro partes:
[Objective]
Verify the submitted [document type(s)] for [purpose].

[Input Documents]
Expected documents: [list of document types]

[Verification Steps]
1. Extract [specific fields] from [specific document]
2. Verify that [condition A]
3. Check that [condition B]
4. Cross-validate [field X] against [field Y]
5. Screen [person/entity name] against [database/list]

[Decision Criteria]
- APPROVE if [all success conditions]
- REJECT if [any failure conditions]
- FLAG for manual review if [ambiguous conditions]
No necesita usar exactamente estos encabezados de sección. Lo importante es que su policy cubra las cuatro áreas: objetivo, inputs, pasos y decisiones. Omni analiza el significado, no el formato.

Ejemplos por caso de uso

Verify the submitted business registration documents for corporate entity validation.

Expected documents: business registration certificate, corporate registry extract

Verification steps:
1. Extract company name, registration number, incorporation date, registered address,
   and representative name from the business registration certificate
2. If a corporate registry extract is provided, cross-validate company name and
   registration number between both documents
3. Verify that the incorporation date is in the past and the registration has not expired
4. Check that the registered address includes street, city, and country
5. Screen the representative name against AML/sanctions watchlists
6. Verify that all required fields are present and non-empty

Decision criteria:
- APPROVE if all fields are consistent across documents, no AML matches found,
  and registration is valid and not expired
- REJECT if AML screening returns a high-risk match (SAN-CURRENT, PEP-CURRENT)
  or the registration is expired
- FLAG for manual review if AML returns a partial or medium-risk match,
  or if fields are inconsistent between documents
Engines activados: Text Verifier - Glove, AML Search - Person
Verify the submitted invoice for payment processing approval.

Expected documents: invoice (PDF or image)

Verification steps:
1. Extract vendor name, vendor address, invoice number, invoice date, payment due date,
   line items (description, quantity, unit price, amount), subtotal, tax amount,
   and total amount
2. Verify that all required fields are present: vendor name, invoice number,
   invoice date, at least one line item, and total amount
3. Calculate the expected subtotal from line items (quantity x unit price for each)
   and check it matches the stated subtotal
4. Verify that tax is calculated correctly based on the subtotal
5. Check that the total equals subtotal plus tax
6. Validate that the invoice date is not in the future
7. Validate that the payment due date is after the invoice date

Decision criteria:
- APPROVE if all required fields are present, all calculations are correct,
  and dates are valid
- REJECT if required fields are missing, amounts do not add up,
  or the invoice date is in the future
- FLAG for manual review if minor discrepancies exist (e.g., rounding differences
  less than 1%) or if any field is partially unreadable
Engines activados: Text Verifier - Glove
Review the submitted compliance document to verify regulatory requirements are met.

Expected documents: regulatory license, compliance certificate, or permit document

Verification steps:
1. Extract document type, issuing authority, issue date, expiration date,
   license/permit number, entity name, and scope of authorization
2. Verify that all required sections are present: document header with issuing authority,
   body with license details, signature block, and date fields
3. Check that the expiration date is in the future (document is currently valid)
4. Verify that the entity name on the document matches the expected entity name
5. Confirm that the license/permit number follows the expected format
6. Check that the issuing authority is a recognized regulatory body

Decision criteria:
- APPROVE if all required sections are present, the document is not expired,
  entity names match, and the license number format is valid
- REJECT if the document is expired, required sections are missing,
  or entity names do not match
- FLAG for manual review if the entity name is a close but not exact match,
  or if the issuing authority cannot be verified
Engines activados: Text Verifier - Glove
Screen individuals referenced in the submitted documents against AML/sanctions databases.

Expected documents: any document containing person names (contracts, corporate filings,
partnership agreements, board resolutions)

Verification steps:
1. Extract all person names mentioned in the submitted documents, along with any
   available identifying information (date of birth, nationality, role/title)
2. For each extracted person, perform AML/sanctions watchlist screening
3. Classify screening results by risk level:
   - High risk: current sanctions (SAN-CURRENT), current PEP (PEP-CURRENT),
     regulatory enforcement (REL)
   - Medium risk: linked to PEP (PEP-LINKED), former PEP (PEP-FORMER),
     former sanctions (SAN-FORMER)
   - Low risk: media reports (RRE), insolvency (INS)
4. Summarize all screening results with person name, match status, and risk level

Decision criteria:
- APPROVE if no AML/sanctions matches are found for any screened individual
- REJECT if any individual has a high-risk match
- FLAG for manual review if any individual has a medium-risk or low-risk match
Engines activados: Text Verifier - Glove (para extracción de nombres), AML Search - Person (para screening)

Errores frecuentes

Evite estos errores al redactar policies:
Problema: Omni no sabe qué verificar. “Verify the document” no proporciona información sobre qué campos revisar o qué constituye una aprobación.Solución: Sea explícito sobre qué revisar.
# Mal
Verify the document and check if it is valid.

# Bien
Extract the company name, registration number, and incorporation date from the
business registration certificate. Verify that all fields are present, the
registration number follows a valid format, and the incorporation date is in the past.
Problema: Sin reglas claras de approve/reject, el agente de IA tiene que adivinar qué constituye un resultado aprobado.Solución: Termine siempre su policy con criterios de decisión explícitos.
# Mal
Extract invoice details and check the amounts.

# Bien
Extract invoice details and check the amounts.
- APPROVE if all line item amounts sum to the stated total and all required fields
  are present
- REJECT if amounts do not match or required fields are missing
- FLAG for manual review if amounts match but optional fields are missing
Problema: Omni funciona mejor cuando sabe qué tipo de documento esperar. Sin este contexto, la precisión de extracción puede verse afectada.Solución: Especifique los tipos de documento esperados al inicio de su policy.
# Mal
Check the submitted files for compliance.

# Bien
Review the submitted business registration certificate (PDF or scanned image)
for corporate compliance requirements.
Problema: Incluir demasiadas tareas de verificación no relacionadas en una sola policy dificulta la ejecución limpia del agente de IA. Los resultados se vuelven menos fiables.Solución: Si su proceso involucra tipos de verificación fundamentalmente diferentes (p. ej., validación de facturas Y screening de antecedentes de empleados), divídalos en workflows separados.
# Mal - una policy que hace todo
Verify the vendor invoice, check the vendor's business registration,
screen all directors against AML lists, validate the vendor's insurance
certificate, and confirm their bank account details.

# Bien - dividir en workflows enfocados
Workflow 1 (Invoice): Verify invoice amounts, dates, and required fields
Workflow 2 (Vendor KYB): Validate business registration and screen directors
Workflow 3 (Vendor Compliance): Check insurance certificate and bank details

Relación entre policy y engines

El NLP Workflow Generator de Omni analiza el texto de su policy para sugerir qué engines activar. Comprender este mapeo le ayuda a redactar policies que activen los engines correctos.

AML Search - Person

Este engine se sugiere cuando su policy contiene palabras clave relacionadas con sanciones y screening de listas de vigilancia. Palabras clave de activación:
  • “AML”, “anti-money laundering”
  • “sanctions”, “sanctioned”
  • “watchlist”, “watch list”
  • “screening”, “screen against”
  • “PEP”, “politically exposed”
Frases de ejemplo que activan AML Search:
"Screen the representative name against AML/sanctions watchlists"
"Perform AML screening on all directors"
"Check individuals against sanctions databases"

Text Verifier - Glove

Este engine se sugiere cuando su policy describe tareas de análisis de documentos, extracción de datos o validación de campos. Palabras clave de activación:
  • “extract”, “extraction”
  • “verify”, “validate”, “validation”
  • “check”, “compare”, “cross-check”
  • “match”, “consistency”
  • “present”, “missing”, “required fields”
Frases de ejemplo que activan Text Verifier:
"Extract the company name and registration number from the certificate"
"Verify that all required fields are present"
"Cross-validate the address between the two documents"
"Check that the invoice total matches the sum of line items"
Ambos engines pueden activarse simultáneamente. Por ejemplo, una policy KYB que menciona “extract company details” (Text Verifier) y “screen directors against AML watchlists” (AML Search) sugerirá correctamente ambos engines. Siempre puede modificar manualmente las sugerencias en el Paso 3 de la creación del workflow.

Referencia rápida

Si su policy necesita…EngineFrases clave a incluir
Extraer datos de documentosText Verifier - Glove”extract”, “parse”, “read from”
Validar valores de camposText Verifier - Glove”verify”, “check that”, “validate”
Comparar campos entre documentosText Verifier - Glove”cross-validate”, “compare”, “match between”
Verificar completitud de documentosText Verifier - Glove”required fields”, “all sections present”
Screening de nombres contra listasAML Search - Person”AML screening”, “sanctions check”, “watchlist”
Evaluar riesgo AML/PEPAML Search - Person”risk assessment”, “PEP screening”, “sanctions”

Siguientes pasos

Crear un workflow

Ponga su policy en acción creando un workflow.

Plantillas de workflow

Empiece con una plantilla predefinida y personalícela.