Die Zukunft von Enterprise Software

Wie KI die Systems-Engineering-Disziplin zurückbringt – und Dezentralisierung sie beweisbar macht

Veröffentlicht von Polity | Juli 2026
Autoren: Alexandre Kotcherguine, Vision Officer & Investor, Polity;
Kevin Riedl, Managing Partner, Wavect GmbH

Dieser Artikel befasst sich mit Enterprise-Software-Architektur und Engineering-Methodik. Er stützt sich auf öffentlich zugängliche Quellen, darunter Peer-Review- und Preprint-Forschung, Branchenumfragen sowie Berichte von Anbietern und Praktikern mit Stand Mitte 2026. Mehrere der diskutierten Technologien befinden sich noch früh auf ihrer Reifekurve; Aussagen über sie werden entsprechend eingeordnet. Zahlen aus einem sich schnell entwickelnden Feld sind Momentaufnahmen und können revidiert werden. Nichts darin stellt professionelle, rechtliche oder Anlageberatung dar.

Executive Summary

Zwei Jahrzehnte lang verfolgte Enterprise Software Agilität, indem sie Dinge auseinanderbrach. Der Monolith wurde in Microservices zerlegt; die Suite wurde in einen Wildwuchs aus SaaS entbündelt; die Auslieferung wurde beschleunigt, bis sich die Architektur, die alles zusammenhielt, stillschweigend auflöste. Die versprochene Agilität erschien oft als ihr Gegenteil – der Distributed Monolith, ein System mit der gesamten Kopplung der alten Welt und ohne deren Kohärenz, in dem niemand das Ganze besitzt und jede Änderung zu einer Koordinationsübung wird. Was in der Fragmentierung verloren ging, war Systems Engineering: die Disziplin, das Ganze als Gegenstand des Designs zu behandeln, mit expliziten Anforderungen, governten Interfaces, architektonischer Integrität und Verifikation gegen die Absicht. Dieser Artikel argumentiert, dass die nächste Phase den Trend an zwei Fronten zugleich umkehrt. Erstens macht KI den Systems-Engineering-Ansatz im großen Maßstab wieder bezahlbar. Sie erweitert die governte, spezifikationsorientierte „Software Factory“ vom Code auf die Architektur des Gesamtsystems, sodass Absicht wieder erfasst, modelliert und durchgesetzt werden kann, statt zu erodieren. Zweitens, und folgenreicher, härtet Dezentralisierung das Ergebnis: Sie verschiebt die Garantien des Systems von vertrauensbasiert zu verifizierbar – von Verträgen, die auf Papier dokumentiert und durch das Wort einer Organisation gedeckt sind, zu Verträgen, die durch kryptografische Beweise, On-Chain-Attestierung und verteilte Kontrolle durchgesetzt werden, die keine einzelne Partei unbemerkt übersteuern kann. Die Fabrik baut das System; die Chain beweist, dass es sich korrekt verhält. Die ehrlichen Vorbehalte werden vollständig dargelegt: Verifizierbare Berechnung bleibt weit teurer als Ausführung, sie kommt zuerst in High-Stakes-, Low-Volume-Umgebungen statt überall zugleich an, und für einen großen Teil des Inneren eines Unternehmens bleibt das institutionelle Vertrauen, auf dem es bereits beruht, das richtige Werkzeug. Die hier vertretene These lautet nicht, dass kryptografischer Beweis Audits und Verträge ersetzt, sondern dass er Assurance über die Grenzen hinweg erweitert, die diese Instrumente nicht erreichen können. Doch die Richtung ist klar, und sie führt auf vertrautes Terrain: Regulierte On-Chain-Finanzsysteme, die Domäne, in der Polity arbeitet, sind genau dort, wo beweisbare Architektur zuerst verlangt und am frühesten angenommen wird.

Das Zeitalter der Fragmentierung

Die dominante Bewegung in der Enterprise-Architektur der 2010er-Jahre hatte eine klare und weitgehend vernünftige Motivation. Monolithen waren zu „Big Balls of Mud“ geworden – eng gekoppelt, schwer zu ändern, langsam auszuliefern – und Microservices versprachen einen Ausweg: die Anwendung entlang von Business Capabilities zerlegen, jedem Service ein unabhängiges Deployment geben und Teams parallel arbeiten lassen. Für viele Organisationen funktionierte das zunächst. Doch das Muster wurde weithin als Default statt als abgewogener Trade-off übernommen, und das branchenweit wiederholte Ergebnis war ein charakteristischer Fehlermodus, dem Praktiker einen präzisen Namen gaben. Der „Distributed Monolith“ besitzt, so eine häufig zitierte Beschreibung, die operative Komplexität von Microservices ohne die architektonische Unabhängigkeit: Services, die physisch getrennt, aber logisch gekoppelt sind, voneinander abhängige Datenbankschemas, synchronisierte Deployments und lange Aufrufketten, sodass eine Änderung in einem Service drei andere beschädigt und jedes Release zu einer Koordinationsübung wird (1). Die Organisation gewann mehr Repositories, mehr Pipelines, mehr Logs, mehr Fehlermodi und mehr Governance-Aufwand – ohne die Fähigkeit zu gewinnen, sich schneller zu bewegen.

Zur Mitte dieses Jahrzehnts war die Korrektur in den Daten sichtbar, nicht nur in der Fachpresse. Die 2024 Cloud Native Survey der Cloud Native Computing Foundation unter 689 technischen Entscheidungsträgern ergab, dass 42 Prozent der Organisationen, die Microservices eingeführt hatten, Services wieder zu größeren deploybaren Einheiten konsolidierten, während die Nutzung des Service Mesh – der Infrastruktur, die Microservices im großen Maßstab beherrschbar machte – von 18 auf 8 Prozent fiel (2). Das war keine pauschale Abkehr von Verteilung; die Cloud-Native-Adoption insgesamt blieb nahe neunzig Prozent. Es war eine Korrektur verfrühter Einführung, und die konsolidierenden Teams bewegten sich zurück zu modularen Monolithen – einzelnen Deployments mit disziplinierten internen Grenzen – und berichteten von deutlichen Senkungen bei Kosten und Deployment-Zeit. Amazons eigenes Prime-Video-Team hatte die Vorlage geliefert und für einen Monitoring-Workload eine Senkung der Infrastrukturkosten um rund neunzig Prozent gemeldet, indem es eine Microservices-Pipeline wieder in einen Monolithen zusammenführte; der Chief Technology Officer des Unternehmens zog die Moral unmissverständlich: Evolvierbare Systeme zu bauen ist eine Strategie, keine Religion. Die Lehre lautete nicht, dass Verteilung falsch ist, sondern dass sie ein Ziel und kein Startpunkt ist und ihre Vorteile nur jenen offenstehen, die die von ihr verlangte Disziplin aufrechterhalten: verantwortete Interfaces, versionierte Verträge, durchgesetzte Grenzen. Dieser Nebensatz – nur jenen, die die Disziplin aufrechterhalten – ist die ganze Geschichte. Fragmentierung scheiterte nicht, weil Zerlegung eine schlechte Idee ist. Sie scheiterte, weil Zerlegung ohne Systems Engineering nur Entropie mit zusätzlichen Schritten ist.

Was verloren ging: Systems Engineering

Systems Engineering ist die ältere Disziplin, die durch Fragmentierung verdrängt wurde. Sie behandelt das System als Ganzes – nicht als Sammlung unabhängig optimierter Teile – als primäres Designobjekt. Ihre Instrumente sind Anforderungen, die die Absicht vor dem Bau erfassen, Interface-Verträge, die das Zusammenspiel der Teile regeln, Architekturmodelle, die das Ganze lesbar machen, und Verifikation, die das gebaute System gegen das Spezifizierte prüft. Das sind wenig glamouröse Praktiken, und die Move-fast-Kultur der Fragmentierungsära behandelte sie als bürokratischen Ballast, der im Namen der Geschwindigkeit abgeworfen werden müsse. Die Ironie, bekannt aus der früheren Geschichte von Enterprise Agile, besteht darin, dass das Abwerfen der Disziplin keine dauerhafte Geschwindigkeit erzeugte; es erzeugte Systeme, die gerade deshalb langsamer und brüchiger wurden, weil niemand mehr das Ganze pflegte.

Es gibt einen Grund, weshalb die Disziplin aufgegeben und nicht bloß vernachlässigt wurde: Im Maßstab und Tempo moderner Software war Systems Engineering von Hand tatsächlich unbezahlbar. Ein präzises, aktuelles Modell eines großen Systems – seiner Komponenten, Abhängigkeiten, Verträge und Constraints – zu pflegen, war eine arbeitsintensive Aufgabe, die schneller veraltete, als Menschen sie warten konnten. Model-Based Systems Engineering, die formale Disziplin, solche Modelle zu bauen und über sie nachzudenken, gilt seit Langem als leistungsfähig und im selben Atemzug als zu schwergewichtig, als dass die meisten Organisationen sie aufrechterhalten könnten. Der Blick auf das Gesamtsystem war ein Luxusgut. Also hörten Teams auf, ihn zu kaufen, und Architektur verfiel zu dem, was die laufenden Services zufällig waren.

Warum KI die Disziplin zurückbringt

Das Argument des vorherigen Teils dieser Serie lautete, dass KI Engineering-Disziplin nicht abschafft, sondern verlagert – nach oben im Stack, vom Tastenanschlag zur Spezifikation – und dass die governte „Software Factory“ genau dann funktioniert, wenn Handwerk in die Pipeline eingebettet statt aus ihr entfernt wird (3). Eine Ebene weiter gedacht gilt dieselbe Logik für Architektur. Was Systems Engineering unbezahlbar machte, waren die menschlichen Kosten, das Gesamtsystemmodell zu bauen und zu pflegen sowie Absicht, Spezifikation und Implementierung in Einklang zu halten. Genau diese Kosten senkt KI. Große Modelle können heute riesige Legacy-Codebasen analysieren und deren implizite Business Rules und Absicht in menschenlesbare Anforderungen extrahieren – und Modernisierung von einer riskanten Bergungsaktion in ein handhabbares Designproblem verwandeln. Die Systems-Engineering-Community hat ihrerseits begonnen, KI-Copiloten für Model-Based Systems Engineering selbst zu bauen, um die Barriere zu senken, die die Disziplin außer Reichweite hielt (4).

Das Ergebnis ist, dass der Gesamtsystemblick kein Luxusgut mehr sein muss. Eine lebende, versionierte Spezifikation – dasselbe Artefakt, das die agentische Code Factory diszipliniert – wird zur Source of Truth der Architektur, kontinuierlich gegen das laufende System abgeglichen von Agenten, die der Buchhaltung nie müde werden. Interfaces können aus Verträgen generiert und automatisch gegen sie geprüft werden; Architecture Drift kann erkannt werden, während sie entsteht, statt erst in einem Incident; das Modell kann aktuell bleiben, weil seine Aktualisierung nicht länger primär menschliche Arbeit ist. Das ist die Rückkehr von Systems Engineering – nicht als Nostalgie für Waterfall, sondern als eine endlich wirtschaftlich gewordene Disziplin. Das Enterprise-System kann wieder als Ganzes gestaltet werden, weil das Ganze wieder zu vertretbaren Kosten im Blick gehalten werden kann.

Die Grenze von KI allein: Vertraut ist nicht bewiesen

Doch das durch KI wiederhergestellte Systems Engineering führt für sich genommen das Problem, das es löst, in subtilerer Form wieder ein. Eine von einem Agenten abgeglichene Spezifikation bleibt ein Dokument; ein von einer Pipeline durchgesetzter Interface-Vertrag wird weiterhin von demjenigen durchgesetzt, der die Pipeline kontrolliert; ein vom System geschriebenes Audit-Log ist nur so vertrauenswürdig wie die Partei, die es umschreiben kann. Der gesamte Apparat beruht auf delegiertem Vertrauen – der Nutzer verlässt sich darauf, dass die deployende Organisation korrekt spezifiziert, ehrlich verifiziert und den Datensatz nicht manipuliert hat. Innerhalb eines einzelnen Unternehmens mag das akzeptabel sein. Über jene Grenzen hinweg, die moderne Systeme definieren – zwischen Firmen, zwischen einer Institution und ihrer Aufsicht, zwischen einem Netzwerk und seinen Teilnehmern – ist es genau die Annahme, die nicht trägt. Und im agentischen Zeitalter steigt der Einsatz: Wenn Code und sogar Architekturänderungen schneller erzeugt werden, als irgendein Mensch sie unabhängig prüfen kann, wird „Vertraut uns, das System tut, was die Spezifikation sagt“ zu einer Behauptung, die keine Gegenpartei im Glauben akzeptieren sollte.

Die fragliche Unterscheidung wird in der jüngeren Literatur prägnant als trusted versus verifiable beschrieben. Trusted Systems beruhen auf zentralisierter Reputation, institutionellen Audits und interner Governance: Verlässlichkeit wird durch rechtliche Vereinbarungen und Unternehmensaufsicht erzwungen, und die interne Berechnung bleibt hinter der Versicherung des Anbieters verborgen, dass sie sich korrekt verhalten habe. Verifiable Systems arbeiten nach dem Gegenprinzip – Verifikation statt Vertrauen – und ersetzen blinden Glauben an eine zentrale Partei durch eine Garantie, die jeder prüfen kann. Das ist eine andere Art von Aussage über ein System: nicht „Wir attestieren, dass es sich korrekt verhält“, sondern „Hier ist der Beweis, dass es das getan hat.“ (5) Wiederhergestelltes Systems Engineering sagt dir, dass die Architektur spezifiziert ist. Es sagt für sich genommen niemandem außerhalb der spezifizierenden Organisation, dass die Architektur wahr ist.

Wie Dezentralisierung sie härtet

Hier leistet Dezentralisierung ihre Arbeit, und ihre primäre Rolle im Argument ist nicht topologisch, sondern evidenziell. Das Wichtigste, was ein dezentrales Substrat dem Enterprise-System bietet, ist nicht, dass es an vielen Orten läuft, sondern dass die Garantien des Systems bewiesen statt behauptet werden können. Kryptografische Verifikation verwandelt die Verträge der Architektur von Policy auf Papier in erzwingbare, unabhängig prüfbare Fakten. Eine Berechnung kann aus Geschwindigkeitsgründen off-chain laufen und von einem kompakten Beweis begleitet werden, der günstig on-chain verifiziert, dass sie korrekt gegen ein festgeschriebenes Modell oder eine Spezifikation ausgeführt wurde – ohne die zugrunde liegenden Daten oder die Logik offenzulegen. Die Branchenpraxis 2026 versteht die Chain zunehmend als Accountability- und Provenance-Layer für KI-gesteuerte Systeme: ein gemeinsames Substrat für Modellattestierungen, Entscheidungsprotokolle und Audit-Logs, die nicht unbemerkt umgeschrieben werden können. Die Frage verschiebt sich, wie es eine Untersuchung formulierte, davon, ob ein System einen Output erzeugen kann, dahin, ob man beweisen kann, wie er erzeugt wurde, wer verantwortlich ist und ob er einer Prüfung standhält.

Der Mechanismus, der das praktikabel macht, ist eine Asymmetrie: Berechnung kann teuer sein, während Verifikation billig ist. Ein Modell kann eine Stunde lang auf einem Cluster laufen und dann eine kryptografische Quittung zurückgeben, die eine Gegenpartei in Millisekunden prüft – Gewissheit darüber, was berechnet wurde, ohne es erneut auszuführen und ohne die Inputs zu sehen. Die Infrastruktur ist nicht länger hypothetisch, und drei ihrer Kategorien sind heute in Produktion. Allzweck-Zero-Knowledge Virtual Machines (wie RISC Zero) kompilieren gewöhnliche Programme in einen bewiesenen Instruction Set und erzeugen eine Quittung, die jede Partei gegen einen Vertrag auf einer öffentlichen Chain prüfen kann; Coprozessoren (wie Lagrange und Axiom) beweisen Fakten über On-Chain-State; und Machine-Learning-spezifische Frameworks (darunter Giza auf Starknet) lassen einen autonomen Agenten beweisen, dass jede seiner Entscheidungen tatsächlich aus dem festgeschriebenen Modell stammt, während Gewichte und Strategie privat bleiben. Der Use Case, der den Einsatz konkret macht, ist der regulierte: Statt „Vertraut dem Risikomodell der Bank“ kann eine Kreditentscheidung mit einem Beweis eintreffen, dass genau dieses Modell mit diesen eingefrorenen Parametern die Daten dieses Antragstellers ausgewertet hat. Die Aussage über das System ist nicht länger eine Frage des Wortes des Betreibers, sondern wird zu einem Fakt, den Aufsicht, Gegenpartei oder Smart Contract selbst prüfen können.

Zwei weitere Stränge verstärken den evidenziellen. Topologisch beseitigt die Verteilung eines Systems über unabhängige Nodes Single Points of Failure und, wichtiger noch, Single Points of Control – jene Stellen, an denen eine Partei stillschweigend Verhalten ändern, einen Datensatz unterdrücken oder einen Vertrag übersteuern kann. Konstitutionell liefert dezentrale Governance eine Autoritätsschicht für die Fabrik selbst: Die Regeln, unter denen Spezifikationen geändert, Agenten autorisiert und Änderungen zugelassen werden, können explizit, verteilt und ihrerseits auditierbar gemacht werden, statt bei demjenigen zu liegen, der die Schlüssel hält. Zusammen verwandeln die drei Stränge die wiederhergestellte Architektur von einer gut entwickelten privaten Behauptung in ein System, dessen Integrität von außen lesbar und erzwingbar ist. Die auf diese Weise gehärtete Fabrik baut das System nicht nur gut. Sie lässt das System beweisen, dass es ist, was es zu sein behauptet – kontinuierlich, gegenüber Parteien, die nie gebeten wurden, ihm zu vertrauen.

Die Einwände: Reife und ob es überhaupt gebraucht wird

Der stärkste Einwand gegen all das ist nicht philosophisch, sondern praktisch, und er verdient es, in voller Stärke dargestellt zu werden, weil er heute korrekt ist. Verifizierbare Berechnung ist teuer. Einen kryptografischen Beweis für eine Berechnung zu erzeugen ist nach aktuellen Schätzungen um Größenordnungen aufwendiger als die Berechnung selbst – für große Modelle wurde berichtet, dass das Beweisen tausendfach langsamer als einfache Inferenz sei. Die ehrlichen Einschätzungen im Feld sagen klar, dass das Beweisen von Inferenz kleiner bis mittlerer Modelle machbar ist, das Beweisen der Inferenz großer Modelle nur teilweise und das Beweisen vollständigen Trainings weiterhin ein Ziel bleibt (6). Ein Skeptiker darf folgern, dass „beweisbare Architektur“ für die meisten Enterprise-Workloads 2026 eher ein Forschungsprogramm als deploybare Realität ist – und darauf hinweisen, dass vieles, was als Verifiable AI vermarktet wird, näher an einer Ambition als an ausgelieferter Fähigkeit liegt.

Der Einwand hat mit Blick auf die Gegenwart recht und auf die Entwicklung unrecht, und die Form der Antwort ist aufschlussreich. Der Proving-Overhead ist stark gefallen und fällt weiter, während Proof-Systeme, Hardwarebeschleunigung und Circuit Design besser werden; leichtere Proof-Schemata entstehen genau, um die Kosten zu adressieren. Wichtiger noch: Die Technologie muss nicht universell sein, um entscheidend zu werden. Die konsistente Einschätzung lautet, dass verifizierbare Ansätze zuerst genau dort ankommen, wo sie am dringendsten gebraucht werden: in High-Stakes-, Low-Volume-Umgebungen – regulierten Entscheidungen, finanzieller Abwicklung, Content Provenance –, die die Proving-Kosten tragen können, weil der Wert einer unabhängig prüfbaren Garantie dort am höchsten ist. Das ist keine Schwäche des Arguments; es ist das Argument. Beweisbare Architektur wird nicht überall zugleich ankommen. Sie wird zuerst in den Domänen ankommen, in denen es sich lohnt, für den Beweis des Systemverhaltens zu zahlen – also in regulierten Finanzsystemen vor Consumer Apps und in institutionenübergreifender Abwicklung vor internem Tooling. Die Frontier ist heute schmal und wird breiter, und sie verbreitert sich genau von jenem Territorium aus, um das sich dieses Argument am meisten kümmert.

Es gibt noch einen tieferen Einwand, und er betrifft nicht die Kosten. Die meisten Unternehmen bräuchten überhaupt keine kryptografische Verifikation, weil das Vertrauen, auf dem sie beruhen, institutionell ist und immer war: Verträge, Reputation, Aufsichtsbehörden und die geprüften Zusicherungen von Firmen wie den Big Four. Nach dieser Sicht liefern ein SOC-2-Bericht oder eine Trusted Execution Environment bereits „hinreichend gute“ Verifikation, Regulatoren akzeptieren diese Instrumente heute, und einen funktionierenden Stack aus Anwälten und Auditoren durch einen schwerer zu bauenden Stack aus Kryptografen und Provern zu ersetzen, sei eine Lösung auf der Suche nach einem Problem. Das ist die ernsthafteste Herausforderung für das Argument, und die ehrliche Antwort gesteht ihr viel zu. Institutionelles Vertrauen wird nicht verschwinden; für das große Innere einer Organisation, in dem die Parteien einander bereits vertrauen, bleibt es das richtige und billigere Werkzeug, und die eigenen Einschätzungen des Feldes räumen offen ein, dass kryptografische Verifikation noch kein Drop-in-Ersatz für traditionelle Audits ist und beide vorerst komplementär sind. Doch das Zugeständnis lokalisiert genau, wo die neue Schicht ihren Wert verdient. Institutionelles Vertrauen funktioniert genau dort, wo es eine Institution gibt, der man vertrauen, und eine gemeinsame Autorität, an die man sich wenden kann. An den Grenzen – zwischen Firmen, die nicht im Audit-Perimeter der jeweils anderen liegen, zwischen einem Netzwerk und einem Teilnehmer, der dessen Betreiber nicht prüfen kann, zwischen einem autonomen Agenten und der Gegenpartei, mit der er in Maschinengeschwindigkeit transagiert – hat „Vertraut der Firma“ keine Firma, auf die es zeigen kann. Verifizierbare Architektur ersetzt das Audit nicht; sie erweitert Assurance über jene Nähte hinweg, die Audits nicht erreichen können, und genau aus solchen Nähten besteht ein dezentrales, multiparteiliches Finanzsystem.

Fazit: Entwickelt, um bewiesen zu werden

Die Zukunft von Enterprise Software ist kein weiterer Pendelschlag zwischen Monolith und Microservice, Zentralisierung und Verteilung. Sie ist die Wiedergewinnung eines älteren Ernstes gegenüber Systemen, bezahlbar gemacht durch eine Technologie und glaubwürdig durch eine andere. KI bringt die Systems-Engineering-Disziplin zurück, die Fragmentierung verwarf – das Ganze im Blick, Absicht erfasst und abgeglichen, Architektur gestaltet statt angesammelt –, indem sie die menschlichen Kosten senkt, die diese Disziplin zum Luxus machten. Dezentralisierung tut dann, was weder Dokumentation noch gute Absichten je konnten: Sie lässt das resultierende System seine eigenen Belege tragen, sodass seine Garantien nicht bloß spezifiziert, sondern beweisbar, nicht bloß vertraut, sondern verifizierbar und nicht bloß von demjenigen durchgesetzt werden, der die Schlüssel hält, sondern für jeden lesbar sind, der von ihnen abhängt.

Die beiden Bewegungen ergänzen sich, und jede beantwortet die Schwäche der anderen. Systems Engineering ohne Verifikation liefert eine gut gestaltete private Behauptung – besser als Fragmentierung, aber weiterhin auf dem Wort von jemandem beruhend. Verifikation ohne Systems Engineering liefert kryptografische Beweise für eine inkohärente Architektur – mathematisch gewisse Aussagen über ein System, das niemand als Ganzes entworfen hat. Gemeinsam beschreiben sie ein Enterprise-System, das entwickelt wurde, um bewiesen zu werden: mit Disziplin spezifiziert, von einer governten Fabrik gebaut und durch ein Substrat gehärtet, das seine Verträge in Fakten verwandelt, die jeder prüfen kann. Für den größten Teil der Softwareindustrie wird das allmählich ankommen, Workload für Workload, während die Proving-Schicht reift. Für regulierte On-Chain-Finanzsysteme – wo die Forderung nach beweisbarem Verhalten keine Präferenz, sondern eine Betriebsbedingung ist – kommt es jetzt an. Das ist der Boden, auf dem die Zukunft von Enterprise Software zuerst gebaut wird, und es ist der Boden, auf dem Polity arbeitet.

Die Fragmentierungsära fragte, wie schnell Software in Bewegung gebracht werden kann. Die jetzt beginnende Ära stellt eine schwierigere und dauerhaftere Frage: nicht, wie schnell sich ein System ändern kann, sondern ob man in jedem Moment beweisen kann, was es ist. Jene Organisationen werden erfolgreich sein, die diese Frage nicht als Compliance-Belastung, sondern als Designproblem behandeln – und von der ersten Spezifikation an Systeme bauen, die entwickelt wurden, um bewiesen zu werden.

Über Polity

Dieser Artikel ist Teil eines fortlaufenden Programms für Governance- und Thought-Leadership-Publikationen, das innerhalb des Polity-Governance-Modells entwickelt wird. Politys zentrale These lautet, dass dauerhafte Ergebnisse von Governance-Architektur geformt werden: den Regeln, Anreizen und Institutionen, durch die Arbeit, Wert und Verpflichtung entstehen. Die hier beschriebene Konvergenz – durch KI wiederhergestelltes Systems Engineering, gehärtet durch ein verifizierbares, dezentrales Substrat – ist genau in diesem Sinn ein Governance-Problem: Sie ist der Unterschied zwischen einem System, das um Vertrauen bittet, und einem, das geprüft werden kann. Polity baut Infrastruktur für regulierte digitale Finanzsysteme mit Governance-Frameworks, die dezentrale Systeme mit institutionellen Compliance-Anforderungen verbinden; die Frage, wie autonome Softwareproduktion mit hohem Durchsatz nicht bloß schnell, sondern beweisbar gemacht werden kann, in Umgebungen, in denen Assurance eine Betriebsbedingung ist, gehört zu denen, mit denen es sich direkt befasst.

Über Wavect

Die Wavect GmbH ist eine österreichische Software-Engineering-Agentur, die produktorientierte Software für Start-ups, Scale-ups und Enterprises entwickelt. Das Spektrum reicht von Full-Stack-Entwicklung über Fractional Engineering und Product Leadership bis zu Software Quality Assurance und angewandter Arbeit in künstlicher Intelligenz, Blockchain und Zero-Knowledge-Systemen. Wavect hat für das Polity-Programm Softwareentwicklungs- und Qualitätssicherungsleistungen erbracht. Co-Autor Kevin Riedl ist Managing Partner des Unternehmens. Weitere Informationen unter https://wavect.io.

Disclaimer: Dieser Artikel dient ausschließlich Informations- und Bildungszwecken. Er stellt weder professionelle, rechtliche, finanzielle noch Engineering-Beratung dar und ist keine Empfehlung für eine Methode, ein Produkt, ein Protokoll, einen Service oder eine Organisation. Verweise auf genannte Forscher, Studien, Tools, Standards und Unternehmen dienen ausschließlich Analyse und Kommentar. Mehrere der diskutierten Technologien – insbesondere verifizierbare Berechnung und Zero-Knowledge-Beweise der Modellausführung – befinden sich noch in einem frühen Reifestadium, und ihre Fähigkeiten und Kosten entwickeln sich weiter; relevante Einschränkungen werden im Text eingeordnet. Alle Drittquellen sind als Referenz zitiert; ihre Aufnahme bedeutet weder Empfehlung durch noch Zugehörigkeit zu Polity. Co-Autor Kevin Riedl ist Managing Partner der Wavect GmbH, die Softwareentwicklungs- und Qualitätssicherungsleistungen für das Polity-Programm erbringt, siehe „Über Wavect“. Diese Geschäftsbeziehung wird im Interesse der Transparenz offengelegt und beeinträchtigt die Unabhängigkeit der Analyse nicht. Die geäußerten Ansichten sind jene der Autoren.

Literatur

1. vFunction (2026) Distributed Monolith Architecture: What It Is, Why It Happens, and How to Fix It. Available at: https://vfunction.com/blog/distributed-monolith-architecture/ (Accessed: 23 June 2026).
2. Cloud Native Computing Foundation (CNCF) (2025) 2024 Cloud Native Survey. (689 respondents; 42% consolidating microservices; service-mesh decline 18%→8%.) Available at: https://www.cncf.io/reports/the-cncf-annual-cloud-native-survey/ (Accessed: 23 June 2026).
3. McIlroy, M.D. (1968) ‘Mass-produced software components’, in Naur, P. and Randell, B. (eds.) Software Engineering: Report on a Conference Sponsored by the NATO Science Committee. Brussels: NATO Scientific Affairs Division, pp. 138–155. Available at: https://www.cs.dartmouth.edu/~doug/components.txt (Accessed: 23 June 2026).
4. Zhang, W., Cockburn, C., Henshaw, M. et al. (2026) ‘MBSE Co-Pilot: A Research Roadmap’, Systems Engineering, 29(1), pp. 20–33. INCOSE / Wiley. doi:10.1002/sys.70011. Available at: https://doi.org/10.1002/sys.70011 (Accessed: 23 June 2026).
5. Chainlink (2026) Verifiable AI vs Trusted AI: Key Differences. (Delegated-trust vs cryptographic-trust distinction; relevance to financial services.) Available at: https://chain.link/article/verifiable-ai-vs-trusted-ai (Accessed: 23 June 2026).
6. Everstake (2026) Blockchain and Verifiable AI: Can AI Be Blindly Trusted? (Feasibility of proving small/mid vs large-model inference; staged 2026–2028 adoption; high-stakes-first pattern.) Available at: https://everstake.one/resources/blog/verifiable-ai-onchain-trust-layer (Accessed: 23 June 2026).

Presse- und Webquellen (nummeriert zur Faktenprüfung)

Wenn der Haupttext einer namentlich genannten Studie einen konkreten Befund zuschreibt, steht die Primärquelle oben unter „Literatur“. Die folgenden Einträge dokumentieren die verwendete Sekundärberichterstattung sowie die jeweils gestützten Punkte.

• vFunction (2026). ‘Distributed monolith architecture.’ Operational complexity of microservices without architectural independence; logical coupling; synchronised deployments. vfunction.com
• Pietschsoft / C. Pietschmann (2026). ‘Disposable software is the future.’ Distributed-monolith failure modes; interfaces needing ownership and versioned contracts; change-flow as the real measure of architecture. pietschsoft.com
• XYZBytes (2025). ‘From microservices hell to monolith heaven: the great architecture reversal of 2025.’ Consolidation back toward (modular) monoliths; reported cost and deploy-time reductions. xyzbytes.com
• SoftwareSeni (2026). ‘From microservices consolidation to modular monoliths.’ Modular monolith as enforced internal boundaries; CNCF 2024 Cloud Native Survey consolidation signal. softwareseni.com
• Engenia Technologies (2026). ‘AI software modernization: the 2026 enterprise guide.’ LLMs extracting business rules/intent into human-readable requirements; engineers shifting to constraints and architectural trade-offs; ~75% of enterprises on legacy systems. engeniatech.com
• Wishtree (2026). ‘Microservices architecture for enterprise.’ Clean versioned APIs as agent-callable skills; agentic orchestration of services; distributed-monolith risk without disciplined design. wishtreetech.com
• Blockchain Council (2026). ‘Verifiable AI inference using blockchain.’ Off-chain inference plus on-chain ZK proof; chain as accountability/provenance layer; ‘prove how the output was produced.’ blockchain-council.org
• Chainlink (2026). ‘Verifiable AI vs trusted AI.’ Delegated-trust vs cryptographic-trust; ‘verification over trust’; suitability for high-stakes financial environments. chain.link
• Everstake (2026). ‘Blockchain and verifiable AI.’ Proving cost/latency limits; small/mid feasible, large partial, training aspirational; high-stakes-low-volume-first adoption across 2026–2028. everstake.one
• Phemex Academy (2026). ‘What is verifiable AI?’ TEEs, ZK proofs, provenance standards (C2PA); why smart contracts cannot rely on opaque off-chain AI without a trust-minimising layer. phemex.com
• INCOSE / Wiley (2026). ‘MBSE Co-Pilot: a research roadmap.’ AI-driven model-based systems engineering to lower the adoption barrier for digital engineering. incose.onlinelibrary.wiley.com
• CNCF (2025). 2024 Cloud Native Survey. 689 respondents (±3.8% at 95% confidence); 42% of microservices adopters consolidating to larger units; service-mesh adoption 18%→8%; cloud-native adoption ~89%. Reported via SoftwareSeni / byteiota. cncf.io
• RISC Zero (2026). zkVM documentation and overview. General-purpose zkVM; Rust → RISC-V; STARK receipt with on-chain SNARK verifier; Bonsai proving service; Q1 2026 latency/throughput figures. (Also: Eco / degen0x explainers on RISC Zero, Lagrange, Axiom.) risczero.com
• ICME Labs (2026). ‘The definitive guide to zkML.’ Compute-expensive / verification-cheap asymmetry; Giza LuminAIR verifiable DeFi agents; loan-decision proof example; overhead trajectory (1,000,000×→10,000×); zkPyTorch and Lagrange DeepProve. blog.icme.io