Comprobar datos, integración y viabilidad técnica

Una oportunidad puede parecer excelente en una reunión y atascarse al llegar a los sistemas reales. A veces el dato que debía activar el flujo no existe. O existe, pero está repartido entre correos, carpetas y una aplicación sin acceso programático. También puede ocurrir que el equipo disponga de muchos documentos, aunque no de ejemplos suficientemente representativos para comprobar si una extracción o una clasificación funciona.

La viabilidad técnica no pregunta si la IA puede hacer algo en abstracto, sino si el proceso concreto puede operar con las entradas, permisos, integraciones y controles disponibles. La línea base de la lección 1 describía la situación actual; aquí comprobarás el funcionamiento técnico posible.

Empieza por el recorrido de la información

Sigue una instancia real desde que empieza hasta que termina. Para cada paso, identifica:

• qué información entra;
• dónde se encuentra;
• quién puede acceder a ella;
• en qué formato aparece;
• qué transformación recibe;
• dónde debe quedar el resultado;
• qué sistema conserva el estado oficial.

Esta revisión descubre diferencias que una descripción general oculta: correo puede significar un buzón compartido o cuentas personales; registrar en el ERP puede significar una integración, una importación o una copia manual. Identifica también el sistema de referencia que prevalece cuando dos fuentes discrepan y evita crear estados incompatibles.

Evalúa las entradas reales, no las ideales

Una demostración suele utilizar documentos limpios, campos completos y ejemplos sencillos. El proceso real contiene escaneos torcidos, abreviaturas, adjuntos equivocados, mensajes sin contexto, plantillas antiguas y casos en varios idiomas. La pregunta útil no es si existe información, sino si su calidad permite operar con una fiabilidad aceptable.

Examina una muestra que represente la diversidad del trabajo, con casos frecuentes, excepciones conocidas y ejemplos difíciles. Observa:

• completitud: faltan campos necesarios para decidir o actuar;
• consistencia: el mismo concepto aparece con nombres o formatos distintos;
• legibilidad: el texto o la imagen puede procesarse sin reconstrucción manual;
• procedencia y actualidad: se conoce el origen y la información sigue siendo válida;
• sensibilidad: contiene información con restricciones;
• representatividad: incluye la variedad prevista.

No necesitas disponer de un conjunto perfecto para empezar. Sí necesitas saber qué defectos existen y qué comportamiento tendrá el flujo cuando aparezcan. Una entrada incompleta puede enviarse a revisión; una ilegible puede rechazarse con una causa explícita; una fuente desactualizada quizá invalide toda la oportunidad.

Distingue acceso, integración y automatización

Que una persona pueda ver un dato no significa que un sistema pueda utilizarlo de forma segura y estable. Conviene separar tres preguntas.

¿Existe acceso autorizado?

Identifica propietarios, permisos y condiciones de uso. Un archivo al que solo accede una cuenta personal es una dependencia frágil. Un buzón compartido sin una política clara puede mezclar conversaciones fuera de alcance. Si el caso requiere información sensible, registra desde el principio quién necesita acceder y con qué finalidad.

¿Existe una vía de integración?

Las vías habituales incluyen una API, un webhook, una exportación programada, una carpeta controlada, un archivo estructurado o una acción manual. No todas ofrecen el mismo control. Una API documentada puede permitir leer y escribir estados; una exportación diaria introduce retraso; copiar y pegar mantiene una intervención humana que debe aparecer en el diseño.

No des por supuesta una capacidad porque una herramienta tenga una página web. Comprueba, para el entorno contratado y la cuenta concreta, qué operaciones están disponibles, qué permisos requieren, qué límites aplican y cómo se detectan los errores. Las integraciones y sus condiciones cambian; por eso esta verificación debe quedar fechada.

¿Puede mantenerse el flujo?

Una prueba puntual puede funcionar con credenciales de una persona y archivos preparados. Un proceso mantenible necesita propietarios, registros de ejecución, tratamiento de fallos, control de versiones y una forma de reanudar o repetir sin duplicar efectos. La viabilidad incluye operar el sistema después de la demostración.

Comprueba la cadena completa

Una solución de IA rara vez vive aislada. Puede recibir un documento, extraer campos, aplicar reglas, pedir una revisión y actualizar una aplicación. Cada transición añade una condición que puede fallar.

Representa la cadena con cinco tipos de elemento:

1. Origen: correo, formulario, carpeta, CRM, ERP u otra fuente.
2. Preparación: descarga, conversión, limpieza, división o anonimización.
3. Capacidad: extracción, clasificación, recuperación, generación o recomendación.
4. Control: reglas, umbrales, revisión, aprobación o escalado.
5. Destino: sistema de referencia, tarea, respuesta, informe o archivo.

Para cada conexión anota qué ocurre si no responde, devuelve datos incompletos o procesa dos veces el mismo caso. Esta revisión evita confundir la capacidad central con el sistema completo. Extraer correctamente cinco campos de una factura no resuelve por sí solo la identificación del proveedor, la validación contra un pedido ni el registro contable.

Comprueba la capacidad con una muestra adecuada

El AI RMF de NIST recomienda utilizar casos realistas y representativos de las condiciones de uso previstas y documentar la metodología. Adapta esa recomendación voluntaria al alcance: utiliza ejemplos autorizados o una muestra que conserve las características relevantes sin exponer información innecesaria, y separa los casos de ajuste de los de evaluación.

Define qué resultado se considera correcto por campo, categoría o tarea. Una cifra global puede ocultar fallos importantes. En una extracción, quizá el número de referencia sea imprescindible mientras que una descripción secundaria admita corrección manual. En una búsqueda documental, no basta con que la respuesta suene plausible: hay que comprobar si recupera evidencia pertinente y si permite rastrear la fuente.

Cuando el patrón sea RAG, la guía específica de Microsoft propone métricas ajustadas al caso de uso y permite separar recuperación y respuesta. En esta lección general basta con identificar qué componente falla y si el resultado completo sirve para la tarea; el diseño detallado de evaluación RAG queda fuera.

No confundas esta medición con las demás del curso: la lección 1 fijó la situación actual; esta comprueba comportamiento técnico; la lección 7 utilizará indicadores para comparar prioridades; y la lección 8 elegirá el criterio que decide si el experimento avanza o se detiene.

Un ejemplo: altas de proveedores desde documentos

Imagina una empresa que recibe por correo formularios de alta, certificados bancarios y documentos fiscales. Quiere extraer datos y crear un borrador en el ERP.

La primera propuesta podría ser: IA que lee los documentos y da de alta al proveedor. El análisis técnico la descompone:

• el buzón compartido es el origen autorizado;
• un correo puede contener varios adjuntos y conversaciones anteriores;
• los formatos varían según país y proveedor;
• algunos documentos son imágenes y otros contienen texto;
• el ERP dispone de una importación controlada, pero no permite crear el alta definitiva sin aprobación;
• el identificador fiscal y la cuenta bancaria requieren validaciones específicas;
• los casos sin pedido asociado deben escalarse a Compras;
• el estado oficial permanece en el ERP.

Con esta información, el patrón inicial cambia. El sistema puede agrupar adjuntos, extraer campos y preparar un borrador; las reglas validan formatos y duplicados; una persona compara los datos sensibles y aprueba el alta. La oportunidad sigue siendo viable, pero su alcance y su grado de autonomía ya no son los de la idea inicial.

Registra la viabilidad técnica

Añade a tu ficha de oportunidad los siguientes campos:

• fuentes de entrada y propietarios;
• sistema de referencia para cada estado relevante;
• formatos y variaciones observadas;
• muestra disponible y limitaciones de representatividad;
• calidad mínima necesaria;
• datos sensibles y restricciones de acceso;
• vía de integración por sistema;
• operaciones que deben leerse o escribirse;
• dependencias de cuentas, permisos o proveedores;
• controles de duplicidad y trazabilidad;
• fallos previsibles y forma de recuperación;
• hipótesis técnicas todavía no comprobadas.

Marca cada elemento como confirmado, pendiente de verificar o bloqueante. No conviertas una suposición en un dato. Si todavía no sabes si el ERP admite una importación, escríbelo como hipótesis y asigna una comprobación concreta.

Ejercicio: auditoría de una instancia real

Elige una instancia terminada del proceso y reconstruye su recorrido sin modificar sistemas ni datos. Recoge evidencia autorizada de cada paso y completa esta tabla:

Termina con una conclusión de tres partes: qué cadena mínima parece posible, qué hipótesis debes probar y qué condición haría inviable el alcance actual. Evita responder solo sí o no. Una decisión útil explica bajo qué condiciones técnicas existe la oportunidad.

Conclusión técnica

Ya puedes distinguir una capacidad atractiva de un flujo técnicamente operable. Has identificado datos, sistemas, accesos, integraciones y puntos de fallo, y has convertido las incertidumbres en comprobaciones. La siguiente lección añadirá la otra mitad de la decisión: qué daño puede causar un error y qué supervisión necesita el proceso.