Un operador 3PL en Fontana, California, gastó la primavera pasada aproximadamente $45,000 en un asistente de IA que supuestamente respondería «todas las preguntas de SOP en planta». La demo fue impecable. El informe del piloto del proveedor presumía un 94% de satisfacción. Treinta días después del lanzamiento, el responsable de seguridad revisó los registros y descubrió que casi una de cada cuatro respuestas contenía algo erróneo: una altura de apilado incorrecta, un umbral de temperatura incorrecto, una regla de empaque de un cliente incorrecta. El asistente entregaba cada una con total confianza y una cita con formato impecable.
Esta es la parte que los proveedores no ponen en el deck: un asistente de almacén con recuperación aumentada no falla porque el modelo de lenguaje sea tonto. Falla porque la ingeniería que lo rodea nunca se terminó. Ya he visto cuatro de estos despliegues torcerse en el último año, y el patrón de fallo es tan consistente que prácticamente puedo recitarlo.
De dónde salen realmente las respuestas erróneas
El primer punto de fallo es el retrieval, y es el responsable de la mayor parte del daño que he visto. Los documentos de almacén — SOPs, manuales de equipos, SLAs de clientes — normalmente se trocean en fragmentos de tamaño fijo, 500 tokens cada uno, y se indexan en un almacén vectorial. Un operario pregunta si las carretillas pueden cargar dentro de la zona de cadena de frío. El sistema recupera una política de sala de baterías de hace tres años, escrita para un cobertizo de carga exterior, y arma una respuesta que suena autorizada y es completamente inaplicable. El fragmento perdió su contexto; el embedding solo entendió la similitud superficial.
El segundo punto de fallo es el versionado de documentos, y es más traicionero. Los documentos de almacén cambian más rápido de lo que TI espera. Un SOP pasa de v2 a v3 porque lo dijo un gerente de cliente y alguien pegó un formulario nuevo en la pared. El PDF antiguo sigue en la base de conocimiento sin marca de «reemplazado» ni filtro por fecha de vigencia. El modelo no puede saber qué versión está vigente: simplemente ensambla los fragmentos con mayor puntuación. En Fontana, el asistente una vez citó «SOP v3.2, Sección 4» para un límite de apilado. El almacén nunca había producido un v3.2. El modelo había fusionado una sección de v2 con una de v3 e inventado el número de versión. Las alucinaciones suelen construirse a partir de fragmentos recuperados medio verdaderos, no de la nada.
El tercer punto de fallo es el límite del conocimiento. Los trabajadores hacen preguntas fuera de la base de conocimiento: cambios del salario mínimo local, tarifas de la agencia de trabajo temporal de al lado, políticas de RR. HH. Un asistente bien diseñado debería decir «eso no lo tengo; pregunta a tu supervisor». Pero un modelo con la configuración por defecto odia decir que no sabe. Fabrica, y los números fabricados vienen con decimales, lo que los hace parecer creíbles.
El conjunto golden: 50 a 100 preguntas antes de hablar de modelos
Mi consejo para los operadores ahora es directo: no empiecen por la selección del modelo. Empiecen por un conjunto de evaluación.
La receta es sencilla. Pidan a los jefes de turno y al responsable de seguridad que cada uno liste 20 preguntas de esas en las que «equivocarse haría daño a alguien»: límites de apilado, holguras de pasillos, distancias de segregación de mercancías peligrosas, umbrales de alarma de cadena de frío, reglas de empaque específicas de cada cliente. Luego extraigan tres meses de preguntas reales que los empleados hicieron y tomen las 30 a 50 más frecuentes. Eso da entre 50 y 100 ítems, cada uno con una «respuesta golden» firmada por un operador senior y por quien sea dueño del cumplimiento — hasta el número de cláusula y la versión vigente.
El conjunto hace tres trabajos. Primero, ejecutarlo antes del lanzamiento; si la precisión de coincidencia exacta contra las respuestas golden está por debajo del 85%, no lancen. Segundo, volver a ejecutarlo después de cada cambio de modelo, cambio de retrieval o actualización de documentos, para que arreglar una cosa no rompa otra. Tercero — y este es el que importa — escribirlo en el contrato con el proveedor: precisión de aceptación, tasa de rechazo y cobertura de citas, vinculados a los términos de pago.
El contrato más serio que he visto especificaba un piloto de 30 días con al menos 50 preguntas al día, y la aceptación exigía ≥90% de precisión en el conjunto golden con una tasa de rechazo entre el 5% y el 15%. Fíjense en el piso de los rechazos. Un asistente que nunca dice «no sé» es mucho más peligroso que uno que declina de vez en cuando. Un rechazo es una señal de salud, no un fallo.
Arreglen el retrieval antes de culpar al modelo
Cuando las respuestas salen mal, la mayoría de los equipos busca un modelo más grande. En mi experiencia, ocho de cada diez veces el problema es el retrieval, y el modelo carga con la culpa.
Cambien primero la estrategia de fragmentación. Dejen de cortar por conteos fijos de tokens. Fragmenten según la estructura natural del documento: los SOPs por sección y cláusula, los manuales de equipos por procedimiento completo de solución de problemas. Una cláusula cortada por la mitad no la salva un mejor embedding. En la práctica, la fragmentación semántica es la ganancia de precisión más barata disponible: casi no cuesta nada.
Luego agreguen filtrado por metadatos. Etiqueten cada documento al ingresarlo: versión, fecha de vigencia, sitio aplicable, zona aplicable. Filtren a la última versión vigente antes del emparejamiento semántico. No borren las versiones antiguas — las auditorías pueden necesitarlas — pero márquenlas como reemplazadas y exclúyanlas del retrieval por defecto. El sitio de Fontana hizo exactamente este cambio y los números de versión fantasma prácticamente desaparecieron.
Un movimiento más, infravalorado: den a las preguntas de alta frecuencia y alto riesgo un carril rápido determinista. Alturas de apilado, anchos de pasillo, umbrales de alarma: hay tal vez dos o tres docenas de estas. Pónganlas en pares de Q&A de coincidencia exacta que evitan por completo el retrieval vectorial. Eso no es hacer trampa. Es sacar las preguntas más peligrosas de un sistema probabilístico y pasarlas a uno determinista.
Tres reglas que obligan al asistente a admitir incertidumbre
Incluso con el retrieval arreglado, los modelos a veces confabulan. Las alucinaciones no se gobiernan con esperanza. Se gobiernan con tres reglas duras.
Primero, citas obligatorias. Cada respuesta debe nombrar su documento fuente y su cláusula, y el enlace tiene que llevar al texto real. En la evaluación, una respuesta sin cita verificable se califica como errónea, punto. Esta sola regla obliga a los proveedores a hacer bien el retrieval, porque no queda nada que fabricar.
Segundo, rechazar por debajo de un umbral de confianza. Si los documentos recuperados puntúan por debajo de un corte de relevancia, o si múltiples fuentes se contradicen, el asistente responde «sin respuesta clara en la base de conocimiento; escalado a tu jefe de turno» y deriva la pregunta a un humano. Fijen el umbral con criterio conservador. En una planta de almacén, el costo de una respuesta errónea siempre es mayor que el costo de no tener respuesta.
Tercero, revisiones humanas puntuales con calendario. Primer mes tras el lanzamiento: 20 preguntas y respuestas reales aleatorias revisadas por un humano cada día. Segundo mes: 30 por semana. Tras tres meses estables: 10 por semana. Cada fallo vuelve al flujo: problema de retrieval, arreglar fragmentación y etiquetas; problema de documento, actualizar la base de conocimiento; problema de límite, agregar una regla de rechazo. Lleven la pista de auditoría. La van a necesitar cuando seguridad pregunte.
Los almacenes que no deberían construir esto
Ahora la parte que molesta a los proveedores. No todos los almacenes deberían construir un asistente de Q&A con IA.
Una operación de menos de 30 personas no debería. Los SOPs caben en una carpeta, los veteranos están en planta, y gritar una pregunta al otro lado del pasillo es más rápido y gratis. Un almacén cuyos SOPs son un desastre tampoco: documentos erróneos, vencidos y contradictorios alimentados a la IA solo producen confusión confiada a velocidad de máquina. Y un sitio con menos de 20 preguntas al día no debería molestarse: el trabajo de mantener el conjunto de evaluación, las revisiones puntuales y la gobernanza documental costará más que el tiempo de Q&A que se ahorra.
El encaje es real para sitios de más de 100 personas con múltiples turnos y SOPs significativamente distintos por cliente: alta rotación, turnos nocturnos sin nadie a quien preguntar, montones de requisitos específicos de clientes. Incluso ahí, posiciónenlo con honestidad: es un veterano digital siempre disponible con el que consultar cosas, no un gerente que juzga por ustedes.
Antes de firmar nada, respondan una pregunta: ¿pueden sus operadores senior encontrar la última versión vigente del SOP sin abrir una laptop? Si no pueden, la IA tampoco podrá. Solo les dará la respuesta errónea más rápido — con una cita que parece real.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
