Vibe Coding in der Steuerkanzlei: Warum ein Prototyp noch keine Software ist

Ein funktionierender Prototyp ist nach einem Wochenende möglich. Ein Werkzeug, dem Sie Mandantendaten anvertrauen können, ist etwas völlig anderes. Zwischen beidem liegt kein kleiner Schritt, sondern der größte Teil der Arbeit.

KI-gestütztes Programmieren, oft „Vibe Coding“ genannt, hat die Einstiegshürde drastisch gesenkt. Immer mehr Kanzleiinhaber bauen sich damit eigene Tools: eine Fristenübersicht, ein Formular für die Mandantenaufnahme, eine kleine Auswertung. Das ist grundsätzlich eine gute Entwicklung. Sie birgt aber ein Risiko, das man dem Ergebnis nicht ansieht: Eine App, die auf dem Bildschirm sauber läuft, kann unsicher, fragil und im Ernstfall nicht betreibbar sein.

Dieser Artikel erklärt, was zwischen Prototyp und produktivem Einsatz liegt. Er richtet sich an Kanzleiinhaber, die selbst bauen oder darüber nachdenken, und soll helfen, die Verantwortung realistisch einzuschätzen, bevor echte Mandantendaten im Spiel sind.

Das Wichtigste in Kürze

• Vibe Coding erzeugt Code schnell. Es erzeugt nicht automatisch Sicherheit, Zuverlässigkeit oder Betriebsfähigkeit.
• Der sichtbare Teil einer App (Oberfläche und Grundfunktion) ist oft nur ein kleiner Teil des Aufwands.
• Die unsichtbaren Teile entscheiden im Ernstfall: Sicherheit, Tests, Sonderfälle, Updates, Betrieb, Wartung.
• Sobald Mandantendaten verarbeitet werden, tragen Sie als Inhaber die Verantwortung, auch für Fehler, die die KI eingebaut hat.
• Prototypen sind wertvoll, aber nur mit klarer Grenze: Testdaten ja, echte Mandantendaten erst nach einer echten Absicherung.

Was Vibe Coding wirklich gut kann

Bevor es um die Grenzen geht, lohnt ein fairer Blick auf die Stärken. Wer Vibe Coding pauschal abtut, verpasst echten Nutzen.

KI-Werkzeuge sind hervorragend darin, aus einer Beschreibung in Alltagssprache lauffähigen Code zu erzeugen. Sie eignen sich gut, um:

• eine Idee in Minuten sichtbar zu machen und mit Kollegen zu diskutieren,
• Abläufe zu verstehen, bevor man sie professionell umsetzen lässt,
• kleine, in sich abgeschlossene Hilfsmittel für den eigenen Rechner zu bauen,
• Anforderungen zu schärfen: Wer einen Prototyp gesehen hat, kann viel präziser sagen, was er wirklich braucht.

Der letzte Punkt wird unterschätzt. Ein Prototyp ist ein hervorragendes Lastenheft. Er zeigt, was Sie brauchen, und verhindert, dass Sie ein Jahr lang das Falsche planen.

Das Problem beginnt an einer klaren Stelle: in dem Moment, in dem aus „das probiere ich mal aus“ ein „das benutzen wir jetzt im Tagesgeschäft“ wird. Ab dort gelten völlig andere Maßstäbe.

Aus der Praxis: Wenn die selbstgebaute Kanzlei-App an ihre Grenzen stößt

Dieses Szenario ist keine Theorie. Ein Steuerkanzlei-Kunde von uns hatte sich eine eigene Kanzlei-App per Vibe Coding gebaut. Der Einstieg war leicht, die ersten Ergebnisse kamen schnell, und das Werkzeug erfüllte zunächst seinen Zweck.

Dann stieß die Kanzlei an Grenzen und kam zu uns. Die Einzelheiten geben wir hier bewusst nicht wieder, das Muster dahinter ist aber typisch und lässt sich gut verallgemeinern:

1. Der Funktionsumfang wächst schneller als das Fundament. Jede neue Anforderung wird auf den bestehenden Code gesetzt. Irgendwann verändert eine kleine Anpassung an Stelle A unbemerkt das Verhalten an Stelle B.
2. Niemand weiß mehr genau, was der Code tut. Wer ihn nicht selbst geschrieben und verstanden hat, kann Fehler weder sicher finden noch sicher beheben. Fragt man die KI erneut, entsteht oft eine neue Variante statt einer gezielten Korrektur.
3. Die Fragen kommen von außen. Wer sichert die Daten? Was passiert bei einem Ausfall? Wer darf was sehen? Wer haftet bei einem Fehler? Diese Fragen stellen Mandanten, Prüfer oder die eigene Versicherung, nicht die KI.
4. Aus dem Werkzeug wird eine Abhängigkeit. Je mehr Abläufe daran hängen, desto teurer wird jeder Ausfall und desto schwerer wird der Ausstieg.

Die Lehre daraus ist nicht, dass die Kanzlei falsch gehandelt hätte. Sie hat schnell gelernt, was sie braucht. Kritisch wird es erst, wenn dieser Lernprozess mit echten Mandantendaten im Produktivbetrieb stattfindet.

Prototyp und Produktivsystem: der eigentliche Unterschied

Ein Prototyp beantwortet die Frage „Geht das grundsätzlich?“. Ein Produktivsystem beantwortet eine ganz andere: „Können wir uns jeden Tag darauf verlassen, auch wenn etwas schiefgeht?“

Ein Bild hilft: Ein Prototyp ist wie ein Modellhaus aus Pappe. Es zeigt, wie das Haus aussehen könnte. Wohnen kann man darin nicht. Es fehlen Fundament, Statik, Leitungen, Brandschutz und die Abnahme. Und genau diese Teile machen ein Haus bewohnbar, obwohl man sie später kaum noch sieht.

Aspekt	Prototyp	Produktivsystem
Ziel	Idee zeigen, Machbarkeit prüfen	Zuverlässig im Tagesgeschäft arbeiten
Daten	Testdaten	Echte, schützenswerte Mandantendaten
Fehlerfall	Neu starten, nochmal versuchen	Darf Daten nicht verlieren oder verfälschen
Nutzer	Eine Person, die das Tool kennt	Mehrere Personen mit unterschiedlichen Rechten
Sicherheit	Spielt kaum eine Rolle	Grundvoraussetzung
Änderungen	Direkt im Code, jederzeit	Geplant, getestet, nachvollziehbar
Ausfall	Ärgerlich	Kann Fristen, Mandate und Vertrauen kosten
Verantwortung	Bei niemandem	Beim Inhaber

Die KI hilft enorm bei der linken Spalte. Für die rechte Spalte braucht es Erfahrung, Prozesse und Disziplin, also genau das, was Software Engineering als Fach ausmacht. Es geht dabei weniger um das Schreiben von Code als um die Frage, wie man Software so baut und betreibt, dass sie über Jahre verlässlich bleibt.

Eine grobe Faustregel aus der Praxis: Der reine Bau der Funktion ist oft nur ein Teil des Gesamtaufwands. Der größere Teil entfällt auf Absicherung, Test, Betrieb und Pflege. Das gilt unabhängig davon, ob der Code von Hand oder mit KI geschrieben wurde.

Diese Beobachtung ist nicht neu. Bereits 1975 schätzte der Software-Pionier Frederick Brooks in seinem einflussreichen Werk „The Mythical Man-Month“, dass ein fertiges, getestetes und dokumentiertes Softwareprodukt rund neunmal so viel Aufwand erfordert wie ein einfaches, funktionierendes Programm. Diese Faustregel stammt aus einer Zeit lange vor KI-gestütztem Programmieren und beschreibt ein grundlegendes Verhältnis der Softwareentwicklung, das durch schnellere Code-Erzeugung nicht verschwindet.

Sicherheit: das Thema, das man nicht sieht

Sicherheit ist der Bereich, in dem selbstgebaute Tools am häufigsten scheitern, und zwar unbemerkt. Ein unsicheres Tool funktioniert genauso gut wie ein sicheres. Der Unterschied zeigt sich erst, wenn jemand ihn ausnutzt. Bei Steuerkanzleien ist das Risiko besonders hoch, denn Sie verwalten Daten, die für Angreifer attraktiv sind: Identitäten, Bankverbindungen, Einkommens- und Vermögensverhältnisse.

KI-generierter Code ist kein böswilliger Code. Er ist aber darauf optimiert, dass etwas funktioniert, nicht darauf, dass es widerstandsfähig ist. Sicherheitsmaßnahmen fehlen deshalb oft still, weil niemand danach gefragt hat.

Zugriff: Wer darf was?

Die erste Frage jeder Sicherheitsbetrachtung lautet: Wer kommt überhaupt an die Anwendung heran, und was darf er dort tun? Typische Schwachstellen in selbstgebauten Tools:

• Keine oder schwache Anmeldung. Die App ist im Netz erreichbar, aber jeder mit dem Link kommt hinein. Oder es gibt ein einziges gemeinsames Passwort.
• Fehlende Rechtetrennung. Alle Nutzer sehen alle Mandanten. Praktikant, Sachbearbeiter und Inhaber haben dieselben Rechte.
• Lücken bei der Autorisierung. Die Oberfläche versteckt Daten, aber ruft jemand die zugrunde liegende Adresse direkt auf, gibt das System sie trotzdem heraus. Ein klassischer Fehler: Ändert man in der Adresszeile eine Nummer, erscheint der Datensatz eines anderen Mandanten.
• Fehlende zweite Sicherungsebene. Eine Zwei-Faktor-Anmeldung ist bei Mandantendaten heute Standard, in Prototypen aber fast nie vorhanden.

Geheimnisse und Zugangsdaten

API-Schlüssel, Datenbankpasswörter und Zugangsdaten gehören niemals in den Programmcode. KI-Assistenten schreiben sie aber häufig genau dorthin, weil es in der Demo am einfachsten ist. Landet dieser Code in einem öffentlichen Repository, in einer geteilten Datei oder im Browser der Nutzer, ist der Schlüssel praktisch öffentlich. Automatisierte Suchprogramme durchforsten das Netz ständig nach solchen Schlüsseln, oft binnen Minuten.

Zu einer professionellen Lösung gehören getrennte Umgebungen, sichere Ablage von Geheimnissen, regelmäßiger Austausch und die Möglichkeit, einen kompromittierten Schlüssel sofort zu sperren.

Eingaben: Vertraue niemals dem, was hereinkommt

Jedes Feld, jeder Upload und jede Schnittstelle ist ein möglicher Angriffspunkt. Wird eine Eingabe nicht geprüft, kann sie im schlimmsten Fall Befehle einschleusen, die die Datenbank auslesen oder verändern (SQL-Injection), oder Schadcode im Browser anderer Nutzer ausführen (Cross-Site-Scripting).

Besonders wichtig für Kanzleien: Datei-Uploads. Mandanten schicken PDFs, Bilder, Tabellen. Ein Upload-Feld ohne Prüfung von Dateityp, Größe und Inhalt ist ein beliebter Weg, Schadsoftware einzuschleusen. Auch Inhalte, die eine KI später verarbeitet, können manipuliert sein und dem System versteckte Anweisungen unterschieben (sogenannte Prompt Injection). Wer KI-Funktionen in sein Tool einbaut, muss diese Angriffsart kennen.

Abhängigkeiten: Fremder Code in Ihrer Anwendung

Moderne Software besteht zum großen Teil aus fremden Bausteinen. Eine kleine App bindet schnell Hunderte solcher Pakete ein, ohne dass man es merkt. Das birgt mehrere Risiken:

• Ein Baustein hat eine bekannte Sicherheitslücke, die nie geschlossen wird, weil niemand Updates einspielt.
• Ein Baustein wird nicht mehr gepflegt und veraltet.
• KI-Assistenten schlagen gelegentlich Pakete vor, die es gar nicht gibt. Angreifer registrieren solche Namen gezielt und legen dort Schadcode ab.

Dagegen helfen automatische Prüfungen auf bekannte Schwachstellen, eine Übersicht aller eingebundenen Bausteine und ein fester Prozess, sie aktuell zu halten.

Bösartige Pakete: ein wachsendes Problem

Das Risiko durch bösartige Bausteine ist kein Randthema mehr, es wächst schnell. 2025 wurden über 454.000 neue bösartige Open-Source-Pakete registriert, ein Anstieg von 75 Prozent gegenüber dem Vorjahr, kumuliert mittlerweile über 1,2 Millionen bekannte Schadpakete. Bei npm, einem der größten Paket-Verzeichnisse, hat sich die Zahl erkannter bösartiger Pakete binnen eines Jahres mehr als verdoppelt.

Ein Teil dieser Pakete führt seinen Schadcode bereits bei der Installation aus, nicht erst später beim Betrieb der Anwendung. Das trifft direkt den Rechner, auf dem entwickelt wird, unabhängig davon, ob die App je veröffentlicht wird. Ende 2025 verbreitete sich erstmals ein Schadprogramm dieser Art selbstständig weiter: Es infizierte automatisch zusätzliche Pakete und Entwicklerkonten, ganz ohne dass ein Angreifer manuell eingreifen musste.

Ein neueres Muster kommt speziell durch KI-Coding hinzu: KI-Assistenten erfinden gelegentlich Namen von Programmbibliotheken, die es gar nicht gibt, das passiert je nach Modell in 5 bis über 20 Prozent der Fälle. Angreifer beobachten, welche erfundenen Namen wiederkehren, und registrieren sie vorsorglich mit Schadcode. Wer diesen Namen später tatsächlich installiert, holt sich die Schadsoftware direkt auf den Rechner. Ein bekannter Testfall zeigte, dass ein rein erfundener, nie real existierter Name über 30.000-mal heruntergeladen wurde.

Verschlüsselung und Datenhaltung

Daten müssen auf dem Weg (zwischen Browser und Server) und im Ruhezustand (in der Datenbank, auf der Festplatte, im Backup) geschützt sein. Häufige Mängel in Prototypen: unverschlüsselte Verbindungen, Klartext-Passwörter in der Datenbank, Datenbanken, die versehentlich aus dem Internet erreichbar sind, und Dateien in öffentlich zugänglichen Ordnern.

Noch ein Punkt, der oft vergessen wird: Wohin gehen die Daten noch? Sendet Ihr Tool Inhalte an einen externen KI-Dienst, verlassen Mandantendaten Ihre Kontrolle. Ob und unter welchen Bedingungen das zulässig ist, muss vor dem Einsatz geklärt sein, nicht danach.

Protokollierung und Nachvollziehbarkeit

Wenn etwas passiert, müssen Sie wissen, was. Wer hat wann welche Daten geöffnet oder geändert? Ohne Protokolle können Sie einen Vorfall weder aufklären noch belegen, was betroffen war. Umgekehrt dürfen Protokolle selbst keine sensiblen Daten im Klartext enthalten. Auch Fehlermeldungen sind heikel: Zeigt eine App bei einem Fehler technische Details an, verrät sie Angreifern, wie sie aufgebaut ist.

Was passiert im Ernstfall?

Sicherheit bedeutet nicht nur Verhinderung, sondern auch Reaktion. Fragen Sie sich ehrlich:

• Würden Sie einen unbefugten Zugriff überhaupt bemerken?
• Wüssten Sie, wen Sie informieren müssen und in welchen Fristen?
• Können Sie den Zugriff sofort sperren, ohne alles abzuschalten?
• Gibt es einen sauberen, getesteten Stand, auf den Sie zurückgehen können?

Wer darauf keine Antwort hat, hat kein Sicherheitskonzept, sondern Hoffnung.

Warum KI hier allein nicht reicht

Man kann eine KI bitten, den eigenen Code auf Sicherheitslücken zu prüfen, und das ist sinnvoll. Es ersetzt aber keine unabhängige Prüfung. Die KI kennt weder Ihre Infrastruktur noch Ihre Konfiguration, und sie bewertet ihren eigenen Code mit denselben blinden Flecken, mit denen sie ihn geschrieben hat.

Das zeigt sich auch in Zahlen: Eine große Untersuchung von über 100 KI-Modellen fand 2025 in 45 Prozent der geprüften Programmieraufgaben mindestens eine Sicherheitslücke im generierten Code. Diese Quote blieb über mehrere Testreihen bis ins Jahr 2026 nahezu unverändert, obwohl der Anteil fehlerfrei lauffähigen Codes im selben Zeitraum deutlich gestiegen ist. Größere, neuere KI-Modelle schnitten dabei nicht sicherer ab als ältere. KI-generierter Code funktioniert also zunehmend zuverlässig, wird aber nicht zuverlässig sicherer.

Professionelle Sicherheit umfasst Bedrohungsanalyse, Konfigurationsprüfung, automatisierte Scans und bei sensiblen Systemen unabhängige Penetrationstests durch Dritte.

Tägliche Prüfungen, die keine KI-Interpretation brauchen

Neben der einmaligen Prüfung braucht es laufende Kontrollen, die jeden Tag automatisch laufen, unabhängig davon, ob sich am Code etwas geändert hat. Der Grund: Neue Sicherheitslücken in verwendeten Bausteinen werden auch bekannt, ohne dass Sie selbst etwas verändert haben.

Zu diesen täglichen, deterministischen Prüfungen gehören:

• ein automatischer Scan aller eingesetzten Bausteine auf bekannte Schwachstellen,
• eine Suche nach versehentlich im Code abgelegten Passwörtern oder Schlüsseln,
• eine automatische Prüfung des Codes auf bekannte Fehlermuster wie unsichere Datenbankabfragen,
• eine Kontrolle der Serverkonfiguration, etwa Zugriffsrechte und offene Schnittstellen,
• ein Abgleich, ob die Liste der verwendeten Bausteine unverändert oder wie erwartet ist.

Diese Prüfungen ersetzen keine der zuvor genannten Maßnahmen. Sie ergänzen sie um etwas Entscheidendes: eine tägliche, verlässliche Kontrolle, die nicht davon abhängt, dass jemand daran denkt.

Lokale Tools sind nicht automatisch sicher

Ein Werkzeug, das nur auf dem eigenen Rechner läuft und nie im Internet veröffentlicht wird, wirkt sicher. Das ist ein Trugschluss, gerade bei Tools, die per Schnittstelle auf DATEV oder andere Kanzleisysteme zugreifen.

Der Browser als unbeabsichtigtes Einfallstor. Viele selbstgebaute Werkzeuge laufen im Hintergrund als kleiner lokaler Server, oft ganz ohne eigene Anmeldung, weil ja „nur ich“ darauf zugreife. Besucht man nebenbei eine präparierte Webseite, kann diese über einen technischen Trick den eigenen, lokal laufenden Server ansprechen, obwohl er eigentlich nur für den eigenen Rechner gedacht war. Genau diese Lücke wurde bei mehreren bekannten Entwicklungswerkzeugen gefunden und musste nachträglich geschlossen werden.

Der KI-Agent mit echten Rechten. Moderne KI-Coding-Werkzeuge dürfen oft selbst Dateien lesen, schreiben oder Befehle ausführen. Das macht den Agenten selbst zum Angriffsziel: Enthält eine Datei, eine Webseite oder die Antwort eines angebundenen Systems versteckte Anweisungen, kann der Agent diese für echte Befehle halten und ausführen, etwa Dateien auslesen und weiterschicken. Besonders betrifft das Anbindungen an externe Systeme, wie sie für einen Zugriff auf DATEV nötig sind: Dieses noch junge Feld hat bereits mehrere gemeldete Schwachstellen, bei denen das bloße Öffnen eines präparierten Projekts zur unbemerkten Codeausführung führte, oder bei denen manipulierte Werkzeugbeschreibungen den Agenten zu falschen Aktionen verleiteten.

Was das für die Kanzlei bedeutet. Ein lokales Tool mit Zugriff auf DATEV oder ähnliche Systeme hat potenziell dieselben Rechte wie der Mitarbeiter, der es nutzt. Die Angriffsfläche ist dann nicht „die App im Internet“, sondern der Arbeitsplatzrechner selbst, mit direktem Weg zu allen Mandantendaten dahinter. Wer lokal Zugriff auf empfindliche Systeme einrichtet, braucht dieselbe Sorgfalt wie bei einer öffentlich erreichbaren Anwendung: eine eigene Anmeldung, eingeschränkte Rechte für den KI-Agenten und eine Prüfung, welche externen Anbindungen wirklich nötig sind.

Datenschutz und Berufsrecht: Verantwortung lässt sich nicht delegieren

Steuerberater unterliegen strengen Vorgaben zu Datenschutz und Verschwiegenheit. Diese Pflichten gelten unabhängig davon, wie ein Werkzeug entstanden ist. Ob ein Programm von einem Entwicklerteam oder von einer KI geschrieben wurde, ändert nichts daran, dass die Kanzlei für den Umgang mit den Daten verantwortlich ist.

Im Zusammenhang mit selbstgebauten Tools sind vor allem drei Fragen relevant:

• Wo liegen die Daten, und wer hat Zugriff? Das betrifft den Speicherort, eingesetzte Dienstleister und alle externen Dienste, an die Daten übermittelt werden, auch KI-Dienste.
• Sind die nötigen Vereinbarungen vorhanden? Sobald Dritte Daten verarbeiten oder Zugriff darauf haben können, sind vertragliche und organisatorische Regelungen erforderlich.
• Lässt sich der Umgang mit den Daten nachweisen? Wer nicht dokumentieren kann, wie Daten geschützt werden, hat im Prüfungs- oder Schadensfall ein Problem.

Die Details hängen vom Einzelfall ab und sollten mit dem Datenschutzbeauftragten oder einer fachkundigen Beratung geklärt werden. Als Grundsatz gilt: Datenschutz und Verschwiegenheit werden nicht am Ende „noch schnell dazugebaut“. Sie gehören von Anfang an in die Architektur. Ein Werkzeug, das ohne diese Überlegungen entstanden ist, lässt sich nachträglich nur mit erheblichem Aufwand in Ordnung bringen, manchmal gar nicht.

Tests und Sonderfälle: Der Alltag ist selten der Normalfall

Der Prototyp funktioniert, weil Sie ihn mit den Daten ausprobiert haben, an die Sie gedacht haben. Ein Produktivsystem muss auch mit den Daten funktionieren, an die niemand gedacht hat.

In der Steuerberatung ist das besonders relevant, weil die Realität voller Ausnahmen steckt. Einige Beispiele, die in der Praxis regelmäßig Probleme machen:

• Zahlen und Formate: Komma oder Punkt als Dezimaltrenner, Tausendertrennzeichen, negative Beträge, Rundungsdifferenzen, sehr große und sehr kleine Werte.
• Namen und Text: Umlaute, Sonderzeichen, Doppelnamen, sehr lange Firmenbezeichnungen, zwei Mandanten mit gleichem Namen.
• Zeit und Fristen: abweichende Wirtschaftsjahre, Schaltjahre, Wochenenden und Feiertage (die je nach Bundesland unterschiedlich ausfallen), Jahreswechsel, Zeitumstellung.
• Dokumente: gescannte statt digitaler PDFs, schlechte Bildqualität, mehrseitige Belege, falsch benannte Dateien, doppelt hochgeladene Belege, Passwortschutz.
• Daten: fehlende Pflichtfelder, unvollständige Angaben, widersprüchliche Werte, Dubletten.
• Gleichzeitigkeit: Zwei Personen bearbeiten denselben Datensatz zur selben Zeit. Wer gewinnt, und geht dabei etwas verloren?
• Rechtsänderungen: Regeln, die sich mit dem Gesetzgeber ändern, sodass eine früher richtige Berechnung plötzlich falsch ist.

Wie professionelles Testen aussieht

Testen heißt nicht, ein paar Mal auf Knöpfe zu klicken. Es umfasst mehrere Ebenen:

1. Einzeltests (Unit-Tests) prüfen kleine Funktionen isoliert, etwa eine Berechnung, mit vielen Eingaben, auch absichtlich falschen.
2. Integrationstests prüfen, ob die Bausteine miteinander funktionieren, zum Beispiel Oberfläche, Datenbank und externe Schnittstellen.
3. Durchgängige Tests (End-to-End) spielen komplette Abläufe nach, so wie ein Nutzer sie erlebt.
4. Regressionstests stellen sicher, dass eine neue Änderung nichts kaputt macht, was vorher funktionierte. Genau das ist das Kernproblem bei KI-generierten Änderungen, die gern an mehreren Stellen gleichzeitig eingreifen.
5. Sicherheitstests prüfen gezielt, ob Schutzmechanismen umgangen werden können.

Ein Warnsignal: Die KI schreibt Tests, die ihren eigenen Code bestätigen, statt ihn zu hinterfragen. Ein Test, der nur das absichert, was der Code ohnehin tut, findet keine Fehler. Gute Tests entstehen aus der Frage „Was könnte schiefgehen?“, und die stellt man am besten mit Fachwissen über die Domäne.

Hinzu kommt die inhaltliche Richtigkeit. Ein Programm kann technisch einwandfrei laufen und trotzdem falsch rechnen. Wer prüft, ob die Fachlogik stimmt? Bei Zahlen, die in Steuererklärungen oder Auswertungen einfließen, ist das keine Nebensache.

Updates, Releases und Pipelines: Änderungen ohne Risiko

Software ist nie fertig. Es kommen neue Anforderungen, Fehlerkorrekturen, Sicherheitsupdates und Änderungen an angebundenen Systemen.

Der Softwareforscher Meir Lehman beschrieb bereits 1980 ein Grundgesetz der Softwareentwicklung: Ein System, das im Einsatz ist, muss laufend angepasst werden, sonst sinkt sein Nutzen mit der Zeit, weil sich sein Umfeld weiterentwickelt, das System selbst aber nicht.

Die entscheidende Frage lautet daher nicht „Läuft es heute?“, sondern „Können wir es morgen ändern, ohne dass etwas kaputtgeht?“

Im Prototyp passiert eine Änderung so: Man ändert etwas direkt im laufenden System und hofft. Im professionellen Umfeld läuft es geordnet ab:

1. Versionsverwaltung: Jede Änderung wird festgehalten, mit Datum, Autor und Begründung. Dadurch lässt sich jederzeit auf einen früheren, funktionierenden Stand zurückgehen.
2. Getrennte Umgebungen: Entwickeln, Testen und Produktivbetrieb finden an verschiedenen Orten statt. Neue Versionen werden nie zuerst an echten Mandantendaten ausprobiert.
3. Automatisierte Prüfung (CI): Bei jeder Änderung laufen Tests und Sicherheitsprüfungen automatisch. Erst wenn alles grün ist, geht es weiter.
4. Kontrollierte Auslieferung (CD): Neue Versionen werden reproduzierbar und nach festen Regeln ausgerollt, idealerweise so, dass sich ein Fehlschlag sofort rückgängig machen lässt.
5. Datenbankänderungen mit Plan: Ändert sich die Struktur der Daten, müssen bestehende Datensätze sauber mitwandern (Migration). Ein Fehler an dieser Stelle kann Daten dauerhaft beschädigen.

Diese Kette nennt man Pipeline. Sie wirkt wie Bürokratie, ist aber das, was Geschwindigkeit auf Dauer erst ermöglicht: Wer sich auf seine Tests und den Rückweg verlassen kann, ändert mutig und schnell. Wer das nicht kann, ändert gar nicht mehr, oder mit Angst.

Die Update-Falle

Ein häufiges Muster: Die App läuft monatelang unverändert, weil „nichts kaputtgehen soll“. Währenddessen veralten Betriebssystem, Bibliotheken und Server, und Sicherheitslücken bleiben offen. Irgendwann ist ein Update unumgänglich, aber inzwischen so groß und riskant, dass sich niemand mehr traut. Regelmäßige, kleine Updates sind sicherer als seltene, große.

Auch externe Schnittstellen ändern sich. Wenn Ihr Tool mit anderen Systemen spricht, etwa mit Buchhaltungs-, Kanzlei- oder Behördenschnittstellen, dann ändern diese Systeme ihre Formate und Regeln, ohne Rücksicht auf Ihr Tool. Jemand muss das bemerken und anpassen, sonst bricht Ihr Ablauf irgendwann zu einem ungünstigen Zeitpunkt zusammen.

Betrieb: Hosting, Erreichbarkeit, Backups und Support

Eine App läuft irgendwo. Dieses „irgendwo“ muss jemand bereitstellen, absichern, überwachen und im Fehlerfall reparieren. Auf dem eigenen Rechner ist das unkompliziert. Sobald mehrere Personen von verschiedenen Orten zugreifen sollen, etwa aus dem Homeoffice, vom Handy oder von Mandanten aus, beginnt ein eigenes Fachgebiet.

Hosting und Erreichbarkeit

• Wo läuft die Anwendung? Eigener Server, Cloud-Anbieter, Rechner im Büro? Jede Variante hat andere Risiken, Kosten und Pflichten.
• Wie greift man von außen zu? Freigaben ins Internet sind ein zentrales Sicherheitsrisiko. Sie brauchen verschlüsselte Verbindungen (Zertifikate, die regelmäßig erneuert werden müssen), sinnvoll konfigurierte Netzwerkregeln und Schutz vor Überlastung und automatisierten Angriffen.
• Was passiert bei Ausfall? Läuft die App auf dem PC eines Mitarbeiters, der im Urlaub den Rechner ausschaltet, steht die Kanzlei. Verfügbarkeit ist kein Zufall, sondern Ergebnis von Planung.
• Wie viele Nutzer verträgt das System? Ein Tool, das mit zwei Personen flüssig läuft, kann bei zwanzig oder zum Fristende hin einbrechen.

Überwachung: Wissen, dass etwas nicht stimmt

Im Prototyp merkt man einen Fehler, wenn jemand sich beschwert. Im Betrieb will man ihn vorher merken. Monitoring bedeutet: Das System meldet selbst, wenn es langsamer wird, Fehler häufen, der Speicherplatz knapp wird oder ein Zertifikat abläuft. Ohne diese Warnungen erfahren Sie von Problemen erst, wenn sie Schaden angerichtet haben.

Datensicherung: Nur getestet ist gesichert

Das Thema Backup wird in Prototypen fast immer vergessen, und es gehört zu den wichtigsten Punkten überhaupt. Drei Fragen entscheiden:

1. Wird regelmäßig gesichert, und liegt die Sicherung getrennt vom Original? Ein Backup auf demselben Server schützt nicht vor einem Totalausfall oder einem Angriff.
2. Wurde die Wiederherstellung getestet? Ein Backup, das sich nicht einspielen lässt, ist wertlos. Das merkt man erst im Ernstfall.
3. Wie lange dauert die Wiederherstellung, und wie viel Datenverlust ist tragbar? Ein Tag Datenverlust kann bei einer Kanzlei zu viel sein.

Support: Wer hilft, wenn es brennt?

Solange Sie selbst Fehler beheben können, ist das kein Problem. Doch was passiert, wenn das Tool an einem Freitagabend vor einer Frist ausfällt? Wer analysiert den Fehler, wer entscheidet über Notfallmaßnahmen, und wer vertritt bei Krankheit oder Urlaub? Professioneller Betrieb heißt: klar geregelte Zuständigkeiten, dokumentierte Abläufe und eine Vertretung.

Auch Ihre Nutzer brauchen Unterstützung. Sie stellen Fragen, melden Fehler und wünschen Änderungen. Jede dieser Anfragen muss aufgenommen, bewertet und beantwortet werden. Das ist laufende Arbeit, die schnell größer wird als der ursprüngliche Bau.

Wartung, Dokumentation und Wissensträger

Code, den niemand versteht, ist eine Schuld, die mit Zinsen wächst.

Der Software-Experte Robert Glass fasste in seinem Standardwerk zusammen, dass Wartung über die gesamte Lebensdauer einer Software typischerweise 40 bis 80 Prozent der Gesamtkosten ausmacht, im Schnitt etwa 60 Prozent. Allein das Verstehen des bestehenden Codes verschlingt danach rund 30 Prozent der gesamten Wartungszeit, mehr als jede andere einzelne Tätigkeit in der Pflege einer Software.

Bei KI-generiertem Code tritt dieses Problem besonders schnell auf, denn der Autor ist keine Person, die man später fragen kann.

Drei Aspekte werden oft übersehen:

• Verständlichkeit. Guter Code ist strukturiert, benannt und kommentiert, sodass auch eine andere Person ihn übernehmen kann. KI-Code ist oft funktional, aber uneinheitlich: Bei jeder Anfrage entsteht ein anderer Stil, mit doppelter Logik und unklaren Zuständigkeiten.
• Dokumentation. Wie ist das System aufgebaut? Welche Entscheidungen wurden getroffen und warum? Wie stellt man es auf einem neuen Server wieder her? Ohne diese Antworten steht und fällt alles mit dem Gedächtnis einzelner Personen.
• Abhängigkeit von Einzelnen. Wer kann das Tool ändern, wenn die Person, die es gebaut hat, die Kanzlei verlässt, krank ist oder keine Zeit hat? In der Fachsprache spricht man vom „Bus-Faktor“: Wie viele Personen dürfen ausfallen, bevor das Projekt gefährdet ist? Bei selbstgebauten Tools liegt er oft bei eins.

Hinzu kommt ein Kostenfaktor, der gern übersehen wird: die eigene Zeit des Inhabers. Jede Stunde, die in Fehlersuche, Pflege und Krisenmanagement fließt, fehlt bei Mandanten, Beratung und Kanzleiführung.

Was Software wirklich kostet: eine ehrliche Rechnung

„Die KI baut das kostenlos“ stimmt nur für den ersten Schritt. Die Gesamtkosten eines Werkzeugs im Produktivbetrieb setzen sich aus deutlich mehr Posten zusammen, und die meisten davon tauchen in keiner Rechnung auf, weil sie in Ihrer Arbeitszeit oder erst im Schadensfall entstehen.

Kostenposition	Wann sie anfällt
Bau der Funktion	Einmalig, zu Beginn
Absicherung und Sicherheitsprüfung	Einmalig, dann regelmäßig
Tests und Qualitätssicherung	Bei jeder Änderung
Hosting, Zertifikate, Backups	Laufend
Monitoring und Störungsbehebung	Laufend, oft ungeplant
Sicherheits- und Abhängigkeitsupdates	Laufend
Anpassung an geänderte Schnittstellen und Rechtslage	Unregelmäßig, aber sicher
Nutzersupport und Schulung	Laufend
Dokumentation und Wissenssicherung	Zu Beginn und fortlaufend
Ausfall, Datenverlust, Vorfall	Im Ernstfall, dann meist teuer

Die letzte Zeile ist die, die man in keiner Kalkulation sieht und die am meisten kosten kann: Bußgelder, Haftungsfragen, Reputationsschaden, Mandantenverlust und die Arbeit, einen Vorfall aufzuarbeiten. Hier zeigt sich der Kern des Themas: Bei einem Prototyp ist das Risiko gering, weil nichts auf dem Spiel steht. Beim Produktivbetrieb steht Ihr Ruf auf dem Spiel.

Das heißt nicht, dass Eigenbau sich nie lohnt. Es heißt, dass man die Rechnung vollständig aufmachen sollte: Was kostet es, das Werkzeug sicher und dauerhaft zu betreiben, und ist das im Verhältnis zum Nutzen vertretbar?

Checkliste: Bevor echte Mandantendaten ins Tool kommen

Können Sie jede dieser Fragen mit „Ja“ beantworten? Jedes „Nein“ ist ein Punkt, der vor dem Produktiveinsatz geklärt werden sollte.

Sicherheit

• Gibt es eine sichere Anmeldung mit persönlichen Konten und Zwei-Faktor-Schutz?
• Sehen Nutzer nur die Daten, die sie sehen dürfen, und ist das serverseitig erzwungen?
• Liegen Passwörter und Schlüssel außerhalb des Codes und lassen sich im Notfall sofort tauschen?
• Werden Eingaben und Datei-Uploads geprüft?
• Sind alle Abhängigkeiten bekannt, aktuell und werden automatisch auf Schwachstellen geprüft?
• Sind Daten unterwegs und im Ruhezustand verschlüsselt?
• Gibt es Protokolle, die zeigen, wer wann was getan hat?
• Hat eine unabhängige Stelle das System geprüft?
• Ist das Tool nur auf dem eigenen Rechner erreichbar, ohne dass fremde Webseiten oder andere Programme darauf zugreifen können?
• Hat ein KI-Agent nur die Datei- und Systemzugriffe, die er wirklich braucht?
• Laufen automatisierte Sicherheitsprüfungen täglich, unabhängig davon, ob sich am Code etwas geändert hat?
• Werden alle Bausteine, auch von der KI vorgeschlagene, vor der Übernahme geprüft?

Qualität

• Gibt es automatisierte Tests, die auch Sonderfälle und Fehleingaben abdecken?
• Wurde die fachliche Richtigkeit der Berechnungen von einer fachkundigen Person geprüft?
• Werden Änderungen versioniert, getestet und kontrolliert ausgeliefert?
• Lässt sich ein fehlerhaftes Update schnell zurücknehmen?

Betrieb

• Ist klar, wo die Anwendung läuft, und ist der Zugang von außen abgesichert?
• Gibt es Monitoring mit Warnungen bei Störungen?
• Werden Backups regelmäßig erstellt, getrennt gelagert und wurde die Wiederherstellung getestet?
• Ist geregelt, wer bei Störungen erreichbar ist, auch im Urlaub und bei Krankheit?
• Gibt es einen Plan für den Sicherheitsvorfall?

Organisation und Recht

• Sind Datenschutz und Verschwiegenheit geklärt und dokumentiert, auch für alle externen Dienste?
• Ist das System dokumentiert, sodass eine andere Person es übernehmen könnte?
• Ist klar, wer verantwortlich ist und wer die Kosten für Pflege und Betrieb trägt?
• Ist die Haftungs- und Versicherungsfrage geklärt?

Fazit: Prototypen ja, aber mit klarer Grenze

Vibe Coding ist ein starkes Werkzeug, und es wird bleiben. Es senkt die Hürde, Ideen auszuprobieren, und das ist ein echter Gewinn. Gefährlich wird es nicht durch das Werkzeug, sondern durch die Annahme, dass ein funktionierender Prototyp schon ein fertiges Produkt sei.

Der Weg von einem zum anderen ist Software Engineering: Sicherheit von Anfang an, Tests, die Sonderfälle abdecken, geordnete Änderungen, zuverlässiger Betrieb und dauerhafte Pflege. Das sind keine Feinheiten, sondern der größte Teil der Arbeit. Und es ist der Teil, der über Ihre Mandantendaten und Ihren Ruf entscheidet.

Aus unserer Sicht ergeben sich drei sinnvolle Wege:

1. Prototypen als Ideenlabor nutzen. Bauen Sie, probieren Sie aus, lernen Sie, aber ausschließlich mit Testdaten und außerhalb des Tagesgeschäfts.
2. Den Prototyp als Lastenheft verwenden. Was Sie gebaut haben, zeigt präzise, was Sie brauchen. Das ist eine ideale Grundlage, um eine professionelle Umsetzung zu beauftragen oder eine bestehende Lösung sorgfältig zu bewerten.
3. Wenn Sie selbst in den Produktivbetrieb gehen, holen Sie Engineering-Erfahrung dazu. Mindestens für die Sicherheitsarchitektur, die Testabdeckung und den Betrieb. Nicht am Ende, sondern von Anfang an.

Die wichtigste Frage vor jedem Einsatz lautet: Was passiert, wenn dieses Werkzeug falsch, gar nicht oder von Unbefugten benutzt wird? Können Sie darauf keine beruhigende Antwort geben, ist das Werkzeug noch ein Prototyp, und sollte auch so behandelt werden.

Häufige Fragen

Darf ich als Steuerberater eine selbst per KI gebaute App nutzen?

Grundsätzlich ja, es gibt kein Verbot. Sie tragen aber dieselbe Verantwortung für Datenschutz, Verschwiegenheit und Datensicherheit wie bei jedem anderen Werkzeug. Entscheidend ist, ob Sie diese Anforderungen nachweisbar erfüllen können.

Was ist der Unterschied zwischen einem Prototyp und einer produktiven Anwendung?

Ein Prototyp zeigt, dass eine Idee grundsätzlich funktioniert, meist mit Testdaten und ohne Absicherung. Eine produktive Anwendung verarbeitet echte Daten zuverlässig, sicher und nachvollziehbar und ist so aufgebaut, dass sie im Fehlerfall wiederhergestellt und dauerhaft gepflegt werden kann.

Warum ist KI-generierter Code oft unsicher?

KI-Assistenten optimieren auf Funktionalität, nicht auf Widerstandsfähigkeit. Sicherheitsmaßnahmen wie Rechteprüfung, Eingabevalidierung oder sicherer Umgang mit Zugangsdaten fehlen häufig, wenn niemand ausdrücklich danach fragt und das Ergebnis überprüft.

Kann ich die KI den eigenen Code auf Sicherheit prüfen lassen?

Als zusätzliche Kontrolle ist das sinnvoll. Eine unabhängige Prüfung ersetzt es nicht, weil die KI Ihre Infrastruktur und Konfiguration nicht kennt und ihren eigenen Code mit denselben blinden Flecken bewertet, mit denen sie ihn erzeugt hat.

Welche Daten sollte ich in einem selbstgebauten Tool niemals verwenden?

Echte Mandantendaten gehören erst in ein System, dessen Sicherheit, Betrieb und datenschutzrechtliche Grundlagen geklärt sind. Für Experimente eignen sich erfundene oder anonymisierte Testdaten.

Was gehört zu einem professionellen Software-Betrieb?

Versionsverwaltung, getrennte Test- und Produktivumgebungen, automatisierte Tests, kontrollierte Updates, Überwachung, getestete Backups, dokumentierte Zuständigkeiten sowie ein Plan für Sicherheitsvorfälle.

Wann lohnt sich Eigenbau, wann professionelle Unterstützung?

Eigenbau eignet sich für Experimente, Ideenfindung und kleine, unkritische Hilfsmittel ohne sensible Daten. Sobald Mandantendaten, mehrere Nutzer oder geschäftskritische Abläufe im Spiel sind, sollte Engineering-Erfahrung von Anfang an eingebunden werden.

Was ist mit „Bus-Faktor“ gemeint?

Der Bus-Faktor beschreibt, wie viele Personen ausfallen dürfen, bevor ein Projekt gefährdet ist. Ist er bei einem Kanzleitool eins, hängt der Betrieb an einer einzelnen Person.

Ist ein Tool, das nur lokal läuft, automatisch sicher?

Nein. Auch ein rein lokal genutztes Werkzeug kann über den Browser, über verseuchte Programmbausteine oder über einen KI-Agenten mit weitreichenden Rechten angegriffen werden. Bei einer Anbindung an sensible Systeme wie DATEV gilt dieselbe Sorgfalt wie bei einer öffentlich erreichbaren Anwendung.

Was ist das Risiko bei Programmbausteinen aus dem Internet?

Fertige Programmbausteine (Bibliotheken) sparen Zeit, können aber selbst Schadcode enthalten, der teils schon bei der Installation ausgeführt wird. Die Zahl solcher bösartigen Bausteine ist 2025 deutlich gestiegen, auch begünstigt durch KI-Assistenten, die gelegentlich Namen nicht existierender Bausteine erfinden, die Angreifer dann gezielt besetzen.

Quellen

• Frederick P. Brooks Jr.: The Mythical Man-Month: Essays on Software Engineering (1975)
• Robert L. Glass: Facts and Fallacies of Software Engineering (2003)
• Meir M. Lehman: Programs, Life Cycles, and Laws of Software Evolution, Proceedings of the IEEE (1980)
• Veracode: 2025 GenAI Code Security Report und Folgeauswertung 2026
• Sonatype: 2026 State of the Software Supply Chain Report
• ReversingLabs: 2026 Software Supply Chain Security Report