Extracción documental con IA
Evidencia antes de aprobar

Un equipo de seguros que estudia un proceso de siniestros podría preguntar qué documento respalda una fecha declarada. Un equipo industrial que revisa un registro de mantenimiento podría preguntar si un número devuelto conserva su unidad y su contexto. Son preguntas de compradores, no relatos de implantaciones. Ambas revelan el mismo punto de traspaso: un campo puede ser fácil de consumir para el software y seguir siendo difícil de justificar para una persona. En su artículo técnico del 29 de septiembre de 2026, Microsoft sostiene que extraer contenido fiable y trazable sigue siendo una disciplina de ingeniería propia, aunque mejoren los modelos. Describe el trabajo que requieren los formatos, las estructuras de página, las relaciones entre páginas, la confianza, la normalización y el tratamiento de errores. La novedad reciente es esa publicación, no un lanzamiento ni un incidente de octubre. Sus afirmaciones más amplias sobre rendimiento proceden del proveedor; este análisis no las ha demostrado.

La distinción útil es entre obtener un valor y aceptar su uso. La descripción general de Content Understanding de Microsoft presenta tres métodos de campo: extract obtiene valores tal como aparecen en el documento; classify asigna categorías predefinidas; generate produce valores a partir de la entrada, como resúmenes. Una respuesta ajustada a un esquema no elimina esas diferencias. Quien revise debe saber si está contrastando texto de origen, una categoría asignada o una interpretación generada. También importa la versión. La descripción general recomienda la API 2025-11-01, identificada como GA o disponibilidad general, para cargas de producción. La API 2026-06-01-preview sirve para evaluar funciones en versión preliminar. Las notas de versión indican que estas versiones no tienen acuerdo de nivel de servicio y no se recomiendan para producción. Ninguna etiqueta demuestra que todas las funciones estén disponibles para cualquier entrada o configuración.

Las notas de julio de 2026 describen puntuaciones de confianza y vinculación con la fuente para todos los tipos de campo de documentos, incluidos generate y classify, tanto en versión preliminar como en GA. Indican los ajustes estimateFieldSourceAndConfidence y estimateSourceAndConfidence para activar ese comportamiento. Es una afirmación sobre campos de documentos, no una promesa de señales idénticas en todas las modalidades. La descripción general presenta la confianza como una estimación de fiabilidad entre 0 y 1, y la vinculación como la localización de regiones de origen que sustentan el valor. Ninguna constituye una tasa de exactitud medida de forma independiente para sus documentos ni un umbral de aprobación empresarial demostrado. La normalización introduce otro límite de revisión. Las mismas notas de julio señalan que los valores de tipos admitidos, como fechas y números, se convierten automáticamente a un formato canónico. La normalización no es configurable y la respuesta no ofrece por separado el valor original y el normalizado. Por ello, el registro de revisión debería conservar el acceso a la fuente y distinguir la representación devuelta de la redacción original. No prometa un campo de valor original que la respuesta documentada no proporciona. Si la redacción es ambigua, un formato uniforme no debe decidir su significado.

Una solicitud correcta no implica necesariamente un conjunto completo de campos. La descripción general explica que las medidas de protección pueden restringir la generación de campos y conservar el contenido extraído de la fuente. El análisis puede finalizar con advertencias aunque falten valores; el bloqueo también puede limitar la extracción o impedir que termine. La instrucción de revisar las advertencias antes de automatizar el uso es muy distinta de considerar un estado correcto como una aprobación. Proponemos que el traspaso incluya el documento y la referencia a su ubicación de origen, el método del campo, el valor devuelto, la configuración y versión pertinentes, la confianza y vinculación disponibles, y cualquier ausencia o advertencia. El equipo receptor debería distinguir un campo no devuelto de uno revisado y aceptado. El responsable de la integración debería conservar esas diferencias; el responsable del proceso de negocio debería decidir qué significan para la tarea prevista. El diagrama muestra esa secuencia de revisión propuesta, no controles impuestos por el proveedor ni resultados observados.

Para evaluar un proceso de seguros, pregunte qué ocurre si el formulario de siniestro y un anexo discrepan sobre una fecha: qué fuente se contrasta, quién resuelve la contradicción y si el proceso siguiente espera. En manufactura, pregunte cómo se comprueba un número frente al encabezado de la tabla, la unidad y la revisión documental antes de incorporarlo a una tarea de mantenimiento. Estas preguntas definen el trabajo de evaluación; no implican que ninguno de los sectores haya obtenido un resultado concreto. Acuerde las condiciones de aceptación antes de evaluar documentos representativos. Incluya redacciones ambiguas, valores ausentes, interpretaciones generadas y respuestas con advertencias, no solo extracciones claras. Registre si quien revisa acepta un valor para un uso específico, solicita una aclaración o detiene el traspaso. Si la fuente no respalda la interpretación prevista, mantenga visible esa carencia en lugar de convertirla en una respuesta plausible. El resultado útil no es simplemente un JSON con campos rellenados. Es un valor cuyo origen y transformación pueden inspeccionarse, cuyas excepciones siguen visibles y cuyo uso permitido tiene un responsable. Ese es el límite de aceptación que un comprador puede examinar sin confundir una salida estructurada con permiso para actuar.