Individuelle Software warten und betreiben: Was nach dem Launch nötig ist

Der häufigste Moment, in dem individuelle Software in KMU beginnt, Vertrauen zu verlieren, ist nicht der Launch. Es ist der erste ungeplante Ausfall drei Monate später, bei dem sich herausstellt: Niemand fühlt sich zuständig, niemand hat die letzten Änderungen dokumentiert, und der ursprüngliche Entwickler ist im nächsten Projekt. Das Projektbudget war für „Bauen bis produktiv” kalkuliert – Wartung und Betrieb standen nicht auf dem Plan, weil sie beim Launch abstrakt wirkten.

Dieser Artikel gehört zu unserem Themen-Cluster KI-Softwareentwicklung und beantwortet, was nach dem Launch tatsächlich an Aufgaben entsteht, wie du Updates und Abhängigkeiten planst, welche SLAs realistisch sind, wie Monitoring funktioniert und wie du Weiterentwicklung priorisierst, ohne dass sie im Tagesgeschäft untergeht. Er richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die eine individuelle Software oder ein internes KI-Tool bereits im Einsatz haben oder kurz davor stehen.

Das Problem: Der Launch ist der Anfang, nicht das Ziel

In Projektgesprächen erlebe ich das immer wieder als blinden Fleck: Die Beauftragung dreht sich fast ausschließlich um den Bau – Anforderungen, Design, Entwicklung, Go-Live. Was danach passiert, wird selten mitgedacht, obwohl Software ab dem ersten produktiven Tag drei Dingen ausgesetzt ist, die sie unweigerlich verändern werden: Fehler, die erst unter echter Last sichtbar werden, eine Umgebung, die sich weiterentwickelt (Betriebssysteme, Bibliotheken, APIs, bei KI-Bausteinen auch die zugrunde liegenden Modelle), und Nutzer:innen, deren Anforderungen sich ändern, sobald sie das Werkzeug wirklich benutzen.

Das ist kein Sonderfall individueller Software – es ist ihr Normalzustand. Der Unterschied zu Standardsoftware ist nur, dass bei einem SaaS-Produkt ein Anbieter genau dafür bezahlt wird, diese drei Kräfte zu managen. Bei individueller Software liegt diese Verantwortung beim Auftraggeber, ob intern oder extern organisiert – und wird sie nicht bewusst zugewiesen, liegt sie faktisch bei niemandem.

Die Folgen davon sehe ich in der Praxis in drei wiederkehrenden Mustern: Erstens wächst technische Schuld unbemerkt, weil kleine Korrekturen ohne Übersicht „irgendwie” gemacht werden. Zweitens bleiben Sicherheitslücken offen, weil niemand systematisch prüft, ob eine verwendete Bibliothek eine bekannte Schwachstelle hat. Drittens verliert das Tool an Akzeptanz, weil naheliegende Verbesserungswünsche der Nutzer:innen nirgends landen und nie umgesetzt werden – bis das Tool als „das alte System” gilt, obwohl es erst ein Jahr alt ist.

Begriffe kurz geklärt: Wartung ist nicht gleich Betrieb

Zwei Begriffe werden in Gesprächen oft synonym verwendet, sind aber unterschiedliche Aufgabenfelder mit unterschiedlichen Verantwortlichkeiten:

• Betrieb ist die Grundversorgung: Hosting, Verfügbarkeit, Backups, Sicherheits-Patches, Überwachung. Betrieb sorgt dafür, dass die Software läuft, so wie sie ist.
• Wartung verändert die Software: Fehler beheben, an geänderte Umgebungen anpassen, verbessern, latente Probleme vorbeugend beseitigen. Der internationale Standard ISO/IEC/IEEE 14764 unterscheidet dafür vier Kategorien – korrektiv, adaptiv, perfektiv und präventiv –, auf die dieser Artikel im nächsten Abschnitt eingeht.
• Weiterentwicklung (manchmal als eigene Kategorie geführt, hier bewusst getrennt von reiner Wartung behandelt) ist der Ausbau um neue Funktionen, die über den ursprünglichen Auftrag hinausgehen. Der Unterschied zur perfektiven Wartung ist graduell, aber wichtig für Budgetierung: Wartung hält das Versprochene am Laufen, Weiterentwicklung erweitert es.

Diese Trennung ist mehr als Begriffsklauberei. Wer Betrieb, Wartung und Weiterentwicklung in einen Topf wirft, hat am Jahresende keine Chance zu erklären, wofür das Wartungsbudget tatsächlich verbraucht wurde – und keine Grundlage, um für das nächste Jahr realistisch zu planen.

Welche Aufgaben entstehen?

Nach dem Standard ISO/IEC/IEEE 14764 lassen sich Wartungsaufgaben in vier Kategorien einordnen, die sich in der Praxis gut auf individuelle KMU-Software übertragen lassen:

Kategorie	Definition (ISO/IEC 14764)	Typisches Beispiel in KMU-Software	Wer stößt es an
Korrektiv	Fehler beheben, der eine Anforderung nicht erfüllt	Ein Formular speichert unter bestimmten Eingaben nicht korrekt	Meldung durch Nutzer:in oder Monitoring
Adaptiv	Anpassung an eine geänderte Umgebung	Ein externer API-Anbieter ändert sein Schema, ein Browser-Update bricht ein Feature	Ankündigung des Anbieters oder Fehlerhäufung
Perfektiv	Verbesserung von Leistung, Bedienbarkeit oder Wartbarkeit	Eine häufig genutzte Ansicht lädt spürbar langsam, der Code wird vor der nächsten Erweiterung aufgeräumt	Nutzer-Feedback oder technische Analyse
Präventiv	Latente Probleme beheben, bevor sie im Betrieb auftreten	Eine veraltete Bibliothek mit bekannter Sicherheitslücke wird aktualisiert, bevor sie ausgenutzt wird	Systematische Prüfung, nicht Zufall

Eigene Übersetzung der ISO/IEC/IEEE-14764-Kategorien in KMU-Praxisbeispiele, Philogic Labs.

Dazu kommt, außerhalb der reinen Wartungsdefinition, der laufende Betrieb: Hosting und Infrastruktur bereitstellen, Backups fahren und regelmäßig auf Wiederherstellbarkeit prüfen, Zugriffe und Berechtigungen pflegen, sowie – bei Software mit KI-Baustein – die Qualität der Modellausgaben laufend beobachten, weil sich diese ändern kann, ohne dass am eigenen Code etwas verändert wurde (etwa nach einem Modell-Update des Anbieters).

Für Software mit KI-Komponenten kommt in bestimmten Fällen eine fünfte, regulatorische Dimension hinzu: Für Hochrisiko-KI-Systeme verlangt Artikel 72 des EU AI Act ein dokumentiertes Post-Market-Monitoring, das aktiv und systematisch Daten zur Systemleistung über die gesamte Lebensdauer sammelt und auswertet – diese Pflicht trifft primär Anbieter (Provider) solcher Systeme, gilt ab dem 2. August 2026 und ist in den meisten KMU-Anwendungsfällen (kein Hochrisiko-System) nicht direkt einschlägig, aber ein nützlicher Maßstab für gute Praxis. Stand Juli 2026, keine Rechtsberatung – bei Unklarheit zur Einstufung gehört die Prüfung zu Datenschutz- oder Rechtsberatung.

Wie plant man Updates und Abhängigkeiten?

Jede individuelle Software hat eine unsichtbare Liste an Dingen, von denen sie abhängt und die sie selbst nicht kontrolliert: die Programmiersprache und ihre Version, verwendete Bibliotheken und Frameworks, das Betriebssystem oder die Cloud-Plattform, externe APIs und – zunehmend häufig – KI-Modelle von Drittanbietern. Jede dieser Abhängigkeiten wird irgendwann aktualisiert, verändert oder abgekündigt, unabhängig davon, ob im eigenen Projekt gerade Kapazität dafür ist.

In meiner Praxis hat sich ein einfaches Vorgehen bewährt, das ohne aufwändiges Tooling auskommt:

1. Abhängigkeiten inventarisieren. Eine schlichte Liste aller wesentlichen Bausteine mit aktueller Version reicht als Start – die meisten modernen Entwicklungsumgebungen können das automatisiert erzeugen.
2. Kritikalität einstufen. Was passiert, wenn diese Komponente ausfällt oder eine Sicherheitslücke bekannt wird? Kern-Abhängigkeiten (z. B. das Framework, auf dem alles aufbaut) bekommen engere Prüfintervalle als Randkomponenten.
3. Update-Rhythmus festlegen. Sicherheitsrelevante Updates bekommen eine feste, kurze Reaktionsfrist – üblich sind wenige Tage bis maximal wenige Wochen, abhängig vom Schweregrad. Funktionale Updates laufen in planbaren Zyklen, etwa quartalsweise, statt einzeln und ungeplant.
4. Testabdeckung sicherstellen, bevor du überhaupt Abhängigkeiten regelmäßig aktualisierst. Ohne automatisierte Tests wird jedes Update zum Blindflug, und Teams beginnen, Updates aus Angst vor Regressionen aufzuschieben – bis mehrere Versionen auf einmal fällig sind und die Umstellung zum Großprojekt wird. Das ist der häufigste Grund, warum „wir aktualisieren später gesammelt” am Ende teurer ist als kontinuierliches Pflegen.

Besonders relevant bei KI-Bausteinen: Wenn ein Anbieter ein zugrunde liegendes Sprachmodell aktualisiert oder abkündigt, ändert sich unter Umständen das Verhalten der eigenen Software, ohne dass eine Zeile eigenen Codes geändert wurde. Diese Abhängigkeit gehört in dieselbe Inventarliste wie technische Bibliotheken – mit der Besonderheit, dass hier nicht nur Funktionsfähigkeit, sondern auch Ausgabequalität geprüft werden muss (dazu mehr im Abschnitt Monitoring).

Welche SLAs sind sinnvoll?

Ein Service Level Agreement (SLA) ist zunächst nichts anderes als eine schriftliche, überprüfbare Zusage: Wie schnell reagieren wir, wie schnell stellen wir wieder her, und was passiert, wenn wir das nicht schaffen? Für die meisten individuellen KMU-Lösungen ist eine pauschale Verfügbarkeitszusage – „99,9 % Uptime” – weniger hilfreich, als sie klingt: Sie sagt wenig darüber, wie schnell auf ein konkretes Problem reagiert wird, und eine hohe Prozentzahl ohne Betriebsressourcen dahinter ist ein Versprechen ohne Substanz.

Praktikabler ist eine Abstufung nach Schweregrad. Diese eigene Matrix zeigt ein typisches, aber anpassbares Grundgerüst für individuelle KMU-Software:

Schweregrad	Beispiel	Typische Reaktionszeit	Typische Wiederherstellungszeit
Kritisch	System komplett nicht erreichbar, Datenverlust droht	Innerhalb weniger Stunden, auch außerhalb der Kernarbeitszeit bei geschäftskritischen Systemen	So schnell wie möglich, mit klarem Eskalationsweg
Hoch	Kernfunktion gestört, Umgehung nicht möglich	Innerhalb eines Arbeitstages	Innerhalb weniger Arbeitstage
Mittel	Teilfunktion gestört, Umgehung vorhanden	Innerhalb weniger Arbeitstage	Im nächsten planbaren Update-Zyklus
Niedrig / Verbesserungswunsch	Kosmetischer Fehler, Komfortfunktion fehlt	Kein festes SLA	Landet priorisiert im Weiterentwicklungs-Backlog

Eigenes SLA-Raster Philogic Labs, als Ausgangspunkt für die individuelle Abstimmung mit Betriebsgröße und Budget.

Die konkreten Zeitwerte hängen stark von Betriebsgröße, Budget und tatsächlicher Geschäftskritikalität ab – ein internes Reporting-Tool für zwei Personen braucht ein anderes SLA als ein kundenzugängliches Bestellsystem. Wichtiger als die exakte Zahl ist, dass drei Dinge schriftlich und für alle Beteiligten verständlich festgehalten sind: wer meldet ein Problem wie, wer reagiert in welcher Frist, und was passiert, wenn die Frist verstreicht (Eskalation an wen?). Ein SLA, das nur auf Papier existiert, aber nie gegen echte Vorfälle geprüft wurde, ist keine verlässliche Zusage – nur ein gutes Gefühl.

Wie funktioniert Monitoring?

Monitoring beantwortet eine einfache, aber entscheidende Frage: Woher weißt du, dass etwas nicht stimmt, bevor eine Nutzerin oder ein Kunde es dir meldet? Ohne Monitoring ist jede Störung ein Zufallsfund.

Aus der Praxis großer verteilter Systeme – dokumentiert im SRE-Book von Google – lassen sich vier Signale ableiten, die sich auch auf kleinere individuelle Software gut übertragen lassen:

• Latenz: Wie lange dauert eine typische Anfrage oder Aktion? Wichtig ist, erfolgreiche und fehlgeschlagene Anfragen getrennt zu betrachten – ein schneller Fehler verschleiert sonst ein langsames, aber „erfolgreiches” Problem.
• Traffic: Wie viel Last liegt gerade an – Anzahl Anfragen, aktive Nutzer:innen, verarbeitete Vorgänge? Ohne diese Referenzgröße lassen sich andere Signale schwer einordnen.
• Fehler: Wie hoch ist der Anteil fehlgeschlagener Vorgänge – explizit (Fehlermeldungen) und implizit (technisch „erfolgreiche” Antwort mit falschem Inhalt)?
• Sättigung: Wie ausgelastet sind die knappsten Ressourcen – Rechenleistung, Speicher, Warteschlangen? Systeme verschlechtern sich häufig schon deutlich vor 100 % Auslastung.

Für Software mit KI-Baustein kommt ein fünftes, eigenständiges Signal dazu, das die vier technischen Signale nicht erfassen: die Qualität der Modellausgaben gegen eine vorher festgelegte Testmenge realer Fälle. Ein System kann technisch fehlerfrei laufen – schnell, verfügbar, ohne Server-Fehler – und trotzdem zunehmend schlechtere oder unpassendere Antworten liefern, etwa nach einer stillen Modelländerung beim Anbieter. Genau diese Lücke adressiert der Post-Market-Monitoring-Gedanke aus Artikel 72 des EU AI Act für Hochrisiko-Systeme: laufende, dokumentierte Erfassung der tatsächlichen Systemleistung statt einmaliger Abnahme beim Launch. Für die meisten KMU-Anwendungsfälle ist das keine Rechtspflicht, aber eine sinnvolle Praxis, unabhängig von der Risikoeinstufung.

Praktisch reicht für den Einstieg ein einfaches Grundgerüst: automatisierte Warnungen bei Fehlerhäufung und Ausfall, ein regelmäßiger Blick auf Auslastungstrends (nicht erst, wenn die Ressourcen knapp werden), und bei KI-Bausteinen eine feste Stichprobe, die periodisch gegen die Testmenge geprüft wird. Kein KMU braucht dafür von Anfang an ein aufwändiges Observability-Setup – wichtig ist, überhaupt anzufangen und die Abdeckung mit wachsender Kritikalität der Software auszubauen.

Wie priorisiert man Weiterentwicklung?

Der häufigste Grund, warum Weiterentwicklung in der Praxis ins Stocken gerät, ist keine fehlende Idee, sondern ein fehlendes Budget dafür, das von der Pflichtwartung getrennt ist. Wenn Fehlerbehebung und neue Funktionen aus demselben Topf und vom selben kleinen Team bedient werden, gewinnt akute Wartung fast immer – zu Recht, denn ein Systemausfall ist dringlicher als eine Komfortfunktion. Das Problem entsteht, wenn das strukturell dazu führt, dass Weiterentwicklung nie an die Reihe kommt.

Sinnvoll ist deshalb eine klare Trennung in der Planung, nicht zwingend in der Organisation:

• Pflichtkanal: Korrektive, adaptive und präventive Wartung – hat definitionsgemäß Vorrang, läuft kontinuierlich, wird nach dem SLA-Raster oben priorisiert.
• Entwicklungskanal: Perfektive Verbesserungen und echte Weiterentwicklung – wird in eigenen, planbaren Zyklen bewertet, mit festem, wenn auch bescheidenem Zeitbudget, das nicht regelmäßig für Notfälle geplündert wird.

Für die Priorisierung innerhalb des Entwicklungskanals genügt ein einfaches Raster, das Nutzen gegen Aufwand stellt:

Nutzen \ Aufwand	Gering	Hoch
Hoch	Sofort einplanen – bester Hebel	Für nächsten Zyklus vormerken, Aufwand vorher genauer schätzen
Gering	Bei Kapazität mitnehmen, kein Grund zur Eile	Zurückstellen oder verwerfen

Eigenes Priorisierungsraster Philogic Labs für den Entwicklungskanal, angelehnt an gängige Nutzen-Aufwand-Bewertung.

Zwei Praxisregeln ergänzen das Raster: Erstens sammle Verbesserungswünsche zentral an einem Ort, den Nutzer:innen kennen – ein verstreutes „mal jemandem sagen” führt dazu, dass gute Ideen verloren gehen, bevor sie überhaupt bewertet werden. Zweitens kommuniziere Entscheidungen zurück, auch negative. Ein Wunsch, der kommentarlos im Nichts verschwindet, entmutigt mehr als eine ehrliche Absage mit Begründung.

Umsetzung: So baust du Wartung und Betrieb praktisch auf

Aus eigenen Projekten hat sich diese Reihenfolge bewährt, unabhängig davon, ob Wartung intern oder extern organisiert wird:

1. Verantwortung schriftlich benennen, bevor der Launch stattfindet, nicht danach. Eine Person oder ein kleines Team muss wissen, dass Betrieb und Wartung zu ihren Aufgaben gehören – inklusive realem Zeitbudget dafür.
2. Abhängigkeiten inventarisieren und Update-Rhythmen festlegen, wie oben beschrieben.
3. SLA-Raster gemeinsam mit dem Fachbereich festlegen, nicht rein technisch – die Fachseite kennt die tatsächliche Geschäftskritikalität besser als die Technik allein.
4. Basis-Monitoring einrichten, bevor der erste Vorfall zeigt, dass es fehlt. Die vier Golden Signals als Ausgangspunkt reichen für den Start.
5. Melde- und Priorisierungskanal für Nutzer:innen etablieren, getrennt nach Fehlermeldung und Verbesserungswunsch, damit beides unterschiedlich behandelt werden kann.
6. Wartungs- und Entwicklungsbudget getrennt planen, damit Weiterentwicklung nicht strukturell verdrängt wird.

Wenn unklar ist, wie viel Betriebsaufwand eine konkrete Architektur realistisch erzeugt oder ob eine bestehende Lösung überhaupt sinnvoll wartbar ist, lässt sich das im Rahmen unserer KI-Beratung einschätzen – oder direkt in einem unverbindlichen Erstgespräch klären. Scope- und Betriebsfragen bei individueller Software und KI-Bausteinen sind Teil unseres Tagesgeschäfts. Wo intern Kompetenz für laufenden Betrieb und Qualitätsprüfung aufgebaut werden soll, sind gezielte Schulungen für das verantwortliche Team oft der schnellere Weg als externe Dauerbetreuung für jede Kleinigkeit.

Risiken und Grenzen

• Ein SLA ohne Ressourcen dahinter ist ein Risiko, kein Schutz. Eine schnelle Reaktionszeit zuzusagen, ohne die Kapazität dafür zu haben, erzeugt beim ersten ernsten Vorfall mehr Vertrauensschaden als ein realistisches, aber eingehaltenes SLA.
• Monitoring ersetzt kein Verständnis des Systems. Alarme ohne jemanden, der sie versteht und einordnen kann, führen entweder zu Ignorieren oder zu Alarmmüdigkeit – beides macht das Monitoring wirkungslos.
• KI-Ausgabequalität kann sich unbemerkt ändern, ohne dass am eigenen Code etwas geändert wurde. Wer das nicht laufend prüft, merkt eine schleichende Verschlechterung oft erst, wenn Nutzer:innen sich beschweren.
• Regulatorische Einstufung ist im Zweifel keine Selbsteinschätzung. Ob eine konkrete KI-Software als Hochrisiko-System im Sinn des EU AI Act gilt und welche Pflichten daraus folgen, ist eine Rechtsfrage, die im Einzelfall zu klären ist – dieser Artikel ersetzt keine Rechtsberatung. Stand Juli 2026.
• Nicht jede Software braucht denselben Aufwand. Ein internes Tool mit wenigen Nutzer:innen und geringem Schaden im Fehlerfall rechtfertigt kein Enterprise-Betriebsmodell. Die Kunst liegt darin, den Aufwand proportional zur tatsächlichen Kritikalität zu wählen – nicht maximal, aber auch nicht bei null.

Kosten: grobe Bandbreiten mit Annahmen

Belastbare pauschale Zahlen für „Wartung und Betrieb” gibt es nicht seriös – zu unterschiedlich sind Systemgröße, Kritikalität und gewählter Aufwand. Als grobe Orientierung aus eigener Projektpraxis, jeweils mit den Annahmen, unter denen sie gilt:

• Laufender Betrieb (Hosting, Basis-Monitoring, Backups): Für Standard-Cloud-Infrastruktur ohne besondere Zertifizierungsanforderungen bewegt sich dieser Block meist im niedrigen bis mittleren dreistelligen Eurobereich pro Monat – abhängig von Nutzerzahl, Datenmenge und Infrastrukturwahl.
• Regelmäßige Wartung (korrektiv, adaptiv, präventiv): Als grobe Faustregel aus meiner Praxis solltest du für aktiv genutzte individuelle Software mit einem wiederkehrenden Zeitbudget im niedrigen einstelligen Prozentbereich des ursprünglichen Entwicklungsaufwands pro Jahr rechnen – als Ausgangspunkt, nicht als feste Zusage, da Umfang und Systemalter stark variieren.
• Weiterentwicklung: Wird separat budgetiert, typischerweise in Zyklen (z. B. quartalsweise), abhängig davon, wie viele priorisierte Wünsche tatsächlich umgesetzt werden sollen.

Der größte, oft unterschätzte Kostenblock ist nicht der Betrieb, sondern aufgeschobene Wartung: Wer Updates über längere Zeit sammelt statt kontinuierlich einzupflegen, zahlt später ein Vielfaches für die Nachholung – plus das Risiko, dass in der Zwischenzeit eine bekannte Sicherheitslücke offen blieb.

Checkliste: Software Wartung und Betrieb aufsetzen

1. Es gibt eine schriftlich benannte Person oder ein Team mit realem Zeitbudget für Betrieb und Wartung.
2. Alle wesentlichen Abhängigkeiten (Sprache, Frameworks, Bibliotheken, externe APIs, KI-Modelle) sind inventarisiert.
3. Sicherheitsrelevante Updates haben eine feste, kurze Reaktionsfrist; funktionale Updates laufen in planbaren Zyklen.
4. Automatisierte Tests decken die wichtigsten Funktionen ab, damit Updates kein Blindflug sind.
5. Ein SLA-Raster nach Schweregrad ist mit dem Fachbereich abgestimmt und beiden Seiten bekannt.
6. Basis-Monitoring läuft für Latenz, Traffic, Fehlerrate und Sättigung – nicht erst nach dem ersten Vorfall eingerichtet.
7. Bei KI-Bausteinen wird die Ausgabequalität regelmäßig gegen eine feste Testmenge geprüft.
8. Fehlermeldung und Verbesserungswunsch laufen über getrennte, bekannte Kanäle.
9. Wartungs- und Weiterentwicklungsbudget sind getrennt geplant, damit Weiterentwicklung nicht strukturell verdrängt wird.
10. Priorisierungsentscheidungen zu Verbesserungswünschen werden an die Vorschlagenden zurückkommuniziert – auch Absagen.

Stand: Juli 2026. Wartungskategorien nach ISO/IEC/IEEE 14764, Monitoring-Signale nach dem Google-SRE-Ansatz; Kosten- und Zeitbandbreiten sind Erfahrungswerte aus eigener Projektpraxis unter den jeweils genannten Annahmen und ersetzen keine Rechts- oder Compliance-Beratung.