Un asistente IA con documentos internos puede ayudar a encontrar procedimientos, manuales y decisiones dispersas. Yo empezaría por una tarea concreta: que una persona resuelva una consulta de trabajo con una respuesta que pueda comprobar. Si el buscador actual ya la resuelve bien, añadir generación de texto puede no compensar.
La dificultad aparece cuando una respuesta suena convincente pero omite una condición, mezcla dos versiones o cita un documento que no demuestra lo afirmado. Es uno de los problemas que hay que resolver para pasar de una demo de IA a producción. El piloto debe descubrir esos fallos antes de ampliar el uso.
Acotar el trabajo antes de elegir el modelo
Definiría un equipo, un proceso y una colección documental con responsable. Por ejemplo, consultar procedimientos de soporte sin modificar cuentas, enviar mensajes ni aprobar excepciones. Responder y ejecutar una acción son alcances diferentes. El primer presupuesto debe decir cuál incluye.
El sistema necesita ingesta con versiones, identidad y permisos comprobados por el servidor, búsqueda de pasajes autorizados y respuestas con trazabilidad. La guía de aceptación de un piloto RAG desarrolla las pruebas de caducidad, borrado y revocación de acceso. Aquí me centro en evaluar la respuesta que recibe la persona.
Cómo evaluar respuestas y citas
Prepararía preguntas reales anonimizadas junto al responsable del proceso, antes de ajustar el asistente. Para cada pregunta guardaría el perfil de prueba, la fuente y versión válidas, el pasaje esperado, las condiciones que no puede omitir y la salida aceptable. Reservaría preguntas para una comprobación posterior: probar solo los ejemplos usados durante el desarrollo oculta errores.
| Comprobación | Evidencia que pediría | Motivo de rechazo |
|---|---|---|
| Recuperación | El pasaje necesario aparece en el contexto autorizado. | El documento existe, pero no se recuperó la condición relevante. |
| Respaldo | Cada afirmación decisiva se vincula a un pasaje que la demuestra. | La cita habla del tema, pero no sostiene la conclusión. |
| Integridad | Se conservan límites, excepciones y pasos necesarios. | La respuesta elimina una excepción que cambia la decisión. |
| Incertidumbre | Pide el dato que falta o explica qué no puede confirmar. | Completa un vacío con una regla inventada. |
| Utilidad | La persona identifica el siguiente paso correcto y puede abrir la fuente. | Debe reconstruir toda la respuesta o llega a una acción equivocada. |
Una puntuación de confianza declarada por el modelo no sustituye estas comprobaciones. Tampoco aprobaría por el número de citas: hay que leer qué sostienen. Un evaluador automático puede ayudar a ordenar revisiones, pero el responsable del proceso debe comprobar los casos críticos y resolver discrepancias.
La investigación Evaluation and Continual Improvement for an Enterprise AI Assistant trata la evaluación como un problema de varios componentes y de mejora continua. La ficha anterior es una propuesta de trabajo, no un resultado de ese estudio ni una garantía de precisión.
Ejemplo: una respuesta correcta que omite una excepción
Supongamos un manual ficticio que permite solicitar acceso temporal y exige aprobación del responsable para un sistema concreto. Un empleado pregunta cómo conseguir ese acceso. El asistente enlaza el manual y responde «abre una solicitud», pero omite la aprobación. La fuente se recuperó; la respuesta sigue incompleta.
Yo registraría la condición omitida y comprobaría dónde se perdió: extracción del documento, selección del pasaje o redacción. Después repetiría la pregunta y otras equivalentes. Si el empleado no indica qué sistema necesita, la salida esperada puede ser pedir esa aclaración. Este ejemplo no describe una implantación ni resultados de un cliente.
Qué exigir para aceptar el piloto
- Pregunta completa: respuesta respaldada, condiciones necesarias y referencia al pasaje correcto.
- Pregunta ambigua: solicita el dato que cambia la respuesta, sin escoger una interpretación por su cuenta.
- Evidencia parcial: distingue lo confirmado de lo que falta; no presenta la respuesta parcial como completa.
- Sin respuesta documental: reconoce la ausencia y ofrece el canal de revisión acordado.
- Fuentes contradictorias: muestra el conflicto al revisor autorizado y evita resolverlo con una preferencia arbitraria.
- Petición de actuar: mantiene el límite de consulta y no interpreta una explicación como autorización para ejecutar.
Acordaría criterios por categoría y gravedad antes de probar. Mediría por separado respuestas respaldadas, omisiones, rechazos correctos y rechazos innecesarios sobre sus respectivos casos. Un asistente que rechaza todo no es útil. Un promedio favorable tampoco compensa una exposición de datos: ese fallo bloquea la ampliación hasta corregirlo y repetir las pruebas.
Medir el trabajo que queda para el equipo
Compararía consultas equivalentes con el proceso actual, incluyendo tiempo de búsqueda, lectura de fuentes, corrección y escalado. Añadiría mantenimiento documental, incidencias y consumo del sistema. Menos tiempo generando texto no implica menos trabajo total ni ahorro monetario automático.
El piloto puede justificar continuar, reducir el alcance o volver al buscador. También puede ser inconcluso si faltan casos representativos. La planificación técnica antes de programar ayuda a dejar esas decisiones y sus responsables por escrito.
Trazas y mantenimiento después de la entrega
Conservaría identificador de consulta, perfil de prueba, versiones de fuentes, pasajes recuperados, respuesta, citas, versión de configuración y resultado de revisión. El acceso y la retención de esas trazas también necesitan límites: copiar documentos sensibles a un registro abierto crea otro problema.
En Adslyfy se documentan ejecuciones, fallos y capturas para monitorizar anuncios. Es una referencia de visibilidad operativa, no un caso de asistente documental ni una prueba de precisión de IA.
Asignaría quién corrige una fuente, quién resuelve una incidencia técnica y quién revisa respuestas tras cambiar modelo, instrucciones o documentos. Repetiría el conjunto de evaluación tras esos cambios y registraría regresiones, en lugar de dar por permanente el resultado inicial.
Qué preparar para contratar el desarrollo
Pediría una propuesta con fuentes y formatos incluidos, conexión de identidades, conjunto de evaluación, interfaz, trazas, traspaso y mantenimiento. Separaría construcción de costes recurrentes y tareas que seguirá haciendo tu equipo. Puedes usar la guía para comparar presupuestos de software y concretar entregables y exclusiones.
Si necesitas convertir una demo en un sistema evaluable, puedo revisar el alcance desde mis servicios de automatización e IA aplicada. Cuando el bloqueo afecta a decisiones de varios equipos, también puede encajar el apoyo de dirección técnica.
Para hablar del primer piloto, prepara los tipos de documentos, los usuarios y dos preguntas representativas con su respuesta esperada. Empecemos con ejemplos anonimizados, sin enviar documentación confidencial en el primer contacto.