Cuando una cadena pequeña compara sucursales, suele acumular reportes, hojas de cálculo y capturas. El resultado parece completo, pero deja una pregunta incómoda: ¿alguien puede rastrear cada dato hasta su origen y explicar por qué una excepción llegó a la mesa de revisión?
Un tablero puede ordenar información. La confianza exige algo más: reglas visibles, fuentes identificables, límites claros, pruebas con casos conocidos y una persona responsable de decidir qué hacer.
Respuesta corta
Para evaluar inteligencia artificial en una operación multisucursal, no empiece por un tablero que “lo vea todo”. Empiece por un reporte estrecho de excepciones. Defina qué dato entra, qué regla activa una alerta, de qué archivo proviene cada cifra, qué errores debe rechazar el sistema y quién revisa el resultado. NIST plantea que la confiabilidad depende del contexto de uso y que los sistemas desplegados requieren pruebas o monitoreo continuos.[6] La IA puede preparar y ordenar hallazgos; la dirección de operaciones conserva la interpretación, la prioridad y cualquier cambio en tienda.
El mito: más información produce mejores decisiones
En una operación con varias sucursales, un tablero amplio puede mezclar ventas, inventario, devoluciones, horarios y márgenes en una sola vista. Eso no garantiza que los datos sean comparables, actuales ni completos. Tampoco aclara si una diferencia es un error de captura, una regla distinta, una promoción local o un problema real.
La comparación útil no es “tablero contra hoja de cálculo”. Es esta:
| Enfoque | Pregunta principal | Riesgo | Control necesario |
|---|---|---|---|
| Tablero general | ¿Qué está pasando? | Convertir datos incompletos en una historia convincente | Definiciones y fuentes visibles |
| Reporte de excepciones | ¿Qué registro rompió una regla acordada? | Alertas falsas o reglas mal definidas | Casos de prueba y revisión humana |
| Decisión operativa | ¿Qué debe cambiar? | Confundir una señal con una instrucción | Responsable con autoridad y contexto |
Ninguno de los tres niveles sustituye al siguiente. Un reporte de excepciones prepara la revisión. No decide un cambio de precio, inventario, personal, proveedor o política comercial.
Qué debería contener una prueba pequeña
Una prueba responsable puede trabajar con registros ficticios creados desde cero. Nada de datos reales disfrazados, anonimizados a medias o copiados de una tienda. El objetivo inicial es probar el mecanismo, no demostrar un resultado comercial.
1. Una sola pregunta
Por ejemplo: “¿Qué sucursales entregaron un cierre con campos faltantes o totales fuera de la tolerancia definida?”
Esa pregunta evita que el sistema improvise explicaciones sobre ventas, fraude, desempeño del personal o demanda. Solo compara campos cerrados contra reglas que la empresa ya documentó.
2. Un diccionario mínimo
Cada campo necesita nombre, definición, formato, fuente, periodo y responsable. Si “venta neta” significa algo distinto en dos sucursales, la comparación se detiene. La IA no debe inventar una equivalencia para salvar el reporte.
3. Un rastro por cifra
El reporte debe mostrar el archivo ficticio, la fila, el campo y la regla que originaron cada alerta. KIGWI describe públicamente un agente Data Analyst que prepara reportes y busca que cada cifra pueda rastrearse hasta sus datos de origen.[1] Esa descripción pública sirve para ubicar el tipo de agente, pero no demuestra una integración activa, disponibilidad específica en México ni resultados para comercios multisucursal.
4. Casos que deben fallar
Incluya duplicados, campos vacíos, formatos incompatibles, cortes incompletos y valores que parecen válidos pero provienen del periodo equivocado. NIST identifica la confabulación como contenido falso o erróneo expresado con seguridad y recomienda comparar salidas con datos de referencia conocidos, además de usar supervisión humana y otros métodos de evaluación.[4]
Una prueba que solo contiene ejemplos limpios es una demostración, no una evaluación.
5. Una persona que pueda detener el flujo
La revisión humana necesita autoridad real. Esa persona debe poder rechazar el reporte, corregir la regla, pedir el archivo fuente o suspender la prueba. KIGWI también presenta públicamente la idea de definir límites y decidir qué requiere autorización humana.[2] En esta propuesta, la dirección de operaciones conserva todas las decisiones y el agente solo prepara excepciones.
Qué no debería hacer el agente
Durante la prueba, el agente no debería:
- conectarse a sistemas vivos;
- leer nombres, teléfonos, correos, ubicaciones precisas de personas ni datos de pago;
- calificar sucursales, gerentes o empleados;
- inferir fraude, negligencia, intención o desempeño;
- recomendar precios, descuentos, compras, despidos o sanciones;
- enviar mensajes, modificar inventarios o publicar reportes;
- convertir una alerta en una orden de trabajo.
Si una alerta puede afectar a una persona, una relación laboral, una transacción o una decisión comercial, vuelve al responsable humano antes de cualquier acción.
Cómo medir si la prueba sirve
La primera evaluación no necesita una promesa de ahorro. Necesita medidas incómodamente concretas:
- ¿Cuántas excepciones conocidas detectó?
- ¿Cuántas alertas fueron falsas?
- ¿Cuántos casos ambiguos devolvió correctamente para revisión?
- ¿Cuánto tardó una persona en verificar cada salida?
- ¿Se pudo rastrear cada cifra al registro ficticio que la originó?
- ¿El sistema se detuvo cuando faltó una definición o una autorización?
NIST señala que la validez y la confiabilidad de sistemas desplegados suelen evaluarse mediante pruebas o monitoreo que confirmen si funcionan como se esperaba.[6] Aquí, eso significa conservar los casos, las reglas, las salidas, los errores y la decisión humana de continuar, ajustar o retirar el flujo.
Tablero y reporte de excepciones pueden convivir
No hace falta declarar ganador. El tablero ayuda a explorar. El reporte de excepciones reduce el universo que una persona debe revisar. La decisión sigue en manos del equipo que conoce la operación.
El orden importa:
- la empresa define la regla;
- el agente compara registros permitidos;
- el agente muestra la fuente y la excepción;
- una persona verifica el contexto;
- el responsable decide si actúa;
- el resultado alimenta la siguiente prueba.
Si el sistema no puede mostrar de dónde salió una cifra, el dato no avanza. Si no sabe aplicar una regla, devuelve el caso. Si intenta decidir por la empresa, la prueba se detiene.
La pregunta que conviene hacer antes de comprar otro tablero
No pregunte primero cuántos gráficos tendrá. Pregunte qué decisión seguirá siendo humana, qué evidencia acompañará cada alerta y qué hará el sistema cuando no sepa.
Un buen piloto no impresiona por su tamaño. Permite detectar errores, explicar límites y retirar el flujo sin romper la operación. Para una cadena pequeña, esa disciplina vale más que una pantalla llena de certezas bonitas.
CTA propuesto: revise un cierre reciente y marque una sola excepción que su equipo ya sepa verificar. Ese caso puede convertirse en el primer escenario ficticio de una prueba, sujeto a evaluación técnica, de datos y de alcance antes de usar información real.
Sources
[1] KIGWI Solutions
[2] KIGWI México
[4] NIST AI 600-1 Generative AI Profile
[6] NIST AI Risks and Trustworthiness
