¿Qué ocurre al automatizar control de stock?

En tu empresa el día de la entrega de la solución de IA para automatizar control de stock suele ser el inicio de una nueva fase. Lo que ya no se habla es qué ocurre una vez que el proyecto está en producción: quién responde ante fallas, cómo se gestiona el mantenimiento y qué medidas tomar para no quedar atrapado en una dependencia tecnológica.

Lo que empieza el día de la entrega

Nadie menciona que, antes de firmar, deben definirse claramente los entregables operativos. No basta con recibir un bot que actualiza inventarios; la empresa necesita:

• Un documento que detalle cada proceso automatizado, con entradas, salidas y métricas de rendimiento.
• Accesos a los servidores o a la nube donde se aloja el modelo de IA, con credenciales que puedan ser rotadas.
• Un plan de capacitación de al menos dos semanas para los usuarios clave del almacén y el área de operaciones.

En Perú, la normativa de SUNAT exige que los registros de stock estén disponibles para auditorías electrónicas. Por eso, el contrato debe especificar cómo se exportan los datos a la plataforma de facturación electrónica y en qué formato (XML, CSV, etc.). Sin este detalle, la empresa corre el riesgo de incumplir obligaciones tributarias en los primeros 30 días de operación.

Quién responde cuando algo falla

Después de la entrega, la responsabilidad no desaparece. Es crucial que el acuerdo incluya:

• Tiempo de respuesta: un SLA (Service Level Agreement) que establezca, por ejemplo, 2 horas para incidencias críticas (pérdida total de actualización de stock) y 24 horas para incidentes menores.
• Canales de soporte: correo corporativo, ticketing interno y, si es necesario, un número de emergencia para incidencias fuera del horario laboral.
• Exigencias por escrito: un anexo que describa los criterios de aceptación post‑entrega, incluyendo pruebas de carga (p.ej., 1 000 transacciones por minuto) y la tolerancia a errores (máximo 0,1 % de desvío en los niveles de inventario).

Si la falla proviene de una integración con el ERP de la empresa, la responsabilidad recae en el proveedor que realizó la conexión. En cambio, si el modelo de IA deja de predecir correctamente la reposición, el contrato debe prever una revisión de los datos de entrenamiento y, si es necesario, una recalibración dentro de los 10 días hábiles.

Mantenimiento: qué es y qué no

El mantenimiento no es sinónimo de “estar siempre disponible”. Se divide en tres niveles:

1. Corrección – Solucionar bugs o errores de lógica que impiden la actualización del stock.
2. Mejora – Incorporar nuevas reglas de negocio, como la gestión de productos con fecha de caducidad, sin rehacer la arquitectura.
3. Rehacer – Cuando la infraestructura subyacente (por ejemplo, una versión obsoleta de la base de datos) requiere una migración completa.

Un contrato típico de mantenimiento en Perú contempla un ciclo de revisión trimestral: se evalúan los indicadores de precisión del modelo y se actualizan los datasets con los últimos movimientos de inventario. Las mejoras menores (ajustes de umbrales, cambios de formato de reporte) suelen estar incluidas, mientras que una ampliación de alcance (p.ej., añadir un nuevo almacén) se negocia por separado.

Cómo evitar quedar atrapado

El riesgo de dependencia tecnológica se reduce con tres acciones concretas:

• Accesos y copias: solicita al proveedor una copia de los scripts, modelos entrenados y bases de datos en un formato estándar (por ejemplo, archivos .pkl para modelos y .sql dump para la base). Estas copias deben entregarse dentro de los 15 días posteriores a la firma.
• Documentación completa: un manual técnico que incluya diagramas de arquitectura, flujos de datos y procedimientos de backup. En Perú, es recomendable que el documento también mencione los requisitos de la SUNAT para la conservación de registros digitales (mínimo 5 años).
• Propiedad del código: el contrato debe estipular que el código fuente y los modelos son propiedad de tu empresa, con licencia de uso perpetua. De lo contrario, cualquier cambio futuro dependerá exclusivamente del proveedor.

• No tienes acceso al código. Cada vez que necesitas un ajuste menor, dependes de un ticket que puede tardar semanas.
• La documentación está incompleta. Cuando el equipo interno intenta entender la lógica, se generan errores que afectan la exactitud del stock.
• El contrato no menciona SLA. Las incidencias críticas quedan sin prioridad y el negocio sufre pérdidas por falta de inventario.

Conclusión

Quien ha leído hasta aquí sabe que automatizar control de stock no termina con la firma del contrato. El día de la entrega es solo el punto de partida; deben quedar claros los tiempos de respuesta, el alcance del mantenimiento y las garantías de acceso y propiedad. Cumplir con estos requisitos evita sorpresas, asegura la conformidad con la normativa peruana y permite que la inversión en IA genere el ahorro y la precisión esperados.

Una entrega bien documentada y con SLA definido convierte la automatización en un activo rentable y sostenible.