Crea un conjunto de pruebas útil para un chatbot

Describe primero el comportamiento esperado

Crea una tabla pequeña con la pregunta del visitante, la fuente aprobada y el comportamiento esperado. A veces será una respuesta directa; otras, una pregunta aclaratoria o una derivación. Escribe la expectativa antes de probar. De lo contrario, una respuesta fluida puede convencerte de aceptar un comportamiento que no buscabas. Incluye los datos que deben aparecer y las promesas sin respaldo que no deben hacerse.

Utiliza preguntas realistas dentro del alcance elegido. Incluye una petición directa, otra formulación y un mensaje al que le falte contexto. Una pregunta de entrega puede omitir el destino o referirse a un pedido no identificado. La respuesta esperada debe reflejar lo que el bot puede saber realmente. No marques como útil un estado de pedido inventado solo porque se parezca a lo que el visitante esperaba recibir.

Incluye casos que no deben producir una respuesta

Prueba preguntas fuera del alcance publicado y peticiones de acciones que el bot no pueda realizar. Pregunta por un detalle de producto desconocido, una excepción que necesita aprobación o un cambio de cuenta concreto. Comprueba si la respuesta expresa el límite y ofrece una vía real para continuar. La prueba no consiste en que el bot siga hablando siempre, sino en que describa con exactitud su información y sus capacidades.

Incluye peticiones que intenten ignorar la información aprobada o revelar material que no debería ser público. Usa datos ficticios inocuos y un entorno controlado. Registra lo observado y el límite previsto sin suponer que unos pocos ejemplos demuestran seguridad completa. Si intervienen cuentas o registros reales, la implementación necesita comprobaciones propias de acceso y tratamiento de datos, además del conjunto de pruebas editorial.

Registra fallos y vuelve a probar el cambio

Conserva para cada caso la respuesta real, la fecha y una nota breve sobre cualquier carencia. Clasifica el problema de forma útil: dato erróneo, condición omitida, acción sin respaldo, derivación confusa o diferencia entre idiomas. Evita una puntuación única sin explicación. Los tipos concretos de incidencia indican si hay que corregir la fuente, ajustar la conversación o investigar la implementación.

Tras corregir, repite el caso fallido y algunos relacionados. Comprueba ambos idiomas si cambia información o comportamiento compartidos. Distingue una demostración local del servicio que utilizarán los visitantes. Superar una prueba en un entorno no demuestra que la entrega de contactos, la separación de cuentas o el widget publicado funcionen en otro. Termina con una lista explícita de comportamientos aceptados y carencias pendientes para decidir sobre el lanzamiento con evidencias concretas.

Conserva un pequeño conjunto de casos que hayan fallado antes. Repítelos tras cambiar una fuente o una regla de conversación y guarda los resultados. Así será más fácil detectar si corregir una respuesta altera otra inesperadamente y mantener la revisión ligada a comportamientos concretos observados.

Fuentes

• NIST AI RMF: pruebas, límites y evaluación de IA (en inglés)

Patrocinado