En 2022, estaba en un almacén 3PL en Ontario viendo a un proveedor correr un POC de conteo cíclico basado en visión. En el sitio, la demo alcanzó 98.6% de precisión — escanearon un rack, los números en la pantalla cuadraban. El gerente del almacén quería firmar en el acto. El contrato solo decía "payment due upon acceptance". Tres meses después el sistema salió en vivo, y en racks reales la precisión cayó a 84%. ¿Cajas con film retráctil reflectante en los niveles altos? La mitad irreconocibles. El gerente me preguntó qué hacer. Le dije que el contrato nunca definió cómo se mide la aceptación, así que en una disputa no recuperaría ni un centavo. En los proyectos de IA, ocho de cada diez minas están enterradas en el contrato.
Antes de que salga el dinero, deja bien amarrada la regla de medición
Un POC no es una demo — es donde fijas la regla de medición. Hay tres reglas, y las tres deben quedar escritas en un anexo del contrato antes de firmar. Sin excepciones.
Regla uno: métricas de efectividad. Responde a "¿acierta?". No escribas solo "accuracy" — define el numerador y el denominador. Para el conteo por visión, algo así: "500 SKUs del conjunto de prueba, escaneados en racks en vivo durante 5 días consecutivos, precisión de reconocimiento ≥97% (un acierto válido exige SKU y cantidad correctos)". Las métricas de efectividad también necesitan un presupuesto de errores: qué errores son tolerables (cajas dañadas) y cuáles son de tolerancia cero (SKUs de alto valor — un fallo cuenta como fracaso).
Regla dos: métricas de ingeniería. Responde a "¿corre de forma confiable?". Tres números son los que más importan: disponibilidad (uptime ≥99% durante 30 días consecutivos, excluyendo ventanas de mantenimiento programado), latencia (respuesta de un reconocimiento ≤2 segundos en el percentil 95) y tasa de falsos positivos (≤1%; cada falso positivo resta puntos del puntaje de aceptación). Muchos proveedores hacen la demo a velocidad de rayo y se caen en cuanto la red tartamudea. Si las métricas de ingeniería no están en el contrato, solo verás cómo el sistema se cae tres veces por semana sin recurso alguno.
Regla tres: métricas de negocio. Responde a "¿vale el dinero?". Al final del POC debes producir dos números: horas de mano de obra ahorradas (p. ej., el tiempo de conteo cíclico por persona-día baja de 6 horas a 1.5, promediado sobre 10 ciclos de conteo) y una puerta de ROI (el contrato establece: si el ahorro anualizado de mano de obra < 1.5× el costo total del proyecto, el cliente puede retirarse de la compra sin penalización). La métrica de negocio es la línea de fondo del jefe — y tu licencia para matar un mal proyecto.
Los tres trucos favoritos de los proveedores
Primero: solo prueban el camino feliz. El rack de la demo tiene cajas estándar, iluminación perfecta, códigos de barras de frente. Insiste en esto: el conjunto de prueba lo pones tú, muestreado de los SKUs que realmente se mueven en tu almacén — cajas dañadas, film reflectante, estibas chuecas, todo incluido. El contrato debe decir que el conjunto de prueba lo provee el cliente y que el proveedor no puede ver las muestras específicas por adelantado.
Segundo: contaminación del conjunto de prueba. El proveedor ajusta el modelo con tus datos de prueba por adelantado, así claro que sale bien. La defensa: prepara dos conjuntos de prueba. Uno se revela al firmar para ajustar; el otro queda sellado y solo se revela el día de la aceptación. Escríbelo así: "La aceptación usa un conjunto de prueba ciego, sellado por el cliente, que el proveedor nunca ha visto".
Tercero: los datos de aceptación no coinciden con tu entorno real. El POC corrió hermoso en el Edificio 1, pero lo vas a desplegar en el Edificio 5 — diferente iluminación, alturas de rack, mezcla de SKUs. El contrato debe decir "entorno de aceptación = entorno final de despliegue", o como mínimo "la aceptación se realiza en dos o más zonas designadas por el cliente".
El manual de aceptación: quién prueba, cuánto dura, quién gana una discusión
Cada métrica del contrato sigue la misma plantilla de cinco partes: línea base (lo que el trabajo manual o el sistema actual logra hoy), valor objetivo (específico con un decimal), método de medición (quién provee los datos, con qué herramientas se mide), ventana de medición (cuántos días consecutivos, cuántas corridas por día) y la regla de aprobado/reprobado (el listón, la política de retest, cuántos fallos cuentan como un POC fallido). Si falta una de las cinco, la aceptación se vuelve una pelea a gritos.
Este es el manual que suelo usar: las pruebas las lidera el cliente con apoyo del proveedor, y las exportaciones del WMS son el sistema de registro para los datos de terceros. La ventana de medición corre 14 días consecutivos, al menos 3 turnos por día. Cualquiera de las partes puede impugnar un resultado dentro de 48 horas, lo que activa un retest; el resultado del retest es definitivo. Si el retest sigue fallando, el cliente puede terminar sin condiciones y el proveedor reembolsa las tarifas del POC ya pagadas. Escribe la resolución de disputas como retest-no-discusión — esa es la cláusula que importa.
Una cosa más desde las trincheras: los proveedores aceptan verbalmente las métricas de aceptación cuando venden, y empiezan a dar largas cuando llega el momento de escribirlas en el anexo del contrato. Mi experiencia es simple — quien lleva la plantilla primero tiene la ventaja. Prepara una hoja de aceptación en blanco con la plantilla de cinco partes y mándasela para que la llenen. Eso es ir primero. Si esperas a que el proveedor la redacte, cada métrica que te favorezca regresará como "to be mutually agreed" — cuatro palabras que no significan nada.
Esta es la verdad honesta: antes de firmar, tienes toda la ventaja en un POC. Después de firmar, lo único que tienes es esperanza. Mañana, haz una cosa: saca el contrato de cualquier proyecto de IA que estés negociando y revisa si el anexo de aceptación tiene las cinco — línea base, objetivo, método de medición, ventana de medición, regla de aprobado/reprobado. Si falta alguna pieza, devuélvelo y haz que el proveedor la llene; para lo que no tengas claro, apóyate en el contrato y en la documentación oficial del proveedor. Ese anexo es la única póliza de seguro real que tendrás en todo el proyecto. Y una pregunta que vale la pena hacerse con honestidad: si este sistema desapareciera el próximo trimestre, ¿tu operación notaría la diferencia? Si la respuesta es no, el POC nunca debió ocurrir.
Traducido del inglés. En caso de discrepancia, prevalece la versión en inglés.
