Wem gehört Ihr digitales Tool wirklich?

Drei unterschiedliche Eigentumsformen bestimmen, wem ein digitales Tool wirklich gehört: der Code, der es zum Laufen bringt, die Daten, die es enthält, und die Konfiguration oder das Modell, das Ihre Geschäftsregeln kodiert. Ein Vertrag, der ein zugängliches Code-Repository, einen jederzeit möglichen Export und das Recht garantiert, das Tool durch einen Dritten weiterentwickeln zu lassen, erfüllt alle drei Punkte. Die meisten SaaS-Verträge – und ein Teil schlecht formulierter Verträge für massgeschneiderte Entwicklungen – erfüllen keinen einzigen davon.

Drei Eigentumsformen, drei unterschiedliche Fragen

Die erste Eigentumsform ist der Code. Gibt es ein Repository – einen Ort, an dem der Quellcode versioniert und datiert existiert –, zu dem Sie echten Zugang haben, oder nur das Versprechen, dass er Ihnen auf Anfrage ausgehändigt wird? Der Unterschied zwischen beidem zeigt sich erst an dem Tag, an dem die Beziehung angespannt ist.

Die zweite sind die Daten. Können Sie diese vollständig, in einem nutzbaren Format, genau dann exportieren, wenn Sie es entscheiden, oder müssen Sie ein Support-Ticket eröffnen und auf das Wohlwollen eines Anbieters warten? Diese Frage vertiefe ich in Wie man Daten aus einem SaaS migriert, ohne etwas zu zerstören.

Die dritte Eigentumsform wird am häufigsten vergessen: die Konfiguration oder das Modell. Die Workflows, die geduldig in einem No-Code-Tool aufgebaut wurden, die Geschäftsregeln, die in einem ERP parametrisiert wurden, das Feintuning eines KI-Modells auf Ihren eigenen Daten – all diese Arbeit hat einen echten Wert, existiert aber oft ausschliesslich innerhalb eines Tools, das Ihnen nicht gehört. Am Tag, an dem Sie gehen, bleibt diese Logik beim Anbieter, weil sie nie wirklich Ihnen gehörte, sondern nur mitgemietet wurde.

Was bedeutet „Eigentümer" konkret in einem Vertrag?

Das Wort „Eigentümer" schleicht sich leicht in eine Verkaufsbroschüre ein und weitaus schwerer in eine präzise Vertragsklausel. Drei Elemente verwandeln die Absicht in eine überprüfbare Realität.

Ein Code-Repository, das laufend zugänglich ist und nicht nur einmal bei Projektabschluss übergeben wird: Sie müssen jederzeit darauf zugreifen können, nicht erst, wenn der Dienstleister beschliesst, es Ihnen zu öffnen. Ein Selbstbedienungs-Datenexport, verfügbar ohne Abhängigkeit von einem Eingriff des Anbieters – der Unterschied zwischen einem Knopf, den Sie selbst drücken, und einer Anfrage, die Sie stellen und auf eine Antwort hoffen. Und das ausdrückliche Recht, das Tool durch einen Dritten weiterentwickeln zu lassen: ohne Exklusivklausel, die Sie für jede künftige Änderung an den ursprünglichen Anbieter bindet, und mit ausreichender Dokumentation, damit ein anderer Entwickler die Arbeit übernehmen kann, ohne raten zu müssen.

Ein Tool zu besitzen setzt also diese drei unterschiedlichen Eigentumsformen voraus – den Code, die Daten, die Konfiguration oder das Modell –, die jeweils derselben Anforderung genügen müssen: echter Zugang, kein Versprechen.

Gut gemachte Massanfertigung liefert den Code standardmässig

Das ist eine Verpflichtung, die ich in meiner Arbeit für nicht verhandelbar halte: Wenn ich ein massgeschneidertes Tool baue, gehört das Code-Repository dem Kunden vom ersten Tag an, ohne dass er danach fragen muss, und ohne Mehrkosten für den Zugang. Die Website, die Sie gerade lesen, mcva.ch, wurde genau nach diesem Prinzip neu aufgebaut – zugänglicher, dokumentierter, übertragbarer Code, falls ich eines Tages nicht mehr der Einzige bin, der daran arbeitet.

FiscalDoc, die lokale Anwendung, die ich für meine eigene Steuererklärung gebaut habe, treibt dasselbe Prinzip auf die Spitze: Ich besitze das Tool, ich besitze den Code, ich besitze die Daten, ich besitze sogar das KI-Modell, das sie analysiert. Ich habe diesen Fall dokumentiert in FiscalDoc: 1'400 CHF/Jahr SaaS durch lokale KI ersetzen. Es ist keine Frage des Vertrauens gegenüber dem Dienstleister, sondern eine Frage des Vertrags, und ein gut abgestecktes massgeschneidertes Projekt regelt das von Anfang an, nicht nachträglich.

Die Fallen hausgemachter CMS und gefangener Konfigurationen

Die trügerischste Falle ist nicht das klassische SaaS, das man recht leicht als gemietet erkennt. Es ist das „hausgemachte" CMS oder Tool, gebaut von einer Agentur, präsentiert als eigenständiger Vermögenswert des Unternehmens, obwohl der Code nirgendwo dokumentiert ist, kein Repository ausserhalb dieser Agentur zugänglich ist und jede noch so kleine Weiterentwicklung zwingend über sie laufen muss. Das Wort „massgeschneidert" hat als Verpackung für eine Sperre gedient, die ebenso strikt ist wie ein geschlossenes SaaS – manchmal sogar strikter.

Die gefangene Konfiguration folgt derselben Logik auf einem anderen Weg. Wochen, die damit verbracht wurden, Automatisierungen in einem No-Code-Tool zu parametrisieren, komplexe Szenarien in einem CRM aufzubauen, Regeln in einem ERP zu verfeinern: Diese Arbeit hat einen echten Wert, existiert aber nur innerhalb der Lizenz, die sie zum Laufen bringt. Am Tag, an dem Sie gehen wollen, lässt sich diese Logik nicht exportieren – sie bleibt in einem Format eingeschlossen, das nur der Anbieter lesen kann.

Einige Anzeichen verraten recht zuverlässig ein Tool, das Ihnen nicht wirklich gehört:

• kein zugängliches Code-Repository, nur das Wort des Dienstleisters;
• der Export erfordert ein Support-Ticket statt eines Selbstbedienungs-Klicks;
• keine technische Dokumentation erlaubt einem Dritten, die Arbeit zu übernehmen;
• niemand ausser dem ursprünglichen Anbieter konnte je wirklich eingreifen;
• Ihre Geschäftslogik existiert nur in einem proprietären Format, das anderswo unlesbar ist.

Wie Sie schon heute prüfen können, was Ihnen gehört

Die Übung erfordert für den Anfang keine tiefe juristische Expertise: Stellen Sie jedem Dienstleister in Ihrem Software-Stack dieselben drei grundlegenden Fragen – wo ist der Code, wie kommen die Daten heraus, wer kann das Tool morgen weiterentwickeln. Die Antworten, oder ihr Fehlen, verorten Sie sofort auf der Skala des echten Eigentums.

Diese Bestandsaufnahme knüpft an die an, die ich in nDSG: Wo schlummern die Daten Ihres KMU wirklich? empfehle: zu wissen, wo Ihre Daten leben, ist die halbe Arbeit, zu wissen, wer die Schlüssel dazu hat, die andere Hälfte. Sie knüpft auch an die Frage des Hostings an – ein Schweizer Hosting sagt nichts über das Eigentum des darauf laufenden Codes aus, wie ich in In der Schweiz hosten: Was das wirklich verändert darlege – und an die Frage des Ausstiegs, für den Tag, an dem sich das Eigentum als unzureichend erweist und eine Migration nötig wird, behandelt in Wie man Daten aus einem SaaS migriert, ohne etwas zu zerstören.

Der richtige Zeitpunkt, diese drei Eigentumsformen zu klären, ist nie nach einem Streit. Es ist vor der Unterschrift oder andernfalls bei der nächsten Verlängerung – einer der Punkte, die ich bei der Abgrenzung einer massgeschneiderten Lösung systematisch prüfe, und eines der Themen, auf die ich in Was sollte ein Schweizer KMU 2026 im Umgang mit KI tun? zurückkomme.

Wichtig in Kürze

— Ein digitales Tool besitzt man durch drei unterschiedliche Eigentumsformen: den Code, die Daten und die Konfiguration oder das Modell, das Ihre Geschäftsregeln kodiert. — „Eigentümer" bedeutet nichts ohne ein zugängliches Code-Repository, einen Selbstbedienungs-Export und das Recht, das Tool durch einen Dritten weiterentwickeln zu lassen. — Massanfertigung schützt nicht automatisch vor Einsperrung: ein schlecht dokumentiertes hausgemachtes CMS kann ebenso sperren wie ein geschlossenes SaaS.

FAQ

Wenn ich für eine massgeschneiderte Entwicklung bezahlt habe, gehört mir der Code dann automatisch? Nicht zwangsläufig. Alles hängt von den Vertragsbedingungen ab: eine ausdrückliche Rechteübertragung hat nichts mit einer einfachen Nutzungslizenz zu tun, selbst wenn die Rechnung identisch aussieht. Prüfen Sie – bei bereits unterzeichneten wie bei künftigen Verträgen – die Klausel zum geistigen Eigentum, statt sie einfach als günstig vorauszusetzen.

Ist ein von meiner Agentur gebautes „proprietäres" CMS zwangsläufig ein Problem? Nicht zwangsläufig, aber es verdient eine Überprüfung. Ein zugängliches, dokumentiertes Code-Repository bleibt auch bei einem einzigen Dienstleister handhabbar. Das eigentliche Problem entsteht, wenn nichts dokumentiert ist und niemand sonst übernehmen könnte, sollte die Beziehung morgen enden.

Ich stelle fest, dass mir nichts von dem gehört, was ich zu besitzen glaubte – was tun? Beginnen Sie mit einer Bestandsaufnahme statt mit einer Konfrontation: welche Tools, welche Daten, welcher Code, bei wem. Bringen Sie die Eigentumsfrage dann bei der nächsten Vertragsverlängerung ein – der Moment, in dem der Anbieter am meisten zu verlieren hat, wenn er ablehnt. Für wirklich kritische Tools wird ein massgeschneiderter Neuaufbau manchmal zur langfristig sichersten Lösung.

Gehört mir ein KI-Modell, das ich bei einem Anbieter feinjustiert habe? Im Allgemeinen nicht, standardmässig nicht: Das Basismodell bleibt Eigentum des Anbieters, und Ihr Feintuning bleibt meist lizenziert statt übertragen. Die Bedingungen variieren stark von Anbieter zu Anbieter – eine Klausel, die man lesen sollte, bevor man Zeit in die Feinjustierung eines Modells investiert, nicht danach.

Kostet der Besitz des eigenen Codes zwangsläufig mehr als die Miete eines SaaS? Nicht systematisch, und der Abstand hat sich in den letzten Jahren verringert: KI-gestützte Entwicklung hat die Baukosten eines massgeschneiderten Tools gesenkt, wie ich mit FiscalDoc dokumentiert habe. Die Frage verdient es, funktionsweise neu gestellt zu werden, statt aus Gewohnheit entschieden zu werden.

Sie könnten heute nicht sagen, wer wirklich den Code Ihrer Tools hält? Die KI-Nutzungsdiagnose: sechzig Minuten, um Ihre tatsächlichen Abläufe darzulegen, zu identifizieren, was eine Massanfertigung verdient, was in SaaS bleibt und was gar keine KI braucht. Diagnose buchen

Jérôme Deshaie ist CEO und Gründer von MCVA Consulting SA, einer augmentierten Agentur mit Sitz im Wallis. Fünfzehn Jahre im Dienst grosser internationaler Marken, jetzt direkt für Schweizer KMU tätig. Werdegang.