On-Prem-KI-Coding löst nicht die Architekturfrage

KI-Coding-Agenten rücken näher an die Infrastruktur von Unternehmen heran.

Das ist wichtig.

Die aktuelle Diskussion rund um OpenAI und Dell, Codex in hybride und On-Prem-Umgebungen zu bringen, ist nicht nur eine weitere Herstellerankündigung. Sie berührt eine echte Hürde für seriöse Unternehmen: Viele Teams können proprietären Code, interne Dokumentation, kundennahen Kontext oder regulierte Arbeitsabläufe nicht einfach in öffentliche Cloud-Werkzeuge geben.

Für Banken, Industrieunternehmen, Healthcare-Anbieter, öffentliche Auftragnehmer und viele Mittelständler war das bisher eine harte Grenze für KI-unterstützte Softwareentwicklung. Das Argument war nicht immer, dass KI-Coding nutzlos sei. Das Argument war viel einfacher:

Diese Daten dürfen dort nicht hin.

Hybride und On-Prem-Bereitstellung verändern dieses Gespräch. Sie machen KI-Coding-Agenten plausibler für Umgebungen, in denen Datenresidenz, Sicherheitspolitik, Kundenverträge und internes Risikomanagement zählen.

Aber sie lösen nicht die Architekturfrage.

Im Gegenteil: Sie machen die Architekturfrage wichtiger.

Private Bereitstellung ist nicht gleich Produktionsreife

Einen KI-Coding-Agenten näher an die Unternehmensinfrastruktur zu bringen, löst eine bestimmte Problemklasse.

Es kann die Abhängigkeit von öffentlichen Cloud-Diensten reduzieren. Es kann Data Governance greifbarer machen. Es kann besser zu internen Sicherheitsrichtlinien passen. Es kann regulierten Teams ermöglichen, stärker zu kontrollieren, wo Quellcode, Logs, Prompts und Dokumente verarbeitet werden.

Das sind echte Verbesserungen.

Aber private Bereitstellung beantwortet nicht automatisch die Fragen, die entscheiden, ob KI-unterstützte Entwicklung im Alltag sicher und nützlich ist:

• Welche Repositories darf der Agent lesen?
• Welche Systeme darf er aufrufen?
• Welche Daten dürfen in Prompts oder Kontextfenster gelangen?
• Welche Aktionen brauchen menschliche Freigabe?
• Wer reviewt generierte Änderungen?
• Wie werden Sessions protokolliert?
• Wo liegen Secrets?
• Was passiert, wenn der Agent eine plausible, aber falsche Änderung macht?
• Wer verantwortet das Betriebsmodell nach dem Pilotprojekt?

Diese Fragen verschwinden nicht, weil das Werkzeug auf bevorzugter Infrastruktur läuft.

Sie wandern ins Unternehmen.

Genau deshalb sollten Gründer, CTOs und Product Owner diesen Schritt sorgfältig behandeln. Hybrides KI-Coding ist kein Freifahrtschein, Agenten durch interne Systeme laufen zu lassen. Es ist eine Chance, die Entwicklungsumgebung von Anfang an besser zu gestalten.

Der nützliche Wechsel: vom Tool-Kauf zum Systemdesign

Frühe KI-Coding-Nutzung war oft individuell.

Ein Entwickler installiert ein Werkzeug. Eine Gründerin testet einen App Builder. Ein Product Manager lässt einen Workflow skizzieren. Ein Team probiert Cursor, Claude Code, Codex-artige Agenten, Lovable, Replit oder andere Werkzeuge aus, um zu sehen, was schneller wird.

Diese Phase ist nützlich. Sie zeigt, wo KI hilft und wo sie Rauschen erzeugt.

Enterprise-Adoption ist etwas anderes.

Sobald KI-Coding in Unternehmensinfrastruktur einzieht, lautet die Frage nicht mehr: Welches Tool schreibt Code am schnellsten?

Die bessere Frage lautet:

Welches System bauen wir um KI-unterstützte Entwicklung herum?

Dieses System enthält Modell und Interface, aber auch:

• Repository-Struktur;
• Dokumentationsqualität;
• Architekturgrenzen;
• Teststrategie;
• Zugriffskontrolle;
• Code Review;
• Deployment-Gates;
• Audit Trails;
• Incident Response;
• Kostensteuerung;
• Ownership.

Der Agent ist nur ein Teil des Delivery-Systems.

Hier werden viele KI-Rollouts enttäuschend. Unternehmen kaufen Zugriff, sehen ein paar beeindruckende Demos und merken dann, dass die eigentliche Arbeit nicht Prompting ist. Die eigentliche Arbeit ist, dem Agenten den richtigen Kontext zu geben, falsche Autorität zu begrenzen, Ergebnisse zu messen und festzulegen, wo menschliches Urteil zwingend bleibt.

On-Prem- oder Hybrid-Infrastruktur reduziert diese Arbeit nicht.

Sie macht sie lohnender.

Warum das im deutschen Markt besonders relevant ist

Deutsche Unternehmen sind bei neuen Entwicklungspraktiken oft aus guten Gründen vorsichtig.

Sie arbeiten mit Kundenverträgen, Datenschutzanforderungen, Branchenregeln, Betriebsräten, Lieferantenpflichten und langlebigen operativen Prozessen. Ein Industrieunternehmen hat vielleicht Software, die Produktion, Logistik oder Qualitätssicherung berührt. Ein SaaS-Unternehmen verarbeitet Kundendaten unter strengen Vertragsbedingungen. Ein Mittelständler nutzt Systeme, die nicht für schnelllebige KI-Werkzeuge gebaut wurden, aber täglich kritisch sind.

In diesem Kontext ist “das KI-Werkzeug gibt es jetzt On-Prem” nicht das abschließende Argument.

Es ist der Beginn einer ernsthafteren Bewertung.

Für viele Teams ist die richtige Antwort abgestuft:

• öffentliche SaaS-KI-Werkzeuge für risikoarme Exploration und wegwerfbare Prototypen;
• kontrollierte Cloud-Umgebungen für normale Produktentwicklung, wo die Datenklassifizierung es erlaubt;
• hybride oder On-Prem-Setups für sensible Repositories, regulierte Workflows oder interne Systeme;
• klare Sperrzonen für bestimmte Produktionssysteme, bis Architektur, Logging und Review bereit sind.

Das ist keine Bürokratie um ihrer selbst willen.

Es ist Kategorisierung.

Nicht jedes Repository trägt dasselbe Risiko. Nicht jeder Produktbereich braucht dieselben Kontrollen. Nicht jeder Agenten-Workflow verdient dieselbe Berechtigungsstufe. Eine Marketing-Website, ein internes Dashboard, ein Billing-System und eine industrielle Integrationsschicht sollten nicht gleich behandelt werden, nur weil derselbe KI-Coding-Agent technisch an allem arbeiten kann.

Gute KI-Adoption beginnt damit, diese Unterschiede zu benennen.

Was vor einem Enterprise-Rollout entschieden werden sollte

Die praktische Arbeit beginnt, bevor das Werkzeug breit freigeschaltet wird.

Ein seriöses Team sollte mindestens sieben Dinge entscheiden.

1. Repository- und Systemgrenzen

Die erste Grenze ist einfach: Wo darf der Agent arbeiten?

Diese Frage sollte nach Risiko beantwortet werden, nicht nach Bequemlichkeit. Einige Repositories eignen sich für breite KI-unterstützte Entwicklung. Andere brauchen nur lesenden Zugriff, engere Berechtigungen oder gar keinen Agentenzugriff, bis die umgebenden Kontrollen existieren.

Ein Design-System-Paket kann zum Beispiel gut für assistiertes Refactoring geeignet sein. Ein Billing-Service braucht wahrscheinlich strengere Abläufe. Ein Datenmigrationstool kann menschliche Freigabe für jede generierte Änderung erfordern. Ein Operations-Repository braucht vielleicht Session-Logging und Trennung von normaler Feature-Arbeit.

Es geht nicht darum, KI zu blockieren.

Es geht darum, Berechtigung an Verantwortung anzupassen.

2. Kontext kuratieren

Die Qualität von KI-Coding hängt stark vom Kontext ab.

In einer privaten Umgebung ist die Versuchung groß, dem Agenten alles zu geben: alle Dokumente, alle Repos, alle Tickets, alle internen Notizen, alle Logs. Das fühlt sich mächtig an, kann aber Verwirrung, Datenabfluss innerhalb falscher Grenzen und schlechte Entscheidungen erzeugen.

Teams brauchen eine Kontextstrategie.

Nützlicher Kontext sind aktuelle Architekturentscheidungen, Coding-Standards, Domänensprache, Testbefehle, Deployment-Regeln, API-Verträge und bekannte Nicht-Ziele. Weniger nützlich sind veraltete Pläne, widersprüchliche Dokumente, alte Tickets und sensible Daten, die der Agent für die Aufgabe nicht braucht.

Besserer Kontext ist nicht immer mehr Kontext.

Besserer Kontext ist ausgewählt, aktuell und an die Aufgabe gebunden.

3. Review-Gates

KI-generierter Code sollte Review nicht überspringen, nur weil er schnell entstanden ist.

Wenn überhaupt, erhöht schnellere Generierung den Bedarf an bewusstem Review. Reviewer prüfen nicht mehr nur Syntax oder Stil. Sie prüfen, ob die Änderung zum Produkt passt, die Architektur respektiert, Randfälle behandelt und keine versteckte Komplexität erweitert.

Für risikoarme Arbeit kann Review leichtgewichtig sein. Für sensible Bereiche sollte Review strenger sein: Tests, Freigabe durch Architekturverantwortliche, Security Checks, Migrationsreview oder gestuftes Deployment.

Das Review-Modell sollte entworfen werden, bevor die Nutzung hohes Volumen erreicht.

Sonst bekommt das Team zuerst Geschwindigkeit und danach Qualitätsschulden.

4. Logging und Nachvollziehbarkeit

Enterprise-Teams müssen wissen, was passiert ist.

Dazu gehören Prompts, Tool-Aufrufe, Dateiänderungen, generierte Diffs, Freigaben, fehlgeschlagene Befehle und finale Entscheidungen. Nicht jedes Detail muss für immer gespeichert werden, aber die Organisation sollte genug Nachvollziehbarkeit haben, um praktische Fragen zu beantworten:

• Warum wurde diese Änderung gemacht?
• Welchen Kontext hat der Agent genutzt?
• Hat ein Mensch sie freigegeben?
• Welche Tests liefen?
• Welche Systeme wurden berührt?
• Wurden sensible Daten unnötig sichtbar?

Nachvollziehbarkeit ist nicht nur Compliance.

Sie ist die Grundlage dafür, den eigenen KI-Entwicklungsprozess zu debuggen.

5. Secrets und Zugangsdaten

Private Bereitstellung macht Secrets nicht automatisch sicher.

Agenten können Dateien lesen, Befehle ausführen, Umgebungsvariablen sehen, Tools aufrufen oder Konfiguration generieren. Wenn Secrets in lokalen Umgebungen, Build-Logs oder alter Dokumentation verstreut sind, kann der Agent ihnen begegnen.

Ein guter Rollout trennt Credentials vom Kontext. Er nutzt wo möglich kurzlebige Zugriffe, vermeidet breite Maschinenautorität und behandelt generierten Code, der Secrets berührt, als Hochrisiko-Arbeit.

Die Frage lautet nicht nur: Schützt der Anbieter unsere Daten?

Die Frage lautet auch: Haben wir uns vor unserer eigenen Entwicklungsumgebung geschützt?

6. Messung

KI-Coding sollte an Delivery-Ergebnissen gemessen werden, nicht an Begeisterung.

Nützliche Messgrößen sind Cycle Time, Review-Aufwand, Fehler nach Release, Nacharbeit, Testabdeckung, Lead Time für bestimmte Aufgabentypen, Wartungslast und Entwicklerzufriedenheit. Tokenverbrauch oder generierte Codezeilen können betriebliche Daten sein, sind allein aber schwache Business-Metriken.

Die besten Rollouts definieren, wo KI helfen soll:

• schnellere Prototyp-Exploration;
• vollständigere Tests;
• sichereres Refactoring;
• bessere Dokumentation;
• weniger repetitive Implementierungsarbeit;
• schnellere interne Tools;
• sauberere Migrationsplanung.

Wenn das erwartete Ergebnis nicht benannt wird, lässt sich der Rollout kaum bewerten.

7. Ownership

Jemand muss das System verantworten.

Nicht nur den Anbieter. Nicht nur die Lizenzen. Das tatsächliche Modell für KI-unterstützte Delivery.

Dazu gehören Repo-Anweisungen, Kontextpflege, Berechtigungsstufen, Incident-Reviews, Prompts und Templates, Kostenkontrolle und die Frage, ob der Workflow dem Produkt noch dient.

Ohne Ownership wird KI-Coding zu einer Sammlung von Gewohnheiten.

Mit Ownership kann es eine echte Delivery-Fähigkeit werden.

On-Prem-KI kann trotzdem schnellere technische Schulden erzeugen

Das größte Missverständnis ist, dass private Infrastruktur KI-Coding zu einem gelösten Problem macht.

Das stimmt nicht.

Ein On-Prem-Agent kann immer noch schwache Abstraktionen erzeugen. Er kann die Domäne missverstehen. Er kann unnötige Abhängigkeiten einführen. Er kann die falsche Schicht ändern. Er kann Tests schreiben, die wenig beweisen. Er kann eine Codebase schwerer wartbar machen und dabei trotzdem alle Daten im Gebäude behalten.

Dieser letzte Punkt ist wichtig.

Daten privat zu halten ist wichtig. Aber ein privates Durcheinander bleibt ein Durcheinander.

Das Geschäftsrisiko ist nicht nur Datenabfluss. Es ist auch die Entstehung von Systemen, die niemand zuverlässig betreiben, erweitern oder übergeben kann.

Deshalb wird architekturorientierte Delivery wichtiger, je näher KI an Produktionssysteme rückt. Geschwindigkeit ist nützlich, wenn sie eine klare Richtung beschleunigt. Sie ist gefährlich, wenn sie Unklarheit beschleunigt.

Ein pragmatischer Einführungspfad

Teams müssen nicht alles lösen, bevor sie KI-Coding-Werkzeuge nutzen.

Sie brauchen aber einen gestuften Pfad.

Ein sinnvoller Ansatz sieht so aus:

1. Aktuelle KI-Nutzung inventarisieren. Welche Tools werden bereits genutzt, von wem, auf welchen Repos und mit welchen Daten?
2. Repositories und Workflows klassifizieren. Risikoarme, normale und sensible Bereiche trennen.
3. Erlaubte Use Cases definieren. Klar sagen, wo KI Code, Tests, Dokumentation, Migrationen oder Betriebsskripte erzeugen darf.
4. Review-Gates entwerfen. Review-Tiefe an Produktrisiko koppeln.
5. Kontext aufräumen. Agenten aktuelle Architekturhinweise, Befehle und Grenzen geben, statt alles erreichbar zu machen.
6. Secrets und Autorität trennen. Permanente breite Credentials und unkontrollierten Systemzugriff vermeiden.
7. Ergebnisse messen. Prüfen, ob KI die Delivery-Qualität wirklich verbessert, nicht nur gefühlt schneller macht.

Erst danach wird das Deployment-Modell zur guten strategischen Frage.

Public Cloud, kontrollierte Cloud, Hybrid und On-Prem können in unterschiedlichen Teilen derselben Organisation sinnvoll sein. Der Fehler liegt darin, die Infrastrukturentscheidung für die gesamte Adoptionsstrategie zu halten.

Sie ist nur eine Schicht.

Wo McDougall Digital helfen kann

Bei McDougall Digital sehen wir diese Entwicklung als nützliches Signal.

KI-unterstützte Softwareentwicklung wird für ernsthafte Produkte realistischer, nicht weniger relevant. Aber gewinnen werden nicht die Teams, die einfach den stärksten Agenten möglichst nah an ihre Daten stellen. Gewinnen werden die Teams, die wissen, welche Arbeit der Agent tun soll, wo menschliches Urteil bleibt und welche Architekturgrenzen nicht verschwimmen dürfen.

Wir können Teams helfen:

• zu prüfen, wo KI-Coding in den aktuellen Delivery-Prozess passt;
• Prototyp-, Internal-Tool- und Kernprodukt-Workflows zu trennen;
• Repository- und Berechtigungsgrenzen zu entwerfen;
• Architekturhinweise und Kontext vorzubereiten, die Agenten sicher nutzen können;
• KI-generierte Systeme zu reviewen, bevor sie operative Abhängigkeiten werden;
• Review-, Test- und Deployment-Gates um KI-unterstützte Arbeit zu definieren;
• einen praktischen Public-, Hybrid- oder On-Prem-Einführungspfad zu wählen.

Das Ziel ist nicht, Teams zu bremsen.

Das Ziel ist, die neue Geschwindigkeit nutzbar zu machen.

Die Kernbotschaft

Hybrides und On-Prem-KI-Coding ist ein ernsthafter Schritt für Enterprise-Adoption.

Es kann Teams ermöglichen, KI-unterstützte Entwicklung für sensible Softwarearbeit zu nutzen, wo öffentliche Cloud-Werkzeuge nicht verantwortbar waren. Es kann besser zu regulierten Branchen, deutschen Markterwartungen und internen Sicherheitsrichtlinien passen.

Aber es ersetzt keine Architektur.

Es ersetzt kein Produkturteil.

Es ersetzt kein Review, keine Tests, keine Dokumentation, keine Berechtigungen und keine operative Verantwortung.

KI-Coding-Agenten werden Teil der Entwicklungsumgebung. Genau deshalb sollten Teams diese Umgebung gestalten, bevor sie sich auf sie verlassen.