Extracción asistida en PHP: aceptar, revisar o cuarentenar

La extracción asistida de datos en PHP convierte documentos, formularios, correos o registros entrantes en campos estructurados. Sin embargo, detectar un nombre, un importe o una fecha no implica que ese valor pueda activar un pago, crear un pedido o modificar un expediente sin intervención. El resultado de extracción es una propuesta: debe contrastarse con reglas del negocio, evidencia disponible y el impacto de equivocarse.

El diseño útil no persigue automatizar el 100 % de los casos desde el primer día. Define qué datos pueden aceptarse de forma segura, cuáles requieren una decisión humana y cuáles deben detenerse hasta disponer de información adicional. Esta separación protege la operación y permite mejorar el sistema con correcciones reales, no con suposiciones sobre una puntuación de confianza.

Definir el dato, su procedencia y el coste del error

Antes de elegir un proveedor, una librería o un modelo de IA, describa cada campo como un objeto de negocio. No basta con indicar que se extraerá una fecha; hay que determinar si es la fecha de emisión, vencimiento, prestación o entrega. La ambigüedad semántica es un riesgo distinto de un fallo de lectura.

• Finalidad: qué proceso consumirá el campo y si puede iniciar una acción irreversible.
• Procedencia: documento original, página, sección, etiqueta, coordenadas o fragmento que respalda el valor.
• Restricciones: tipo, formato, obligatoriedad, rango, moneda, catálogo permitido y relaciones con otros campos.
• Impacto: consecuencia de aceptar un valor erróneo, ausente o atribuido al documento equivocado.
• Fuente de contraste: sistema maestro, regla contractual, base de proveedores o revisión humana que puede confirmar el dato.

Un identificador fiscal puede tener una expresión formal correcta y, aun así, pertenecer a una entidad no autorizada. Un total puede ser numérico y positivo, pero no coincidir con la suma de líneas, impuestos y descuentos. Por eso la validación debe incluir tanto la forma del campo como su significado operativo.

Clasifique asimismo la sensibilidad de los datos. Documentos con información personal, financiera o contractual requieren definir quién puede ver el original, cuánto tiempo se conserva y qué información se envía a servicios externos. La utilidad de la automatización no elimina las obligaciones de minimización y control de acceso.

Diseñar una salida estructurada y verificable

La extracción debería producir una estructura estable, no texto libre que otro componente deba reinterpretar. El contrato puede incluir el valor normalizado, el valor literal, el estado de presencia, la evidencia y los avisos detectados. Conservar ambos valores evita ocultar una transformación relevante: por ejemplo, convertir 1.250,00 a un decimal depende de la convención identificada.

{
  "invoice_number": {
    "raw": "F-01842",
    "normalized": "F-01842",
    "evidence": {"page": 1, "label": "Factura"},
    "warnings": []
  },
  "total": {
    "raw": "1.250,00 EUR",
    "normalized": 1250.00,
    "currency": "EUR",
    "evidence": {"page": 1, "label": "Total"},
    "warnings": ["sum_not_verified"]
  }
}

El esquema debe rechazar campos inesperados, tipos incompatibles y ausencia de obligatorios. En PHP, una capa específica puede validar el resultado antes de que alcance el dominio de la aplicación. Las reglas técnicas incluyen formatos, longitudes y conversiones; las reglas de negocio incluyen duplicados, periodos admitidos, límites de aprobación y correspondencia con registros existentes.

No trate el porcentaje de confianza como una decisión. Su calibración cambia según el tipo de documento, la calidad de la imagen, el idioma y el campo. Puede usarse como una señal adicional, pero no sustituye una comprobación como que el proveedor exista, que la fecha sea plausible o que el total cuadre.

Separar aceptación, revisión y cuarentena

Los tres destinos deben ser estados explícitos del flujo, con permisos, responsables y transiciones controladas. No son etiquetas visuales sobre una misma cola.

• Aceptación automática: se usa cuando el esquema es válido, las reglas de negocio se cumplen, existe evidencia suficiente y el riesgo residual está dentro del umbral definido. Debe persistirse qué reglas se cumplieron.
• Revisión humana: se aplica si el caso es comprensible pero requiere confirmación, como una discrepancia menor, una baja confianza localizada o una coincidencia no concluyente contra un sistema maestro.
• Cuarentena: detiene casos incompletos, potencialmente fraudulentos, duplicados, ilegibles, incompatibles con el esquema o afectados por una regla crítica. No debe permitir que un reintento automático convierta un bloqueo deliberado en aceptación.

Una matriz de decisión práctica combina criticidad y verificabilidad. Un campo de bajo impacto puede aceptarse si cumple formato y catálogo. Un dato que determina un pago exige además conciliación con el pedido, proveedor autorizado y cálculo coherente. Si falta el original, la evidencia es contradictoria o se detecta una posible manipulación, la salida razonable es cuarentena aunque otros campos parezcan correctos.

Flujo de referencia en PHP y persistencia segura

Un flujo robusto separa responsabilidades para que la extracción no quede mezclada con la decisión de negocio. La recepción asigna un identificador inmutable, comprueba tipo y tamaño del archivo, y almacena el original en una ubicación con acceso restringido. Después, un proceso asíncrono prepara el documento, invoca el extractor y valida la respuesta contra el esquema.

La decisión se toma sobre datos normalizados y reglas deterministas. El servicio puede devolver un objeto de decisión con el estado, los motivos, los campos afectados y la versión de las reglas. Sólo tras esa decisión se persiste el registro de negocio o se crea una tarea de revisión. La idempotencia es esencial: un mismo archivo o evento repetido no debe generar registros ni acciones duplicadas.

$result = $extractor->extract($document);
$validated = $schemaValidator->validate($result);
$decision = $decisionEngine->decide($validated, $businessContext);
$repository->saveDecision($documentId, $decision);

Cuando se use IA, defina el caso de uso de forma acotada: clasificación documental, localización de campos o interpretación de texto difícil, por ejemplo. Evalúe la calidad sobre un conjunto representativo antes de activar cualquier automatización, mantenga revisión humana para los supuestos definidos y limite los datos enviados. También calcule coste por documento, latencia tolerable y comportamiento ante respuestas parciales. Una demostración convincente no prueba que el flujo sea operable a escala.

Hacer eficaz la revisión humana y la cuarentena

La persona revisora no debería reconstruir el documento desde cero. La interfaz debe mostrar el valor propuesto junto con su evidencia, el original o un recorte autorizado, las reglas incumplidas y las alternativas disponibles. Debe permitir corregir, confirmar, rechazar o solicitar información, dejando un motivo estructurado.

Registre la corrección como un evento diferenciado del resultado inicial. Esto permite saber si falló la lectura, la normalización, una regla o el documento de origen. No use automáticamente toda corrección como dato de entrenamiento: primero revise calidad, permisos, representatividad y posible incorporación de datos sensibles.

La cuarentena necesita un propietario, una prioridad y un plazo de resolución. Los reintentos deben tener causa concreta, límite y registro: reintentar tras una caída transitoria no es igual que reprocesar un archivo ilegible. Los casos sin resolución deben escalarse o cerrarse con una razón explícita, nunca desaparecer de la cola.

Trazabilidad, pruebas y degradación controlada

Para explicar una decisión, conserve el identificador del documento, huella o referencia del original, versión del esquema y de reglas, resultado de validaciones, evidencia mínima por campo, estado, actor que revisó y marcas temporales. Evite duplicar el documento completo en cada log o almacenar texto sensible cuando un identificador y una referencia segura bastan.

Pruebe con documentos representativos y casos límite: páginas giradas, imágenes borrosas, campos ausentes, múltiples monedas, etiquetas ambiguas, duplicados, formatos regionales y documentos con estructura inesperada. Mida tasas separadas de extracción, validación, aceptación automática, revisión, cuarentena, corrección humana y tiempo de resolución. Una alta tasa de aceptación no es una señal positiva si luego aumentan rectificaciones o incidencias.

Defina degradación antes del despliegue. Si el extractor no responde, excede la latencia o devuelve una estructura inválida, el documento debe conservarse y dirigirse a una cola manual o a un mecanismo alternativo autorizado. No rellene valores críticos con estimaciones silenciosas. Active cambios de reglas o de extractor de forma gradual, compare resultados y mantenga una vía de reversión.

Lista de comprobación antes de automatizar un campo

• ¿El campo tiene definición de negocio inequívoca y un consumidor identificado?
• ¿Existen reglas de formato, rango, catálogo y coherencia con otros datos?
• ¿Puede mostrarse evidencia suficiente para confirmar el valor?
• ¿Se conoce el impacto de un falso positivo y se ha fijado un umbral de riesgo?
• ¿Hay ruta de revisión, cuarentena, reintento limitado y alternativa manual?
• ¿La trazabilidad permite explicar la decisión sin retener datos innecesarios?
• ¿Las pruebas incluyen los errores previsibles y la activación gradual tiene reversión?

Un campo pasa de asistencia a automatización cuando demuestra consistencia bajo estas condiciones, no sólo porque un extractor suele acertar. Así, PHP coordina un proceso verificable donde la velocidad de tratamiento no sustituye la responsabilidad sobre el dato.