AI in logistics: warehouse, routing, and demand forecasting

A logistics manager in a mid-sized distribution company spends several hours a week manually planning routes, adjusting warehouse stock levels, and transcribing data from paper documents into the WMS system. Any deviation from demand forecasts results in either excess stock tying up capital or stockouts and delayed deliveries. This isn’t a scale problem: it affects companies handling 50 orders a day just as much as those handling 5,000.

AI doesn’t solve logistics as a whole. It solves specific, repetitive calculations that humans perform slower and with more errors than an algorithm assisted by a model. The difference lies in the details: which calculation, with what input data, and under what human supervision.

Logistics has many subprocesses, but three areas deliver the fastest measurable return and are technologically mature enough to implement in a Polish company in 2026.

Start with one layer. Attempting to implement all three simultaneously is the most common reason AI projects in logistics stall at the pilot stage.

The classic Vehicle Routing Problem (VRP) is NP-hard: even with 20 delivery points, the solution space is too large for exhaustive search. Heuristic algorithms (like Google OR-Tools) deliver good results but don’t respond to real-time events: traffic jams, changes in customer time windows, or vehicle breakdowns.

An AI agent with access to tools adds dynamic recalculation:

1. The schedule and delivery points are fed to the agent as context.
2. The agent queries traffic APIs and the current fleet status.
3. The VRP algorithm calculates a baseline route; the agent verifies it against time and capacity constraints.
4. If an event occurs (traffic jam, time window change), the agent recalculates the route and sends the driver an updated sequence.
5. Irreversible actions (changing an order for a customer, shifting a delivery window) require dispatcher confirmation via human-gate.

Key principle: the agent manages the calculation, the dispatcher approves decisions with external consequences. Without this boundary, the system quickly sends messages to customers without oversight and generates complaints instead of reducing them.

Most companies forecast demand in Excel: they take an average of the last N months and add an intuitive seasonal adjustment. This works for stable demand and a small number of SKUs. It fails when there are hundreds of SKUs, demand is seasonal, and depends on external events (campaigns, weather, holidays).

A demand forecasting model for logistics combines several data sources:

• Sales history (at the SKU, channel, region level) as training data.
• Seasonality calendar (holidays, industry peaks, days of the week).
• External events (marketing campaigns, price changes, weather data if demand depends on weather).
• Supply data (supplier delivery times, minimum order quantities).

The result is a forecast at the SKU level for 4–12 weeks ahead with a confidence interval. The system doesn’t say: “order 100 units.” It says: “with 80% confidence, you’ll need 80–120 units; with the current lead time, order 90.” The purchasing decision remains with the buyer.

Boundary not to cross: don’t automate purchase order approvals without human-gate. The model makes fewer mistakes than humans for repetitive SKUs, but for new products, supply chain disruptions, and one-off events, historical forecasting has no basis.

A logistics document has structure (order number, address, weight, product code), but this structure varies between partners, formats, and countries. Manually transcribing data from CMR, WZ, notifications, and invoices is work that doesn’t require expertise but consumes time and generates errors due to fatigue.

Document automation architecture:

1. The document (scan, PDF, photo) enters the pipeline via API or a folder monitored by an agent.
2. OCR converts the image into structured text.
3. An extraction model (instruction-tuned, not a generic chatbot) pulls fields according to a defined schema: order number, VAT ID, address, line items.
4. The result is validated against a JSON schema and checked for consistency (line total = invoice value, postal code matches city).
5. The record is automatically sent to WMS/ERP if validation passes. If not, the document goes to a manual verification queue.

Real-world implementation results: 85–95% of documents are processed automatically, 5–15% require intervention. This shifts from “every document is manual” to “one in ten requires attention.” With 100 documents a day, this translates to concrete time savings.

Important: PII in documents (personal data of drivers, individual customers) must be masked before sending to a cloud model. Corporate data (VAT ID, company address) can be sent without masking, as it’s public. For particularly sensitive data (contracts, medical data), consider self-hosting the model.

Logistics processes personal data of drivers (GPS, working hours) and individual customers (delivery addresses, order history). Several requirements must be addressed before implementing AI:

• Legal basis for processing driver data — GPS monitoring and AI analysis of working hours must have a clear legal basis and be communicated to employees. This isn’t a technical issue; it’s a legal one.
• AI Act and evaluation systems — if the AI system evaluates driver performance or decides routes in a way that affects employment, it may qualify as a high-risk system under the AI Act, requiring DPIA and compliance documentation. Details in the article AI Act and RODO 2026.
• Location data and the cloud — raw GPS data of drivers is personal data. Before sending to an external model, anonymize or pseudonymize it. An alternative is self-hosting the optimization model.
• Data residency — for companies handling cross-border transport, check which jurisdiction processes the data and whether the model is hosted in the EU.

Conduct a risk assessment before starting, not after. Retrofitting architecture due to RODO mid-project costs significantly more than addressing these requirements during the design phase.

The most common blocker in AI implementations in logistics isn’t the model—it’s integration with source systems. A 10-year-old WMS, a TMS without a REST API, an ERP that only exports to CSV at 2:00 AM. AI can only work with the data it receives in near real time.

Three questions that determine the architecture:

1. Does the source system have an API? If yes, the agent can read data in real time. If not, you need an ETL layer or scheduled imports.
2. How often do reference data change? Price lists, zone tables, delivery point addresses. If they change frequently, you need a mechanism to refresh the index.
3. Who owns the decision? Not the system, not the model. A specific person who approves the route, order, or escalation. Without a clear owner, human-gate doesn’t work.

An integration pattern that reduces risk: start in read-only mode. AI reads data from WMS/TMS and recommends, the dispatcher approves in the source system. Only after the quality of recommendations is confirmed over 4–6 weeks should you consider write-back with human-gate for specific actions.

There’s no single number. Rule of thumb for logistics:

If your monthly fuel and driver time costs exceed 50,000 PLN and routes aren’t algorithmically optimized, route optimization pays off in 6–12 months. If you process over 50 documents a day manually, document automation pays off in a similar timeframe. Demand forecasting takes longer (12–18 months) but reduces capital tied up in inventory, which is an off-P&L effect.

Calculate this with your numbers using the ROI calculator. Enter real volumes, rates, and estimated automation scope. The cost of piloting one layer is determined individually via the contact form.

Start with the readiness assessment: the form asks about data quality, integrations, and process maturity. The result indicates which layer to implement first and where the technical gaps are.

Describe one logistics process that takes your team disproportionately long, and the model will outline an AI architecture for that case: input data, model type, human-gate, and measurable outcome (playground: PII masked, zero retention).

No. The algorithm calculates optimal routes faster and more systematically than a human, but the dispatcher knows the context: customer preferences, vehicle specifics, relationships with drivers. The dispatcher’s role shifts from manually planning routes to approving and handling exceptions. Decisions with external consequences (changing a customer’s delivery window, renegotiating an order) always require a human.

The minimum is 12 months of sales history per SKU to allow the model to learn seasonality. With 18–24 months, forecast quality improves significantly. If you have less data or new products without history, the model forecasts poorly, and you need a wider confidence interval and tighter buyer oversight. Check data quality and completeness in the readiness assessment before starting.

Drivers' GPS data is personal data. Before sending it to an external model, anonymize it: remove the driver’s identifier, replace start/end locations with pseudonyms, and retain only data necessary for optimization (point sequence, time windows). Store raw GPS data locally with a defined TTL. Details on company obligations are in the article AI Act and RODO 2026.

It can, but it should only do so after validation and with a rollback mechanism. Production pattern: AI recommends a change, the user approves with one click, the system writes and logs. For high-value actions (orders above a certain threshold, supplier contract changes), always use human-gate regardless of model confidence. Start in read-only mode and enable write-back gradually after verifying quality.

One layer (e.g., document automation or route optimization for a fixed fleet) typically takes 3–6 weeks: one week for data analysis and integration, one week for pipeline building, one week for testing and guardrail calibration, one week for piloting on real orders with supervision. Time depends mainly on data quality and availability of source system APIs. See how to start an AI implementation for general pilot design principles.