ШІ в логістиці: склад, маршрутизація та прогнозування попиту

Керівник логістики в середній дистриб'юторській компанії сьогодні витрачає кілька годин на тиждень на ручне планування маршрутів, коригування складських залишків і переписування даних з паперових документів у систему WMS. Будь-яке відхилення від прогнозу попиту закінчується або надлишковими запасами, що блокують капітал, або браком товару та затримкою доставки. Це не проблема масштабу: стосується компаній, які обслуговують 50 замовлень на день, так само як і тих, що обслуговують 5000.

ШІ не вирішує логістику як ціле. Він вирішує конкретні, повторювані обчислення, які людина виконує повільніше і з більшою кількістю помилок, ніж алгоритм, підтриманий моделлю. Різниця полягає в деталях: які обчислення, з якими вхідними даними та з яким людським наглядом.

Логістика має багато підпроцесів, але три області приносять найшвидший вимірюваний результат і є достатньо технологічно зрілими, щоб впровадити їх у польській компанії в 2026 році.

Починайте з одного рівня. Спроба одночасного впровадження трьох — найпоширеніша причина, через яку проекти ШІ в логістиці закінчуються на етапі пілоту.

Класична проблема Vehicle Routing Problem (VRP) є NP-складною: вже при 20 точках доставки простір рішень занадто великий для повного перебору. Евристичні алгоритми (наприклад, Google OR-Tools) дають хороші результати, але не реагують на поточні події: затори на маршруті, зміна часового вікна клієнтом, поломка транспортного засобу.

Агент ШІ з доступом до інструментів додає до цього динамічний перерахунок:

1. Графік і точки доставки потрапляють до агента як контекст.
2. Агент запитує API дорожнього руху та поточний статус флоту.
3. Алгоритм VRP розраховує базовий маршрут; агент перевіряє його на відповідність часовим і об'ємним обмеженням.
4. Якщо виникає подія (затор, зміна вікна), агент перераховує маршрут і надсилає водієві оновлену послідовність.
5. Незворотні дії (зміна замовлення для клієнта, перенесення вікна доставки) потребують підтвердження диспетчера через human-gate.

Ключовий принцип: агент керує обчисленням, диспетчер підтверджує рішення про зовнішні наслідки. Без цієї межі система швидко надсилає повідомлення клієнтам без нагляду і генерує скарги замість їх зменшення.

Більшість компаній прогнозує попит в Excel: бере середнє з останніх N місяців і додає інтуїтивну сезонну корекцію. Це працює при стабільному попиті та малій кількості SKU. Перестає працювати, коли SKU кількасот, попит сезонний і залежить від зовнішніх подій (кампанії, погода, свята).

Модель прогнозування попиту для логістики поєднує кілька джерел даних:

• Історія продажів (на рівні SKU, каналу, регіону) як тренувальні дані.
• Календар сезонності (свята, галузеві піки, дні тижня).
• Зовнішні події (маркетингові кампанії, зміни цін, погодні дані, якщо попит залежить від погоди).
• Дані постачання (терміни доставки від постачальників, мінімальні партії).

Результат — прогноз на рівні SKU на 4–12 тижнів наперед з довірчим інтервалом. Система не каже: «замов 100 штук». Вона каже: «з 80-відсотковою впевненістю тобі потрібно 80–120 штук, при поточному lead time замов 90». Рішення про замовлення залишається за закупником.

Межа, яку не можна перетинати: не автоматизуйте підтвердження закупівельних замовлень без human-gate. Модель помиляється рідше за людину при повторюваних SKU, але при нових продуктах, перервах у ланцюжку постачання та разових подіях історичне прогнозування не має підстав.

Логістичний документ має структуру (номер замовлення, адреса, вага, код товару), але ця структура відрізняється між партнерами, форматами та країнами. Ручне переписування даних з CMR, WZ, авіз та рахунків — це робота, яка не потребує знань, але забирає час і генерує помилки при втомі.

Архітектура автоматизації документів:

1. Документ (скан, PDF, фото) потрапляє до pipeline через API або папку, яку моніторить агент.
2. OCR перетворює зображення на структурований текст.
3. Модель вилучення (instruction-tuned, не універсальний чатбот) витягує поля за визначеною схемою: номер замовлення, NIP, адреса, позиції.
4. Результат валідується схемою JSON і перевіряється на узгодженість (сума рядків = сума рахунку, поштовий індекс відповідає місту).
5. Запис потрапляє до WMS/ERP автоматично, якщо валідація пройшла. Якщо ні — документ потрапляє до черги для ручної перевірки.

Результат у реальних впровадженнях: 85–95% документів обробляються автоматично, 5–15% потребують втручання. Це зміна з «кожен документ — ручний» на «один з десяти потребує уваги». При 100 документах на день це конкретна економія часу.

Важливо: PII в документах (персональні дані водіїв, приватних клієнтів) слід маскувати перед відправкою до хмарної моделі. Корпоративні дані (NIP, адреса компанії) можуть передаватися без маскування, оскільки це публічні дані. Для особливо чутливих даних (договори, медичні дані) розгляньте self-hosting моделі.

Логістика обробляє персональні дані водіїв (GPS, робочий час) та приватних клієнтів (адреси доставки, історія замовлень). Кілька вимог, які потрібно вирішити перед впровадженням ШІ:

• Правова підстава обробки даних водіїв — моніторинг GPS та аналіз робочого часу ШІ повинні мати чітку правову підставу та бути повідомлені працівникам. Це не технічне питання, а правове.
• AI Act та системи оцінки — якщо система ШІ оцінює продуктивність водіїв або вирішує їхні маршрути у спосіб, що впливає на зайнятість, вона може кваліфікуватися як система високого ризику згідно з AI Act, що вимагає DPIA та документації відповідності. Деталі в статті AI Act і RODO 2026.
• Локаційні дані та хмара — необроблені дані GPS водіїв є персональними даними. Перед відправкою до зовнішньої моделі анонімізуйте або псевдонімізуйте їх. Альтернатива — self-hosting моделі оптимізації.
• Data residency — для компаній, що обслуговують міжнародні перевезення, перевірте, в якій юрисдикції обробляються дані та чи модель розміщена в ЄС.

Проведіть оцінку ризиків перед стартом, а не після. Зміна архітектури через RODO в середині проекту коштує набагато дорожче, ніж врахування цих вимог на етапі проєктування.

Найчастіший блокувальник впроваджень ШІ в логістиці — не модель, а інтеграція з вихідними системами. WMS 10-річної давності, TMS без REST API, ERP з експортом лише до CSV о 2:00 ночі. ШІ може лише стільки, скільки отримує даних у режимі, близькому до реального часу.

Три питання, які визначають архітектуру:

1. Чи має вихідна система API? Якщо так, агент може зчитувати дані в реальному часі. Якщо ні — потрібен шар ETL або плановий імпорт.
2. Як часто змінюються довідникові дані? Прайс-листи, таблиці зон, адреси точок доставки. Якщо змінюються часто, потрібен механізм оновлення індексу.
3. Хто є власником рішення? Не система, не модель. Конкретна людина, яка підтверджує маршрут, замовлення, ескалацію. Без чіткого власника human-gate не працює.

Патерн інтеграції, який зменшує ризик: почніть з режиму read-only. ШІ зчитує дані з WMS/TMS і рекомендує, диспетчер підтверджує у вихідній системі. Лише коли якість рекомендацій підтверджена протягом 4–6 тижнів, розглядайте write-back з human-gate для конкретних дій.

Універсальної цифри немає. Емпіричне правило для логістики:

Якщо ваші місячні витрати на паливо та робочий час водіїв перевищують 50 тис. zł, а маршрути не оптимізуються алгоритмічно, оптимізація маршрутів окупається за 6–12 місяців. Якщо обробляєте понад 50 документів на день вручну, автоматизація документів окупається за аналогічний термін. Прогнозування попиту окупається довше (12–18 місяців), але зменшує заморожений капітал у запасах, що є ефектом поза P&L.

Розрахуйте це на своїх цифрах у калькуляторі ROI. Введіть реальні обсяги, ставки та оцінений обсяг автоматизації. Вартість пілоту одного рівня визначаємо індивідуально через контактну форму.

Почніть з оцінки готовності: форма запитує про якість даних, інтеграції та зрілість процесів. Результат вказує, який рівень впроваджувати першим і де є технічні прогалини.

Опишіть один логістичний процес, який займає у вашої команди непропорційно багато часу, а модель розпише архітектуру ШІ для цього випадку: вхідні дані, тип моделі, human-gate та вимірюваний результат (playground: PII маскуються, нульове зберігання).

Ні. Алгоритм розраховує оптимальні маршрути швидше і систематичніше за людину, але диспетчер знає контекст: уподобання клієнта, специфіку транспортного засобу, стосунки з водіями. Роль диспетчера зміщується з ручного планування маршрутів на підтвердження та роботу з винятками. Рішення із зовнішніми наслідками (зміна вікна доставки для клієнта, перегляд замовлення) завжди потребують людини.

Мінімум — 12 місяців історії продажів на SKU, щоб модель могла вивчити сезонність. При 18–24 місяцях якість прогнозу помітно зростає. Якщо даних менше або нові продукти без історії, модель прогнозує гірше, і потрібен ширший довірчий інтервал та суворіший нагляд закупника. Перевірте якість і повноту даних в оцінці готовності перед стартом.

Дані GPS водія є персональними даними. Перед відправкою до зовнішньої моделі анонімізуйте їх: видаліть ідентифікатор водія, замініть початкову/кінцеву локацію псевдонімом і збережіть лише дані, необхідні для оптимізації (послідовність точок, часові вікна). Необроблені дані GPS зберігайте локально з визначеним TTL. Деталі обов'язків компаній описано в статті AI Act і RODO 2026.

Може, але повинна це робити лише після валідації та з механізмом відкату. Продуктивний патерн: ШІ рекомендує зміну, користувач підтверджує одним кліком, система записує та логує. Для дій з високою вартістю (замовлення вище певного порогу, зміна договору з постачальником) завжди застосовуйте human-gate незалежно від впевненості моделі. Почніть з режиму read-only і увімкніть write-back поступово після перевірки якості.

Один рівень (наприклад, автоматизація документів або оптимізація маршрутів для постійного парку) зазвичай займає 3–6 тижнів: тиждень аналізу даних та інтеграції, тиждень побудови pipeline, тиждень тестів і калібрування guardrails, тиждень пілоту на реальних замовленнях з наглядом. Час залежить переважно від якості даних та доступності API вихідних систем. Перевірте як розпочати впровадження ШІ для загальних принципів проєктування пілоту.