Ressourcen Artikel
Lokale KI (On-Premise) für Industrieunternehmen: Wann es sich lohnt, was es braucht, was es kostet
Viele Industrieunternehmen wollen KI nutzen, dürfen oder wollen ihre Daten aber nicht aus der Hand geben. Dieser Artikel zeigt, was lokale KI im Jahr 2026 leistet, welche Hardware und Software dafür nötig ist, mit welchen Kosten zu rechnen ist und wo die typischen Sicherheitslücken liegen. Mit Zahlen und Beispielen aus unseren Projekten in Maschinenbau und Chemie.
Von Marco Bürckel, Gründer der axio concept GmbH Stand:
Lokale KI, auch On-Premise-KI genannt, bedeutet: Vom KI-Modell bis zu den einzelnen Use-Cases läuft alles vollständig in der eigenen Infrastruktur. Keinerlei Daten gehen dabei an externe Dienste. Für Industrieunternehmen ist das vor allem dort sinnvoll, wo Konstruktionsdaten, Rezepturen, Kundenspezifikationen oder Prüfberichte verarbeitet werden, also Daten, die das Haus nicht verlassen dürfen.
Oft verlangen auch dritte Partner und Anbieter den KI-Betrieb in der lokalen Infrastruktur: Zum Beispiel, weil Ausschreibungen dies erfordern oder weil es die Lizenz genutzter Inhalte verlangt. Dies kann zum Beispiel bei Normen der Fall sein.
Kurz gefasst
- Lokale KI ist heute auf kompakter Hardware produktiv betreibbar. Kleine Sprachmodelle (SLMs) reichen für eine Vielzahl von dokumentenbasierten Fachprozessen bereits aus. Selbst mehrschrittige KI-Agenten lassen sich mit verhältnismäßig geringem Hardware-Bedarf im Jahr 2026 abbilden.
- Das KI-Modell ist für die lokale Verarbeitung selten der Engpass. Entscheidend sind Dokumentenverarbeitung, Retrieval, Berechtigungen und die Integration in die tatsächlichen IT-Systeme des Unternehmens. Sei es das ERP, das CAQ, ein DMS oder unternehmensweite Dokumente.
- Lokale KI ist nicht unbedingt sicherer. Die typischen Lecks sind dauerhafte Wartungszugänge, zentrales Logging außerhalb der eigenen Infrastruktur, Testdaten auf Entwicklerrechnern oder schlicht Lücken in der Sicherheitsarchitektur.
- Es lohnt sich nicht für jeden: Wer nur unkritische Daten verarbeitet und wenig Volumen hat, findet in privaten Cloud-KIs das unkompliziertere Setup.
Was bedeutet eine On-Premise-KI genau?
On-Premise heißt: Das Sprachmodell läuft auf Servern im eigenen Rechenzentrum oder im eigenen Serverraum, inklusive aller technischen Abhängigkeiten und den eigentlichen KI-Use-Cases. Es gibt keine API-Aufrufe zu externen Modellanbietern.
Der wesentliche Hardware-Aufwand entsteht dabei vor allem durch das Hosting des KI-Modells, bzw. der KI-Modelle. Gerade Sprachmodelle haben zur Laufzeit einen sehr hohen Ressourcenbedarf. Die KI-Server müssen vor allem mit einer starken GPU ausgestattet sein, welche zur Größe des Modells (Anzahl Parameter) und den zu erwartenden Lastspitzen (Anzahl paralleler Nutzer und Komplexität der Anfragen) passen muss.
Das KI-Modell und der KI-Server sind jedoch nur die halbe Miete. KI arbeitet nicht im luftleeren Raum: sie braucht eine Verbindung zu den Daten und Systemen im Unternehmen, muss für Mitarbeiter im Kontext verschiedener Anwendungsfälle erreichbar sein, muss aber auch vor unerlaubtem Zugriff effektiv geschützt werden.
Lokale KI bedeutet also stets, eine ganzheitlich gedachte KI-Infrastruktur aufzubauen.
Für welche Industrieunternehmen lohnt sich On-Premise?
On-Premise lohnt sich, wenn mindestens eine von drei Bedingungen zutrifft: Die Daten sind ein sensibler Wettbewerbsvorteil oder geschäftskritisch, Verträge oder Regulierung verbieten die Weitergabe, oder das Volumen an Anfragen ist so hoch, dass Token-Kosten aus dem Ruder laufen.
Darüber hinaus möchten viele Kunden schlicht das Risiko vermeiden, sich von Cloud-Anbietern abhängig zu machen, insbesondere von US-Anbietern. Datenschutzpraktiken und die in den jeweiligen Ländern geltenden Gesetze sorgen für Unsicherheit in Bezug auf den Schutz von Intellectual Property und persönliche Informationen.
Aus Sicht verschiedener Branchen:
Maschinen- und Anlagenbau
Typisch schützenswerte Dokumente sind Konstruktionsunterlagen, Kundenspezifikationen, Lastenhefte, Serviceberichte, 8D-Reports, CAQ-Dokumente. Häufig kommen Geheimhaltungsvereinbarungen mit OEMs hinzu, die eine Verarbeitung bei Dritten ausschließen.
Aus der Praxis: Ein Maschinenbaukunde von uns verarbeitet 8D-Reports und CAQ-Dokumente mit lokaler KI, um OEM-Lastenhefte schneller zu bewerten.
Chemie und Labor
Typisch schützenswert sind Rezepturen, Analysenzertifikate, SOPs, Sicherheitsdatenblätter, regulatorische Dossiers. Rezepturwissen ist der Kern des Geschäfts.
Aus der Praxis: Ein Chemie-Kunde von uns automatisiert das Artikelmanagement im Labor mit lokaler KI und kann sich sicher sein, dass ein externer Anbieter über die Zeit nicht ein genaues Bild der eigenen Zusammenhänge im LIMS erhält.
On-Premise, Private Cloud oder Public API: Was sind die Unterschiede?
Zur Einordnung: Private Cloud heißt, die KI läuft in der eigenen Cloud-Subscription, etwa bei Azure oder AWS. Die Daten bleiben im eigenen Mandanten, aber nicht auf eigener Hardware.
Public API heißt, die eigene Anwendung schickt Anfragen direkt an die Schnittstelle eines Modellanbieters. Die Daten liegen dabei weiter in den eigenen Systemen, aber mit jeder Anfrage fließen Inhalte an den Anbieter ab. Das unterscheidet Public API von SaaS-Produkten mit eingebauter KI, bei denen die Daten ohnehin beim Anbieter liegen.
| Kriterium | On-Premise | Private Cloud | Public API |
|---|---|---|---|
| Wo liegen die Daten? | Eigenes Rechenzentrum | Eigene Cloud-Subscription | In den eigenen Systemen |
| Verlassen Inhalte das Haus? | Nein | Nein, aber fremde Hardware | Ja, mit jeder Anfrage fließen Inhalte an den Modellanbieter ab |
| Kostenmodell | Hardware einmalig, Betrieb laufend | Laufend nach Verbrauch | Laufend nach Verbrauch |
| Modell-Updates | Selbst gesteuert, versioniert | Teilweise gesteuert | Anbieter entscheidet |
| Einstiegshürde | Hardware-Beschaffung | Gering | Sehr gering |
| Typisch für | Rezepturen, Konstruktion, KRITIS | Breiter Wissenszugriff | Unkritische Inhalte, Prototypen |
Welche Hardware braucht KI On-Premise?
Weniger, als die meisten erwarten. Drei Faktoren bestimmen den Bedarf: die Größe des Sprachmodells, die Zahl gleichzeitiger Anfragen und die Menge der angeschlossenen Systeme und Dokumente. Beim dritten Faktor kommt es vor allem darauf an, wie gut die Software ist, welche die KI mit den firmeninternen Daten verbindet. Diese ist oft nicht für den effizienten Betrieb auf moderater Hardware ausgelegt. Mit unserer KI-Plattform KogniLink können beispielsweise auch 300.000+ Dokumente mit einer Hardware verarbeitet werden, die mit einer hohen vierstelligen Summe noch sehr erschwinglich ist.
Kleine Sprachmodelle mit bis zu 15 Milliarden Parametern laufen auf einer einzelnen GPU mit 24 bis 48 GB Speicher. Sprachmodelle wie Qwen3.5-9B laufen schon auf vergleichsweise günstigen Grafikkarten wie die NVIDIA RTX PRO 4500 Blackwell mit 32 GB und erlauben die Automatisierung dokumentenbasierter Aufgaben oder die Recherche in Unternehmensdaten.
Das Wissen kommt aus den Dokumenten, das Modell muss es nicht selbst mitbringen. Größere Modelle ab etwa 24 Milliarden Parametern brauchen deutlich mehr GPU-Speicher, die Hardware beginnt bei rund 20.000 EUR. Sie lohnen sich vor allem bei komplexen, kreativen oder multimodalen Aufgaben.
| Kriterium | S | M | L |
|---|---|---|---|
| Modellklasse | Small Language Models (bis 15B Parameter) | Large Language Models (24B+ Parameter) | Frontier-Modelle |
| Typische Use Cases | Wissensmanagement, Dokumente klassifizieren, Dokumente abgleichen | Kreative Texte schreiben, Kundenkommunikation, mehrschrittige Prompts | Komplexe agentische KI, Vibe Coding, langfristig planen |
| Hosting | Lokal (ab ca. 8.000 EUR) oder Cloud | Lokal (ab ca. 20.000 EUR) oder Cloud | Cloud (Token-Kosten) |
Bevor Unternehmen sich für eine Hardware entscheiden, sollten sie vor allem prüfen, mit welcher Nutzungslast im Alltag zu rechnen ist. Hier muss vor allem Klarheit über die Use-Cases bestehen, da einzelne Aufgaben für die KI oft mehrere KI-Operationen umfassen.
Beispiel: Der Belegabgleich im Einkauf oder die Überwachung von Compliance-Erklärungen in der Lieferkette können pro Beleg und Zertifikat gut und gerne 5 bis 10 Anfragen an das Sprachmodell bedeuten. Nutzen die Mitarbeiterinnen und Mitarbeiter die KI gleichzeitig für Recherche, Zusammenfassungen, Übersetzungen und andere alltägliche Aufgaben, werden Latenzzeiten schnell inakzeptabel.
Rechnen Sie den konkreten Bedarf gemeinsam mit Ihrem KI-Technologiepartner durch.
Welche Software braucht KI On-Premise?
Mit dem gehosteten KI-Modell ist es nicht getan.
Ein KI-Modell wird erst nützlich, wenn es mit der Unternehmenswelt interagiert. Je nach Aufgabe braucht das Modell den richtigen Kontext.
Beispiele:
- Für eine Recherche benötigt die KI Zugriff auf tagesaktuelle Daten aus dem ERP, laufenden Projekten, Bestellungen und mehr.
- Um eine Konformitätserklärung auszufüllen, muss die KI zunächst einmal wissen, welche Zertifikate und Normen das Unternehmen erfüllt und wie die Organisation aufgebaut ist.
- Um eine Kundenanfrage zu verstehen, braucht die KI die Kundenhistorie aus CRM und Ticketsystem.
Die Brücke zum Kontext schlägt eine entsprechende KI-Middleware oder -plattform, die als Vermittler zwischen KI-Modell und Unternehmenswelt dient. Die KI-Middleware enthält Datenpipelines zwischen Quellsystemen und KI (Stichwort: Retrieval Augmented Generation), koordiniert agentische KI und erhöht Sicherheit und Nachvollziehbarkeit im Betrieb.
Beispiele für solche Systeme sind Microsoft Copilot, das auf die Microsoft-365-Cloud zugeschnitten ist, und KogniLink von axio concept, das vor allem auf den strikten On-Premise-Betrieb zugeschnitten ist.
Für größere mittelständische Industrieunternehmen (oft so ab 150–250 Mitarbeiter) lohnt es sich, die KI-Plattform rund um den Modellbetrieb in Teilen selbst zu bauen bzw. an die eigenen Bedürfnisse anzupassen. On-Premise-KI funktioniert besonders gut, wenn die Verarbeitung in der Middleware auf hauseigene Datenformate, -schemas und Schlüsseldokumente (z.B. komplexe Entscheidungstabellen) optimiert wurde. Daher ist es wichtig, auf die Erweiterbarkeit der eingekauften KI-Middleware zu achten.
Der Aufbau einer KI-Middleware from scratch rentiert sich in mittelständischen Industrieunternehmen häufig nicht.
Was kostet KI On-Premise?
Die Kosten bestehen aus den Blöcken: Hardware (einmalig) sowie den laufenden Kosten für Software, Einführung und den laufenden Betrieb. Da die Kosten von konkreten Use-Cases, Nutzerzahlen, dem parallelen Betrieb durch mehrere Nutzer und vielen weiteren Parametern abhängen, ist es nahezu unmöglich, hier genaue Zahlen zu nennen. Daher sind die nachfolgenden Spannen eher als ganz grobe Orientierung zu verstehen.
Typisches Einsteiger-Setup:
- Hardware: 8.000 bis 16.000 EUR
- Software: Monatlich drei- bis vierstelliger Eurobetrag, je nach Anzahl Nutzer, Use-Cases und Funktionsumfang
- Einführung: 4 bis 12 Wochen
- Betrieb: Monatlich 2–6 Stunden Aufwand durch IT oder Dienstleister
Dem stehen bei Cloud-Lösungen Token-Kosten und monatliche Plattformgebühren gegenüber. Datenpipelines (z.B. RAG) verbrauchen deutlich mehr Token, als die meisten kalkulieren, weil jede Anfrage Kontext aus mehreren Dokumenten mitschickt. In einer aktuellen Case-Study von uns haben wir bei einem internationalen Zertifizierungsunternehmen das Cloud-RAG auf On-Premise-Technologie umgestellt und dabei 23 % Kosteneinsparung ermöglicht bei 76 % höherer Performance.
Sicherlich darf man On-Premise nicht pauschal als überlegen bewerten. Es gibt jedoch durchaus Szenarien, wo die lokale KI am Ende kostengünstiger ist, als der vermeintlich unkomplizierte und günstige Betrieb in der Cloud.
Auf der Nutzenseite sehen wir in Fachabteilungen typischerweise 30 bis 100 eingesparte Stunden pro Prozess und Monat. Diese Rentabilitätsrechnung sollten Unternehmen im Zuge ihrer KI-Strategie auf jeden Fall use-case-bezogen durchführen.
Welche Anwendungsfälle funktionieren On-Premise besonders gut?
Alles, was auf eigenen Dokumenten beruht und einen Beleg braucht:
- Wissenssuche in SOPs, Normen, Handbüchern und Projektdokumentation, jede Antwort mit Quelle
- Kundenanforderungen aus F&E- bzw. QM-Dokumenten bewerten
- Auftragsbestätigungen gegen Bestellungen abgleichen
- Analysenzertifikate gegen Spezifikationen prüfen
- Auswirkungen geänderter QM-Dokumente auf interne Dokumente analysieren
- Troubleshooting in Wartung und Instandhaltung
Weniger geeignet sind offene Web-Recherche, Aufgaben mit Frontier-Anspruch wie Vibe Coding oder langfristige Planung und alles, was aktuelles Weltwissen braucht. Dafür sind große Cloud-Modelle die bessere Wahl.
Ist On-Premise automatisch sicher?
Nein. Aus unseren Projekten kennen wir vier typische Lecks:
- Dauerhafte Wartungszugänge des Anbieters. Zugriffe sollten immer nur temporär freigeschaltet werden.
- Zentrale Komponenten, die Daten abfließen lassen, etwa Logging oder Telemetrie beim Anbieter.
- Testdaten, die der Anbieter für die Einrichtung bekommt und die auf Entwicklerrechnern landen.
- Berechtigungen. Wer im SharePoint keinen Zugriff hat, darf ihn auch über den KI-Assistenten nicht bekommen. Rechte aus ERP, DMS und SharePoint müssen durchgereicht und bei Änderungen nachgezogen werden.
Dazu gehören Audit-Trail, rollenbasierte Zugriffe und versionierte Modelle, damit nachvollziehbar bleibt, welches System wann welche Antwort gegeben hat. Eine vollständige Prüfliste steht in unserer Enterprise-RAG-Checkliste.
Wie läuft die Einführung ab?
Ein erster Prozess ist in 4 bis 12 Wochen produktiv. Bei On-Premise kommt die Hardware-Beschaffung dazu, die je nach Einkaufsprozess einige Wochen dauern kann.
- Einen klar abgegrenzten Prozess wählen.
- Dokumentenbestand und Berechtigungen anbinden.
- Pilot mit der Fachabteilung durchführen und Benchmarks definieren.
- In den Produktivbetrieb gehen, danach Prozess für Prozess erweitern.
Der häufigste Fehler: mit einem unternehmensweiten „Chat mit allen Dokumenten“ starten. Besser ist ein einzelner Prozess mit messbarem Aufwand.
Am besten definiert man einen konkreten Nutzer aus einer konkreten Abteilung, die ein konkretes Problem lösen muss. Beispiel: Bei der Beantwortung von Kundenanfragen benötigt ein Mitarbeiter im Vertrieb Zugriff auf Informationen aus aktuellen Produktdatenblättern, so dass er Anfragen zu Grenzwerten, Betriebsumgebungen etc. schnell beantworten kann.
Wann ist On-Premise die falsche Wahl?
Wenn die Daten unkritisch sind, das Volumen gering ist und niemand im Haus Server betreiben will oder kann. Dann ist eine Private-Cloud-Installation in der eigenen Subscription meist der bessere Weg: gleiche Anwendung, gleiche Berechtigungen, keine Hardware.
Oft ist die Antwort auch hybrid: Sensible Prozesse laufen lokal auf einem kleinen Sprachmodell, unkritische Aufgaben mit Frontier-Anspruch, etwa Vibe Coding, über Cloud-Modelle.
