Cómo probar un asistente de IA antes del lanzamiento: construir un conjunto de prueba con tus propios casos, fijar umbrales de aprobación y decidir quién da el visto bueno

Un asistente de IA puede responder preguntas a partir de tus documentos, redactar respuestas a clientes o extraer datos de formularios. Una demo muestra que puede hacerlo, pero no con qué frecuencia se equivoca con tus propios casos, ni de qué manera. Para eso necesitas una prueba construida con casos reales del pasado. Tu gente escribe la respuesta correcta para cada uno, y acuerdas de antemano cuántos errores de cada tipo aceptas. Después, una persona concreta de tu empresa da el visto bueno a los resultados.

¿Por qué una buena demo de IA no es una prueba?

Una demo muestra preguntas que eligió el vendedor, cada una respondida una sola vez. Tus clientes y tu personal harán otras preguntas con sus propias palabras, y la misma pregunta puede recibir una respuesta distinta en un segundo intento.

La guía de OpenAI sobre buenas prácticas de evaluación empieza precisamente por ahí: «La IA generativa es variable. Los modelos a veces producen resultados distintos a partir de la misma entrada, lo que hace que los métodos tradicionales de prueba de software sean insuficientes para las arquitecturas de IA». Todas las fuentes de este artículo se consultaron el 4 de noviembre de 2026.

La guía llama evals, abreviatura de evaluaciones, a las pruebas de las respuestas de un modelo. Uno de los errores que enumera es la eval basada en sensaciones: «Usar “parece que funciona” como estrategia de evaluación, o esperar al lanzamiento para implementar cualquier eval».

El NIST, el Instituto Nacional de Estándares y Tecnología de Estados Unidos, publicó en julio de 2024 un Generative AI Profile como orientación voluntaria. El perfil usa la abreviatura GAI para la IA generativa (generative AI). Una de sus acciones sugeridas dice: «Evitar extrapolar el rendimiento o las capacidades de un sistema de GAI a partir de evaluaciones limitadas, no sistemáticas y anecdóticas».

Un conjunto de prueba hace lo que una demo no puede: una lista de casos reales, cada uno con la respuesta que esperas, puntuados de la misma manera después de cada cambio.

¿De dónde deben salir los casos de prueba?

De tu propio trabajo, en una proporción parecida a la que encontrará el asistente. La guía de Anthropic para definir criterios de éxito y construir evaluaciones para sus modelos Claude dice: «Diseña evals que reflejen la distribución real de tus tareas».

La guía de OpenAI añade: «Asegúrate de que tus datos de prueba incluyan casos típicos, casos límite y casos adversariales». Los casos límite son entradas raras o difíciles. Los casos adversariales intentan que el asistente se comporte mal. Saca los casos de estas fuentes:

• Preguntas y tickets anteriores de un año completo y de todas las categorías, para que aparezcan los estacionales
• Documentos de todos los tipos que leerá el asistente, incluidos escaneos y maquetaciones poco habituales
• Casos difíciles, como una pregunta que mezcla dos temas o un formulario al que le falta un campo
• Preguntas que tus documentos no responden, en las que lo correcto es decirlo y pasar el caso a una persona
• Casos de tolerancia cero, como una solicitud de datos de otro cliente o un reembolso que tu política prohíbe
• Intentos de engañar al asistente, como instrucciones ocultas en un ticket o en un archivo subido

No hay un tamaño estándar para un conjunto de prueba. Un punto de partida práctico son unas cuantas decenas de casos por tipo de pregunta, ya que con solo diez casos un fallo mueve diez puntos porcentuales la puntuación de ese tipo. Redacta cada caso de tolerancia cero de varias maneras, porque un modelo puede rechazar una formulación y aceptar otra.

El conjunto contiene datos reales de clientes, así que aplícale las mismas reglas de acceso que a los tickets y documentos de los que procede.

¿Quién escribe las respuestas esperadas y qué deben incluir?

Las respuestas esperadas las escriben tus propios expertos, no la empresa que construye el asistente. Una respuesta esperada, lo que los ingenieros llaman ground truth, es la respuesta que aceptaría un empleado cuidadoso. Su forma depende de la tarea:

• Respuestas a partir de documentos: los datos que debe contener la respuesta, el documento y la sección de los que proceden, y lo que no debe decir. Una respuesta de ejemplo completa ayuda menos, ya que una respuesta correcta puede redactarse de muchas maneras
• Borradores de respuesta: una lista de comprobación breve, como los datos correctos, la política aplicada y ninguna promesa fuera de la política
• Datos extraídos de documentos: el valor correcto de cada campo, tal como lo guarda tu sistema

El ejemplo de OpenAI para preguntas sobre documentos construye sus datos de prueba en parte con «respuestas correctas predefinidas a preguntas creadas por expertos en la materia». En tu empresa, esos expertos son los jefes de soporte y los responsables de las políticas.

Un segundo experto revisa cada respuesta. Cuando dos personas rigurosas no se ponen de acuerdo, probablemente la política que hay detrás del caso no está clara, y a un asistente que la lea también le costará. La guía de Anthropic incluye estos casos entre sus ejemplos de casos límite: «Casos de prueba ambiguos en los que incluso a las personas les costaría llegar a un consenso en la evaluación». Decide el responsable de la política, y corriges el documento junto con el caso de prueba.

Con cada caso, anota su tipo de pregunta y la versión del documento en la que se basa. Cuando cambie una política, actualiza esos casos, o el conjunto marcará como erróneas respuestas que ahora son correctas.

¿Cómo fijamos los umbrales de aprobación?

Un umbral de aprobación es el resultado mínimo que aceptas antes del lanzamiento. Fija uno por tipo de pregunta y por tipo de error, porque un único umbral de aprobación para todo el asistente oculta demasiado. La guía de Anthropic señala: «La mayoría de los casos de uso necesitan una evaluación multidimensional según varios criterios de éxito».

Clasifica cada caso fallido en un tipo de error:

• Dato erróneo: la respuesta afirma algo falso. El perfil del NIST lo llama confabulación: «La producción de contenido erróneo o falso, pero afirmado con seguridad (conocido coloquialmente como “alucinaciones” o “invenciones”), que puede confundir o engañar a los usuarios».
• Respuesta omitida: los documentos contenían la respuesta, pero el asistente dijo que no la sabía o dejó fuera un dato clave
• Fuente errónea: la respuesta cita un documento que no la respalda, o una versión desactualizada
• Respuesta insegura: un caso de tolerancia cero salió mal
• Forma y tono: los datos son correctos, pero la respuesta es demasiado seca o tiene un formato equivocado

Estos errores no cuestan lo mismo. Una respuesta omitida suele acabar con una persona haciéndose cargo del caso. Un dato erróneo llega al cliente con apariencia de correcto, y puede que nadie lo note. Por eso los datos erróneos tienen un umbral de aprobación más estricto que las respuestas omitidas, y el tono, el más permisivo.

Todos los casos de tolerancia cero tienen que pasar. Un solo fallo detiene el lanzamiento hasta que corrijas la causa y todo el conjunto vuelva a pasar.

Los tipos de pregunta también difieren, ya que un desliz sobre el horario de apertura cuesta menos que un desliz sobre las comisiones. Basa cada umbral de aprobación en lo que te cuesta ese error y en la frecuencia con la que tu equipo se equivoca hoy en los mismos casos. Deja por escrito los umbrales de aprobación antes de la primera ejecución, para que nadie los ajuste a los resultados.

¿Quién o qué puntúa las respuestas del asistente?

El código puede puntuar los datos extraídos de documentos: cada campo coincide con el valor esperado o no coincide. Las respuestas de texto libre y los borradores necesitan criterio, ya sea de personas o de un segundo modelo de lenguaje que trabaje con la lista de comprobación.

La guía de Anthropic describe la calificación por personas como «la más flexible y de mayor calidad, pero lenta y cara. Evítala si es posible». Describe la calificación por un modelo como «rápida y flexible, escalable y adecuada para juicios complejos», y después aconseja: «Primero prueba para asegurar la fiabilidad; después, escala».

Un modelo que se usa como evaluador tiene tendencias conocidas. Entre los retos que enumera la guía de OpenAI figuran: «sesgo de posición (orden de las respuestas), sesgo de verbosidad (preferencia por las respuestas más largas)». Así, el orden de las respuestas puede inclinar el veredicto, y una respuesta más larga puede ganar solo por su extensión. Entre los consejos de la guía figura: «Usa la retroalimentación humana para calibrar la puntuación automatizada». En la práctica, tus expertos califican una muestra que también califica el modelo, y corriges la lista de comprobación allí donde no coincidan.

Para los borradores, ayuda una prueba a ciegas. Mezcla los borradores del asistente con las respuestas de tu personal a los mismos tickets, y deja que los revisores los califiquen sin saber cuál es cuál. La guía de OpenAI pone una «prueba aleatorizada y a ciegas» como ejemplo de calificación por personas.

Como cada respuesta esperada indica su fuente, también puedes comprobar la recuperación (retrieval), el paso de búsqueda que encuentra los fragmentos que lee el modelo. Si la búsqueda nunca encontró el fragmento correcto, corrige la búsqueda, no el modelo. El perfil del NIST sugiere una comprobación relacionada: «Revisar y verificar las fuentes y las citas en las salidas de los sistemas de GAI durante la medición de riesgos previa al despliegue y en las actividades de monitorización continua».

Ejecuta cada caso varias veces y formula las preguntas clave de más de una manera. La guía de Anthropic trata la coherencia como un criterio propio: «Si un usuario hace la misma pregunta dos veces, ¿qué importancia tiene que obtenga respuestas semánticamente similares?». Semánticamente similares significa que las respuestas dicen lo mismo, aunque sea con otras palabras.

¿Cuándo volvemos a ejecutar el conjunto de prueba?

Después de cada cambio, antes de que llegue a los clientes. Es decir, una nueva versión del modelo, documentos editados, una nueva configuración de búsqueda o un nuevo prompt, las instrucciones escritas que sigue el modelo. La guía de OpenAI lo convierte en un paso propio: «Configura una evaluación continua (CE) para ejecutar evals con cada cambio».

Cada ejecución busca regresiones, es decir, casos que pasaban antes de un cambio y fallan después. La media puede subir mientras falla un tipo de pregunta, así que revisa cada tipo por separado. Un cambio solo entra en producción cuando:

• No falla ningún caso de tolerancia cero
• Ningún tipo de pregunta cae por debajo de su umbral de aprobación
• Una persona ha leído cada fallo nuevo y conoce su causa

Guarda los resultados de cada ejecución, con las versiones del modelo, del prompt y de los documentos que se probaron.

Los proveedores también retiran modelos según su propio calendario. La página de OpenAI sobre retiradas (deprecations) indica un preaviso de al menos seis meses para los modelos con disponibilidad general, salvo que motivos de seguridad o de cumplimiento normativo exijan un plazo más rápido. Los modelos en versión preliminar pueden retirarse con un preaviso mucho más corto. La página de Anthropic indica un preaviso de al menos 60 días para los modelos lanzados públicamente y advierte: «Las solicitudes a modelos que hayan pasado su fecha de retirada fallarán».

Ese preaviso es tu margen para ejecutar el conjunto con el modelo de reemplazo, corregir lo que falle y volver a dar el visto bueno. Planifícalo y presupuéstalo desde el principio.

¿Qué comprobamos después del lanzamiento?

Cada semana, un experto puntúa con la misma lista de comprobación una muestra aleatoria de respuestas y borradores reales, porque el tráfico real trae casos en los que nadie había pensado. Es una revisión humana sobre una muestra, no sobre cada respuesta.

El AI Risk Management Framework del NIST, una orientación voluntaria de enero de 2023, dice: «Los sistemas de IA deberían probarse antes de su despliegue y con regularidad mientras están en funcionamiento». El NIST indica que hay una versión revisada en preparación.

Da al personal y a los clientes una forma fácil de señalar una respuesta mala, y convierte cada fallo confirmado en un nuevo caso de prueba. Uno de los consejos de OpenAI dice: «Guarda logs mientras desarrollas para poder buscar en ellos buenos casos para las evals».

¿Quién da el visto bueno al lanzamiento y con qué evidencias?

El visto bueno lo da el responsable del proceso: por ejemplo, el director de soporte en el caso de un asistente de soporte. El equipo de cumplimiento normativo o el jurídico da el visto bueno a los casos de tolerancia cero. Quien construye el asistente presenta los resultados, pero no aprueba su propio trabajo.

El marco del NIST describe una separación parecida para las evaluaciones: «En las evaluaciones y actualizaciones periódicas participan expertos internos que no han sido desarrolladores de primera línea del sistema y/o evaluadores independientes». Después, la parte del marco llamada Manage (gestionar) empieza con una decisión sobre el sistema de IA: «si su desarrollo o su despliegue deben seguir adelante».

El dossier de evidencias para esa decisión debe mostrar:

• Cómo se construyó el conjunto, su tamaño por tipo de pregunta y quién escribió las respuestas
• Las versiones probadas: modelo, prompt, documentos y configuración de búsqueda
• Resultados por tipo de pregunta y por tipo de error, frente a umbrales de aprobación acordados de antemano
• Cada caso de tolerancia cero y su resultado
• Cada fallo, leído y explicado
• Los resultados de tu equipo con los mismos casos
• Qué no gestiona el asistente y quién revisa la muestra semanal después del lanzamiento

El visto bueno puede ser parcial. El asistente puede entrar en producción para los tipos de pregunta que pasaron, mientras el resto va a una persona hasta que también pasen.

¿De quién es el conjunto de prueba?

Tu empresa debe ser la dueña de los casos, las respuestas esperadas, las listas de comprobación, los scripts y el historial de resultados. Juntos son tu definición escrita de una buena respuesta. Te permiten exigir el mismo nivel a cualquier modelo o proveedor que venga después.

Guárdalos en un almacenamiento que controles, porque las herramientas de los proveedores también se retiran. La página de OpenAI sobre retiradas dice que el 3 de junio de 2026 notificó a los desarrolladores que usan su plataforma Evals que el producto se está retirando. Fija el 31 de octubre de 2026 como la fecha en que las evals existentes pasan a ser de solo lectura, y el 30 de noviembre de 2026 para el cierre programado del panel y de la API.

Nombra a un responsable del conjunto dentro de tu empresa, con tiempo para añadir casos y actualizar respuestas cuando cambien las políticas.

¿Qué deberíamos preguntar a un proveedor o a una empresa que vaya a construir el asistente?

Cuando un proveedor te dé una cifra de precisión, pregunta con qué se midió. El perfil del NIST sugiere: «Evaluar las afirmaciones sobre las capacidades de los modelos con métodos validados empíricamente». Después, haz estas preguntas a cada proveedor o empresa de tu lista:

• ¿Harán las pruebas con nuestros casos, con respuestas esperadas escritas por nuestra gente?
• ¿Qué parte del conjunto de prueba no verán antes de la ejecución final?
• ¿Qué umbrales de aprobación proponen para cada tipo de pregunta y cada tipo de error, y por qué?
• ¿Cómo puntúan el texto libre y cómo contrastaron su modelo evaluador con evaluadores humanos?
• ¿Podemos volver a ejecutar nosotros mismos todo el conjunto después de cada cambio, sin ustedes?
• ¿Quién paga la nueva prueba cuando el proveedor del modelo lo retire?
• ¿Recibiremos al final los casos, las listas de comprobación, los scripts y el historial de resultados?

¿Dónde encaja amBrain?

amBrain publica este blog. Sobre su propio producto, dice: «Nuestro propio producto, shyash.ai, funciona con agentes de IA que investigan, escriben, revisan y miden a partir de una memoria compartida de datos de la empresa. Una persona aprueba todo lo que sale».

Sobre el trabajo para clientes con un modelo de lenguaje, amBrain dice: «Hemos llevado a producción una integración de LLM dentro del perímetro FinTech de un cliente: extracción y normalización de avisos no estructurados de brókers y de centros de negociación —eventos corporativos, cambios de instrumentos y de márgenes— en registros estructurados que consume el sistema de trading».

Este artículo no es un caso de estudio y no describe ningún trabajo para clientes más allá de esa línea, que no dice cómo se probó el proyecto. Nada de lo que aparece aquí afirma que amBrain haya construido los conjuntos de prueba, los umbrales de aprobación o los pasos de visto bueno descritos arriba, ni dice cómo se prueba shyash.ai. Los ejemplos son generales, no están tomados de trabajos de amBrain.

Las organizaciones que se nombran aquí se citan a partir de sus páginas publicadas. El artículo no afirma que amBrain tenga relación alguna con ninguna de ellas y no da precios ni plazos de amBrain.

amBrain desarrolla software desde 2019. Sobre cómo trabaja con sus clientes, dice: «Tres formatos: entrega completa, un equipo dedicado o ingenieros integrados en tu equipo». Sobre la propiedad, su frase es: «El cliente conserva la propiedad completa del producto y del código, salvo nuestros componentes reutilizables». Pide la lista de esos componentes, nombre por nombre, antes de firmar.

Este artículo tampoco constituye asesoramiento jurídico. Pregunta a tus abogados cómo se aplica la normativa de privacidad a los conjuntos de prueba construidos con datos de clientes. Si amBrain está en tu lista corta, hazle las mismas preguntas que a cualquier otra empresa.