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.
Key Takeaways
- Regulatorische Pflichten wie Auditierbarkeit oder Human Override sind Struktureigenschaften — entschieden beim Modulschnitt, nicht im Compliance-Dokument.
- Hexagonale Architektur und Bounded Contexts machen EU-AI-Act-Anforderungen erfüllbar, weil sie Isolation und Kontrollpunkte als Eigenschaft anbieten.
- Data Contracts verwandeln Governance von einer Policy in ein versionierbares, prüfbares Artefakt.
- Konsistenz und Korrektheit gehören in die Struktur (Invarianten, Grenzen), nicht in nachgelagerte Validierung.
- Autonome Agenten sind nur so verantwortbar wie ihre Data Governance — die muss vor dem Agenten stehen, nicht danach.
🔍 FAQ
1. Reicht es nicht, wenn das Legal-Team die EU-AI-Act-Compliance übernimmt?
Nein. Viele Pflichten des EU AI Act — etwa menschliche Aufsicht, Audit-Logging oder Modellversionierung — sind keine juristischen Häkchen, sondern strukturelle Eigenschaften eines Systems. Ob ein System sie erfüllen kann, hängt davon ab, wie Modulgrenzen und Schnittstellen geschnitten sind. Legal kann Anforderungen formulieren, aber nur die Architektur entscheidet über ihre Erfüllbarkeit.
2. Was bedeutet „Compliance als Architektur-Eigenschaft" konkret?
Es bedeutet, regulatorische Anforderungen wie Qualitätsmerkmale zu behandeln — auf einer Ebene mit Performance oder Sicherheit. Statt eine Pflicht nachträglich zu dokumentieren, baut man Kontrollpunkte, Isolation und Nachvollziehbarkeit von Anfang an in die Struktur ein. Hexagonale Architektur etwa liefert über Port-Isolation die Stellen, an denen Human Override und Audit-Logging überhaupt ansetzen können.
3. Welche Architektur-Entscheidungen verlangt der EU AI Act ab August 2026?
Ab August 2026 greifen für Hochrisiko-KI-Systeme Pflichten wie Auditierbarkeit, menschliche Aufsicht, Risikomanagement, technische Dokumentation, Data Governance und Post-Market-Monitoring. Architektonisch heißt das: Risikokategorien auf Bounded Contexts abbilden, Audit-Logging und Modellversionierung über klare Grenzen isolieren und Training von Serving trennen, weil das eine Data-Governance-Grenze ist. Diese Entscheidungen müssen vor dem Audit getroffen sein, nicht danach.
4. Was haben Data Contracts mit Governance zu tun?
Data Contracts machen aus Governance ein prüfbares Artefakt statt einer Richtlinie. Sie spezifizieren Daten als verlässliche Schnittstelle — mit Schema, Qualitätschecks und Versionierung — und sind damit besonders in dezentralen Architekturen wie Data Mesh die Grundlage für Vertrauen. Statt „wir sollten saubere Daten liefern" zu dokumentieren, wird die Zusicherung getestet, versioniert und automatisiert durchgesetzt.
