KI entwickelt unsere Software. Wie souverän macht uns das?

Eine neue Freiheit – und eine neue Frage

Ein Mann entwickelt mit KI Alternativen zu Word, Excel und Photoshop. Matthias Schüssler beschreibt in seinem Artikel vom 17. Oktober 2026 die Craft-Apps von Brandon Thomas: erstaunlich schnell entstanden, teilweise brauchbar, aber mit deutlichen Schwächen. Die Angaben zur Entstehung und Codeherkunft stammen aus dem bereitgestellten Artikel; unabhängig geprüft habe ich die Anwendungen nicht.

Mich interessiert daran mehr als die Aussicht auf ein eingespartes Abo. Was verändert sich, wenn wir uns Software zunehmend selbst erstellen lassen? Gewinnen wir Gestaltungsspielraum – oder verlagert sich die Abhängigkeit vom Produkt zum Modell, das wir für seine Weiterentwicklung benötigen?

Eigener Code ist ein Anfang

Eine kleine Anwendung nach den eigenen Anforderungen kann eine sinnvolle Alternative zu einer umfangreichen Standardlösung sein. Gerade bei knappen IT-Fachkräften ist die Aussicht attraktiv, mehr Vorhaben mit vorhandenen Teams umzusetzen.

Für mich reicht der Besitz des Quellcodes als Souveränitätsmassstab aber nicht aus. Wir brauchen auch das Wissen, die Rechte und die technischen Mittel, ihn weiterzuentwickeln. Wenn nur ein bestimmter Agent die Anwendung noch versteht und das Team jede Änderung von diesem Werkzeug abhängig macht, bleibt die Kontrolle eingeschränkt. Das ist ein mögliches organisatorisches Risiko, keine zwangsläufige Folge von KI.

Umgekehrt macht die Nutzung eines grossen Modells eine Anwendung nicht automatisch unsouverän. Ein externes Werkzeug kann zeitweise helfen, während Code, Dokumentation, Tests und Betriebswissen anschliessend bei der Organisation verfügbar bleiben.

Zwei Abhängigkeiten, zwei unterschiedliche Folgen

Ein mit KI erstelltes Formular kann je nach Architektur ohne weitere Modellverbindung funktionieren. Ein Formular, dessen Eingaben laufend von einem externen Modell ausgewertet werden, hat eine andere Abhängigkeit. Und eine unabhängige Fachanwendung kann durch ihren KI-gestützten Betriebsprozess erneut an einen Anbieter gebunden werden. Diese Ebenen müssen wir getrennt prüfen.

Modellwechsel sind bereits heute ein konkretes Wartungsthema: Anthropic dokumentiert die Stilllegung älterer Modelle und weist darauf hin, dass darauf beruhende Anwendungen Anpassungen benötigen können. Das ist kein Beweis gegen den Anbieter, sondern ein nachvollziehbarer Grund, Migrationen und Tests einzuplanen. [16]

Die Auswahl mehrerer Modelle in einer Entwicklungsumgebung ist bereits möglich, etwa in Visual Studio Code. Daraus leite ich jedoch keine vollständige Portabilität ab: Modellwechsel und Wechsel der gesamten Werkzeugkette sind unterschiedliche Prüfaufgaben. Modell, Entwicklungsumgebung und Agentensteuerung müssen wir jeweils gesondert betrachten. [17]

Die Souveränitätsfrage zieht sich durch den ganzen Lebenszyklus

Die folgenden Einsatzfelder sind mein vorgeschlagenes Arbeitsmodell. Sichere Entwicklung, Schutz der Software und der Umgang mit Schwachstellen gehören zusammen; das NIST-Framework SSDF bietet dafür technische Orientierung, keine Schweizer Rechtsvorgabe. [10]

GitHub empfiehlt selbst, KI-generierten Code zu prüfen und gründlich zu testen. Im Betrieb lässt sich das Prinzip an einem anderen Produkt illustrieren: Der Azure SRE Agent sieht einen Review-Modus vor, in dem vorgeschlagene Eingriffe eine Freigabe verlangen. Diese Herstellerdokumentation belegt Funktionen und Grenzen, keine allgemeine Produktivität oder Sicherheit. [11, 12]

Das Fachkräftepotenzial ist realistisch zu bewerten

Eine 2026 publizierte Studie mit 4’867 Entwicklern aus drei randomisierten Feldexperimenten ermittelte rund 26 Prozent mehr erledigte Aufgaben mit KI-Unterstützung. Die Ergebnisse variierten; an der Forschung waren Microsoft-Mitarbeitende beteiligt. METR fand dagegen bei 16 erfahrenen Entwicklern mit Werkzeugen von Anfang 2025 eine um 19 Prozent längere Bearbeitungszeit. Neuere METR-Schätzungen wurden wegen Auswahl- und Messproblemen als unzuverlässig eingeordnet. [1] [2] [3]

Auch mehr Aktivität ist noch keine entsprechende Einsparung: Ein im September 2026 revidiertes NBER-Working-Paper mit Daten von über 500’000 GitHub-Entwicklern schätzt kumulativ über die untersuchten Werkzeuggenerationen 240 Prozent mehr Codeänderungen, aber 30 Prozent mehr Releases. Es handelt sich um eine Beobachtungsstudie; zwei Autoren weisen Beratungsbeziehungen zu Microsoft aus. [13]

Diese Befunde liefern Gründe für gezielte Versuche. Sie belegen keine pauschale Nettoeinsparquote von der Anforderungsaufnahme bis zum Betrieb. Weniger Nacharbeit, frühere Klärung und schnellere Störungsbehebung bleiben mögliche Wirkungswege, die wir im eigenen Umfeld messen müssen.

Ich unterscheide zusätzliche Kapazität, vermiedene Kosten und tatsächlich sinkende Ausgaben. Frei werdende Zeit bei gleichem Personalbestand ist zunächst Kapazität. Sie kann helfen, einen Rückstand abzubauen, ohne dass sich das Budget sofort reduziert. Ausbildung und technische Urteilskraft dürfen wir darüber nicht vernachlässigen.

Die Tokenrechnung gehört zur Souveränitätsrechnung

Mit KI kommt ein zusätzlicher Verbrauchsfaktor in die Kalkulation: Tokens, also Verarbeitungseinheiten wie Wortteile. Bei verbrauchsabhängigen Modellzugriffen unterscheiden sich Preise für Eingaben, Ausgaben und wiederverwendeten Kontext. Je nach Modell und Vertrag können auch interne Denkschritte und Werkzeugnutzung Kosten verursachen. Tokenkosten sind technisch nicht neu; neu ist ihre ausdrückliche Berücksichtigung in unserer Softwarekalkulation. [14, 15]

Ein Agent kann Anforderungen lesen, Quellcode verarbeiten, Tests auswerten und Korrekturen mehrfach versuchen. Im Betrieb können weitere laufende Analysen hinzukommen. Der tatsächliche Verbrauch hängt vom Workflow ab. Enthaltene Abokontingente sind dabei zu berücksichtigen, damit Kosten nicht doppelt angesetzt werden.

Ich würde deshalb KI-Kosten je abgenommener Änderung und je Betriebsmonat ausweisen – zusammen mit Personal, Prüfung, Nacharbeit, Infrastruktur und Wartung. Ein Modellwechsel gehört ebenfalls ins Budget. Gerade eine Anwendung mit niedrigen Herstellungskosten kann wirtschaftlich abhängig bleiben, wenn ihre Nutzung dauerhaft an schwer ersetzbare Modellleistungen gebunden ist.

Ein hypothetisches Beispiel: Betrifft eine Zeitersparnis von 20 Prozent nur eine Tätigkeit mit 30 Prozent Anteil am Gesamtaufwand, sinkt dieser zunächst um 6 Prozent. Zusätzliche KI-Kosten sind davon noch abzuziehen. Entscheidend ist der Vergleich der Gesamtkosten bei gleichem Leistungsumfang und Qualitätsniveau.

Die rechtlichen Risiken beginnen vor der ersten Veröffentlichung

Wer Anwendungen mit KI entwickelt, sollte fünf Fragen früh klären. Die folgende Einordnung bezieht sich auf die Schweiz; sie beurteilt die Craft-Apps rechtlich nicht.

1. Woher stammt der Code? Das IGE unterscheidet zwischen einer grundsätzlich freien Idee und ihrer geschützten Ausgestaltung. Insbesondere Quelltext kann urheberrechtlich geschützt sein. Eine vergleichbare Funktion ist deshalb nicht automatisch eine Rechtsverletzung. Die Bezeichnung «Clean-Room-Reimplementierung» belegt umgekehrt noch keine Rechtefreiheit. Bei Produktnachbauten empfehle ich eine dokumentierte Prüfung von Codeherkunft sowie gegebenenfalls Oberflächen, Kennzeichen und weiteren Schutzrechten. [4]

2. Welche Lizenzen gelten? Wenn eine KI geschützte Bestandteile übernimmt, verschwinden deren Rechte nicht durch die Generierung. Eingebundene Bibliotheken und Codebestandteile brauchen eine nachvollziehbare Lizenzgrundlage. Je nach Lizenz und Nutzung können Hinweise, Lizenztexte oder die Bereitstellung von Quellcode erforderlich sein. Ein öffentliches Repository allein ist für mich deshalb keine ausreichende Freigabe. [5, 6]

3. Was lässt sich am eigenen Ergebnis schützen? Nach der Erläuterung des IGE setzt urheberrechtlicher Schutz menschliche schöpferische Leistung voraus. KI als Werkzeug schliesst Schutz nicht aus; rein maschinelle Leistung begründet ihn nicht. Wer Exklusivität oder umfassende Rechte zusichert, sollte den menschlichen Beitrag und fremde Bestandteile deshalb sauber unterscheiden. [5]

4. Welche Daten gelangen zum Anbieter? Bereits ein Prompt, ein Fehlerprotokoll oder eine Testdatei kann Personendaten enthalten. Das Schweizer Datenschutzgesetz gilt auch für KI-gestützte Datenbearbeitung. EDÖB und BACS warnen in ihrer Mitteilung vom 16. Oktober 2026 vor unbeabsichtigter Datenpreisgabe am Arbeitsplatz. Für kantonale und kommunale Behörden sind die jeweiligen kantonalen Datenschutzvorgaben massgebend. [7] [8] [9]

Daraus leite ich eine klare Arbeitsregel ab: Datenflüsse, Aufbewahrung, mögliche Trainingsnutzung und vertragliche Vertraulichkeit vor dem Einsatz klären. Für erste Versuche synthetische Testdaten verwenden. Auch Quellcode, Architekturunterlagen und Fehlerprotokolle können vertrauliche Informationen enthalten. Ich würde Modellanbieter, Entwicklungsumgebung und eingebundene Erweiterungen separat prüfen: Welche Informationen erhält jede Komponente, welche Zugriffe besitzt sie und wie lassen sich diese entziehen?

5. Wer übernimmt Fehler und Folgekosten? Ich empfehle, Abnahme, Wartung, Sicherheitsupdates, Rechtezusicherungen und Haftung vertraglich ausdrücklich zu regeln. Eine pauschale Zusage des KI-Anbieters sollte niemand unterstellen. Ob Ansprüche bestehen, hängt vom konkreten Vertrag und anwendbaren Recht ab.

Mein Ansatz: Abhängigkeiten bewusst gestalten und den Ausstieg erproben

Ich würde die stärksten verfügbaren Modelle dort nutzen, wo ihr Nutzen die Risiken und Kosten rechtfertigt. Gleichzeitig würde ich Anforderungen, Architekturentscheidungen, Tests und Betriebswissen in Formaten sichern, die ausserhalb der jeweiligen KI-Oberfläche nutzbar sind. Modellzugriffe sollten, wo wirtschaftlich sinnvoll, über klar abgegrenzte Schnittstellen erfolgen. Eine technische Zwischenschicht allein garantiert allerdings keine gleiche Qualität beim Ersatzmodell.

Offen verfügbare Modellgewichte und eigener Betrieb können Optionen erweitern. Auch dann sind Lizenz, Hardware, Kompetenzen und Sicherheitsupdates zu prüfen. Selbstbetrieb ist für mich eine mögliche Architekturentscheidung, kein automatischer Souveränitätsnachweis.

Die wichtigste Probe ist konkret: Ein anderes Team soll eine begrenzte Änderung ohne das bisherige KI-Werkzeug umsetzen, testen, bauen und ausliefern. Braucht die Anwendung selbst ein Modell, testen wir zusätzlich einen Ersatz oder einen ausdrücklich definierten eingeschränkten Betrieb. So erkennen wir tatsächliche Wechselkosten, bevor ein Ausfall oder eine Vertragsänderung den Wechsel erzwingt.

Lösungsskizze: Ein Pilot mit nachgewiesener Wechselmöglichkeit

Ziel: Eine begrenzte Anwendung KI-gestützt bereitstellen und ihre technische, organisatorische und wirtschaftliche Steuerbarkeit nachweisen.

Ausgangslage: Vorschlag für ein risikoarmes Vorhaben mit synthetischen Testdaten und dokumentierten Abhängigkeiten.

Lösung: KI über den Lebenszyklus einsetzen. Gleichzeitig Wissen und Artefakte übertragbar halten, Rechte prüfen und Modell-, Werkzeug- sowie Betriebswechsel praktisch erproben.

Ablauf: Bedarf bestätigen → Abhängigkeiten erfassen → entwickeln und unabhängig prüfen → kontrolliert ausliefern → Betrieb beobachten → Wechsel und Wiederherstellung testen.

Verantwortung: Vorschlag: Fachbereich verantwortet Nutzen und Abnahme; Architektur und Entwicklung verantworten technische Entscheidungen; Betrieb verantwortet Überwachung und Wiederherstellung. Datenschutz, Sicherheit, Recht und Beschaffung werden risikogerecht einbezogen.

Ressourcen: Fach- und Prüfzeit, freigegebene Werkzeuge, Tokenbudget, Testumgebung sowie Zeit für Übergabe und Wechseltest einplanen. Umfang und Zeitraum vorab festlegen.

Erfolg erkennbar an: Gesamtaufwand und Kosten je abgenommener Änderung, Fehler und Betriebsaufwand, Tokenkosten sowie Zeit und Aufwand für einen Anbieter- oder Teamwechsel. Ausgangswerte und Qualitätsgrenzen vorab festlegen.

Hauptrisiko: Kurzfristige Beschleunigung verdeckt langfristige Bindung. Gegenmassnahmen: zugängliche Dokumentation, kontrollierte Rechte, geübte Rückfallverfahren und wiederholbare Wechseltests.

Souveränität zeigt sich bei der nächsten Änderung

Beginnt mit KI eine neue Ära der Abhängigkeit? Das Risiko besteht. Ich halte es aber für falsch, daraus eine zwangsläufige Entwicklung abzuleiten. Wir können Gestaltungsspielraum gewinnen, wenn wir die Kontrolle über Wissen, Rechte, Daten und Betrieb bewusst organisieren.

Meine Messlatte lautet deshalb: Können wir die Anwendung auch dann verantwortbar verändern und betreiben, wenn das bevorzugte Modell nicht mehr verfügbar ist? Ein bestandener Test bedeutet nicht vollständige Unabhängigkeit. Er macht aber sichtbar, welche Handlungsoptionen wir tatsächlich besitzen.

Souverän werden wir mit KI, wenn ihre Unterstützung unsere eigene Handlungsfähigkeit stärkt. Dafür müssen wir sie auch wechseln oder zeitweise entbehren können.