Del piloto de IA a producción

Al pasar a producción, un piloto de IA cambia de contexto. En una prueba, una persona elige el ejemplo y observa la respuesta. En el trabajo diario llegan documentos incompletos, datos repetidos y situaciones que nadie preparó para la demostración.

La dificultad está en conseguir que el proceso siga siendo útil cuando eso sucede. El equipo necesita saber qué puede aceptar, qué debe revisar y qué hacer cuando el sistema no puede resolver una tarea.

Por eso, antes de ampliar una prueba, conviene describir el trabajo completo. La parte de IA puede ocupar solo un paso. El resto determina si el resultado sirve para la operación.

Empieza por una tarea concreta

«Automatizar administración» es demasiado amplio para evaluar un primer proyecto. Una tarea como extraer ciertos campos de una autorización y vincularla con un registro permite discutir entradas, salidas y errores concretos.

Define quién hace hoy ese trabajo, con qué frecuencia y qué necesita revisar antes de darlo por terminado. También debes identificar qué ocurre después: si el dato se consulta, si alimenta una factura o si desencadena otra acción.

Ese destino cambia la exigencia. Un texto que ayuda a preparar un borrador puede corregirse durante la lectura. Un identificador que se incorpora al registro equivocado puede trasladar el error a varias operaciones posteriores.

Si no puedes describir cómo reconocerás un resultado correcto, todavía falta trabajo de definición. Empezar por ahí evita que el proyecto se valore por lo convincente que parece una respuesta.

La solución puede combinar técnicas distintas

No todas las tareas requieren un asistente generativo. Un archivo estructurado puede procesarse con reglas. Un documento puede necesitar extracción de campos. Una consulta interna puede pedir búsqueda sobre información autorizada.

RAG combina recuperación de información con generación de una respuesta. MCP define una forma de conectar aplicaciones de IA con herramientas y datos. Son conceptos distintos de la extracción documental, como explica la guía sobre IA generativa, RAG y MCP.

No tiene sentido atribuir experiencia en todas esas técnicas a un caso que demuestra una de ellas. Para seleccionar una solución, pide que se explique qué parte realiza cada componente y por qué resulta necesaria para la tarea.

También puede haber pasos que convenga mantener manuales. Si una excepción es poco frecuente y su automatización añade mucha complejidad, ofrecer al equipo una forma clara de resolverla puede ser una decisión razonable.

Prueba lo que realmente llega

Una prueba útil incluye ejemplos representativos y casos incómodos: documentos con formatos distintos, información ausente, duplicados o referencias que no coinciden. El conjunto tiene que reflejar el trabajo que esperas recibir, sin reducirse a los ejemplos que mejor funcionan.

Separa los documentos usados para ajustar el sistema de los que empleas para evaluarlo. Si se revisa una y otra vez la misma muestra, es fácil mejorar esa demostración sin aprender lo suficiente sobre lo que ocurrirá con nuevos datos.

Acuerda qué resultado se considera correcto para cada campo o tarea. El porcentaje global puede ocultar diferencias importantes: confundir un texto secundario no tiene la misma consecuencia que asociar una operación a otra persona.

Registra también los casos que el sistema rechaza o deriva a revisión. Que una tarea no se automatice puede ser un comportamiento adecuado si evita introducir un resultado dudoso. Lo importante es que esa derivación sea visible y utilizable.

Mide el proceso completo

La velocidad de generación no basta para valorar el ahorro. Cuenta la preparación de datos, la revisión, las correcciones y las incidencias. Si obtener la respuesta tarda poco pero comprobarla exige rehacer el trabajo, la mejora es limitada.

Compara tareas equivalentes y deja por escrito el contexto: periodo, tipo de trabajo, personas implicadas y forma de recoger la medida. Cuando no se conoce un dato, es mejor mantener esa limitación que completar el relato con una precisión inventada.

Además del tiempo, puedes observar cuántos casos terminan correctamente, cuántos necesitan intervención y qué errores aparecen. El criterio debe responder a la decisión que necesitas tomar, no a acumular indicadores para una presentación.

No conviertas un resultado inicial en una promesa para todos los clientes. El formato de los datos, las reglas y la organización del trabajo pueden cambiar mucho entre empresas.

Revisión humana que se pueda hacer

Añadir «con supervisión humana» a una descripción no resuelve el diseño del proceso. La persona que revisa necesita ver el dato extraído, su contexto y la información original suficiente para comprobarlo.

También debe poder corregir, rechazar o dejar pendiente una operación sin buscar soluciones fuera del sistema. Si el resultado parece correcto pero falta información, el flujo necesita un estado que represente esa situación.

La responsabilidad tiene que estar clara. Decide quién revisa cada tipo de incidencia y qué operaciones requieren confirmación antes de continuar. No es necesario que una persona compruebe todo de la misma manera. Sí que el criterio esté definido y sea viable en el trabajo diario.

Prueba esa parte con quienes van a usarla. Una pantalla que resulta evidente para quien la ha desarrollado puede exigir demasiada interpretación a alguien que gestiona muchas tareas seguidas.

Permisos y errores forman parte de la integración

Una integración de IA debe respetar qué puede consultar o modificar cada usuario. Que el modelo pueda acceder técnicamente a información no significa que todas las personas deban recibirla.

Distingue lectura de escritura. Preparar una propuesta de cambio y aplicarla a un sistema son acciones diferentes, con consecuencias distintas. Antes de automatizar la segunda, define condiciones, confirmaciones y una forma de investigar lo que ha ocurrido.

La conexión también puede fallar por motivos ajenos al resultado de IA. Debes poder reconocer una operación pendiente, evitar duplicados y recuperar el trabajo cuando un servicio vuelve a estar disponible.

Ese funcionamiento merece una prueba propia. Interrumpir de forma controlada una conexión en un entorno de ensayo puede revelar problemas que una demostración sin incidencias no muestra.

Quiralis demuestra un flujo documental concreto

En Quiralis, la plataforma desarrollada por Mecexis incorpora Google Cloud Document AI para extraer información de autorizaciones. El equipo administrativo revisa y corrige los datos y los vincula con los actos correspondientes y su facturación.

El caso recoge una reducción de 8 horas a 20 minutos de revisión documental diaria por persona, redondeada al 96%. La empresa usuaria validó la medida en diferentes días durante meses de uso, con supervisión administrativa.

El resultado corresponde a esa tarea recurrente. No describe el ahorro de toda la actividad del centro ni permite deducir el mismo resultado en otro proceso. Tampoco convierte el caso en una demostración de asistentes RAG o agentes que actúan de forma autónoma.

Lo relevante para esta decisión es que la extracción está integrada en un recorrido de trabajo con revisión y destino de los datos. El modelo aporta una parte del resultado. La plataforma y las personas hacen posible utilizarlo.

Despliega con un alcance que puedas observar

Una primera fase de producción puede limitarse a un tipo de documento, un equipo o una parte del recorrido. Esa limitación debe permitir completar una tarea útil y detectar problemas antes de ampliar el alcance.

Acuerda cuándo avanzar y cuándo detener la ampliación. Si aparecen errores que el equipo no puede resolver o la revisión consume más trabajo del previsto, necesitas ajustar el proceso antes de incorporar más volumen.

Después del lanzamiento, los formatos, las reglas y los componentes pueden cambiar. Conserva ejemplos de evaluación y revisa el comportamiento tras cambios relevantes. La aceptación inicial no sustituye el mantenimiento.

Un piloto empieza a convertirse en una herramienta cuando el equipo puede usarlo en un día corriente, corregir lo que falla y entender el resultado. Esa es una prueba más exigente y más útil que una demostración que solo necesita salir bien una vez.