IA aplicada: cómo evaluar un asistente antes de ponerlo en producción

Un asistente de IA puede responder correctamente durante una demostración y, aun así, fallar cuando recibe preguntas ambiguas, información desactualizada o solicitudes fuera de alcance. El riesgo aumenta cuando sus respuestas influyen en decisiones operativas, atienden a clientes o se integran con sistemas internos.

Antes de desplegarlo, conviene evaluar algo más que si “responde bien”. Un proceso de evaluación debe comprobar la calidad del contenido, la experiencia de uso y los controles necesarios para operar el sistema de forma supervisable. En este artículo se propone un método práctico para crear casos de prueba, definir criterios de aceptación, registrar evidencia, medir errores y repetir la evaluación después de cambiar el modelo, las fuentes o los prompts.

Qué debe demostrar un asistente antes del despliegue

La primera decisión no es técnica: consiste en delimitar qué trabajo puede realizar el asistente y qué situaciones deben quedar fuera de su responsabilidad. Sin este límite, resulta difícil definir qué es una respuesta aceptable.

Definir el propósito y el alcance

Un asistente interno que consulta políticas de recursos humanos no tiene los mismos criterios que uno que ayuda a diagnosticar errores en una API. En el primer caso, puede ser prioritario citar la política vigente y proteger información personal. En el segundo, puede ser más importante distinguir entre una hipótesis y una causa confirmada.

El alcance debería describir, al menos:

Qué preguntas o tareas puede atender.
Qué fuentes tiene autorizadas.
Qué acciones puede ejecutar, si está conectado a herramientas.
Qué información no debe revelar.
Cuándo debe pedir más contexto.
Cuándo debe abstenerse o derivar la conversación a una persona.

Esta definición evita evaluar al asistente contra una expectativa ilimitada. La exactitud no es universal: depende del dominio, las fuentes disponibles, la fecha de actualización y el riesgo asociado a cada respuesta.

Separar tipos de calidad

Una respuesta puede ser correcta desde el punto de vista técnico, pero inútil para quien la recibe. Por eso es conveniente separar tres dimensiones:

Calidad del contenido: exactitud, relevancia, completitud, coherencia y uso adecuado de las fuentes.
Experiencia del usuario: claridad, tono, capacidad de pedir aclaraciones y facilidad para llegar a una respuesta accionable.
Controles operativos: trazabilidad, protección de datos, límites de acceso, escalamiento, observabilidad y capacidad de reproducir un incidente.

Un resultado agregado puede ocultar fallos importantes. Por ejemplo, un asistente podría responder correctamente a preguntas frecuentes, pero inventar una respuesta cuando no encuentra información. Esa conducta debe tratarse como un riesgo específico, no como un detalle menor de estilo.

Cómo construir un conjunto de evaluación representativo

La evaluación debe basarse en situaciones que el sistema encontrará realmente. Una colección de preguntas improvisadas por el equipo que desarrolló el asistente suele favorecer los casos conocidos y dejar fuera las condiciones que producen errores.

Combinar preguntas reales y casos diseñados

El conjunto de evaluación puede reunir preguntas anonimizadas de tickets, conversaciones de soporte, búsquedas internas y consultas de usuarios. También debe incluir casos diseñados deliberadamente para comprobar límites y comportamientos de seguridad.

Una clasificación útil puede incluir:

Casos frecuentes: preguntas que representan el uso esperado.
Casos importantes: solicitudes menos frecuentes, pero con impacto relevante si la respuesta es incorrecta.
Casos ambiguos: preguntas con términos incompletos, referencias poco claras o varias interpretaciones posibles.
Casos fuera de alcance: solicitudes que el asistente no está diseñado para resolver.
Casos adversariales: intentos de obtener información restringida, alterar instrucciones o forzar una respuesta sin evidencia.
Casos desactualizados: preguntas cuya respuesta depende de una política, versión o documento que cambió.

Incluir variaciones del mismo caso

No basta con probar una única redacción. La misma intención puede expresarse con errores ortográficos, lenguaje informal, abreviaturas o información adicional irrelevante. También conviene probar conversaciones de varios turnos, porque el asistente puede responder bien al primer mensaje y perder el contexto después.

Para cada intención relevante, se pueden crear variaciones que comprueben:

Diferentes formas de formular la pregunta.
Información faltante o contradictoria.
Referencias a mensajes anteriores.
Solicitudes combinadas con tareas no soportadas.
Preguntas sobre información que no está en las fuentes autorizadas.

El objetivo no es acumular preguntas indefinidamente, sino cubrir los riesgos y comportamientos que importan para el producto.

Cómo definir criterios de aceptación para cada respuesta

Evaluar con una impresión general como “parece buena” dificulta comparar versiones y discutir resultados. Cada caso debería tener una expectativa explícita, aunque la respuesta final no tenga que coincidir palabra por palabra con un texto predefinido.

Describir una respuesta aceptable

Para cada prueba, conviene registrar:

La pregunta o conversación de entrada.
La intención que se desea resolver.
La información que debería aparecer.
La información que no debería aparecer.
Las fuentes que respaldan la respuesta.
Si debe pedir aclaraciones.
Si debe abstenerse o escalar.
El nivel de riesgo en caso de error.

Por ejemplo, para una consulta sobre una política interna, una respuesta aceptable podría necesitar citar el documento vigente, indicar una condición concreta y reconocer que no puede resolver una excepción no contemplada. No sería suficiente con una explicación genérica que suene razonable.

Medir errores de contenido, no solo similitud textual

Una respuesta puede utilizar palabras distintas a las esperadas y seguir siendo válida. Por eso, la evaluación debería centrarse en criterios verificables:

Exactitud: las afirmaciones coinciden con la información disponible.
Relevancia: responde a la intención sin desviarse innecesariamente.
Completitud: incluye las condiciones o pasos necesarios para la tarea.
Consistencia: no se contradice con otras respuestas del mismo contexto.
Calibración: diferencia hechos, inferencias y falta de información.
Seguridad: no revela datos ni ejecuta acciones fuera de sus permisos.

También es útil clasificar los fallos. No es lo mismo una respuesta incompleta que una afirmación falsa, una fuente mal atribuida o una recomendación peligrosa. Esta clasificación ayuda a priorizar correcciones y evita esconder riesgos distintos bajo una única puntuación.

Evaluar fuentes, abstención y escalamiento humano

En muchos asistentes empresariales, responder siempre es una mala señal. Cuando la información no está disponible, es ambigua o tiene un nivel de riesgo elevado, la conducta correcta puede ser pedir contexto, abstenerse o transferir el caso.

Registrar evidencia de las fuentes

Cuando el asistente utiliza documentación interna o una base de conocimiento, la evaluación debe comprobar no solo el texto final, sino también su respaldo. Para cada respuesta relevante, se puede revisar:

Qué documentos o fragmentos fueron recuperados.
Si esos documentos estaban autorizados para el usuario.
Si la evidencia realmente respalda la afirmación.
Si la fuente estaba vigente al momento de responder.
Si el asistente distingue entre información encontrada y conocimiento no confirmado.

Mostrar una referencia no convierte automáticamente una respuesta en correcta. El fragmento citado puede ser irrelevante, estar incompleto o corresponder a una versión antigua. La revisión debe validar la relación entre la afirmación y la evidencia.

Definir cuándo debe abstenerse

La abstención no significa que el sistema haya fallado. En ciertos escenarios es una capacidad necesaria. El criterio debe ser explícito y observable.

Un asistente podría abstenerse cuando:

No encuentra una fuente confiable para responder.
Las fuentes disponibles se contradicen.
La pregunta requiere una decisión que corresponde a una persona autorizada.
La solicitud involucra datos o acciones fuera de sus permisos.
La consecuencia de una respuesta incorrecta supera el nivel de riesgo aceptado.

La abstención también debe ser útil. En lugar de responder únicamente “no lo sé”, el sistema puede explicar qué información falta, indicar qué fuente consultar o derivar el caso con el contexto necesario para que una persona continúe la atención.

Diseñar el escalamiento como parte del flujo

Escalar a una persona no debería ser una salida improvisada. El producto debe definir qué información se conserva, cómo se notifica el caso y qué ocurre con la conversación posterior.

Entre los controles que conviene probar están:

Que el usuario entienda por qué se requiere intervención humana.
Que la persona reciba la pregunta original y los datos relevantes.
Que no se envíe información que el operador no está autorizado a ver.
Que el caso quede registrado para su posterior análisis.
Que el asistente no siga ejecutando acciones incompatibles mientras el caso está escalado.

Separar calidad, experiencia y operación en la evaluación

Una evaluación útil necesita observar el sistema completo. El modelo es solo uno de sus componentes; también influyen la recuperación de información, la construcción del prompt, las herramientas conectadas, los permisos y la interfaz.

Calidad del contenido

Revise si la respuesta resuelve la tarea y si sus afirmaciones pueden justificarse. En un asistente para ingeniería, por ejemplo, no basta con sugerir un cambio en una API: debería diferenciar entre una hipótesis de diagnóstico y una causa comprobada, además de señalar qué datos faltan para confirmar la recomendación.

Experiencia del usuario

Compruebe si el asistente:

Hace preguntas de aclaración cuando realmente las necesita.
Evita pedir datos que ya están disponibles en el contexto.
Presenta las instrucciones en un orden comprensible.
Utiliza un nivel de detalle adecuado para el perfil del usuario.
Explica sus límites sin generar una falsa sensación de certeza.

Una respuesta técnicamente válida puede resultar poco operativa si mezcla varias alternativas sin explicar cuándo utilizar cada una. La claridad forma parte de la calidad del producto.

Controles operativos

Antes de producción, también deben verificarse aspectos que no aparecen en una conversación aislada:

Registro de entradas, salidas, fuentes y decisiones de escalamiento, respetando las políticas de privacidad.
Control de acceso a documentos y herramientas.
límites de consumo y comportamiento ante errores o indisponibilidad de dependencias.
Identificación de la versión del modelo, prompt y conjunto de fuentes utilizado.
Capacidad de investigar una respuesta problemática y reproducir el contexto relevante.
Alertas para patrones de error, uso anómalo o aumento de derivaciones.

Estos controles son especialmente importantes cuando el asistente puede consultar sistemas internos o ejecutar acciones. En esos casos, la evaluación debe cubrir también permisos, validaciones y posibilidades de reversión.

Repetir la evaluación después de cada cambio

Modificar un prompt, incorporar una fuente, cambiar el modelo o ajustar la estrategia de recuperación puede mejorar un caso y empeorar otro. Por eso, la evaluación no debe realizarse una sola vez antes del lanzamiento.

Crear una evaluación de regresión

Conviene conservar un conjunto estable de casos representativos y ejecutarlo antes de aceptar cambios relevantes. Ese conjunto puede dividirse en:

Pruebas críticas: casos que no deberían degradarse.
Pruebas de cobertura: situaciones frecuentes y variaciones de lenguaje.
Pruebas de límites: abstención, permisos, información contradictoria y solicitudes fuera de alcance.
Pruebas exploratorias: nuevos casos descubiertos durante el uso o la revisión humana.

Los resultados deberían conservar la configuración con la que se obtuvieron: versión del modelo, instrucciones, fuentes, herramientas disponibles y fecha de ejecución. Sin ese contexto, comparar dos resultados puede llevar a conclusiones equivocadas.

Combinar revisión automática y humana

Las comprobaciones automáticas son útiles para detectar condiciones concretas, como la presencia de una referencia, un formato requerido o la ausencia de determinados datos. Sin embargo, no sustituyen la revisión humana en aspectos como la exactitud contextual, la utilidad de una explicación o la gravedad de una omisión.

Una práctica razonable es utilizar revisores con conocimiento del dominio para los casos de mayor riesgo y registrar el motivo de cada decisión. Cuando varias personas evalúan, es importante acordar previamente qué significa “aceptable”, “requiere corrección” y “debe escalarse”.

Comparar cambios con criterios de decisión

No todo cambio que aumenta la cobertura debe aprobarse. El equipo puede decidir que una versión es aceptable solo si:

No introduce fallos en los casos críticos.
Mantiene los controles de acceso y privacidad.
Mejora o conserva la calidad en los escenarios prioritarios.
Expone correctamente los casos en los que no puede responder.
Permite identificar qué configuración produjo cada resultado.

Estos criterios transforman la evaluación en una parte del proceso de ingeniería y no en una revisión subjetiva al final del proyecto.

Errores frecuentes al evaluar asistentes de IA

Algunos enfoques producen una falsa sensación de seguridad porque miden lo fácil de observar y dejan fuera los riesgos operativos.

Probar solo preguntas ideales: no revela cómo reacciona el sistema ante ambigüedad, datos faltantes o solicitudes maliciosas.
Evaluar únicamente el tono: una respuesta amable puede contener información incorrecta.
Usar una única respuesta de referencia: limita la evaluación cuando existen varias respuestas válidas.
Premiar siempre la respuesta: puede incentivar afirmaciones inventadas en lugar de abstenciones apropiadas.
Ignorar la vigencia de las fuentes: una respuesta respaldada por documentación antigua puede ser incorrecta.
No distinguir severidad: un error de formato no tiene el mismo impacto que una recomendación peligrosa o una filtración de datos.
No repetir las pruebas: una modificación aparentemente pequeña puede cambiar el comportamiento en casos no revisados.
Medir solo el modelo: muchos problemas provienen de la recuperación de información, los permisos, la interfaz o la integración.

Conclusión: evaluar antes de desplegar es diseñar un producto supervisable

Un asistente de IA no debería pasar a producción porque ofrece buenas respuestas en una demostración. Antes es necesario definir su alcance, construir casos representativos, establecer criterios de aceptación y comprobar cómo maneja la incertidumbre, la falta de fuentes y las solicitudes de alto riesgo.

La evaluación debe separar contenido, experiencia de usuario y operación. También debe conservar evidencia de las fuentes, registrar la configuración utilizada y repetirse después de cambiar prompts, modelos, herramientas o documentación. El objetivo no es prometer exactitud universal, sino conocer dónde el sistema es útil, dónde necesita supervisión y cuándo debe abstenerse.

Antes de desplegar un asistente, define casos de prueba y criterios de aceptación. Si tu equipo necesita convertir una demo en una solución de IA aplicada, una asesoría especializada puede ayudar a diseñar la evaluación, los controles y el proceso de mejora continua.

IA aplicada: cómo evaluar un asistente antes de ponerlo en producción