Es gibt einen Satz, den ich immer öfter höre, fast nebenbei gesagt, während man einen Call beendet und zu den „echten“ Dingen zurückkehrt: uns interessiert das Go-Live. Compliance ist eure Sache.
Es ist nicht immer Arroganz. Im Gegenteil, meist das Gegenteil. Es ist ein Satz, gesprochen mit der Selbstverständlichkeit dessen, der Compliance für ein technisches Detail hält — wie die Wahl eines Frameworks oder die Frage, ob der Button rechts oder links steht.
Nur ändert dieses „Detail“ gerade seine Form. Und es wird, viel schneller, als der Markt zuzugeben bereit ist, zu einer Frage der Verantwortung.
Was der Kunde kauft und was der Anbieter verkauft
Jahrelang haben wir uns in der Auftragsentwicklung mit einem ziemlich einfachen impliziten Pakt verstanden. Der Kunde beschreibt, was er will, der Anbieter baut es, man einigt sich auf Zeit und Kosten, bei der Übergabe wird abgenommen, dann geht es in Produktion, fertig.
In diesem Modell endete die „schwere“ Verantwortung fast immer im Projektperimeter. Wenn etwas schiefging, redete man von Bugs, Ausfällen, vielleicht einer Vertragsstrafe. Lästig, sicher, aber beherrschbar.
Der Punkt ist: in Europa kommt zwischen 2025 und 2027 ein Perspektivwechsel, der diesen Pakt weniger stabil macht. Es ist keine einzelne Verordnung, die du ignorieren kannst, bis die Mail vom Justiziar kommt. Es ist ein Bündel von Regeln, das im Ganzen in eine klare Richtung drückt: Software wird zunehmend wie ein Produkt behandelt.
Und wenn etwas ein Produkt ist, haftet, wer es „produziert“, nicht mehr nur vertraglich. Er haftet auch für Mängel — ähnlich wie bei einem Haushaltsgerät, das Schäden verursacht, weil es schlecht entworfen oder zusammengebaut wurde.
Die kommerzielle Schieflage, die Reibung erzeugt
Hier entsteht die echte Reibung — jene, die später in Verhandlungen und Angeboten explodiert.
Der Auftraggeber denkt linear und, aus seiner Sicht, korrekt. Er will eine funktionierende Plattform, ein Portal, eine App. Er will sie zu einem Termin, mit einem Budget, mit den Funktionen, die das Business braucht.
Der Anbieter dagegen hat eine wachsende Last an Anforderungen, die fast nie im Brief stehen. Du findest sie nicht in den User Stories, siehst sie nicht in den Mockups, der Product Owner verlangt sie nicht. Und doch verwandelt ihr Fehlen ein „ausgeliefertes“ Projekt in ein „riskantes“ Projekt.
Ich rede von technischer Dokumentation in einer bestimmten Form, Nachvollziehbarkeit der Komponenten, Schwachstellenmanagement, Transparenz bei bestimmten algorithmischen Entscheidungen, Barrierefreiheit. Alles Tätigkeiten mit einer Gemeinsamkeit: sie kosten Zeit, Kompetenz, Prozess.
Und dann kommt das Dilemma, das meiner Ansicht nach immer toxischer wird.
Stehen sie im Angebot, bist du womöglich teurer als der Wettbewerb, der sie weglässt.
Lässt du sie weg, verschluckst du sie in der Marge, arbeitest mit Verlust und nimmst zusätzlich ein nicht offengelegtes Risiko mit.
Keiner der beiden Wege ist auf Dauer tragbar.
Warum „das war schon immer so“ nicht mehr trägt
Im italienischen B2B haben wir jahrelang in einer Kultur des „machen wir, schauen wir später“ gelebt. Leichte Verträge, vage Spezifikationen, viel persönliches Vertrauen. Manchmal hat das auch funktioniert, das streite ich nicht ab. Vielleicht weil der Kontext es zuließ.
Jetzt aber ändern sich drei Dinge gleichzeitig, und die Kombination ist es, die Angst macht.
Das erste ist eine eher „objektive“ Haftung. In manchen Szenarien reicht „wir waren nicht fahrlässig“ nicht mehr. Es zählt der Mangel und der Schaden. Und in bestimmten Fällen verschiebt sich die Beweislast, dass kein Mangel vorlag, auf den, der produziert oder in den Markt gebracht hat.
Das zweite ist die Erweiterung des Perimeters. Software ist nicht nur, was du selbst schreibst. Sie ist auch, was du integrierst: Open-Source-Bibliotheken, Cloud-Dienste, Drittanbieter-APIs, KI-Modelle. Und wenn das alles ins Endprodukt einfließt, muss jemand verantworten, wie es ausgewählt, integriert und überwacht wurde.
Das dritte ist die Zeit. Wir reden nicht von ferner Zukunft. Wir reden von Fristen zwischen 2026 und 2027. Der Code, den du jetzt schreibst, wird mit hoher Wahrscheinlichkeit noch da sein, wenn diese Regeln voll greifen.
Da frage ich mich, ob es nicht naiv ist, Compliance weiter wie eine Fußnote zu behandeln.
Das Gespräch, das niemand führen will
Das Schwierigste ist nicht, die Norm zu verstehen. Es ist, darüber zu reden, ohne den Vertriebstisch zu sprengen.
Versuch mal, einem Kunden zu sagen, dass das Angebot um 20 % steigt, weil du konforme technische Dokumentation produzieren, einen Schwachstellenmanagementprozess einführen und ein aktuelles Komponenteninventar führen musst.
Im besten Fall antwortet er mit langem Schweigen.
Im schlechtesten sagt er, jemand anders mache es ohne.
Und hier bricht der Markt auseinander. Denn dieses „ohne“ bedeutet selten „effizienter“. Oft bedeutet es „Compliance-Schuld“ — Arbeit und Risiko in die Zukunft verschoben. Eine Zukunft, in der mit den neuen Regeln die Rechnung beim Anbieter, beim Auftraggeber oder bei beiden landen kann.
Und doch führt fast niemand dieses Gespräch, jedenfalls nicht ausdrücklich. Es ist unbequem. Es zwingt den Kunden zu akzeptieren, dass Compliance reale Kosten hat. Und es zwingt den Anbieter, diese Kosten zu erklären, ohne sich hinter Worten zu verstecken, die nach Bürokratie klingen.
Die Kosten der Unsichtbarkeit
Es gibt ein Paradox, das alles erschwert. Compliance-Aktivitäten sind, gut gemacht, unsichtbar.
Ein ernsthaftes Schwachstellenmanagement fällt dann auf, wenn nichts passiert.
Technische Dokumentation wird wertvoll, wenn etwas schiefgeht.
Ein Komponenteninventar (sprich: aktuelle Liste der Abhängigkeiten) ist genau an dem Tag wirklich Gold wert, an dem eine kritische Schwachstelle bekannt wird und du sofort wissen musst, ob du betroffen bist.
Der Kunde sieht das Feature, sieht das Go-Live, sieht die Oberfläche. Alles, was dieses Ergebnis langfristig trägt, bleibt unter dem Boden.
Vielleicht ist das Problem also nicht, dass der Kunde „nicht zahlen will“. Es ist, dass er nicht wahrnimmt, was er kauft.
Wenn du zu einer Unternehmerin gehst und sagst „wir müssen ein konformes Software Bill of Materials einführen“, verlierst du ihre Aufmerksamkeit nach wenigen Worten.
Wenn du stattdessen sagst „wir müssen innerhalb von 24 Stunden wissen können, ob eine eben veröffentlichte Schwachstelle dein Produkt — und damit deine Verantwortung — gefährdet“, sprichst du die Sprache des Risikos. Eine viel universellere Sprache.
Was sich in der Praxis ändert, ohne alles zum Albtraum zu machen
Für Anbieter ist der Weg eng, aber recht klar. Compliance darf nicht länger wie ein versteckter Kostenpunkt behandelt werden, sondern als ausdrückliche Leistung mit erzählbarem Wert.
Das heißt zum Beispiel: funktionale Entwicklung und Sicherheits-/Compliance-Wartung trennen. Nicht in einer undefinierten „Jahrespauschale“, sondern als Position, die sagt, was sie wirklich abdeckt. Auch weil, wenn morgen etwas zur Diskussion steht, Mehrdeutigkeit niemandem hilft.
Es heißt: schwarz auf weiß in den Verträgen, wer was tut. Wer aktualisiert die Abhängigkeiten? Wer überwacht die Schwachstellen? Wer erstellt und pflegt die technische Dokumentation? Wer entscheidet, ob eine Bibliothek verwendet werden darf? Wer haftet, wenn ein Bauteil sich als kompromittiert erweist?
In vielen italienischen Verträgen gibt es diese Fragen schlicht nicht. Und wenn eine Frage nicht existiert, kommt die Antwort immer im schlechtesten Moment.
Es heißt auch: lernen, diese Tätigkeiten als das zu verkaufen, was sie sind — Risikoreduktion. Denn der Kunde kauft keine „Compliance“. Er kauft die Möglichkeit, nicht mit einem rechtswidrigen Produkt, einem schlecht gemanagten Sicherheitsvorfall oder einem Streitfall ohne Beweise und Dokumente dazustehen.
Für Auftraggeber ist der Mentalitätswechsel spiegelbildlich. Compliance ist eure Sache ist keine bequeme Position mehr — und war nie wirklich eine sichere. Wenn du ein digitales Produkt in den Markt bringst, auch wenn du es von Dritten entwickeln ließest, verdunstet die Verantwortung nicht.
Du kannst dich höchstens vertraglich am Anbieter regressieren. Aber inzwischen trägst du Schaden, Reputation, Vorfallmanagement und kommerzielle Folgen selbst.
Eine Frage der Marktreife
Wenn man genauer hinsieht, gleicht das Geschehen einer erzwungenen Reife. Der Softwaremarkt, vor allem das Auftragsgeschäft, geht von einem handwerklichen Modell, das auf Vertrauen und impliziten Absprachen beruhte, zu einem industrielleren über, in dem Verantwortlichkeiten definiert sind, Prozesse dokumentiert und Qualität nicht mehr nur „läuft auf meinem Handy“ heißt.
Das ist nicht zwingend eine schlechte Nachricht.
Für seriöse Anbieter kann es ein Weg werden, sich von jenen abzuheben, die nur über das Kürzen von Ecken konkurrieren.
Für bewusste Auftraggeber kann es eine Garantie sein: zu wissen, dass die Software nicht nur fürs Online-Gehen gebaut ist, sondern um Vorfälle zu überstehen und beim ersten Stoß nicht zum juristischen Problem zu werden.
Vielleicht lautet der richtige Satz heute nicht „Compliance ist eure Sache“. Sondern etwas Ehrlicheres und Nützlicheres: Compliance ist Teil des Produkts.
Und ja, dann ist sie ein struktureller Kostenpunkt des Softwaremachens. Je früher man das anerkennt, desto eher kann man sie steuern. Und mit etwas Mut sogar in einen Wettbewerbsvorteil verwandeln.
Was du mitnimmst
Die Verantwortung für ein in den Markt eingebrachtes digitales Produkt verschwindet nicht, indem man sie an den Anbieter delegiert: sie bleibt beim Auftraggeber.
Der Kunde kauft keine Compliance, er kauft Risikoreduktion — das zu übersetzen ist die Vertriebsarbeit von 2026.
Der italienische Markt verlässt ein handwerkliches Modell aus leichten Verträgen und stiller Vertrauensbasis; die Rechnung für den Aufschub kommt.
Gut gemachte Compliance ist unsichtbar, solange sie funktioniert: deshalb wird sie nicht gesehen, und deshalb muss sie verkauft werden.
Fragen & Antworten
Was bedeutet, dass Software zu einem Produkt mit rechtlicher Verantwortung wird?
Es bedeutet, dass die neue europäische Produkthaftungsrichtlinie (PLD, in Kraft seit 9. Dezember 2026) und der Cyber Resilience Act Software wie ein Industrieerzeugnis behandeln. Wer sie auf den Markt bringt, haftet für Mängel — nicht mehr nur vertraglich, sondern objektiv, wie bei einem Haushaltsgerät oder einem Medikament. Die Last, zu beweisen, dass das Produkt konform war, verschiebt sich auf den Hersteller.
Wenn ein Kunde sagt ‚Compliance ist eure Sache', kann der IT-Anbieter sie ignorieren?
Nein, und der Kunde sollte das auch nicht sagen. Die Verantwortung für ein in den Markt gebrachtes digitales Produkt verschwindet nicht, wenn du es von Dritten entwickeln lässt: du kannst dich höchstens vertraglich am Anbieter regressieren, aber inzwischen managst du Schaden, Vorfall und Reputation. Für den Anbieter heißt Ignorieren: Aufwand und Risiko in der Marge schlucken — auf Dauer untragbar.
Wie schreibt man ein Angebot mit Compliance, ohne gegen die zu verlieren, die sie weglassen?
Indem man funktionale Entwicklung und Wartung von Sicherheit/Compliance als getrennte Vertragspositionen ausweist und Compliance aus der Bürokratiesprache in die Risikosprache übersetzt. Nicht ‚wir implementieren ein konformes SBOM’, sondern ‚wir wissen innerhalb von 24 Stunden, ob eine frisch veröffentlichte Schwachstelle dein Produkt gefährdet’. Der Kunde kauft Risikoreduktion, nicht abstrakte Compliance.
Warum trägt das traditionelle italienische Vertragsmodell nicht mehr?
Weil es auf drei Annahmen beruhte, die gemeinsam wackeln: Haftung beschränkt auf das Vertragliche, Perimeter beschränkt auf intern geschriebenen Code, und Zeit, später nachzubessern. Die neuen EU-Regeln 2026–2027 verschieben die Haftung ins Objektive, weiten den Perimeter auf alle Abhängigkeiten (Open Source, Cloud, APIs, KI-Modelle) aus, und haben bereits operative Fristen. Leichte Verträge und schwammige Spezifikationen, die vor zehn Jahren reichten, sind heute Schulden, die jemand bezahlen wird.
Der Autor
