Corporate LLMs
in Industrial DevOps:
Vorteile, Hürden, Praxis.

Andreas Schönfeld

Geschäftsführer & DevOps-Berater, Comquent GmbH

18+ Jahre Erfahrung in DevOps, CI/CD und Industrial Automation

Veröffentlicht: 20. August 2026

Stand: 20. August 2026 · Modell- und Toolnamen als Beispiele, ohne Versionsstand · Regulatorik einordnend, keine Rechtsberatung

Ein Corporate LLM ist ein Sprachmodell, das ein Unternehmen auf eigener Infrastruktur betreibt und über Retrieval-Augmented Generation (RAG) — die Anreicherung jeder Anfrage mit passenden Auszügen aus internen Quellen — an das eigene Wissen anbindet. Sein Kernnutzen: generative KI dort verfügbar zu machen, wo Cloud-Dienste ausscheiden, weil Quellcode, SPS-Programme und Anlagendokumentation das Haus nicht verlassen dürfen. Der Nutzen entsteht dabei nicht aus dem Modell allein, sondern aus zwei Dingen: der Integration in die CI/CD-Kette und dem Zugang zum eigenen Wissen. Und der Einstieg ist kleiner, als die meisten erwarten — ein fokussierter Pilot auf kompakter Hardware, in Wochen statt Monaten.

// Kurz gefragt1 Klick, anonym

Ist ein Corporate LLM bei Ihnen gerade ein Thema?

Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.

Ja, akutes ThemaWird gerade relevantNur Recherche

Der dritte Teil räumt mit dem häufigsten Missverständnis auf: Niemand trainiert ein eigenes Modell. Das wäre teuer, langsam und nach dem nächsten Modell-Release veraltet. Stattdessen bleibt das offene Basismodell unverändert, und RAG legt vor jede Anfrage die passenden Auszüge aus Ihren Dokumenten, Pipelines und Tickets in den Kontext — mit Quellenangabe. Das Wissen liegt in einer Vektordatenbank, die sich täglich aktualisieren lässt; das Modell lässt sich austauschen, ohne dass das Wissen verloren geht.

Was ein Corporate LLM
tatsächlich bringt.

Der größte Vorteil eines Corporate LLM ist nicht die Modellqualität, sondern dass es überhaupt eingesetzt werden darf: Datenhoheit und Air-Gap-Fähigkeit öffnen die Tür, der Zugang zum eigenen Wissen macht es nützlich, und die Nachweisbarkeit im eigenen Verantwortungsbereich hält die Tür offen.

Wie der Status quo aussieht, zeigt sich meist beim ersten Gespräch mit dem Team: Der Inbetriebnehmer hat den Fehlerblock aus dem Structured Text in sein privates Chat-Konto kopiert, weil der Ausschuss in zwei Stunden stand und das Verbot keine Alternative anbot. Das Programm einer Linie liegt jetzt irgendwo, wo es niemand mehr zurückholt. Kein Vorsatz — eine Lücke im Werkzeugkasten.

• /01

  Datenhoheit und IP-Schutz

  Quellcode, SPS-Programme, Rezepturen und Anlagendokumentation verlassen das Haus nicht — weil es architektonisch nicht geht, nicht weil ein Vertrag es verspricht. In vielen Industrieumgebungen ist das keine Präferenz, sondern die Voraussetzung, ohne die das Thema gar nicht erst auf den Tisch kommt.
• /02

  Air-Gap-Fähigkeit

  Vollständiger Offline-Betrieb in der abgeschotteten Zone. Modell-Updates kommen über kontrollierte, signierte Transferprozesse hinein — derselbe Weg, den Betriebssystem-Patches in einem Air-Gap-CI/CD-Setup heute schon nehmen. Nichts daran ist für die OT neu, nur der Inhalt des Pakets.
• /03

  Zugang zum eigenen Wissen

  Über RAG antwortet das Modell auf Basis interner Handbücher, Pipelines und Ticket-Historie — mit Quellenangabe. Ein öffentliches Modell weiß nicht, dass Ihre Linie 3 einen Sonderfall im Rezeptur-Handling hat. Genau darin liegt der Unterschied, nicht in der Modellgröße.
• /04

  Compliance und Nachweisbarkeit

  Der Betrieb im eigenen Verantwortungsbereich erleichtert die Einordnung unter NIS2, Cyber Resilience Act, IEC 62443 und EU AI Act. Interne Assistenzsysteme fallen dort in der Regel nicht unter Hochrisiko; Transparenz- und Dokumentationspflichten bleiben — und lassen sich mit eigenen Protokollen belegen statt mit Anbieter-Zusagen.
• /05

  Eindämmung von Schatten-KI

  Ein offizielles, erlaubtes Werkzeug beendet die Nutzung privater Cloud-Konten wirksamer als jedes Verbot. Verbote erzeugen Umwege; ein Werkzeug, das auf die eigene Doku antwortet, erzeugt Gewohnheit.
• /06

  Anbieterunabhängigkeit und Kostenkontrolle

  Offene Modellfamilien sind austauschbar, die Kosten folgen der Hardware statt der Token-Zahl. Ehrlich eingeordnet: Bei einer Handvoll Nutzer ist die Cloud günstiger. Der Business Case entsteht über Datenhoheit und über Skaleneffekte, wenn ganze Teams und Pipelines das Modell nutzen.

Vier Stellen, an denen
es in der Praxis trägt.

Ein Corporate LLM trägt in Industrial DevOps an vier Stellen: bei der Log-Triage nach fehlgeschlagenen Builds, als Pipeline-Assistenz für Jenkinsfiles und SPS-Build-Automatisierung, als befragbare Wissensbasis über Handbücher und Altsystem-Doku und beim Entwerfen von Release Notes, Testberichten und Audit-Unterlagen. Allen vier gemeinsam: klarer Trigger, Quellenbezug, Mensch in der Freigabe. Die Beispiele stammen aus Projekten dieser Art — ohne Kundennamen und ohne erfundene Prozentwerte.

Was von diesen vier Beispielen am schnellsten sichtbar wird, ist das erste: ein roter Nightly, und statt des Logs steht morgens eine Meldung im Kanal — drei Zeilen Fehlerbild, zwei betroffene Module, ein Link auf das Ticket vom Herbst, das dieselbe Race Condition beschrieb. Ab diesem Morgen fragt im Team niemand mehr, wozu das Ding gut sein soll.

post {
  failure {
    script {
      // Letzte 400 Zeilen reichen dem Modell — der Rest ist Rauschen.
      sh 'tail -n 400 "${JENKINS_HOME}/jobs/${JOB_NAME}/builds/${BUILD_NUMBER}/log" > build-tail.log'

      // Lokaler RAG-Dienst im eigenen Netzsegment: Vektordatenbank (ChromaDB)
      // + Inferenz-Server (Ollama/vLLM). Kein Byte verlässt das Haus.
      def triage = sh(
        returnStdout: true,
        script: '''
          curl -s http://llm-gateway.build.internal/triage \
            -H "Authorization: Bearer $(cat /run/secrets/llm-token)" \
            -F "job=${JOB_NAME}" -F "build=${BUILD_NUMBER}" \
            -F "log=@build-tail.log"
        '''
      )
      def r = readJSON text: triage

      // Nur melden, nie handeln: die Entscheidung bleibt beim Team.
      slackSend channel: '#ci-linie3', message: """
        Build ${JOB_NAME} #${BUILD_NUMBER} rot — Triage:
        ${r.summary}
        Ähnliche Vorfälle: ${r.similar.collect { "${it.ticket} (${it.date})" }.join(', ')}
        Quellen: ${r.sources.join(', ')}
      """
    }
  }
}

Die Hardware ist
kleiner als gedacht.

Für Pilotprojekte und Team-Installationen genügen kompakte Systeme mit 64 bis 128 GB Unified Memory — Geräteklasse Minisforum AI X1 Pro oder GMKtec EVO-X2, ein Gehäuse, das neben den Build-Server passt und aus dem Budget einer Abteilung bezahlbar ist. Darauf laufen mittelgroße offene Modelle mit RAG für eine Gruppe von fünf bis zehn Nutzern, ohne dass jemand auf Antworten wartet.

Wächst die Nutzung, wächst die Hardware: ein GPU-Server im Rechenzentrum, dieselbe Software, dieselbe Vektordatenbank, dieselben Berechtigungen. Der Weg ist architektonisch identisch — und genau das ist der Punkt: Wer den Piloten richtig schneidet, wirft nichts weg.

Das Modell ist
der kleinste Teil.