De una demo de IA a un proceso que tu equipo puede usar

Una demo suele trabajar con un archivo elegido, una pregunta bien formulada y alguien preparado para interpretar la respuesta. El trabajo diario introduce otras condiciones: documentos incompletos, formatos diferentes, permisos y personas que necesitan seguir con su tarea aunque el modelo falle.

El salto a producción comienza cuando esas condiciones pasan a formar parte del diseño.

Una tarea, de principio a fin

Supongamos que queremos ayudar a revisar documentación de proveedores. El equipo recibe archivos, comprueba determinados campos y registra lo que falta. Es un ejemplo ilustrativo; no representa resultados de un cliente.

El primer alcance podría ser un único tipo de documento. La aplicación recibe el archivo, propone varios datos y muestra dónde aparecen. Una persona los confirma o corrige. Sólo entonces se incorporan a la ficha del proveedor.

Este recorrido ofrece una unidad de trabajo comprensible. Permite decidir qué debe hacer la IA y qué debe permanecer bajo control de una persona. También evita que la primera entrega dependa de sustituir todas las herramientas de la empresa.

Qué merece una prueba

El perfil de IA generativa del NIST sitúa la evaluación, la documentación de riesgos y la supervisión dentro de la gestión del sistema. Es una referencia técnica para organizar el trabajo; seguir una lista no equivale a obtener una certificación. Fuente: NIST AI 600-1.

Para nuestro ejemplo, prepararíamos una muestra de documentos representativos, con autorización para utilizarlos, y definiríamos el resultado esperado antes de evaluar la herramienta.

Situación	Qué comprobar
Documento habitual y completo	Que los campos propuestos coincidan con el original
Dato ausente o ambiguo	Que quede pendiente de revisión y no se invente
Usuario sin permisos	Que no pueda consultar el archivo ni su contenido extraído
Servicio de IA no disponible	Que el equipo pueda continuar o recuperar la tarea sin duplicados
Corrección humana	Que se conserve el dato final y el historial necesario

Los umbrales de aceptación dependen del uso y sus consecuencias. No tiene sentido dar por suficiente una cifra de precisión sin saber qué errores contiene ni quién asume la revisión.

Medir el trabajo completo

Una extracción rápida puede trasladar más trabajo a la persona que corrige. Por eso conviene medir el tiempo de la tarea completa, los errores detectados y las revisiones pendientes, comparándolos con una muestra del proceso actual.

También hay que observar cuánto cuesta procesar un documento y qué ocurre con archivos más largos o con picos de uso. El gasto del modelo es una parte del coste total; mantener conexiones, permisos y trazabilidad también requiere trabajo.

Qué debería quedar al entregar

Una primera versión necesita un responsable, criterios de aceptación y un procedimiento para incidencias. La documentación debería permitir reconocer qué hace la herramienta, sus límites y cómo volver al proceso anterior si es necesario.

En Kenea utilizamos esta conversación para acotar el desarrollo: qué recibe la aplicación, qué propone, quién valida y dónde guarda el resultado. Con ese mapa se puede preparar una propuesta concreta y decidir si merece la pena construirla.