Auditierbarkeit, Human Override, Data Governance: Vorgaben, die längst über Bounded Contexts entschieden werden.
Der EU AI Act ist in Kraft. Ab August 2026 greifen für Hochrisiko-Systeme die meisten Pflichten — Nachvollziehbarkeit, menschliche Aufsicht, Risikomanagement, technische Dokumentation, Data Governance, Post-Market-Monitoring. In den meisten Unternehmen liegt das auf dem Schreibtisch von Legal. Das ist die erste Fehlentscheidung.
Das Problem: Compliance wird verwaltet, nicht gebaut
Wenn Regulierung als Rechtsthema behandelt wird, entsteht ein vorhersehbares Muster: Legal liest die Verordnung, leitet Anforderungen ab, formuliert Richtlinien — und reicht eine Checkliste ins Entwicklungsteam. Dort wird abgehakt, was abhakbar ist, und nachgerüstet, was sich nachrüsten lässt.
Das Problem ist nicht die Checkliste. Das Problem ist die Reihenfolge. Eine Pflicht wie „menschliche Aufsicht über Modellentscheidungen“ ist kein Häkchen, sondern eine strukturelle Frage: Gibt es im System überhaupt einen Punkt, an dem ein Mensch eingreifen kann, bevor eine Entscheidung wirksam wird? Wenn die Architektur diesen Punkt nicht vorsieht, hilft keine Richtlinie der Welt.
Dasselbe gilt für Auditierbarkeit, Modellversionierung und Datenqualität. Ob dein System diese Eigenschaften erfüllen kann, ist entschieden, lange bevor das erste Compliance-Dokument geschrieben wird. Es ist entschieden, als jemand die Modulgrenzen gezogen hat.
Der Denkrahmen: Governance ist eine strukturelle Eigenschaft
Der Perspektivwechsel, der hier zählt, ist klein und folgenreich: Behandle regulatorische und Governance-Anforderungen nicht als nachgelagerte Schicht, sondern als Qualitätsmerkmal — auf einer Ebene mit Performance, Skalierbarkeit oder Sicherheit. Niemand käme auf die Idee, Latenz erst nach dem Audit „herzustellen“. Bei Compliance tun wir genau das.
Governance entsteht nicht durch ein Dokument am Ende. Sie entsteht durch die Struktur-Entscheidungen am Anfang — oder sie entsteht gar nicht.
Sobald du Anforderungen als Struktureigenschaft liest, verändern sich die Fragen. Nicht mehr: „Wie dokumentieren wir, dass wir konform sind?“ Sondern: „Welche Grenze im System trägt diese Anforderung — und ist sie dort, wo sie sein muss?“ Die folgenden vier Sessions setzen auf genau dieser Ebene an, jede an einer anderen Grenze.
Die Lösungsebenen
EU AI Act: Pflichten auf Architektur-Entscheidungen abbilden
Die konkrete Herausforderung: die abstrakten Pflichten des EU AI Act in die Sprache übersetzen, in der Architekt:innen tatsächlich arbeiten — Module, Grenzen, Schnittstellen.
Der Ansatz mappt Risikokategorien auf den Schnitt deiner Bounded Contexts und zeigt, wie hexagonale Architektur über Port-Isolation Dinge wie Human Override, Modellversionierung und Audit-Logging zu einer Eigenschaft der Struktur macht — statt zu einem nachträglich angeflanschten Feature. Auch die Trennung von Training und Serving wird hier nicht als Performance-Muster gelesen, sondern als Data-Governance-Grenze, die der Act implizit verlangt.
Du nimmst eine konkrete Zuordnung mit: von regulatorischer Pflicht zu architektonischer Entscheidung, an produktionsnahen Beispielen.
Architecting for the EU AI Act beim Software Architecture Summit mit Nikita Golovko
Data Contracts: Datenqualität als verlässliche Schnittstelle
Die Herausforderung: In dezentralen Datenarchitekturen wie Data Mesh scheitert Vertrauen an fehlenden, durchsetzbaren Vereinbarungen darüber, was Daten eigentlich zusichern.
Der Ansatz nimmt bestehende Daten „unter Vertrag“ — Data-first. Auf Basis des Open Data Contract Standard der Linux Foundation entstehen Spezifikationen mit eingebauten Qualitätschecks, getestet, dokumentiert und katalogisiert. Anschließend wird der Vertrag versioniert weiterentwickelt, inklusive Migrationspfad von Minor- zu Major-Version. Governance wird damit von einer Policy zu einem prüfbaren, versionierbaren Artefakt.
Du nimmst mit, wie du Daten zu verlässlichen Schnittstellen machst — und wo daraus Automatisierung entsteht.
Dynamic Consistency Boundaries: Invarianten aus der Domäne ableiten
Die Herausforderung: Klassisches Event Sourcing zwingt dich, Aggregate-Grenzen früh festzulegen — bevor du die Domäne und ihre Geschäftsregeln wirklich verstanden hast.
Dynamic Consistency Boundaries drehen die Reihenfolge um: Konsistenzgrenzen emergieren aus den Beziehungen zwischen Commands, Events und Business-Invarianten, statt vorab gesetzt zu werden. Damit lässt sich präziser begründen, wann starke Konsistenz wirklich nötig ist und wo ein Modell unnötig überbestimmt wird. Wer Geschäftsregeln so verankert, erzwingt Korrektheit über die Struktur — nicht über nachgelagerte Validierung.
Du nimmst ein tieferes Gespür dafür mit, wie du die Form deiner Domäne überhaupt erst sichtbar machst.
DCB: rethinking consistency boundaries beim Software Architecture Summit mit Sara Pellegrini
Agentic AI: Data Governance als Voraussetzung, nicht als Beiwerk
Die Herausforderung: Autonome Agenten verfolgen eigenständig Ziele und nutzen Werkzeuge — aber sie sind nur so gut wie die Daten, auf deren Grundlage sie handeln.
Diese Keynote ordnet nüchtern ein, welche Agentic-AI-Versprechen in der Architekturarbeit heute schon tragen und wo die Grenzen liegen. Der Schwerpunkt liegt auf dem Thema, das in der Begeisterung meist untergeht: Ohne klare Vorgaben zu Datenqualität, Zugriffssteuerung und Compliance wird aus dem intelligenten Helfer ein schwer kontrollierbares Risiko. Data Governance ist hier kein Nachgedanke, sondern die Bedingung, unter der Autonomie überhaupt verantwortbar ist.
Du nimmst mit, was du heute an Governance schaffen musst, damit produktive Agenten morgen kein Risiko sind.
Agentic AI & Data Governance beim Software Architecture Summit mit Simon Harrer
Was du heute tun kannst
- Nimm dir eine konkrete EU-AI-Act-Pflicht — etwa Audit-Logging — und prüfe, an welcher Modulgrenze sie in deinem System sitzen müsste. Wenn die Antwort „nirgends“ lautet, hast du eine Architektur-Aufgabe, kein Dokumentationsproblem.
- Wähle einen Datenfluss zwischen zwei Teams und formuliere, was die liefernde Seite zusichert: Schema, Qualität, Versionierung. Das ist der Rohentwurf eines Data Contracts — und der erste Schritt von Governance-Policy zu prüfbarem Artefakt.
- Bevor du Aggregate-Grenzen festlegst, schreib die Business-Invarianten auf, die wirklich starke Konsistenz brauchen. Häufig sind es weniger als gedacht — und die Grenze ergibt sich aus der Regel, nicht umgekehrt.
Fazit
Der EU AI Act, Data Governance, die Verlässlichkeit autonomer Agenten — auf den ersten Blick drei verschiedene Themen, getrieben von Recht, Daten und Hype. Auf den zweiten Blick dieselbe Frage: Trägt deine Struktur die Eigenschaft, die du brauchst? Compliance, Datenqualität und kontrollierbare Autonomie sind keine Schichten, die du auf ein fertiges System legst. Sie sind Konsequenzen der Grenzen, die du gezogen hast.
Die Frage ist nicht, ob dein System konform ist. Die Frage ist, ob deine Struktur es überhaupt sein kann.
Wer diese Grenzen hands-on ziehen und an realen Beispielen durchdenken will: Die vier Sessions oben — vom EU AI Act über Data Contracts und Consistency Boundaries bis zur Governance autonomer Agenten — laufen beim Software Architecture Summit im Oktober 2026 in Berlin.
