Das Problem
Die Touren-Planung in vielen österreichischen Speditionen läuft 2026 noch immer auf einem Mix aus Erfahrungswissen, einer zehn Jahre alten Software und einem Excel mit verbundenen Zellen. Der Dispoleiter zeichnet morgens um sechs die Touren, eine Stunde später kippt der erste Stau am Knoten Linz die Planung, und ab Mittag werden Aufträge per Telefon umverteilt. Lieferfenster werden gerissen, Fahrer fahren Überstunden, und der Geschäftsführer sieht erst am Monatsende in der DB-Auswertung, dass die Pünktlichkeitsquote schon wieder unter 80 Prozent gefallen ist. Genau hier setzt eine moderne KI-Routing-Engine an — nicht als Black-Box-Magie, sondern als sauber gebautes Optimierungssystem mit Re-Planung in Echtzeit.
So funktioniert die KI-Lösung
Eine produktionsreife Routing-Engine besteht aus vier Schichten, die aufeinander aufbauen. Zuerst die Stammdaten-Schicht: Aufträge mit Zeitfenster, Volumen und Gewicht; Fahrer mit Skill-Matrix (ADR-Schein, Kühlgut, Hebebühne), Lenkzeitkonto und Heimatdepot; Fahrzeuge mit Kapazität, Verbrauch und Lade-Restriktionen. Darauf sitzt der Solver, der das Vehicle-Routing-Problem mathematisch löst — bei kleinen Flotten genügt Google OR-Tools, ab 60 Touren pro Tag empfehlen wir einen dedizierten VRP-Solver wie HERE Tour Planning oder PTV xRoute.
Der KI-Layer ist die spannende Schicht: Hier erkennen Anomalie-Modelle in Echtzeit, wann die geplante Tour aus dem Ruder läuft — Stau auf der A1, Wartezeit am Wareneingang in Wels, Ladevorgang dauert dreimal länger als kalkuliert. Sobald die Toleranz gerissen wird, triggert der Layer eine Re-Optimization für die betroffenen Touren. Die vierte Schicht ist die ETA-Kommunikation an die Kunden: SMS oder WhatsApp mit korrigiertem Lieferfenster, automatisch, ohne dass die Dispo telefonieren muss.
Architektur-Skizze
So sieht ein typisches Setup für eine Spedition mit 30 bis 80 Touren pro Tag aus:
- Stammdaten-Layer: PostgreSQL mit Auftrags-, Fahrer-, Fahrzeug- und Kunden-Stamm; ETL aus dem bestehenden TMS (Active Logistics, Soloplan, oder hauseigen)
- Echtzeit-Verkehrsdaten: HERE Traffic API oder TomTom Move, EU-gehostet mit DPA; Wetterdaten von DWD/ZAMG als sekundärer Signalgeber
- Solver: Google OR-Tools (Open Source) für Setups bis 40 Touren, HERE Tour Planning oder PTV xRoute für größere Flotten
- KI-Layer: Isolation-Forest-Modell für Anomalie-Erkennung auf Telematik-Streams, plus Claude Sonnet 4.5 als Reasoning-Layer für Re-Plan-Entscheidungen mit Kontext (Kunde A wichtiger als Kunde B)
- ETA-Kommunikation: Twilio (EU-Region) oder MessageBird für SMS, WhatsApp Business Cloud API für Endkunden
- Hosting: Hetzner Cloud Wien oder Vercel Frankfurt, alles innerhalb EU
- Monitoring: Grafana-Dashboard für Dispo mit Live-Touren-Status, Langfuse für KI-Tracing
DSGVO und EU AI Act
Fahrer-Tracking-Daten sind personenbezogene Daten — Punkt. Telematik-Spuren, Pausenzeiten und Performance-Indikatoren fallen unter Artikel 88 DSGVO plus das österreichische DSG. Das heißt konkret: Betriebsvereinbarung mit dem Betriebsrat vor dem Rollout, klare Zweckbindung (Touren-Optimierung, nicht Mitarbeiter-Bewertung) und Aufbewahrungsfristen maximal so lang, wie für den Zweck nötig.
Beim EU AI Act wird es interessant: Reine Touren-Optimierung ist minimales Risiko, keine besonderen Auflagen. Sobald das System aber Fahrer-Performance bewertet oder Entscheidungen über Einsatzplanung, Boni oder Kündigung beeinflusst, rutscht es in Anhang III Punkt 4 — Hochrisiko-KI im Beschäftigungsbereich. Dann braucht es eine DPIA, Konformitätsbewertung, Human-Oversight-Konzept und Registrierung in der EU-Datenbank. Wir empfehlen, diese Funktionen technisch klar zu trennen, damit das Routing-System nicht aus Versehen zum Hochrisiko-System wird.
ROI-Beispiel
Reales Setup einer oberösterreichischen Spedition, 40 Touren pro Tag, 22 Fahrer, gemischte Flotte Kühl- und Trockentransport:
| Kennzahl | Vorher | Nach 6 Monaten | Differenz |
|---|---|---|---|
| Gefahrene Kilometer pro Tag | 4.850 km | 4.270 km | -12 % |
| Pünktlichkeits-Score | 76 % | 94 % | +18 Pkt |
| Fahrer-Überstunden pro Monat | 380 h | 285 h | -25 % |
| Treibstoffkosten pro Monat | €28.500 | €25.100 | -€3.400 |
| Kundenbeschwerden (Lieferfenster) | 42 / Monat | 9 / Monat | -78 % |
Setup-Kosten: €85.000 (Implementation in 14 Wochen inkl. Telematik-Integration und Schulung). Laufende Kosten: rund €3.200 pro Monat (Solver-Lizenz, Traffic-API, Hosting, LLM-Calls). Amortisation nach 10 Monaten, ROI in Jahr 2 bei +220 Prozent — und das ohne Berücksichtigung der höheren Kundenzufriedenheit, die zwei Großkunden zur Vertragsverlängerung bewogen hat.
Implementation-Aufwand
Wir liefern Routing-KI in drei Größenordnungen, abhängig von Flotten-Größe und TMS-Komplexität:
- Sprint S (8 Wochen, €45.000–65.000): Bis 20 Touren/Tag, OR-Tools-Solver, Anbindung an ein bestehendes TMS, einfache ETA-SMS
- Sprint M (12–16 Wochen, €75.000–110.000): 20–60 Touren/Tag, dedizierter VRP-Solver, Anomalie-Erkennung mit Re-Plan, WhatsApp-ETA, Dispo-Dashboard
- Sprint L (18–26 Wochen, €130.000–220.000): Über 60 Touren/Tag, Multi-Depot, Multi-Tag-Planung, KI-Reasoning-Layer für komplexe Trade-offs, Telematik-Deep-Integration, Mehrsprachen-Fahrer-App
Dazu kommt AI-Care: monatliches Solver-Tuning, Anomalie-Modell-Retraining bei Saison-Wechsel, Anpassung an Flottenveränderungen. Realistisch €2.000–6.000 pro Monat, abhängig von der Volatilität des Geschäfts.
Häufige Fehler
Aus den Implementierungen, die wir 2024 bis 2026 begleitet haben, kommen fünf wiederkehrende Anti-Patterns:
- Routing ohne Lieferfenster-Berücksichtigung: Der Solver optimiert auf Kilometer und produziert wunderschöne Touren — die dann den ganzen Tag verfrüht oder verspätet ankommen. Lieferfenster gehören als harte Constraints rein, nicht als Soft-Score.
- Fehlende Betriebsrats-Einbindung: Das System wird gebaut, geht live, und drei Wochen später blockiert der Betriebsrat den Rollout wegen unzulässiger Mitarbeiter-Überwachung. Betriebsvereinbarung gehört in Woche 1, nicht in Woche 12.
- Keine Re-Plan-Logik bei Stau-Events: Statische Routen sind nett am Morgen, aber ab 09:00 Uhr nur noch Makulatur. Ohne Re-Optimization auf Anomalie-Trigger ist die Effizienz-Steigerung nach drei Monaten weg.
- Telematik-Daten in der Cloud außerhalb der EU: Viele Telematik-Anbieter routen über US-Cloud. Das ist nach Schrems II ohne TIA und SCC kein sauberer Zustand. Vor dem Projekt prüfen, nicht währenddessen.
- Dispo nicht eingebunden: Wenn die Dispo das System als "Black-Box-Bedrohung" empfindet, sabotiert sie es. Co-Design mit der Dispo von Anfang an, transparente Erklärung warum der Solver eine Tour anders legt — sonst landet die KI nach drei Monaten im Schrank.
durchschnittliche Streckenreduktion bei einer Spedition mit 40 Touren/Tag
Häufige Fragen
Was Spediteure und Disponenten zur Routing-KI fragen.
Wie lange dauert es, bis das Routing-System produktiv läuft?
Was passiert, wenn die Telematik kurz ausfällt?
Brauchen wir den Betriebsrat einbinden, auch wenn wir nur Routing optimieren?
Lohnt sich das auch für kleine Speditionen mit zehn Fahrzeugen?
Wie verhindert ihr, dass das System zur Mitarbeiter-Überwachung wird?
Bereit für ein erstes Audit?
Wenn deine Spedition mehr als 15 Touren pro Tag fährt und du den Verdacht hast, dass Strecke, Pünktlichkeit oder Überstunden noch deutlich besser gehen müssten, lohnt sich der genaue Blick. Im Audit S (€3.500) schauen wir uns drei Wochen echte Touren-Daten an, identifizieren das Optimierungs-Potenzial in Prozent und Euro, und liefern einen Implementation-Pfad mit klaren Meilensteinen. Buch dir einen 30-minütigen Discovery-Call — danach weißt du, ob die nächsten Schritte für dich sinnvoll sind.