Tu proveedor te entrega un informe de pruebas de carga: veinte páginas con gráficas, siglas y tablas llenas de milisegundos. Concluye que "el sistema responde correctamente". Tú tienes que decidir si das el visto bueno antes de una campaña, de la temporada alta o del lanzamiento de un agente de IA, y no sabes qué número mirar.
Para leer ese informe basta con contestar cuatro preguntas: cuánta gente lo usaba a la vez, cuánto tardó en responder en el peor de los casos y no solo de media, cuántas peticiones fallaron y qué ocurrió cuando se forzó más allá del límite. Las grandes empresas lo hacen antes de cada campaña grande, porque saben que un sistema que se cae el día de más ventas cuesta más que cualquier prueba. Una pyme puede exigir lo mismo a su proveedor con las preguntas adecuadas.
¿Qué es una prueba de carga y para qué te sirve?
Una prueba de carga consiste en simular que muchas personas usan a la vez tu sistema (tu web, tu tienda, tu agente de atención) para comprobar si aguanta y cómo se comporta cuando se acerca a su límite. No predice el futuro: te dice qué pasó en un entorno y con un tipo de uso concretos. Te sirve para saber si tu sistema tiene margen para el día de más tráfico, cuál es el primer punto que se rompe cuando se le exige demasiado y si, al fallar, falla de forma ordenada o arrastra todo lo demás. El informe debería permitirte responder a esas tres cuestiones sin saber programar.
Cómo traducir las métricas a lo que importa a tu negocio
Casi todos los informes traen las mismas medidas. Esta tabla te ayuda a pasarlas a lenguaje de negocio y a saber qué preguntar:
| Lo que dice el informe | Qué significa en llano | La pregunta que debes hacer |
|---|---|---|
| Usuarios simultáneos | Cuántas personas estaban usando el sistema en el mismo momento | ¿Cuántos tengo yo en mi hora más cargada, y se probó por encima de eso? |
| Tiempo medio de respuesta | Lo que tarda de media en contestar | ¿Y en los casos más lentos? La media esconde a los clientes que esperaron de más |
| Tiempo máximo o percentil alto (p95, p99) | Lo que tardan las peticiones más lentas, el último tramo que queda tras apartar los casos extremos | ¿Qué experimenta el cliente que peor lo pasa? |
| Tasa de errores | Qué parte de las peticiones falló o no contestó | ¿Qué tipo de errores son y cuáles se han dejado fuera del recuento? |
| Peticiones por segundo | Cuánto trabajo es capaz de sacar el sistema | ¿Equivale a mis pedidos, mis consultas o mis mensajes reales? |
| Uso de recursos (procesador, memoria) | Cuánto se acerca la máquina a su tope | ¿Quedó holgura, o llegó al límite y se mantuvo así? |
| Duración de la prueba | Cuánto tiempo se mantuvo la carga | ¿Fue suficiente para ver si empeora con el paso de las horas? |
Lo importante es que cada cifra se compare contra algo tuyo: tu pico real del año pasado, la campaña que vas a lanzar, el número de clientes que esperas atender. Una cifra sola no dice nada.
¿Cuándo es "bueno" un resultado para tu negocio?
Es bueno cuando cubre tu pico real con margen y los tiempos son aceptables para el tipo de uso que tiene. No existe un número universal: un cliente chateando con un agente de atención tolera menos espera que un proceso nocturno que concilia facturas. Por eso conviene acordar con el proveedor, antes de la prueba y por escrito, qué se considerará aceptable y para qué volumen. Si los criterios se fijan después de ver los resultados, el informe siempre saldrá bien.
Pregunta también qué pasa si el día real supera lo previsto. Un buen informe incluye una prueba de estrés, que empuja el sistema más allá de lo esperado, y explica cómo se degrada: si se vuelve lento pero sigue funcionando, o si se cae y pierde pedidos.
Señales de que el informe maquilla los resultados
No hace falta suponer mala fe: a veces es simplemente una prueba hecha con prisa. Pero estas señales piden que levantes la mano:
- Solo hay promedios. Sin tiempos máximos ni percentiles, no sabes qué sufren los clientes más lentos.
- Nunca se llega al fallo. Si la prueba termina sin encontrar el límite, no sabes dónde está.
- El entorno no se parece al real. Una máquina más potente o una base de datos casi vacía dan resultados que no valdrán el día de verdad.
- Los datos de prueba son triviales. Pocas consultas repetidas una y otra vez no se parecen a clientes reales preguntando cosas distintas.
- Se han apartado errores "no relevantes" sin explicar cuáles ni por qué.
- No se compara con tu pico. Los resultados no se relacionan con tus números, sino con los de un caso genérico.
- Falta lo básico: fecha, versión probada, duración, herramienta usada y descripción del escenario. Una captura de pantalla de una gráfica no es un informe.
- Es demasiado breve. Una prueba de pocos minutos no detecta lo que se degrada con el tiempo.
Una sola de estas señales no invalida el informe; varias juntas sí te dan motivo para pedir que se repita.
¿Cada cuánto hay que repetir una prueba de carga?
No hay un calendario fijo: hay que repetirla cada vez que cambie algo que afecte a la carga. Los motivos habituales son una versión nueva del sistema, una integración nueva con otra herramienta, un crecimiento notable de clientes o la proximidad de una campaña o temporada alta. Una prueba hecha hace dos años sobre una versión anterior vale muy poco hoy. Conviene dejarlo acordado en el contrato de servicio, junto con quién la hace y quién paga la repetición. En acuerdo de servicio con un proveedor de IA: qué exigir por escrito tienes más puntos que conviene fijar de antemano.
Qué hace el agente y qué sigue haciendo una persona
Un agente de IA puede ayudarte a leer el informe: pasar sus tablas a una hoja comparable con tus números, señalar qué datos faltan frente a la lista de arriba y redactarte un borrador de preguntas para el proveedor. También puede lanzar comprobaciones periódicas sencillas y avisarte si los tiempos empeoran.
Lo que no hace es decidir si el resultado es suficiente para tu negocio ni diseñar una prueba exhaustiva sin un técnico que la valide. Esa decisión es tuya, con el apoyo de quien entienda tu sistema, y requiere conocer tu pico real, tu tolerancia al riesgo y lo que perderías si algo falla. Si necesitas ayuda para interlocutar con tu proveedor sin ser técnico, cómo hablar con un proveedor de IA sin saber de tecnología te da el vocabulario mínimo.
Conclusión
Un informe de pruebas de carga se lee con cuatro preguntas: cuánta gente a la vez, cuánto tarda en el peor caso, cuántos fallos y qué pasa al pasarse del límite. Si las cifras no se comparan con tu pico real, si solo hay medias o si falta el escenario de prueba, el informe no te sirve para decidir. Y antes de una campaña, un lanzamiento o un cambio importante, vale la pena repetirlo.
En MG Solutions construimos agentes de IA específicos para cada empresa, adaptados a tu forma de trabajar y a tus herramientas, y los probamos con tus volúmenes reales antes de ponerlos delante de tus clientes, no con un caso genérico.
Si quieres ver cómo encajaría en tu empresa, escríbenos y lo hablamos.