El piloto terminó y alguien presenta una pantalla llena de conversaciones resueltas. El gerente pregunta si ahora los clientes reciben una respuesta útil y nadie puede mostrar qué pasó con los pedidos pendientes. Hay mensajes, pero falta evidencia para decidir. En una pyme colombiana de diez a cien empleados, esa diferencia importa: operaciones no necesita otra demostración bonita, sino saber si el seguimiento deja de depender de perseguir personas.
Un agente de IA puede ayudar a reunir contexto, preparar respuestas y señalar excepciones. Eso no demuestra, por sí solo, que el proceso haya mejorado. La decisión de ampliar un piloto debe apoyarse en casos revisables, límites respetados y trabajo que el equipo realmente pueda sostener. Esta guía cierra nuestro arco de seguimiento comercial con una pregunta práctica: ¿qué tendría que pasar para aceptar el piloto, corregirlo o detenerlo?
1. Acuerda qué significa resolver antes de comenzar
Escoge un flujo acotado, por ejemplo, consultar el estado de un pedido y preparar la respuesta para revisión. No mezcles en el mismo ensayo cotizaciones, reclamos, devoluciones y autorizaciones de entrega. Cada flujo tiene riesgos y condiciones distintas. Escribe qué entra, qué queda fuera y cuál es el resultado que necesita el cliente. La aceptación no puede cambiar según la conveniencia de la presentación final.
Una solicitud no queda resuelta porque el agente redactó un mensaje. Puede requerir confirmación del área responsable, una fecha respaldada o una explicación clara de lo que falta. Define también cuándo se considera pendiente. Si falta un dato, el sistema debe conservar ese estado y asignar la siguiente acción, no convertir la incertidumbre en una respuesta aparentemente segura.
La propuesta editorial de esta guía reúne cinco criterios: alcance, evidencia, excepciones, límites y continuidad. Cinco es una selección para organizar la evaluación, no una estadística ni una metodología certificada. El objetivo es que gerente, operaciones y responsable del piloto usen el mismo lenguaje al revisar un caso.
2. Prepara casos que puedan contradecir la demostración
Una demostración suele recorrer el camino fácil: pedido identificado, información completa y responsable disponible. El trabajo real incluye datos contradictorios y cambios de turno. Construye una lista de pruebas con solicitudes representativas, anonimizadas cuando corresponda. Incluye una consulta sencilla, una referencia incompleta, una fecha desactualizada, un caso repetido y una petición que exija una decisión humana.
No busques un número universal de pruebas. El tamaño y la composición de la muestra dependen del volumen, la variedad y el riesgo de tu operación. Registra cuántas solicitudes revisaste, de qué fechas y cómo las seleccionaste. Si solo probaste el canal menos complejo o el horario más tranquilo, no presentes el resultado como prueba de toda la empresa.
Para cada caso, guarda la entrada, la fuente consultada, la propuesta del agente, la decisión humana y el resultado observable. Una captura aislada del mensaje final no explica si la información era vigente. Usa identificadores internos y acceso limitado; evita duplicar datos personales en documentos de prueba que terminarán compartidos sin control.
Incluye una prueba especialmente incómoda: el sistema conectado deja de responder. La respuesta aceptable no es inventar el estado del pedido. Debe indicar la limitación, conservar el caso pendiente y permitir que una persona continúe. Este ensayo comprueba una condición operativa concreta, no garantiza disponibilidad futura.
3. Compara el trabajo completo, no solo la velocidad del chat
Antes de activar el piloto, documenta cómo se atienden solicitudes equivalentes. Registra la espera hasta una respuesta útil, el tiempo humano dedicado a reconstruir información y las reaperturas por el mismo motivo. Mantén la misma definición durante la comparación. Si cambian los horarios, el equipo o la mezcla de casos, explica esa diferencia en vez de atribuir todo movimiento al agente.
La comparación debe incluir revisión y corrección. Una respuesta redactada más rápido puede demandar más trabajo después si alguien necesita verificar cada dato desde cero. Tampoco mezcles el tiempo transcurrido del cliente con los minutos de trabajo de una persona: describen problemas diferentes y sumar ambos produce una cifra difícil de interpretar.
En el artículo sobre espera, retrabajo y reaperturas desarrollamos esas definiciones. Aquí el paso adicional es acordar cómo influyen en la decisión. Define antes del ensayo qué mejora sería útil para tu equipo y qué deterioro resultaría inaceptable. No hay un porcentaje de ahorro aplicable a todas las pymes.
Si la muestra es pequeña o los casos no son comparables, el resultado puede ser “todavía no sabemos”. Esa conclusión es más útil que declarar éxito con una cifra frágil. Conserva observaciones cualitativas: qué información faltó, quién tuvo que intervenir y qué parte del proceso sigue generando espera.
4. Trata permisos y excepciones como condiciones de aceptación
Que el agente encuentre una fecha no significa que pueda comprometer una entrega. Separa consulta, preparación y ejecución. Define qué decisiones requieren confirmación y comprueba que la restricción existe en los permisos del sistema, no solo en las instrucciones escritas al modelo. La integración disponible dependerá de las herramientas, accesos y acuerdos de cada empresa.
La referencia OWASP sobre autonomía excesiva describe riesgos asociados a funcionalidad, permisos y autonomía excesivos. Sirve como orientación para revisar límites; no certifica este piloto ni demuestra que una instalación particular sea segura. Un control documentado también necesita una prueba que muestre cómo responde ante una solicitud fuera de alcance.
Ensaya una instrucción que pida saltarse la aprobación. La evidencia esperada es que la acción no ocurra y que quede registrada la excepción. Si el agente ejecuta un compromiso no autorizado, no compenses ese fallo con una buena velocidad promedio. Suspende esa capacidad, investiga y repite la prueba después de corregirla.
También revisa el relevo humano. El responsable debe recibir contexto suficiente para actuar sin pedirle al cliente que repita todo. La guía de permisos antes de prometer entregas amplía este límite. Detener una acción fuera de alcance puede ser precisamente el comportamiento correcto del piloto.
5. Decide continuar, corregir o detener con una checklist
La reunión de cierre debe terminar con una decisión y su evidencia, no con una lista indefinida de posibilidades. Designa quién tiene autoridad para aceptar el proceso y quién atenderá incidentes después. Si nadie dispone de tiempo para revisar excepciones, ampliar el alcance puede trasladar el problema en vez de resolverlo.
- Alcance: están documentados el flujo evaluado, las exclusiones y la definición de solicitud resuelta.
- Evidencia: cada resultado revisado conserva fuente, fecha, decisión y una comparación entendible con el proceso previo.
- Excepciones: los datos incompletos, la caída de una conexión y el relevo humano tienen una respuesta comprobada.
- Límites: las acciones sensibles requieren la autorización acordada y las pruebas no muestran compromisos indebidos.
- Continuidad: hay responsable operativo, registro de incidentes y una manera ensayada de volver al proceso manual.
Continuar significa ampliar de forma acotada lo que pasó las pruebas, no habilitar todas las acciones. Corregir significa identificar el fallo, asignar responsable y repetir los casos afectados. Detener significa que el riesgo o la carga operativa no justifican seguir en las condiciones actuales. Ninguna de esas decisiones necesita una promesa de rentabilidad que todavía no se ha medido.
En Query proponemos discutir primero ese criterio de aceptación y luego evaluar el mecanismo técnico. La pregunta útil para el dueño no es si la IA respondió de manera convincente, sino si el equipo puede demostrar que el cliente quedó mejor atendido sin perder control del proceso.
Preguntas frecuentes
¿Cuánto debe durar un piloto de seguimiento?
No existe una duración universal. Debe permitir observar suficientes casos representativos y sus reaperturas. Define fechas y cobertura antes de empezar; si faltan situaciones relevantes, declara la limitación y no generalices.
¿Se puede evaluar sin conectar todos los sistemas?
Es posible delimitar una prueba con fuentes autorizadas o exportaciones, según el proceso. Debes registrar su vigencia y sus limitaciones. No equivale a demostrar una integración automática ni disponibilidad en tiempo real.
¿Qué pasa si mejora el tiempo pero falla una aprobación?
El promedio de velocidad no elimina un fallo de permisos. Detén la capacidad afectada, revisa la causa y repite las pruebas antes de ampliar. Mantén una alternativa humana para atender las solicitudes.
Julián Vargas · Query. Guía editorial para responsables de operaciones y dueños de pymes colombianas. Elaborada con apoyo de inteligencia artificial. La portada es un escenario ilustrativo; no representa un cliente ni resultados medidos. Fuente de riesgos consultada el 4 de octubre de 2026. Los criterios son una propuesta editorial y no una certificación de seguridad.
Conversemos sobre el flujo que quieres evaluar y la evidencia que necesitarías para aceptarlo.