Ihre IT kann jetzt Software bauen. Der Rahmen fehlt noch.

/01Individuelle KI-Entwicklung: Begriff und Abgrenzung

Mit Individueller KI-Entwicklung meinen wir etwas Bestimmtes: Eine interne IT-Abteilung ohne Entwickler baut mit einem Coding-Agenten eigene Werkzeuge — und behandelt das Ergebnis als Software, die im Haus läuft, gewartet wird und im Zweifel ausfällt. Der Agent ist ein Programm wie Claude Code, Codex, Cursor oder Aider, das ein Sprachmodell mit Zugriff auf Dateien, Terminal und Versionsverwaltung ausstattet. Es liest den Bestand, schreibt Änderungen, führt Tests aus und liefert einen Vorschlag zur Prüfung.

Was es nicht ist: kein Ersatz für ein Softwarehaus, wenn ein Produkt für Kunden entstehen soll; kein Low-Code-Baukasten, bei dem der Hersteller die Grenzen zieht; und nicht das, was unter dem Schlagwort „Vibe Coding" kursiert — Code, den niemand liest, weil er ja läuft. Genau dieser letzte Punkt ist der Unterschied. Ein Skript, das nachts Rechnungen aus dem ERP zieht, ist nach vier Wochen betriebskritisch, ob es jemand so genannt hat oder nicht. Der Agent schreibt schnell; die Frage lautet, wer dafür geradesteht.

/02Was eine kleine IT-Abteilung damit tatsächlich baut

Die Vorstellung, eine Zwei-Personen-IT würde jetzt Fachanwendungen bauen, führt in die Irre. Was entsteht, ist kleiner und nützlicher. Aus unseren Projekten kommen fünf Kategorien immer wieder:

• Skripte und Automatisierung. Benutzer anlegen und sperren, Freigaben nach Vorlage setzen, Zertifikate prüfen, Lizenzen zählen — Aufgaben, die von Hand liefen, weil niemand Zeit für das Ansible-Playbook oder das PowerShell-Skript hatte.
• Kleine Portale. Ein Formular für Hardwarebestellungen, eine Ticketübersicht für Abteilungsleiter, ein Selbstbedienungsportal für Passwort-Zurücksetzungen mit SSO. Zwanzig Seiten Code, nicht zweitausend.
• Schnittstellen. Zeiterfassung spricht nicht mit dem ERP, das ERP nicht mit dem Ticketsystem. Ein Vermittler zwischen zwei APIs, der Fehler protokolliert, ist eine Sache von Stunden.
• Auswertungen. Der Monatsbericht aus drei Exporten wird zu einer Abfrage gegen PostgreSQL und einer erzeugten Tabelle.
• Werkzeuge für die IT selbst. Eine Bestandsliste, die Proxmox-VMs mit dem Monitoring abgleicht; ein Prüfer, der CVE-Meldungen gegen die eigene Softwareliste hält.

Gemeinsam ist allen fünf: Der Bedarf war lange da, der Aufwand hat ihn verhindert. Ein Coding-Agent senkt den Aufwand so weit, dass die Rechnung kippt — und deshalb entsteht plötzlich viel Code auf einmal.

/03Was fehlt, ist nicht das Modell, sondern der Rahmen

Die Modelle sind gut genug. Das ist der Befund aus jedem Pilotprojekt, das wir begleitet haben: Der Agent liefert Code, der läuft. Was fehlt, ist alles, was ein Entwicklungsteam über Jahre um sich herum aufgebaut hat und was eine kleine IT-Abteilung noch nie brauchte. Wir zählen neun Bausteine.

Keiner dieser Bausteine ist neu. Neu ist, dass eine IT-Abteilung, die bisher Server und Arbeitsplätze betreut hat, alle neun auf einmal braucht — vor dem dritten Werkzeug, nicht danach. Die gute Nachricht: Es sind Betriebsaufgaben, keine Entwicklungsaufgaben. Die kann eine interne IT, und die kann ein Dienstleister übernehmen, ohne den Code zu kennen.

/04Git mit Review: das Fundament

Ohne Versionsverwaltung ist der Rest nicht zu haben. Pipeline, Nachweis, Wiederherstellung und Freigabe hängen alle daran, dass jede Änderung einen Zeitpunkt, einen Urheber und eine Begründung hat. Ein selbst gehostetes GitLab oder ein Forgejo leistet das — und hält den Quelltext im eigenen Netz, was bei Werkzeugen mit Zugangsdaten und Geschäftslogik kein Detail ist. Installation, Sicherung und die Frage, ab wann sich der eigene Betrieb lohnt, stehen in GitLab selbst hosten.

Der entscheidende Baustein ist nicht das Repository, sondern der Merge Request. Der Agent arbeitet auf einem eigenen Zweig und darf nicht auf den Hauptzweig schreiben. Ein Mensch liest den Unterschied, lässt die Tests laufen und gibt frei. Bei einer Zwei-Personen-IT beauftragt der eine, der andere prüft. Bei einer Ein-Personen-IT prüft der Dienstleister oder — ehrlich gesagt — dieselbe Person am nächsten Tag mit frischem Kopf. Beides ist besser als gar nicht.

Geprüft wird nicht der Stil; ein Coding-Agent schreibt lesbaren Code. Geprüft wird, ob das Werkzeug tut, was beauftragt war, und nur das: Trägt es Zugangsdaten hart ein? Schickt es Daten an einen Dienst, der nicht vorgesehen war? Läuft es bei einem Fehler weiter oder bricht es ab? Kam eine Abhängigkeit herein, die niemand kennt — dafür erzeugt die Pipeline eine Stückliste der Bestandteile. Zwanzig Minuten je Merge Request reichen, wenn die Aufgabe klein geschnitten war. Waren es zweitausend Zeilen auf einmal, war die Aufgabe falsch geschnitten.

/05Der Harness: Sandbox, Werkzeuge, Budget, Freigaben

Ein Coding-Agent, der auf dem Laptop des Administrators mit dessen Rechten läuft, kann alles, was der Administrator kann — einschließlich rm -rf auf dem falschen Pfad. Der Harness ist die Umgebung, die das verhindert, mit vier Eigenschaften:

• Sandbox. Der Agent arbeitet in einem Container oder einer Wegwerf-VM mit einer Kopie des Repositorys, ohne Zugriff auf das Produktionsnetz. Was er zerstört, ist in dreißig Sekunden neu gebaut. Bei uns ist das ein LXC-Container auf Proxmox; ein Docker-Container mit eingeschränktem Netz tut es genauso.
• Werkzeugzugriff. Ein Agent, der Auswertungen baut, braucht Lesezugriff auf eine Datenbankkopie und keinen Schreibzugriff auf das ERP. Über MCP-Server vermittelt, lässt sich der Zugriff je Werkzeug einzeln erlauben und protokollieren.
• Budget. Token je Aufgabe, Aufgaben je Tag, Euro je Monat. Ein Agent in einer Schleife verbraucht sonst über Nacht das Monatsbudget.
• Freigaben. Merge auf den Hauptzweig, Ausrollen nach Produktion, Änderungen an Zugangsdaten laufen nie ohne Mensch. Das ist Human-in-the-Loop — als Liste konkreter Schritte, nicht als Prinzip.

Der Harness beantwortet auch die Frage nach der Identität: Der Agent bekommt eine eigene Kennung mit knapp geschnittenen Rechten — nicht das Konto des Administrators, nicht einen geteilten Dienstnutzer. Sonst ist die Auditspur nichts wert. Und was per Prompt Injection über eine gelesene Datei in den Agenten gelangt, richtet in einer Sandbox mit begrenztem Werkzeugzugriff wenig an, auf dem Admin-Laptop dagegen viel.

/06Der Ablauf von der Aufgabe bis zum Deploy

Konkret ist der Rahmen ein Ablauf von acht Schritten, der nach dem dritten Werkzeug zur Routine wird. So sieht er bei uns aus, wenn ein Kunde eine Auswertung beauftragt, die Proxmox-Bestand und Monitoring abgleicht:

# 1  Aufgabe als Issue, klein geschnitten
$ glab issue create -t "Bestandsabgleich Proxmox vs. Monitoring" \
    -d "Liste VMs ohne Monitoring-Ziel. Nur lesen. Ausgabe CSV."

# 2  Eigener Zweig, Sandbox-Container mit Repo-Kopie
$ git switch -c tools/bestandsabgleich
$ pct start 210 && pct exec 210 -- git pull

# 3  Agent baut — in der Sandbox, mit Budget und Werkzeugliste
$ pct exec 210 -- claude -p "Issue #47 umsetzen. Tests schreiben." \
    --allowedTools "Read,Edit,Bash(pytest *)" --max-budget-usd 4

# 4  Tests lokal
$ pct exec 210 -- pytest -q
........                                              [100%]

# 5  Push und Merge Request — nie direkt auf main
$ git push -u origin tools/bestandsabgleich
$ glab mr create --fill --reviewer kollege

# 6  Pipeline: Lint, Tests, SBOM, Secret-Scan — Merge nur bei Gruen
# 7  Review durch einen Menschen, Freigabe im Merge Request
# 8  Ausrollen nach Staging, dann Produktion — per Pipeline, nicht per Hand
$ glab ci run --branch main -v ENV=staging

Wichtiger als die Befehle sind drei Regeln: Die Aufgabe ist ein Issue mit einer Zeile Auftrag und einer Zeile Grenze („nur lesen"). Die Freigabe ist ein Schritt mit Namen, nicht ein Gefühl. Nichts landet per Hand auf einem Produktionsserver. Die Werkzeuge dahinter sind austauschbar.

Die vier US-Dollar Budget in Schritt 3 sind ein Beispiel: Für eine Stunde Arbeit mit Claude Opus 5 bei 50.000 Eingabe- und 15.000 Ausgabe-Token rechnet Anthropic selbst mit rund 0,71 US-Dollar, Laufzeitgebühr des gehosteten Agenten eingeschlossen. Schwere Umbauten brauchen das Zehnfache. Messen Sie zwei Wochen, dann setzen Sie die Grenze.

/07Lokale Modelle: wann sie für Coding reichen

Die Frage nach dem lokalen Modell stellt sich aus einem Grund, der nichts mit Kosten zu tun hat: Der Agent liest, was er bearbeiten soll. Bei einem Skript für die Benutzerverwaltung sind das Active-Directory-Strukturen, bei einer ERP-Schnittstelle Kundendaten und Preise, bei einem Monitoring-Werkzeug Hostnamen, Netzpläne und Zugangswege. All das geht als Kontext an das Modell — und bei einem API-Anbieter an dessen Server.

Ein Open-Weight-Modell auf eigener Hardware ändert das: Kein Byte verlässt das Haus. Die Auswahl hat sich 2026 verbreitert; was im September 2026 für Coding in Frage kommt, sortiert nach der Hardware, die es braucht (Parameterzahlen laut Modellkarten, Speicherbedarf als Größenordnung bei 4-Bit-Quantisierung):

Für eine IT-Abteilung mit zwei bis drei Leuten zählen die ersten fünf Zeilen. Qwen3-Coder-30B-A3B und gpt-oss-20b sind Mixture-of-Experts-Modelle: viele Parameter auf der Karte, wenige je Token aktiv — deshalb antworten sie auf einer Karte schnell genug, um einen Agenten zu treiben. Devstral, Gemma 4 31B und Qwen3.8-27B sind dichte Modelle: bei gleicher Parameterzahl langsamer, dafür mit weniger Ausreißern in der Qualität. Betrieben werden sie alle mit vLLM oder, für den Einstieg auf einer Arbeitsstation, mit Ollama auf Basis von llama.cpp und quantisierten GGUF-Gewichten. Die letzte Tabellenzeile — GLM, DeepSeek, Kimi — ist die Klasse, mit der Anbieter in Benchmarks gegen die Frontier-Modelle antreten; sie braucht einen Server mit vier bis acht Rechenzentrumskarten und ist damit eine andere Preislage als die GPU-Rechnung in Abschnitt /08.

Zwei Einschränkungen zu dieser Liste: Erstens altert sie schnell — allein zwischen April und August 2026 kamen Gemma 4, Qwen3.5, Qwen3.8, GLM-5.2, DeepSeek V4 und Kimi K3 heraus. Zweitens sind veröffentlichte Benchmark-Werte meist Herstellerangaben; wir nennen sie hier bewusst nicht, weil sie über Ihre Aufgaben wenig aussagen.

Wo die Grenze liegt

Ehrlich: Für die Aufgaben aus Abschnitt /02 reicht ein Modell dieser Klasse. Es schreibt sauberen Python- und PowerShell-Code, versteht ein Repository mit fünfzig Dateien und hält sich an Anweisungen. Was es nicht so gut kann wie ein Frontier-Modell: eine Codebasis mit tausend Dateien überblicken, einen Fehler finden, der sich über fünf Module verteilt, einen Umbau drei Schritte vorausplanen. Dort bricht es öfter ab oder liefert eine Lösung, die nur den Test besteht. Belastbare Zahlen liefert nur ein Versuch mit Ihren eigenen Aufgaben — Benchmarks messen etwas anderes als Ihr Repository.

Modellwahl, Speicherbedarf und Durchsatz im Betrieb mit vLLM stehen in unserem Deep Dive zu On-Premise-KI mit vLLM.

/08Lokal, API oder hybrid: die Rechnung

Die Kosten sind weniger eindeutig, als beide Lager behaupten. Die Grundlage haben wir in einem eigenen Artikel offengelegt: Eine RTX PRO 6000 Blackwell samt Server, Strom und Wartung kostet über vier Jahre rund 642 Euro im Monat — Anschaffung 22.990 Euro, Laufzeit 48 Monate, 300 Watt im Mittel bei 17,2 Cent je Kilowattstunde. Für die Modelle aus Abschnitt /07 ist diese Karte mehr als reichlich.

Dagegen steht der Tokenpreis: Claude Sonnet 5 kostet über die API 2 US-Dollar je Million Eingabe-Token und 10 US-Dollar je Million Ausgabe-Token, Claude Opus 5 das Zweieinhalbfache, Claude Haiku 4.5 die Hälfte. Eine IT-Abteilung, die zehn Aufgaben am Tag nach der Beispielrechnung aus Abschnitt /06 beauftragt, liegt deutlich unter 200 US-Dollar im Monat.

Rein nach Kosten gewinnt die API, solange das Volumen klein ist — und bei einer kleinen IT-Abteilung ist es klein. Die eigene Karte rechnet sich nach unserer Beispielrechnung erst ab rund 178 Millionen Token im Monat gegen Sonnet 5, und so viel Code schreibt niemand mit zwei Leuten. Wer trotzdem lokal fährt, tut es wegen der Daten, nicht wegen des Geldes. Das ist ein legitimer Grund; er sollte nur nicht als Kostenargument verkleidet werden.

Die Hybridform löst das auf: Ein lokales Modell übernimmt die Routine und sieht den vollen Kontext. Für schwere Aufgaben geht ein bereinigter Auftrag — ohne Kundendaten, ohne Zugangsdaten, mit anonymisierten Beispielen — an das Frontier-Modell. Der Harness entscheidet nach Datenklasse, welches Modell eine Aufgabe bekommt. Das ist die Form, die wir den meisten Betrieben mit Kundendaten im Code empfehlen.

/09Nach dem Merge: Betrieb, Sicherung, Nachweis

Der Merge ist nicht das Ende, sondern der Übergang: Ab jetzt ist das Werkzeug Betrieb — nach demselben Standard wie jeder andere Dienst im Haus, nicht mit einer Sonderbehandlung für KI-erzeugten Code.

Betrieb. Jedes Werkzeug läuft als Container mit Gesundheitsendpunkt, schreibt Logs in ein zentrales Ziel und liefert Metriken an Prometheus. Ein nächtliches Skript, das seit drei Tagen nicht mehr läuft, löst einen Alarm aus — nicht die Buchhaltung, die sich wundert.

Sicherung. Das Repository ist der Quellcode, aber nicht der einzige Zustand. Die Datenbank des Portals, die Konfiguration im Tresor, das Container-Image mit seiner Abhängigkeitsliste — all das gehört in die Sicherung, und die Wiederherstellung gehört geprobt. Ein Werkzeug, das sich aus dem Repository in einer Stunde neu aufbauen lässt, braucht keinen Notfallplan; eines, dessen Datenbank nur auf einem Server lebt, braucht ihn dringend.

Nachweis und Datenschutz. Für ISO 27001, NIS2 und die DSGVO zählt, was belegbar ist. Der Rahmen liefert die Belege nebenbei: wer beauftragt hat, welches Modell geschrieben hat, wer freigegeben hat, wann es in Betrieb ging. Dazu ein Inventar der Werkzeuge mit Zweck, Datenklasse und Verantwortlichem — eine Tabelle, kein Projekt. Gehen Daten an einen API-Anbieter, braucht es einen Auftragsverarbeitungsvertrag und eine Entscheidung, welche Datenklassen hinausdürfen. Der EU AI Act spielt für interne Verwaltungswerkzeuge in aller Regel keine Rolle; er wird relevant, sobald ein Werkzeug Entscheidungen über Personen trifft. Wie Agenten ohne diesen Rahmen zur Schatten-KI werden, steht im Artikel zur neuen Angriffsfläche durch KI-Agenten.

/10Wo es hakt: Grenzen und Fallstricke

Die Versprechen der Werkzeughersteller enden dort, wo der Betrieb beginnt. Fünf Fallstricke sehen wir regelmäßig.

• Der Agent liefert, was er versteht — nicht, was gemeint war. „Bereinige die inaktiven Benutzer" ist für einen Menschen eindeutig und für einen Agenten eine Definition mit Spielraum. Jede Aufgabe braucht eine Zeile Grenze; die Zeit dafür ist die eigentliche Arbeit.
• Tests, die den Code bestätigen statt prüfen. Ein Agent, der Code und Tests zugleich schreibt, schreibt gern Tests, die genau das prüfen, was der Code tut. Der Review muss die Tests lesen, nicht nur die grüne Pipeline.
• Abhängigkeiten aus dem Nichts. Der Agent zieht ein Paket herein, weil es die Aufgabe erleichtert. Drei Monate später hat das Paket eine CVE, und niemand weiß, dass es im Haus läuft. Stückliste in der Pipeline und ein Patch-Prozess für die eigenen Werkzeuge sind Pflicht.
• Der Wildwuchs. Wenn Bauen billig ist, wird viel gebaut. Nach einem Jahr laufen dreißig Werkzeuge, und der Kollege, der sie beauftragt hat, ist in Elternzeit. Ohne Inventar und Verantwortlichen je Werkzeug wird das zur Altlast — schneller als bei gekaufter Software.
• Das lokale Modell wird zum Betriebsobjekt. Ein GPU-Server braucht Treiberpflege, Modellupdates, Monitoring und eine Antwort auf die Frage, was passiert, wenn die Karte ausfällt.

Dazu kommt eine Grenze, die keine Technik löst: Ein Werkzeug, das Rechnungen verteilt oder Benutzer sperrt, braucht einen Menschen, der dafür geradesteht — auch wenn der Code von einem Agenten stammt. Wer wird angerufen, wenn es nachts um zwei steht?

/11Die Entscheidung: wann sich das lohnt — und wann nicht

Es lohnt sich, wenn drei Dinge zusammenkommen: eine Liste von Aufgaben, die seit Jahren von Hand laufen; mindestens eine Person in der IT, die ein Repository lesen und einen Merge Request beurteilen kann — nicht schreiben, lesen; und die Bereitschaft, den Rahmen vor dem dritten Werkzeug zu bauen. Die meisten KMU mit zwei bis fünf Köpfen in der IT erfüllen die ersten beiden Bedingungen; an der dritten scheitert es, wenn der Rahmen als Bremse verstanden wird statt als Voraussetzung dafür, dass das Gebaute nach einem Jahr noch jemandem gehört.

Es lohnt sich nicht, wenn das Ergebnis eine Fachanwendung mit Kunden am anderen Ende sein soll — dafür gibt es Softwarehäuser. Es lohnt sich nicht, wenn niemand im Haus Code lesen will; dann ist ein Dienstleister die bessere Adresse, der den Code mit Ihnen liest statt ihn Ihnen abzunehmen. Und es lohnt sich nicht als Kostenprojekt: Der Gewinn liegt in Werkzeugen, die es sonst nie gegeben hätte, nicht in einer gestrichenen Stelle.

Was wir empfehlen

Beginnen Sie mit der API und einem Frontier-Modell, aber mit dem Rahmen ab Tag eins: Git mit Merge Request, Sandbox, Budget, Freigabeliste. Bauen Sie das Skript, das ein Kollege ohnehin jede Woche ausführt. Messen Sie zwei Wochen lang Token und Zeit. Dann entscheiden Sie über das lokale Modell — nach der Frage, welche Daten der Agent gesehen hat, nicht nach der Rechnung. Stehen dort Kundendaten, Netzpläne oder Zugangswege, ist der Hybridbetrieb der nächste Schritt. Wenn nicht, bleibt die API die richtige Wahl, und das Geld gehört in den Rahmen.

HostSpezial betreibt seit 2010 Infrastruktur für den Mittelstand im Rechenzentrum Coburg mit Ausweichstandort Neustadt, ISO/IEC 27001:2024 zertifiziert. Den Rahmen bieten wir als betriebenen Stack an oder bauen ihn in Ihrer Umgebung auf; den Code schreiben Sie mit Ihrem Agenten selbst.

/12Häufige Fragen