Ejecutar un piloto documental y entregar el sistema

El proyecto final integra todo el curso. El objetivo del piloto no es procesar el mayor número de documentos ni demostrar que la tecnología «puede hacerlo». Debe responder una pregunta empresarial concreta bajo condiciones definidas y producir evidencia suficiente para decidir qué se despliega, qué se restringe y qué todavía necesita trabajo.

Un buen piloto puede terminar con una decisión de no desplegar. Si identifica que la calidad de entrada, el coste o el riesgo hacen inviable la automatización, ha evitado convertir una demo en un sistema problemático.

Formula una pregunta falsable

Evita objetivos como «validar la solución» o «probar IA documental». Formula una condición que pueda resultar cierta o falsa.

Por ejemplo:

¿Puede el sistema registrar facturas de tres proveedores frecuentes con todos los campos críticos validados, menos del 30 % de revisión completa y sin duplicar escrituras durante cuatro semanas?

La pregunta fija población, clase, resultado y límites. Después añade volumen, canales, exclusiones y métricas.

Congela la configuración evaluada

Registra las versiones de:

• taxonomía;
• muestra y benchmark;
• OCR o procesadores;
• esquemas;
• modelos;
• reglas;
• umbrales;
• workflow;
• integraciones;
• interfaz de revisión;
• política de archivo.

Si cambias una pieza durante el piloto, registra cuándo y separa los resultados. De lo contrario no sabrás qué configuración produjo qué comportamiento.

Despliega por fases de autonomía

Una progresión útil es:

1. Sombra

Procesa documentos reales sin escribir en sistemas de negocio. Compara la salida con el trabajo real y detecta fallos de entrada, clasificación, extracción e integración.

2. Asistida

El sistema propone datos y la persona confirma. Aquí puedes medir cuánto trabajo realmente ahorra la interfaz y qué errores aparecen antes de permitir escrituras automáticas.

3. Automática limitada

Automatiza únicamente segmentos y acciones que cumplen los criterios. Conserva rutas humanas para lo demás.

4. Ampliación

Añade nuevas plantillas, clases o acciones solo después de medirlas. No deduzcas que funcionar en tres proveedores demuestra comportamiento equivalente en todo el universo.

Cada fase debe tener condición de entrada, criterio de salida y procedimiento de reversión.

Prepara operación antes de ampliar volumen

Asigna responsables de:

• cola de revisión;
• incidencias;
• calidad del conjunto de evaluación;
• reglas y umbrales;
• integraciones;
• conservación;
• cambios de proveedor o modelo.

Documenta cómo localizar un caso, corregir un dato, reanudar, reconciliar una escritura, desactivar una ruta, incorporar una plantilla nueva y consultar métricas.

Una persona operadora no debería necesitar que un desarrollador abra la base de datos para saber qué le ocurrió a un documento.

Define mecanismos de parada y reversión

Especifica qué condiciones detienen o restringen el piloto. Por ejemplo:

• error crítico no detectado;
• pérdida o corrupción de documentos;
• duplicación de registros;
• acceso indebido;
• cola de revisión por encima de capacidad;
• degradación sostenida de un segmento;
• dependencia externa indisponible sin recuperación segura.

La parada no debe perder los casos en curso. Conserva estado y ruta para volver al proceso anterior o terminar manualmente.

Mantén un registro de incidencias y cambios

Cada problema relevante debería registrar:

• caso afectado;
• versión del sistema;
• etapa donde apareció;
• impacto;
• causa conocida o hipótesis;
• acción aplicada;
• necesidad de nueva prueba;
• decisión sobre alcance.

No uses el piloto como una secuencia de correcciones invisibles. Los cambios forman parte de la evidencia.

Entregable final del curso

El paquete de entrega debería contener:

1. definición del caso y alcance;
2. inventario de clases;
3. benchmark y línea base;
4. arquitectura del pipeline;
5. contratos de extracción;
6. validaciones;
7. matriz de revisión;
8. ciclo de vida e integración;
9. conjunto de pruebas;
10. informe de evaluación;
11. configuración versionada;
12. manual operativo;
13. registro de incidencias;
14. responsables;
15. criterios de despliegue;
16. mecanismo de reversión;
17. riesgos residuales y alcance no cubierto.

Revisión de cierre

Entrega el paquete a una persona que no haya diseñado el sistema. Debería poder responder:

• qué documentos procesa;
• cuáles no;
• qué datos extrae;
• cómo se valida un campo crítico;
• cuándo interviene una persona;
• cómo se evita duplicar una escritura;
• cómo se reconstruye un caso;
• qué métricas deciden el despliegue;
• cómo se detiene y revierte.

Si necesita preguntarte «qué querías decir» para operar una ruta crítica, esa parte todavía no está suficientemente documentada.

Resultado final del curso

Has pasado de una colección de archivos a un sistema documental especificado y evaluable. Has separado lectura, clasificación, extracción, validación, revisión e integración; has medido calidad y cobertura por segmentos; y has definido cómo operar y detener el sistema.

A partir de aquí puede tener sentido conectar los documentos procesados con otros sistemas de conocimiento o automatización. Un sistema RAG, por ejemplo, resuelve una necesidad distinta: recuperar información de fuentes para responder preguntas. No sustituye la extracción y validación estructurada que has diseñado en este curso.