--- schema_version: "1" id: 0f617b3eb18e3b7929b462066d7ebd8e02891b501cf6108debe6ca11459f6e46 title: IA de documento de Data 360 collection: architect version: current locale: es-mx portal_url: https://docs.salesforce.com/architect/current/es-mx/fundamentals/guides/data360-document-ai.md canonical_url: https://architect.salesforce.com/docs/architect/es-mx/fundamentals/guide/data360-document-ai.html source_site: architect.salesforce.com content_type: documentation content_hash: 76e17d1be219e90893311e967a75e63913b87cfc25db91356eb10d47d886ae0b products: - Fundamentos - Architect Site Content Repo updated_at: 2026-07-01T00:00:00Z --- ## Descripción general Las compañías gestionan una amplia gama de tipos de documentos, incluyendo facturas, pedidos de compra, contratos legales y manuales técnicos. El procesamiento manual es lento, proclive a errores y consume un estimado del 15 al 25% del tiempo de los empleados. Los enfoques de automatización anteriores (por ejemplo, _Automatización de procesos robóticos (RPA)_, _Reconocimiento óptico de_ caracteres (OCR) y herramientas de flujo de trabajo) redujeron parte de la carga, pero produjeron oportunidades en curso rígidas, altos gastos generales de mantenimiento y adopción de silos entre equipos de negocio individuales. Los documentos llevan contexto estructural enriquecido (por ejemplo, jerarquías de tablas, relaciones de campos espaciales y secciones de referencia cruzada) que el procesamiento de texto plano no puede conservar. Eliminar un documento en texto sin formato descarta el contexto de negocio que hace que la extracción sea precisa y útil, lo que degrada la calidad de análisis descendente, inferencia de _Inteligencia artificial (_IA) y automatización de procesos. Para ser efectivos, los sistemas de _Procesamiento inteligente de_ documentos deben clasificar documentos por tipo, extraer datos estructurados con precisión desde formatos de variable y entregar esos datos de forma gobernada y consultable a sistemas descendentes. Los IDP también deben gestionar la variabilidad de documentos a escala sin requerir configuración por plantilla para cada nuevo formato de documento, y deben estar centralizados y ser accesibles entre unidades de negocio. Este reto se ve agravado por el gran volumen del problema clave: Los datos no estructurados representan aproximadamente el 80% de todos los datos de la compañía, y la mayoría se acumulan en forma de documentos entre sistemas de archivos, almacenamiento en la nube y repositorios de contenido que están fuera del alcance de los sistemas de Gestión de _relaciones con clientes (CRM)_, agentes de IA y plataformas de análisis. La _IA de documentos_ de Data 360 es la función de procesamiento de documentos de Salesforce en _Data 360_, que está diseñada para solucionar esta brecha. Extrae, clasifica y analiza contenido de documentos no estructurado y semiestructurado utilizando _Modelos de lenguaje grande_, _Reconocimiento óptico de caracteres_, _Procesamiento de lenguaje natural_ y _Aprendizaje automático_. El resultado son datos estructurados, gobernados y consultables que se integran en las oportunidades en curso de _Data 360_ donde los agentes _Agentforce_, las herramientas de análisis y los flujos de trabajo de automatización pueden acceder a ellos a través de interfaces estándar sin requerir capas de extracción o transformación personalizadas. ## ¿Por qué importa la IA de documentos? Las plataformas de datos de compañía procesan datos tabulares estructurados. Sin embargo, la mayoría de los datos de la compañía llegan como documentos y permanecen inaccesibles para agentes de CRM, ERP, IA y oportunidades en curso de análisis hasta que alguien los extraiga manualmente. Esta es una brecha arquitectónica, no un problema de flujo de trabajo. ### Limitaciones de la extracción basada en reglas Los enfoques anteriores combinaban el cambio manual de claves, el OCR basado en reglas y las secuencias de comandos RPA. Estos métodos funcionaban a pequeña escala, pero no podían gestionar el volumen, la variedad y la velocidad de los tipos de documentos que generan las empresas modernas. Las herramientas basadas en reglas requieren plantillas explícitas por variante de formato. Cualquier cambio de formato interrumpe la extracción y requiere un desarrollador, una nueva plantilla y un ciclo de implementación. A escala, esto produce soluciones de puntos frágiles sin gobernanza centralizada, esquema compartido y ruta a la preparación para la IA. Las oportunidades en curso de extracción incoherentes se propagan aguas abajo. En otras palabras, los análisis heredan incoherencias de datos, los modelos de IA producen resultados poco fiables y el contenido regulado como _Información de salud personal_ e _Información de identificación personal_ carece de gobernanza sistemática. ### Procesamiento de documentos nativo de IA Los LLM extraen campos sin plantillas explícitas. Una configuración de esquema única rige la extracción entre variantes de formato, idiomas y formatos, que se adapta al documento en vez de requerir que el documento se ajuste a una estructura fija. Esto cambia el procesamiento de documentos de una operación de silo con gran carga de mantenimiento a una función centralizada y gobernada. ![Descripción general de la IA de documentos de Data 360 mostrando cómo las oportunidades en curso por lotes y transaccionales convierten documentos no estructurados en datos gobernados y consultables](https://architect.salesforce.com/ns-assets/data360-doc-ai/data360-document-ai-overview.png) La _IA de documentos_ de Data 360 pone en marcha el procesamiento de documentos en la plataforma _Data 360_ a través de dos oportunidades en curso. - Las _Oportunidades en curso_ por lotes enrutan datos extraídos a través de ingreso, resolución de identidad, perspectivas calculadas, activaciones, análisis y activación Agentforce. - Las _Oportunidades en curso_ de procesamiento de transacciones exponen una API de REST que devuelve _JSON_ estructurado de forma síncrona, lo que permite a los arquitectos enrutar datos derivados de documentos a _SObjects_ de Salesforce, las oportunidades en curso _Objeto de lago_ de datos / _Objeto de modelo_ de datos (DLO/DMO) o bases de datos externas y almacenes sin sobrecarga de configuración por lotes. En ambos casos, los datos extraídos ingresan en un modelo gobernado dirigido por esquemas en vez de un conjunto fragmentado de herramientas de puntos. ## Producto en ámbito La [IA de documentos](https://help.salesforce.com/s/articleView?id=data.c360_a_document_ai.htm&type=5) de Data 360 es la función nativa de Salesforce _Procesamiento inteligente de_ documentos (IDP) en la plataforma _Data 360_. Convierte contenido de documento no estructurado y semiestructurado en datos gobernados y consultables que participan completamente durante todo el ciclo de vida de _Data 360_. ## ¿Qué es la IA de documentos de Data 360? La [IA de documentos](https://help.salesforce.com/s/articleView?id=data.c360_a_document_ai.htm&type=5) de Data 360 es la función nativa de Salesforce _Procesamiento inteligente de_ documentos (IDP) en _Data 360_. Ingresa documentos no estructurados y semiestructurados, extrae datos estructurados utilizando una configuración de esquema declarativo y entrega esos datos a las oportunidades en curso de _Data 360_ para Armonización, Resolución de identidad, Análisis y Activación Agentforce. La IA de documentos de Data 360 admite dos modalidades de procesamiento: - **Procesamiento por lotes masivo:** Procesa conjuntos de documentos de gran tamaño que se definen en _Objetos de modelo_ de datos no estructurados (UDMO) en base a eventos. - **Procesamiento transaccional:** Procesa un único documento a través de la API de REST y devuelve una carga _JSON_ estructurada de forma síncrona. Los arquitectos pueden enrutar esa carga a las oportunidades en curso de DLO/DMO de _Data 360_, _los objetos_ de Salesforce o las bases de datos y almacenes externos a través de _MuleSoft_, llamadas _Apex_ o _Einstein Trust Layer (ETL)_. El nivel de destino es una decisión arquitectónica dirigida por los requisitos de latencia, gobernanza y residencia de datos. La IA de documentos admite actualmente archivos PDF, archivos de imagen (JPEG, PNG) y documentos manuscritos. ## Componentes principales La _IA de documentos_ de Data 360 reúne cuatro tecnologías de procesamiento en una única canalización gobernada. Cada componente gestiona una etapa distinta del ciclo de vida de documento a datos: - **Reconocimiento óptico de caracteres (OCR):** Convierte imágenes escaneadas, contenido manuscrito y PDF basados en imágenes en texto legible por máquina antes del procesamiento LLM. Se recomienda un mínimo de 150 ppp para una extracción fiable. - **Modelos de lenguaje grande (LLM):** Enrute la extracción a través de la pasarela _Einstein_ LLM utilizando el modelo elegido por el usuario. El LLM recibe la salida de OCR junto con la configuración del esquema _JSON_ y devuelve una carga de extracción estructurada. Se están planificando modelos _de Géminis_ y modelos adicionales para su futura aplicación. - **Procesamiento del lenguaje natural (NLP):** Realiza comprensión contextual, reconocimiento de entidades, análisis de fechas y extracción de campos semánticos directamente en el LLM a través de ingeniería de solicitudes estructurada: la solicitud definida por esquema y la salida de OCR sirven como las únicas entradas. Todas las interacciones LLM se enrutan a través del ETL, que aplica retención de datos cero con proveedores de modelo y enmascara el _PII_ en entradas basadas en texto antes de que lleguen al modelo. No se emplea ningún motor NLP separado. - **Procesamiento multimodal:** Procesa imágenes incrustadas en PDF como entradas de extracción separadas, lo que permite al LLM extraer datos de diagramas, tablas representadas por imágenes y páginas de contenido mixto que OCR por sí solo no puede analizar. Además de las cuatro tecnologías de procesamiento, la _IA de documentos_ también gestiona: - **Capa Einstein Trust:** Enruta todas las interacciones de LLM a través del ETL, que aplica retención de datos cero con proveedores de modelos y enmascara _PII_ antes de que las entradas lleguen al LLM con la excepción de datos multimodales (por ejemplo, documentos adjuntos que se procesan a través de _IA de documentos_) donde el enmascaramiento de PII no es compatible actualmente y los datos se envían tal cual a modelos externos. El ETL solo rige la ruta de interacción LLM. Los datos extraídos que se redactan en _Objetos de lago_ de datos se almacenan tal cual; el enmascaramiento a nivel de campo en periodos de inactividad debe solucionarse a través de controles de regulación de datos descendentes. - **Límites de tamaño de archivo:** La _IA de documentos_ procesa archivos de hasta 10MB por solicitud. Los límites de longitud de contexto LLM pueden restringir aún más el procesamiento para documentos densos de varias páginas dentro de este límite. ## Principios arquitectónicos clave Los arquitectos de compañía que están implementando la _IA de documentos_ de Data 360 deben aplicar estos principios antes de comprometerse a un diseño de implementación. - **Seleccione la canalización antes de diseñar el esquema.** Las oportunidades en curso de procesamiento _por lotes_ y _transaccionales_ difieren en modelo de ingreso, vinculación de esquemas, flexibilidad de destino y latencia. Es importante confirmar qué oportunidades en curso requiere cada caso de uso antes de definir el esquema como la actualización agrega una renovación evitable. - **Diseñe esquemas a nivel de tipo de documento.** El uso de un esquema único y bien elaborado por tipo de documento es más mantenible que el uso de configuraciones por caso, y también es la palanca más grande para la calidad de extracción. Hacer esto correctamente requiere el uso de un conjunto diverso de documentos, incluyendo casos extremos, en vez de diseñar desde un único ejemplo. Utilice solicitudes de forma iterativa en los niveles de _campo_, _tabla_ y _esquema_ para encontrar brechas, y luego pruébelas y ajústelas con múltiples muestras de documentos antes de finalizar. Tenga en cuenta que un esquema que funciona bien en un documento puede quedarse corto en otros, por lo que la amplitud y la iteración son esenciales. La flexibilidad de esquema, incluyendo la eliminación de columnas que no se extraen de forma fiable entre tipos de documentos, es igualmente importante. Mantenerse en campos que introducen ruido o incoherencia socava la calidad general de la extracción, de modo que es importante tratar la eliminación de columnas como una decisión de diseño de primera clase. - **Seleccione el nivel de destino correcto por grupo de campos.** Los campos que dirigen flujos de trabajo o aprobaciones de CRM se redactan en _SObjects_. Los campos que están enriqueciendo el perfil unificado o los análisis de noticias en tiempo real pertenecen a las oportunidades en curso de _DLO/DMO_. Los campos que sirven sistemas externos pertenecen al nivel _RDBMS_. Tenga en cuenta que un esquema único puede extenderse a múltiples niveles simultáneamente. - **Aplique la regulación antes de procesar contenido regulado.** Los datos regulados necesitan protección en cada capa. Es por eso que es importante configurar el enmascaramiento de _PII_, las etiquetas de clasificación de datos y el Control de acceso basado en _atributos (ABAC)_ después de almacenar los datos extraídos en los _Objetos de lago de datos (DLO) de salida._ Esto proporciona una aplicación más precisa y acceso consciente del contexto que se basa en la clasificación de datos, la función de usuario y el contexto organizativo. La _gobernanza_ se divide en dos vías: el _ELT_ rige la interacción LLM, mientras que los datos extraídos almacenados en los DLO deben gobernarse por separado (directamente a nivel de DLO y base de datos) a través de configuraciones de _Espacio de datos_, _Conjuntos de permisos_ y políticas _ABAC_. Estos controles deben mantener la coherencia en el nivel de almacenamiento (no solo la capa de aplicación), de modo que las restricciones de acceso permanecen intactas independientemente de cómo se acceda a los datos después del ingreso. Tenga en cuenta que las brechas en cualquier capa pueden exponer datos regulados aguas abajo incluso cuando otros están configurados correctamente. - **Diseño para modos de fallo antes de la producción.** Trate la gestión de campos nulos, los umbrales de calidad de OCR, la validación previa del tamaño de archivo, el desbordamiento del contexto LLM, la idempotencia de escritura RDBMS y los límites de presupuesto de crédito antes de la primera ejecución por lotes de producción. Estos no son casos extremos: son superficies de fallo predecibles que deben tratarse explícitamente en el diseño de oportunidades en curso, no descubrirse durante el tiempo de ejecución. - **Trate los puntuajes de confianza como una señal de enrutamiento de primera clase, no como una idea posterior al diagnóstico.** Los resultados de extracción llevan valores de confianza a nivel de campo derivados de las probabilidades de registro (logprobs) del resultado del modelo subyacente. Para cada campo, tabla o columna extraídos, el puntuaje refleja la certeza a nivel de token del modelo del valor extraído. Esto hace que los puntuajes de confianza sean una señal fundamentada estadísticamente lo suficientemente fiable como para servir como la puerta principal para umbrales de distribución _humana en bucle_. Utilice puntuajes de confianza para identificar sistemáticamente extracciones de baja calidad e iniciar puntos de control HITL para valores de campo de baja confianza, coincidencias de esquemas ambiguas o fallos de oportunidades en curso repetidos en vez de basarse en heurística o comprobaciones puntuales manuales. Cuando la recuperación automatizada no es posible, el puntuaje de confianza respaldado por HITL garantiza que el juicio humano se aplica exactamente donde se necesita. - **Diseñe rutas de activación en paralelo con el diseño de esquemas.** El valor de la _IA de documentos_ proviene de la capacidad de activar datos extraídos en agentes y flujos de trabajo de Salesforce. Le permite diseñar _Acciones_, _Flujos_ y _Perspectivas calculadas de_ Agentforce junto con el diseño de esquemas de extracción, no después. ## Arquitectura: Canalizaciones de IA de documentos de Data 360 La _IA de documentos_ funciona en dos oportunidades en curso: - Una canalización _por lotes_ para un procesamiento de gran volumen respaldado por UDMO - Una canalización de _procesamiento_ _transaccional_ para la extracción en tiempo real dirigida por API Ambas oportunidades en curso comparten el mismo contrato de configuración de esquema y la misma regulación de ETL, pero difieren en cómo entran los documentos en el sistema y dónde llegan los datos extraídos. Echemos un vistazo más de cerca a cada canalización. ### Canalizaciones de procesamiento por lotes Las oportunidades en curso _por lotes_ procesan conjuntos de documentos recurrentes definidos por un UDMO. Se adapta a casos de uso programados o dirigidos por eventos en los que los documentos se ingresan desde el almacenamiento de la compañía, luego pasan por la extracción de documentos y se entregan a las oportunidades en curso de _DATA 360 DLO/DMO_ para Armonización, Resolución de identidad y Activación. **Escenario del mundo real** Cada día, un asegurador recibe miles de documentos de reclamaciones médicas de portales de proveedores que se cargan como PDF en _Amazon S3_. El UDMO define el conjunto de documentos dentro del ámbito y envía todos los PDF de reclamaciones al depósito de `/claims/incoming/` en un plazo de 24 horas. ![Oportunidades en curso de procesamiento por lotes para reclamaciones médicas de una compañía de seguros, desde el ingreso hasta Armonización, Resolución de identidad y Activación Agentforce](https://architect.salesforce.com/ns-assets/data360-doc-ai/data360-document-ai-batch-processing.png) #### Etapa 1: Ingerir Los documentos se ingresan en _Data 360_ desde sistemas de origen de compañía sin duplicación física. Las fuentes compatibles incluyen _Amazon S3_, _Google Cloud Storage_, objetos de archivos de Salesforce CRM, oportunidades en curso _orquestadas por MuleSoft_ y cargas de API directas. En implementaciones de _Headless 360_, los documentos se ingresan a través de conectores de almacenamiento en la nube o la _API de ingreso_, que omite la capa de CRM. El servidor _Model Context Protocol (MCP)_ expone el ingreso como una herramienta llamable para agentes de IA externos y clientes LLM. Al ingresar, los documentos sin procesar se almacenan como _Objetos de lago de datos no estructurados (UDLO)_, que se asignan a la ubicación física y los metadatos de cada documento sin mover o transformar el archivo de origen. **Ejemplo:** Los archivos PDF de reclamaciones se ingresan desde _S3_ en _Data 360_ a través del conector de almacenamiento en la nube. Cada documento se almacena como un UDLO que apunta al objeto _S3_. No se produce ninguna duplicación física. #### Etapa 2: Extraer La _IA de documentos_ procesa cada UDLO con una configuración de esquema que define qué campos extraer junto con sus tipos de datos de destino. El UDMO define qué documentos están en el ámbito. El LLM (_GPT-4o_, _Géminis_ o _Claude_) lee cada documento y devuelve una carga de extracción estructurada. **Ejemplo:** La _IA de documentos_ procesa cada UDLO con un esquema de reclamaciones que define campos como: ClaimID, PatientName, DiagnosisCode, BillingAmount y ServiceDate. Los LLM luego leen cada PDF y devuelven una carga de extracción estructurada. #### Etapa 3: Persistir Una vez extraídos los datos, persisten en los DLO, que son la capa de almacenamiento sin procesar de _Data 360_. Los DLO conservan los campos extraídos sin imponer lógica de negocio, lo que mantiene una representación física precisa para la trazabilidad y la transformación descendente. El UDLO mantiene una referencia al documento de origen para activar el linaje a nivel de campo en cualquier punto de las oportunidades en curso. **Ejemplo:** Todos los campos extraídos llegan a un _DLO de reclamaciones_, lo que mantiene una representación precisa y sin procesar de cada reclamación con un linaje completo que se puede rastrear hasta el PDF de origen. #### Etapa 4: Armonizar Los campos de DLO se asignan a DMO que se alinean con el _Modelo de datos Customer 360_ estándar. Este es el límite donde los datos derivados de documentos pasan de campos sin procesar extraídos a entidades con sentido de negocio. El _DLO de factura_ se asigna a un _DMO de factura_, y campos como _CustomerID_ y _BillingAmount_ se convierten en claves de unión y atributos de coincidencia en el modelo de datos unificado. Los datos de documentos armonizados participan en segmentación, _Perspectivas calculadas_ y activación a través de las mismas interfaces utilizadas por CRM y datos de transacciones. **Ejemplo:** El _DLO Reclamaciones_ se asigna a un _DMO Reclamaciones_. Los campos PatientID y PolicyNumber se convierten en claves de unión que vinculan registros de reclamaciones a perfiles de pacientes unificados. #### Etapa 5: Unificar Los datos de DMO armonizados participan en la resolución de identidad. Los campos extraídos (por ejemplo, nombres de clientes, direcciones de email o números de cuenta) sirven como claves de coincidencia para vincular registros de documentos a _Personas unificadas (Registros dorados)_, lo que cierra la brecha de documento a perfil. **Ejemplo:** Los campos de extracción (por ejemplo, PatientName, DateOfBirth y PolicyNumber) sirven como claves de coincidencia para la resolución de identidad, lo que vincula registros de reclamación al _particular unificado_ correcto. Esto se produce incluso si el mismo paciente aparece con una ortografía de nombre ligeramente diferente en los documentos. #### Etapa 6: Derivar perspectivas Los arquitectos definen _Perspectivas calculadas_, que son mediciones agregadas que se calculan entre datos de documentos armonizados (por ejemplo, el gasto total de varias partidas de factura, puntuajes de riesgo de renovación de contratos e índices de gravedad de reclamaciones). **Ejemplo:** _Perspectivas calculadas_ calcula TotalClaimsPerPatient, AverageClaimAmount y HighRiskClaimScore entre datos de reclamaciones armonizados para consultas Agentforce. #### Etapa 7: Acto Los datos armonizados resueltos por identidad son accesibles para Agentforce Agents, _Tableau_, plataformas de marketing y _SObjects de_ Salesforce. El nivel de destino es una decisión arquitectónica dirigida por los requisitos de latencia, gobernanza y residencia de datos. **Ejemplo:** Un _Claims Adjudication Agentforce_ consulta los DMO e IC de _Data 360_ para encontrar reclamaciones de alto riesgo para revisión de prioridad. Los tableros de _Tableau_ muestran el volumen de reclamaciones y las tendencias de anomalías. Los registros de reclamaciones aprobados vuelven al _Objeto Reclamaciones_ para iniciar flujos de trabajo de pago. En arquitecturas de _Headless 360_, la activación enruta directamente a sistemas externos a través de la _API de consulta_, la _API Pub/Sub_ o los destinos de activación del almacén de datos de Cloud. A continuación, el servidor MCP encuentra datos de documentos armonizados y _Perspectivas calculadas_ como herramientas llamables para agentes de IA externos. ### Canalizaciones de procesamiento de transacciones Las oportunidades en curso de _procesamiento transaccional_ gestionan la extracción de documentos únicos en tiempo de ejecución sin un UDMO o UDLO preintroducido, que se adapta a casos de uso dirigidos por eventos (por ejemplo, un cliente cargando un formulario, un agente recibiendo un PDF o un sistema externo iniciando la extracción dentro de un flujo de trabajo de procesamiento transaccional). La regulación de ETL se aplica a ambas oportunidades en curso de forma idéntica. **Escenario del mundo real** Mientras solicita un préstamo, un cliente de banco carga un PDF de su factura de servicios públicos a través de la aplicación móvil del banco. El evento inicia la extracción en tiempo real, lo que significa que no hay implicado ningún UDLO u UDMO ingresado previamente. ![Oportunidades en curso de procesamiento transaccional mostrando la extracción de API de REST síncrona en tiempo real para la factura de servicios públicos de un solicitante de préstamo](https://architect.salesforce.com/ns-assets/data360-doc-ai/data360-document-ai-ad-hoc-processing.png) #### Etapa 1: Definir configuración de esquema Antes de invocar la API, los arquitectos deben definir y almacenar un esquema en _Data 360_ que especifique los campos, los tipos de datos y las instrucciones de extracción en formato _Esquema JSON_. Cada esquema tiene asignado un _Id. de esquema_ exclusivo. En tiempo de ejecución, la aplicación que llama hace referencia al Id. de esquema para mantener la lógica de extracción centralizada en _Data 360 en_ vez de integrarla en el código de la aplicación. **Ejemplo:** El equipo del banco tiene un esquema de `ProofOfAddress` predefinido en _Data 360_, que especifica campos como `CustomerName`, `AddressLine1`, `City`, `PostCode` y `DocumentDate`. Esta información se almacena como una configuración versionada a la que se puede hacer referencia mediante un _Id. de esquema_. #### Etapa 2: Enviar documentos La aplicación que llama envía el documento y el Id. de esquema en una única solicitud de API de REST como una referencia de archivo o carga codificada con base64. No se requiere ingreso de UDLO. La _IA de documentos_ aplica la extracción de documentos y devuelve el resultado estructurado basándose en el esquema proporcionado. **Ejemplo:** La aplicación móvil envía la factura de servicios públicos como una carga codificada con base64 junto con el Id. de esquema de `ProofOfAddress` en una sola llamada de API de REST. Este proceso no requiere un paso de ingreso de UDLO. #### Etapa 3: Extraer El LLM procesa la salida de OCR con el esquema y devuelve una carga de JSON estructurada de forma síncrona. Los campos que no se encuentran en el documento se devuelven como _nulos_. La persona que llama es propietaria de la respuesta JSON completa y continúa con el enrutamiento. **Ejemplo:** La _IA de documento_ aplica OCR al PDF y el LLM devuelve una carga de JSON estructurada con campos de dirección extraídos. Los campos que no se encuentran (por ejemplo, si falta el `PostCode` en la factura) se devuelven como _nulos_. #### Etapa 4: Enrutar a destino (Opcional) Una vez extraída, la carga JSON se puede enrutar a uno o más niveles de destino dependiendo del caso de uso: - **Objeto de Salesforce:** Asigne directamente a campos _de SObject_ mediante _Apex_ o _Flow_ para flujos de trabajo y aprobaciones de CRM. - **Oportunidades en curso de DLO/DMO de Data 360:** Enruta a un DLO para Armonización, Resolución de identidad, _Perspectivas calculadas_ y Fundamentación Agentforce. - **RDBMS externo o Almacén de datos:** Enruta a través de _MuleSoft_, llamadas _Apex_, _eventos de plataforma_ o ETL para sistemas que están fuera de Salesforce. - **Integración personalizada:** Devuelve cargas de JSON estructuradas a la aplicación llamante para su almacenamiento en cualquier sistema externo o establecimiento de datos. - **Flujo descendente o Agente:** Pasa la salida de JSON estructurada directamente a un flujo descendente o agente sin ninguna persistencia en un _SObject_. Este es un patrón común para clientes que utilizan la _IA de documentos_ como un paso de extracción en tiempo real en una automatización más grande o un flujo de trabajo de agentes. Tenga en cuenta que un esquema único puede extenderse a múltiples niveles simultáneamente, con diferentes grupos de campos enrutando a diferentes destinos desde el mismo punto de extracción. **Ejemplo:** Una carga de `ProofOfAddress` puede extenderse a tres niveles a la vez (por ejemplo, `CustomerName` y `AddressLine1` escriben en el _Objeto de contacto_), que inicia un _Flujo_ de verificación de dirección. A continuación, la carga completa enruta a un DLO para Armonización y Puntuaje de Riesgo, y una copia enruta al sistema KYC del banco a través de _MuleSoft_ para el registro del cumplimiento normativo. #### Etapa 5: Acto Una vez redactados, los datos extraídos se activan en el sistema de destino de inmediato. Para destinos _de SObject_, los desencadenadores, flujos y procesos de aprobación se activan en el registro alterado. En el caso de objetivos de _DLO/DMO_, los datos entran en las oportunidades en curso de _Armonización y Resolución_ de identidad y en el contexto Agentforce. Para destinos de _RDBMS_ externos, los datos están disponibles para consultas descendentes en cuanto se complete la escritura. **Ejemplo:** El _Flujo de verificación_ de dirección se activa inmediatamente en el registro _Contacto_ alterado, lo que hace avanzar la solicitud de préstamo a la siguiente etapa. El _agente de préstamos_ Agentforce encuentra la dirección verificada de _Data 360_ y el sistema KYC registra el envío del documento para fines de auditoría. ## ¿Cuándo debe utilizar la IA de documentos? La _IA de documentos_ se adapta mejor a condiciones arquitectónicas específicas. Aplicarlo fuera de esas condiciones introduce complejidad innecesaria y costos adicionales. Como arquitectos, es importante evaluar estos criterios antes de comprometerse con la _IA de documentos_ como el mecanismo de extracción. **Utilice la IA de documentos cuando:** - **Los documentos son el origen de datos principal.** La información requerida solo existe en formato de documento y no está disponible desde una API estructurada o base de datos (por ejemplo, contratos escaneados, reportes de laboratorio, formularios de admisión o reclamaciones de seguros). - **Los formatos de documento varían entre orígenes.** El mismo tipo de documento llega de múltiples proveedores, socios o regiones con diferentes formatos y posiciones de campo. La extracción LLM dirigida por esquemas se adapta sin mantenimiento por formato. - **Los datos extraídos deben alimentar Data 360 o Agentforce.** La extracción debe participar en la resolución de identidad, _Perspectivas calculadas_ o Fundamentación Agentforce. La _IA de documentos_ se entrega directamente en las oportunidades en curso de _DLO/DMO_ sin una capa ETL separada. - **El volumen justifica la automatización gobernada.** El volumen de documentos supera lo que el procesamiento manual puede gestionar sin costos de mano de obra mensurables o riesgos de calidad de datos. - **Los documentos contienen contenido regulado.** _PHI_, _PII_ o datos financieros deben enrutarse a través de una capa de retención de datos cero y enmascaramiento de PII antes de alcanzar un LLM. El ETL satisface esto de forma nativa. Los clientes que no requieren que se mantenga ningún contenido extraído en ningún punto también deben tener en cuenta el flujo de _API transaccional_, que devuelve resultados estructurados directamente a la aplicación que llama sin escribir en ningún _SObject_ o establecimiento de datos. - **El caso de uso está dirigido por eventos.** Un documento llega en tiempo de ejecución (por ejemplo, una carga de cliente, un archivo adjunto PDF de agente o un desencadenador del sistema externo). Las oportunidades en curso de _procesamiento transaccional_ gestionan la extracción síncrona de un solo documento sin configuración por lotes. **No utilice la IA de documentos cuando:** - **Los datos de origen ya están estructurados.** Si el sistema ascendente expone una API de REST, una tabla de base de datos o un archivo estructurado (por ejemplo, CSV, JSON o XML), utilice un conector _Data 360_ estándar. La ejecución de datos estructurados a través de una canalización de extracción LLM agrega latencia y costos de crédito sin beneficios adicionales. - **Los documentos se generan automáticamente con un esquema fijo.** Los PDF generados por el sistema desde un sistema ERP conocido o una plataforma de facturación con un formato estable son más adecuados para un analizador determinista. La extracción LLM está diseñada para la variabilidad, y su aplicación a documentos de esquema fijo desperdicia contexto y créditos. - **Los requisitos de precisión superan los umbrales de confianza de LLM.** La _IA de documentos_ no garantiza una precisión de extracción del 100%. Los casos de uso donde un valor de campo perdido o incorrecto conlleva un riesgo financiero, legal o clínico significativo requieren un paso de validación HITL. No utilice la _IA de documentos_ como la única capa de extracción para decisiones de alto riesgo sin un flujo de trabajo de validación. - **Los documentos superan las restricciones de la plataforma.** El límite de tamaño de archivo de 10MB actual y las restricciones de longitud de contexto LLM hacen que la _IA de documentos_ no sea adecuada para documentos grandes o densos sin procesamiento previo para dividirlos y volver a ensamblarlos fuera de la plataforma. - **Nota:** En Salesforce, estamos mejorando activamente estas barandillas de aceptación para ampliar los tamaños de archivo, conteos de páginas y extensiones de archivo compatibles. Las restricciones seguirán evolucionando hacia adelante. ## Casos de uso: Revisar los patrones en la práctica ### Casos de uso de oportunidades en curso por lotes Echemos un vistazo con más detalle a varios escenarios que utilizan las oportunidades en curso por _lotes de IA_ de documentos respaldadas por un objeto de origen UDMO. En estos casos, los datos extraídos se enrutan a través de las oportunidades en curso de _DATA 360 DLO/DMO_ para Armonización, Resolución de identidad, _Perspectivas calculadas_ y Activación Agentforce. Cada caso de uso es el más adecuado para el procesamiento de documentos de gran volumen programado o dirigido por eventos. **Agentforce Sales: Inteligencia de** contratos y facturas Los PDF _de contratos_ se ingresan desde el almacenamiento de Cloud a través de las oportunidades en curso _por lotes_. El esquema extrae ContractValue, RenewalDate, PaymentTerms y CounterpartyName, y luego los asigna a los DMO de _Cuenta_ y _Contrato_. _Perspectivas calculadas_ deriva puntuajes de riesgo de renovación. Agentforce alerta a los ejecutivos de cuentas antes de que se cierren los plazos de renovación, lo que elimina la revisión manual de contratos y las renovaciones perdidas. **Servicio Agentforce: Desviación de casos y Fundamentación** de Knowledge Los PDF de _encuestas_ y los archivos adjuntos de casos se ingresan a través de las oportunidades en curso _por lotes_. El esquema extrae indicadores de opinión, categorías de problemas y notas de resolución, y luego los asigna a los DMO de _caso_ y _artículo Knowledge_. Agentforce consulta la base de Knowledge armonizada cuando se abre el caso y localiza pasos de solución de problemas relevantes, lo que reduce la carga de trabajo de búsqueda de agentes. **Agentforce Health: Procesamiento** de documentos clínicos Los reportes de laboratorio, los PDF de admisión y los formularios clínicos manuscritos se ingresan a través de las oportunidades en curso _por lotes_. El esquema extrae campos, incluyendo _PatientID_, _DiagnosisCode_, _MedicationName_ y _TestResult_, y luego los asigna a los DMO de _Health Cloud_, que admiten flujos de trabajo de investigación clínica y coordinación de cuidados alineados con HIPAA. **Servicios financieros: Automatización de** documentos de préstamos e impuestos Las solicitudes de préstamos, las declaraciones de impuestos y las declaraciones de ingresos se ingresan a través de las oportunidades en curso por lotes. El esquema extrae campos, incluyendo AnnualIncome, TaxYear y EmployerName, y luego los asigna a los DMO de _Cuenta financiera_. _Perspectivas calculadas_ une datos de ingresos derivados de documentos y datos de CRM para facilitar el puntuaje de riesgo de crédito automatizado. Agentforce localiza los detalles del préstamo extraído en línea durante las interacciones de servicio al cliente. Este patrón admite directamente el caso de uso [Agente de precalificación](https://developer.salesforce.com/developer-centers/agentic-enterprise-solutions) de préstamos que se publicó en el centro de desarrollador de _Soluciones de negocio_ de Salesforce. **RRHH: Procesamiento de** documentos de plantilla de trabajo Los documentos de incorporación, los formularios de impuestos y los PDF de certificación se ingresan a través de las oportunidades en curso _por lotes_. Los campos extraídos se asignan a los DMO de _Registro de empleado_ y luego se vinculan al perfil _Empleado unificado_. _Flujos_ específicos inician tareas de incorporación y comprobaciones de cumplimiento basándose en los datos extraídos. Este patrón admite directamente el caso de uso Agente de [procesamiento de reanudación](https://developer.salesforce.com/developer-centers/agentic-enterprise-solutions) automático. _La IA de documentos_ extrae habilidades, historial laboral y cualificaciones de los PDF de currículum, que Agentforce utiliza para comparar candidatos con criterios de funciones abiertas y enrutarlos a flujos de trabajo de contratación. **Servicios profesionales: Inteligencia de** propuestas e investigaciones Los conjuntos de propuestas y los reportes de investigación se ingresan a través de las oportunidades en curso _por lotes_. Los marcos de trabajo, los indicadores y los resúmenes de implicación extraídos se asignan a DMO personalizados y luego se indexan para la búsqueda de vectores. Agentforce recupera recomendaciones relevantes en contexto en el momento de la consulta, que se basan en contenido de documento extraído. Este patrón amplía el patrón [Ground Agentforce en contenido](https://developer.salesforce.com/developer-centers/agentic-enterprise-solutions) de sitio web. Los documentos se indexan a través de la _IA de documentos_ y cumplen la misma función de fundamentación para respuestas de agentes que el contenido del sitio web indexado a través de conectores de _Data 360_. **Estado de cumplimiento de HIPAA:** Las pautas _Health Cloud_ descritas en este documento aplican controles de ETL (por ejemplo, retención cero de datos y enmascaramiento de PHI) para entradas de texto. Estos controles por sí solos no constituyen certificación HIPAA. Los arquitectos que están diseñando entornos clínicos regulados deben confirmar el estado de certificación HIPAA actual con el equipo de cumplimiento de Salesforce antes de comprometerse con una arquitectura basada en _IA de documentos_ en esos contextos. ### Casos de uso de oportunidades en curso de procesamiento de transacciones Echemos un vistazo con más detalle a varios escenarios que invocan la API de REST de _IA de documentos_ con un esquema que no está vinculado a un UDMO. Las cargas JSON extraídas se enrutan directamente a sistemas externos de forma síncrona en tiempo de ejecución. **Cadena de suministro: Procesamiento de facturas de proveedor a ERP** Cuando un PDF de _factura de proveedor_ llega a un depósito de almacenamiento monitoreado o pasarela de email, un desencadenador de evento llama a la API de REST de _IA de documento_ con la factura y un Id. de esquema predefinido. El esquema extrae VendorID, InvoiceNumber, LineItems, TotalAmount, TaxAmount y DueDate. La carga de JSON se enruta a través de _MuleSoft_ al módulo _Cuentas ERP a_ pagar con validación de campo _nula_ y lógica de alteración idempotente, lo que elimina el mantenimiento de plantillas para la variabilidad de formato de proveedores. **Operaciones legales: Revisión de contratos en CLM** Cuando se carga un PDF de _contrato_ en el portal legal, el backend llama a la API de REST de _IA de documentos_ de forma síncrona. El esquema extrae GoverningLaw, IndemnityCapAmount, TerminationNoticePeriod, AutoRenewalClause y CounterpartySignatory. La carga de JSON se enruta a través de una llamada _Apex_ al sistema de gestión del ciclo de vida de _contratos (CLM)_. Cualquier campo que no se encuentre se devuelve como _nulo_ y el CLM aplica las reglas de obligación predeterminadas a los valores que faltan. **Reclamaciones de seguros: Primer aviso de procesamiento de pérdidas** Cuando un tomador de póliza envía un formulario de _Primer aviso de pérdida (FNOL)_, el portal backend llama a la API de REST de _IA de documentos_ de forma síncrona. El esquema extrae PolicyNumber, IncidentDate, IncidentLocation, DamageDescription, ClaimantName y ContactPhone. La carga útil de JSON enruta a la base de datos de _gestión de reclamaciones_ a través de una llamada _Apex_ o ETL, que crea un registro de reclamación rellenado previamente para que los ajustadores lo revisen antes de abrir la reclamación formal. ## Consideraciones de diseño y modos de fallo Antes de pasar a producción, debe crear diseños para estos escenarios de fallo. - **Gestión de campos nulos:** El LLM devuelve _nulo_ para campos que no puede localizar o extraer con confianza. Valide la lógica de gestión de nulos en el diseño de esquemas e implemente la lógica de rechazo o valor predeterminado en la capa de integración antes de escribir en cualquier destino con restricciones _NO NULAS_ o claves de coincidencia requeridas. - **Degradación de calidad de OCR:** La precisión de OCR se degrada por debajo de 150 ppp, en escritura irregular o en exploraciones ruidosas. Los errores de lectura se propagan a la extracción LLM como entrada dañada sin señales de error. Aplique la calidad de exploración mínima en el ingreso e implemente comprobaciones de umbral de confianza en campos numéricos y de fecha. - **Desajuste de versión de esquema:** La actualización de una configuración de esquema después de programar un trabajo por lotes provoca que los documentos en vuelo se procesen con la versión anterior, lo que produce campos que faltan o que cambian de nombre que interrumpen la asignación descendente. Verifique esquemas de forma explícita y coordine actualizaciones con programaciones de trabajos por lotes. - **Límites de tamaño de archivo:** Los documentos que superen los 10MB se rechazan. Los fallos de oportunidades en curso por lotes guardan silencio sin la configuración de monitoreo y los llamantes de transacciones reciben un error _4xx_. Valide previamente los tamaños de archivo en el momento de la admisión e implemente el procesamiento previo para dividir o comprimir documentos que se acercan regularmente al límite. - **Desbordamiento de contexto LLM:** Los documentos densos o de varias páginas pueden superar el plazo de contexto LLM dentro del límite de 10MB. El LLM descarta silenciosamente contenido que supera el contexto. Implemente una estrategia de fragmentación que divide documentos por intervalo de página y vuelve a reunir los campos extraídos antes de transferirlos al destino. - **Enmascaramiento de capa de confianza que afecta a la extracción:** El ETL funciona a nivel de solicitud (no a nivel de documento), de modo que el enmascaramiento no se aplica al contenido de documentos que pasa por la _IA de documentos_. Los campos de esquema que dependen de valores de _PII_ en el documento no se ven afectados por políticas de enmascaramiento de ETL. - **Idempotencia de escritura RDBMS externa:** Las oportunidades en curso de _procesamiento transaccional_ no tienen ninguna idempotencia integrada para objetivos de _RDBMS_ externos. Los reintentos de _capa de integración_ crean filas duplicadas a menos que la lógica de escritura trate la desduplicación de forma explícita. Implemente alteraciones idempotentes utilizando una huella de documento o un Id. externo en todas las rutas de escritura externas. - **Agotamiento de crédito a mitad de ejecución:** Las ejecuciones por lotes de gran tamaño pueden agotar los créditos _Digital Wallet_ antes de que se procesen todos los documentos, lo que produce conjuntos de datos de DLO incompletos que los pasos posteriores ven como completos. Establezca alertas de consumo en 75% y 90% de créditos disponibles y limite el tamaño de los lotes para permanecer dentro del presupuesto de crédito para cada ciclo. - **Límite de campos de esquema: Restricción arquitectónica:** La _IA de documentos_ aplica un límite de 50 campos para campos de nivel raíz en una configuración de esquema. Esta es una restricción de tiempo de diseño, no un error de tiempo de ejecución, y los arquitectos deben tenerla en cuenta durante el diseño de esquemas y modelos de datos. - Para casos de uso que requieren una extracción más amplia: - Priorice despiadadamente. Restrinja el esquema a campos que dirigen el valor de automatización, no la cobertura de documentos exhaustiva. - Aproveche los objetos anidados (hasta 3 niveles; modo por lotes solo con objeto de origen) para reducir el conteo de campos a nivel de raíz sin sacrificar la profundidad de extracción. - Descomponga documentos complejos entre múltiples configuraciones de _IA de documentos_ que se dirigen a secciones de documentos distintas, redacte resultados en DLO separados que se unen aguas abajo en _Data 360_. - **Límites de frecuencia de API:** La _IA de documentos_ aplica un límite de 50 llamadas de API de extracción por minuto por arrendatario. El límite máximo teórico es de 300 llamadas por minuto, que se rige por la _Puerta Einstein LLM_. Las integraciones de transacciones de gran volumen deben diseñarse con retroceso exponencial, colas de solicitudes y presupuestos de rendimiento a nivel de arrendatario. No asuma que la capacidad de ráfaga está disponible en entornos de producción de múltiples arrendatarios. - **Perfil de latencia de API:** Las API de extracción de _IA de documentos_ son completamente síncronas. Los tiempos de respuesta habituales oscilan entre 5 y 15 segundos y varían por tamaño de archivo y complejidad de esquema. - Esto tiene implicaciones directas para la arquitectura de integración: - Establezca los tiempos de espera de los llamantes en un mínimo de 30 segundos. - No invoque la _IA de documentos_ en flujos con requisitos de SLA de subsegundos. - Tenga en cuenta la latencia en los cálculos de rendimiento frente al límite de frecuencia máximo para oportunidades en curso de _procesamiento por lotes_. - **Documentos cifrados y protegidos por contraseña:** La _IA de documentos_ no procesa archivos protegidos por contraseña (se requieren contraseñas de usuario para abrir archivos) o PDF cifrados con una contraseña de propietario/permisos, incluyendo archivos que se abren normalmente pero restringen la copia, impresión o modificación en la capa de _permisos PDF_. - Esta restricción se encuentra en el límite de ingreso: - Diseñe oportunidades en curso de _admisión de documentos_ para detectar y enrutar archivos cifrados a una ruta de _rechazo_ o _procesamiento manual_ antes de que alcancen la _IA de documentos_. - No se base en la gestión de errores en tiempo de ejecución como la puerta principal. ## Alineación bien diseñada La _IA de documentos_ de Data 360 se alinea con varios pilares del _Marco bien diseñado_ de Salesforce. - **Confianza:** El ETL aplica retención de datos cero con proveedores LLM, enmascara entradas de _PII_ antes de que lleguen al modelo y explora salidas para contenido confidencial. Los arquitectos deben ampliar esta postura a datos extraídos en periodos de inactividad. El ETL no aplica el enmascaramiento a nivel de campo en los DLO y requiere políticas de _espacio de datos_ descendentes y _conjuntos de permisos_. - **Fiabilidad:** Cada modo de fallo en la sección _Consideraciones de diseño_ (extracción de campo nulo, lectura incorrecta de OCR, no coincidencia de versión de esquema, brecha de tamaño de archivo, desbordamiento de contexto LLM, interferencia de enmascaramiento ETL, idempotencia de escritura RDBMS y agotamiento de crédito) representa una clase de fallo distinta con una señal de detección documentada y una ruta de resolución. - **Excelencia operativa (gestión de cambios):** El modelo de extracción dirigido por esquema desvincula la lógica de extracción del formato de documento. Cuando un proveedor cambia un formato de factura o se actualiza un formulario regulador, los arquitectos solo necesitan actualizar una configuración de esquema en vez de modificar el código de integración. - **Excelencia operativa (mantenibilidad):** La centralización de configuraciones de esquemas en _Data 360 en_ vez de integrar lógica de extracción en código de aplicación hace que la intención de extracción sea explícita, versionada y auditable. Todos los destinos descendentes consumen el mismo contrato de esquema independientemente de su nivel de destino. - **Excelencia operativa (reutilización de integración):** La _IA de documentos_ expone la extracción en múltiples superficies de integración: API de REST, _Apex_, _Flow_, _MuleSoft_, Agentforce _Actions_ y el servidor MCP. Una configuración de esquema única se despliega a múltiples niveles de destino de forma simultánea sin volver a construir la capacidad de extracción por consumidor. - **Optimización de recursos y costos:** Las directrices de selección de oportunidades en curso, el límite de tamaño de archivo de 10MB y las restricciones de longitud de contexto LLM previas al ensamblaje representan decisiones de diseño que tienen en cuenta el desempeño. La sección _Cuándo utilizar_ formaliza las condiciones para cuando _la IA de documentos_ no es la herramienta correcta (por ejemplo, requisitos de latencia por debajo del segundo, datos de origen completamente estructurados y documentos generados por máquina de esquema fijo). ## Guía de inicio rápido para arquitectos Este es un punto de inicio estructurado para configurar la _IA de documentos_ de Data 360 en un entorno sandbox. Complete todas las fases en el entorno sandbox antes de pasar a producción. ### Antes de empezar Antes de iniciar la configuración, debe confirmar: - **Tamaño de archivo:** Valide que los tamaños de documentos representativos sean inferiores a 10MB. - **Oportunidades en curso:** Confirme si el caso de uso requiere la canalización _por lotes_ (con respaldo de UDMO, de gran volumen) o la canalización de _procesamiento transaccional_ (dirigida por API, de un solo documento). Esto dirige toda la configuración posterior. - **Nivel de objetivo:** Confirme dónde llegan los datos extraídos: _SObject_ de Salesforce, DLO/DMO de _Data 360_, RDBMS externo o una combinación. - **Dependencia Agentforce:** Antes de implementar cualquier procesamiento de documentos con tecnología Agentforce, confirme que un [LLM](https://help.salesforce.com/s/articleView?id=ai.generative_ai_large_language_model_support.htm&type=5) compatible (por ejemplo, _GPT-4o_) está activado en su organización a través de la configuración de ETL. Agentforce es un requisito previo de plataforma sólida para la _IA de documentos_. Toda la superficie de la función de _IA de documentos_, incluyendo todas las API de extracción, no estará disponible hasta que Agentforce esté activo en la organización de destino. Tenga esto en cuenta en las evaluaciones de preparación de la organización y la secuenciación de aprovisionamiento. Espere unos minutos para que la disponibilidad de API se estabilice tras la activación. - **Repercusión de desactivación Agentforce:** Si Agentforce se desactiva después de configurar e implementar la _IA de documentos_, todo el procesamiento de extracción (interfaz de usuario y API) se bloqueará inmediatamente. Lo mismo se aplica a la desactivación de modelos. La desactivación del modelo subyacente tiene un efecto equivalente en la disponibilidad de _IA de documentos_. En ambos casos, las configuraciones de esquemas existentes se mantienen y permanecerán visibles (no se producirá ninguna configuración o pérdida de datos), pero la capacidad es completamente inoperable hasta que Agentforce y el modelo se vuelvan a activar. Diseñe guías operativas para tratar la disponibilidad Agentforce y la activación de modelos como dependencias de salud de _IA de documentos_. - **Precio/consumo de crédito:** Utilice créditos de _Data 360_ o _Flex Credits_ para estimaciones de TCO derivadas de documentos de muestra representativos. #### Fase 1: Configuración de esquemas y oportunidades en curso - **Cree la configuración del esquema.** Defina campos de extracción, tipos de datos e instrucciones en formato _Esquema JSON_ en la configuración de la _IA de documentos_ de Data 360. Para las oportunidades en curso _por lotes_, vincúlelas a un UDMO. Para las oportunidades en curso de _procesamiento de transacciones_, créelas sin un objeto de origen. Registre el Id. de esquema. - **Alinee los nombres de campo con el nivel de destino.** Haga coincidir nombres de campo con definiciones de columna de DLO, nombres de API _de SObject_ o nombres de columna de RDBMS. Los nombres desalineados crean gastos generales de asignación en la capa de integración. - **Configure el objeto de origen de UDMO (solo por lotes).** Defina documentos en ámbito y configure la conectividad de origen de ingreso (por ejemplo, _S3_, _Google Cloud Storage_, _Salesforce Files_ o _MuleSoft)_. Confirme que la cuenta de servicio de admisión tiene el ámbito de credencial de _OAuth_ o _IAM_ requerido. - **Aplique políticas de enmascaramiento de PII.** Configure políticas de _Enmascaramiento de datos_ en la configuración de ETL antes de procesar cualquier contenido regulado. Defina qué tipos de campo (_PHI_, _PII_ e identificadores financieros) están enmascarados antes de que las entradas lleguen al LLM. **No** aplace este paso. - **Asigne el ámbito Espacio de datos y los conjuntos de permisos.** Procesamiento de ámbito en el _Espacio de datos_ apropiado y configure _Conjuntos de permisos_ para controlar la creación de esquemas, la ejecución de trabajos por lotes, la invocación de API de REST y la activación descendente. - **Configure la autenticación de API (solo oportunidades en curso de procesamiento de transacciones).** Cree una _aplicación conectada_ con ámbitos de _OAuth_ cdp_ingest_api y api. Para llamantes internos de la organización, utilice una _Credencial nombrada_ que vincula a una _Credencial externa_. Para llamantes externos, configure credenciales de cliente de _OAuth 2.0_ o un flujo de soporte JWT. Pruebe y valide la extracción antes de continuar. #### Fase 2: Integración y configuración de destino - **Escritura no simultánea de SObject:** Implemente un elemento _Apex_ (@InvocableMethod) o _Flow_ que asigne campos de respuesta JSON a campos _SObject_. Utilice Database.upsert() con un Id. externo para evitar duplicados. Aplique _Seguridad a nivel_ de campo en campos _de SObject_ de destino. - **Oportunidades en curso de DLO/DMO de Data 360:** Asigne campos de DLO extraídos a DMO que se alinean con el _Customer 360 Data Model_. Configure reglas de resolución de identidad para vincular registros de documentos a _particulares unificados_. Defina _Perspectivas calculadas_ y agregue DMO para Agentforce. Para las oportunidades en curso de procesamiento de transacciones, enrute la carga útil de JSON a un DLO a través de la API _de ingreso_ primero. - **RDBMS externo o almacén de datos:** Seleccione el patrón de integración: _MuleSoft_ (tejido de integración existente), llamada HTTP _de Apex_ (ligera, nativa de la organización), _eventos de plataforma_ con el suscriptor _Pub/Sub_ (dirigido por eventos) o ETL (lote de gran volumen). Implemente alteraciones idempotentes utilizando una huella de documento o un Id. externo en todas las rutas de escritura externas. - **Rutas de activación:** Conecte acciones Agentforce con configuraciones de esquemas para una extracción interactiva. Configure desencadenadores de _Flujo_ o _Apex_ para flujos de trabajo de procesamiento automatizado y establezca los destinos de activación para cada grupo de campos. - **Tratamiento de errores (solo oportunidades en curso de procesamiento de transacciones).** Configure la superficie de respuesta HTTP completa: **200** (_correcto_, incluyendo respuestas _nulas_ parciales), **400** (_solicitud incorrecta_ o _Id. de esquema no encontrado_), **413** (archivo superior a 10MB), **5xx** (error de servicio). Implemente una reducción exponencial para reintentos _5xx_ con un máximo de 3 intentos. Registre la respuesta JSON sin procesar y el Id. de esquema en cada llamada. #### Fase 3: Validar y prepararse para la producción - **Pruebe esquemas con documentos de muestra.** Envíe muestras representativas a través de la interfaz de _IA de documentos_ o la API de REST. Confirme la precisión de extracción, la cobertura de campo y la gestión nula entre variaciones de formato. - **Valide la gestión de campos nulos.** Confirme que todos los destinos descendentes pueden gestionar valores _nulos_ para _campos no encontrados_ en un documento. Tenga en cuenta que las restricciones _NO NULAS_ fallan silenciosamente sin una gestión nula explícita. - **Valide tamaños de archivo previamente.** Confirme que los documentos de producción permanecen por debajo de 10MB. Implemente el procesamiento previo para dividir o comprimir documentos que se acercan regularmente al límite. - **Valide la extracción de extremo a extremo.** Para las oportunidades en curso _por lotes_, inicie una ejecución completa y confirme que los campos extraídos llegan correctamente a cada nivel de destino. Para las oportunidades en curso de _procesamiento de transacciones_, siga la respuesta JSON a través de la capa de _integración_ hasta el destino. Verifique el desencadenador y la ejecución del flujo para los objetivos _de SObject_, el vínculo de resolución de identidad para los objetivos _de DLO/DMO_ y la idempotencia para los objetivos _de DRBMS_. - **Confirme el comportamiento de Trust Layer.** El ETL no aplica el enmascaramiento de _PII_ al contenido de documentos, de modo que el LLM devolverá datos de _PII_ en campos extraídos tal cual. Confirme que sus campos de esquema, enrutamiento de datos y almacenamiento descendente están diseñados para gestionar resultados que llevan PII de forma apropiada, y asegúrese de que cualquier requisito de cumplimiento o retención se soluciona fuera de la plataforma. - **Establezca alertas Digital Wallet.** Configure alertas de consumo al 75% y 90% de los créditos disponibles. Establezca límites de tamaño de lote y estimaciones de tipo ad hoc dentro del presupuesto de crédito para cada ciclo. - **Valide el monitoreo por lotes (solo oportunidades en curso por lotes).** Revise índices de éxito de extracción, índices de campos nulos y finalización de trabajos en la consola de monitoreo de _Data 360_. Confirme la propagación de etiquetas desde el UDLO a través del DLO al DMO en el linaje de datos. - **Valide la gestión de errores de API (solo oportunidades en curso de procesamiento de transacciones).** Pruebe todas las condiciones de error: **413** (documentos de más de 10MB), **400** (Id. de esquema no válidos), **200** (extracciones válidas con nulos parciales). Confirme que la lógica de reintento se activa en respuestas **5xx** simuladas sin crear escrituras duplicadas. ## Conclusión Este documento destaca los fundamentos arquitectónicos de la _IA de documentos Data 360_: - Dos oportunidades en curso de procesamiento y cuándo utilizarlas - El modelo de configuración de esquemas - El marco de decisiones de nivel de destino - Restricciones tecnológicas principales - Modos de fallo - Alineación de _Marco bien estructurado_ La [Guía de inicio rápido para arquitectos](/docs/architect/es-mx/fundamentals/guide/data360-document-ai#guía-de-inicio-rápido-para-arquitectos) proporciona la secuencia de configuración para una prueba de concepto de sandbox. La postura arquitectónica principal admite datos derivados de documentos que se rigen en la capa _Esquema_, se procesan a través de una canalización LLM aplicada por ETL y se entregan al mismo ciclo de vida de datos de _Data 360_ que rige todos nuestros otros datos de compañía. Los arquitectos que aplican estos principios (seleccionar las oportunidades en curso correctas, diseñar esquemas a nivel de tipo de documento y diseñar modos de fallo antes de la producción) crean funciones de extracción que se amplían y perduran bajo requisitos de regulación de la industria regulados. ### Acerca de los autores **Yugandhar Bora** es un Arquitecto de Ingeniería de Software en Salesforce que se especializa en arquitectura de datos dentro de la plataforma _Aplicaciones de datos e inteligencia_. Lidera iniciativas del _Enterprise Architecture Review Board (EARB)_ que se centran en la gobernanza de datos y modelos de datos unificados, mientras que también contribuye a soluciones de aprovisionamiento de plataforma automatizadas. **Ananth Anto** es una Directora de Gestión de productos de Salesforce _Data 360_ que lidera iniciativas de _IA de documentos y gráficos_ de datos. Con sede en Bangalore, trabaja con clientes de negocio para resolver retos reales de procesamiento de documentos e inteligencia de datos. Le gusta explorar casos de uso _de Enterprise_ para _IA generativa (IA general)_. **Nishan Naseer** es un Arquitecto de Ingeniería de Software de Salesforce que trabaja en _Procesamiento de datos_ no estructurado, Canalizaciones de _RAG_ e _Inteligencia de documentos_. Le apasiona aprovechar el poder de la IA para abordar retos reales y encontrar soluciones creativas a problemas complejos de los clientes.