La decisión en una frase
Prueba cada opción con la misma muestra, los mismos datos y el mismo resultado esperado. Puntúa el trabajo que queda después de la respuesta, no lo convincente que parece la demostración.
Las páginas comerciales enseñan el caso ideal: un texto corto, una imagen atractiva o una respuesta que llega en segundos. El costo real aparece después, cuando el equipo corrige cifras, elimina frases inventadas, adapta el resultado a su proceso y descubre que una función importante solo existe en otro plan.
Esta guía propone una prueba pequeña y repetible. No pretende medir todos los modelos, certificar una herramienta ni producir un ranking universal. Sirve para responder una pregunta delimitada: “¿esta configuración resuelve esta muestra de tareas con un nivel de control, corrección y costo que nosotros definimos como aceptable?”.
Parámetros que debes adaptar
Cinco tareas mantienen corta la primera revisión, pero puedes usar menos si la decisión es estrecha o más si existen flujos distintos. Sesenta minutos es una caja de tiempo editorial, no la duración correcta para toda compra. Los pesos expresan una prioridad inicial de TopiApps y deben cambiar cuando, por ejemplo, privacidad o costo sean decisivos. Las bandas 60 y 80 ayudan a ordenar una conversación; no son probabilidades, estándares del sector ni garantía de desempeño.
Define cualquier cambio antes de abrir las herramientas y aplícalo por igual a todas las opciones. Conserva junto al resultado la muestra, los pesos y la regla de decisión elegidos.
Antes del reloj: define una muestra manejable
Una prueba útil comienza fuera de la herramienta. Como punto de partida, reúne cinco tareas que el equipo ya realiza cada semana. No hay nada obligatorio en ese número: la muestra debe cubrir el trabajo que justifica la compra sin mezclar procesos que requieren criterios distintos. Las tareas deben representar trabajo, no trucos diseñados para favorecer a un proveedor. Un comercio podría usar: clasificar diez consultas de clientes, redactar una respuesta con una política de devoluciones, resumir un informe, convertir una tabla en hallazgos y preparar un borrador de publicación.
Para cada tarea escribe el resultado esperado. No tiene que ser una respuesta literal, pero sí condiciones observables. Por ejemplo: “debe identificar las tres excepciones de la política, no prometer devolución automática, mantener el tono de la marca y señalar que una persona revisará el caso”. Sin este patrón, es fácil premiar la salida más larga o más segura de sí misma.
Construye un paquete de prueba seguro
- Reemplaza nombres, correos, identificaciones y cifras sensibles por datos ficticios.
- Incluye al menos un caso normal, uno ambiguo y uno que la herramienta deba rechazar o escalar.
- Conserva exactamente los mismos archivos e instrucciones para todas las opciones.
- Anota idioma, navegador, plan, funciones activas y fecha; estos detalles pueden cambiar el resultado.
- No conectes correo, almacenamiento ni sistemas de producción durante una prueba inicial.
Si no puedes crear datos ficticios sin perder la naturaleza de la tarea, detente. Esa dificultad indica que la evaluación necesita autorización, controles o un entorno especializado antes de usar un servicio externo.
Ejemplo de agenda de 60 minutos
La siguiente distribución es una caja de tiempo para una primera criba. Amplíala si debes revisar contratos, permisos, accesibilidad, integraciones o requisitos regulados. Redúcela si solo estás comprobando una función estrecha. Registrar el tiempo real es más importante que terminar exactamente en el minuto 60.
Limitar el número de intentos importa. Una herramienta puede terminar dando una buena respuesta después de doce aclaraciones, pero esa fricción volverá cada semana. Registra el primer resultado y, como máximo, una corrección. El tiempo de conversación es parte del costo.
Rúbrica inicial: siete criterios, de 0 a 4
| Criterio | Qué observar | Peso |
|---|---|---|
| Precisión | Hechos, cálculos, citas y restricciones esenciales correctos. | 25 % |
| Ajuste a la tarea | Cumple el objetivo y el formato sin omitir condiciones decisivas. | 20 % |
| Trabajo de revisión | Tiempo y conocimiento necesarios para dejar la salida lista. | 15 % |
| Privacidad y control | Documentación comprensible, opciones de retención, administración y eliminación. | 15 % |
| Facilidad de uso | Consistencia, accesibilidad y curva de aprendizaje para el equipo real. | 10 % |
| Integración | Entrada, exportación y encaje con el proceso sin permisos excesivos. | 10 % |
| Costo total | Plan, consumo, límites y revisión humana frente al valor obtenido. | 5 % |
Estos pesos suman 100 %, pero no proceden de un estudio comparativo. Reflejan una prioridad editorial inicial: precisión y ajuste reciben más peso que costo. Antes de probar, copia la tabla y cambia los porcentajes si tu decisión exige otra prioridad. Documenta la razón y usa exactamente la misma versión con cada opción.
Usa una escala definida de antemano: 0 significa que no resuelve o crea un riesgo inaceptable; 1, deficiente; 2, utilizable con correcciones importantes; 3, adecuado; 4, sólido para el alcance probado. Un puntaje no compensa un fallo eliminatorio: una filtración de datos no se equilibra con una interfaz bonita.
Calculadora de evaluación
Los valores se calculan en tu navegador y no se envían a TopiApps. La calculadora aplica únicamente los pesos iniciales mostrados arriba; no los presenta como validados. Si decides usar otros, registra el cálculo en tu propia hoja y no compares su total con esta escala como si fueran equivalentes.
Fallos que detienen la compra
Define los límites antes de probar para no justificarlos después. TopiApps recomienda detener o escalar la evaluación si ocurre cualquiera de estos casos:
- La herramienta expone, retiene o reutiliza información de una forma incompatible con el caso.
- Ejecuta una acción externa sin confirmación clara o solicita permisos que la tarea no necesita.
- Inventa de forma repetida datos esenciales y no permite rastrear el origen.
- No existe una forma viable de exportar el trabajo o eliminar la cuenta y los datos.
- El proveedor no documenta aspectos que tu organización necesita para aprobarlo.
- El equipo no puede detectar razonablemente cuándo la salida está equivocada.
Un “no” también es un resultado útil. Puede significar que la tarea no es adecuada para IA, que hace falta un plan empresarial, que el proceso debe rediseñarse o que otra categoría de software resuelve mejor el problema.
Ejemplo ficticio: elegir apoyo para responder consultas
Este escenario sirve para explicar cómo documentar una decisión; TopiApps no ejecutó la prueba ni observó esos resultados en productos reales. Imagina un negocio que recibe preguntas sobre cambios y garantías. Prueba dos asistentes con diez mensajes ficticios y la política pública del comercio. La opción A redacta rápido, pero promete devoluciones en dos casos excluidos. La opción B tarda más, cita el apartado correcto y escala los casos ambiguos.
La opción A obtiene 4 en facilidad, pero 1 en precisión y 1 en revisión: una persona debe comprobar cada respuesta completa. La B obtiene 3 en facilidad, 4 en precisión y 3 en revisión. Aunque ambas cuesten lo mismo, la B reduce trabajo posterior y riesgo de promesas incorrectas.
La decisión no debería decir “B es la mejor IA”. Debe registrar: “B pasa a un piloto de dos semanas para borradores internos de consultas frecuentes; no enviará mensajes automáticamente; una persona aprobará cada respuesta; se revisarán veinte casos y la tasa de correcciones antes de ampliar el uso”. Ese alcance permite volver a evaluar sin convertir una prueba pequeña en aprobación ilimitada.
Evita cinco sesgos frecuentes
- Marca: no subas la nota porque ya pagas otros productos del proveedor.
- Demostración: no uses solo el ejemplo que el vendedor preparó.
- Novedad: una función reciente no vale más si añade revisión o permisos.
- Longitud: una respuesta extensa puede ocultar más errores.
- Costo hundido: haber dedicado horas a configurarla no obliga a aprobarla.
Cómo interpretar el resultado sin convertirlo en garantía
Como regla editorial inicial, 80 o más abre la conversación sobre un piloto; de 60 a 79 invita a corregir el flujo, reducir el alcance o comparar otra opción; y menos de 60 orienta a detener esta configuración. Esas bandas no fueron calibradas contra compras exitosas y no representan porcentajes de calidad o aprobación.
Puedes reemplazarlas por criterios propios —por ejemplo, un máximo de minutos de revisión y cero errores críticos— antes de empezar. Cualquier fallo eliminatorio prevalece sobre el total. Una puntuación alta tampoco justifica una compra anual automática: solo resume la evidencia recogida en esa muestra y fecha.
En el piloto mide volumen, minutos de revisión, errores escapados, tareas rechazadas, incidentes y ahorro útil. Después combina esos datos con la guía de costo real de IA en un equipo. Si el uso implica datos o acciones, define también una política interna de uso.
Fuentes y criterio de construcción
- NIST AI Resource CenterRecursos para pruebas, evaluación, verificación y validación de sistemas de IA.
- NIST AI RMF CoreResultados y prácticas sobre documentación, medición y evaluación en condiciones cercanas al uso.
- NIST AI 600-1Perfil de riesgos de IA generativa que complementa el AI RMF.
- OWASP — Prompt InjectionReferencia para considerar entradas no confiables, privilegios mínimos, pruebas y aprobación humana.
Fuentes consultadas el 24 de julio de 2026; alcance editorial revisado el 12 de agosto de 2026. La muestra de cinco tareas, la duración, la ponderación y las bandas de decisión son puntos de partida creados por TopiApps: no son una norma de estas organizaciones ni un benchmark validado.