---
title: "Architect: KI-Marketing-Architektur und Operating Model"
description: "Architect verbindet Workflows, Wissen, Technologie, Governance, Rollen und Messung zu einer KI-Marketing-Architektur, bevor die Umsetzung beginnt."
url: "https://kodokalabs.com/de/ki-marketing-framework/architektur-und-operating-model/"
language: de
published: 2026-08-07
updated: 2026-11-06
---

# Architect: KI-Marketing-Architektur und Operating Model

## Architect: das KI-Marketing-Operating-Model entwerfen

Architect ist die zweite Phase des [kōdōkalabs Transformation System](../ai-marketing-framework.md). Sie übersetzt validierte Erkenntnisse aus Diagnose in ein Ziel-Operating-Model, Workflow-Spezifikationen, Governance-Kontrollen, Wissensanforderungen, Technologieentscheidungen, ein [Mess](./ai-marketing-measurement-and-value-realization.md)-Design und ein Backlog für die Umsetzung.

## Zusammenfassung für die Geschäftsleitung

Architect gibt es, weil die meisten Organisationen, die bei der KI-Marketing-Transformation scheitern, nicht an Diagnose scheitern. Sie scheitern in der Lücke zwischen „wir wissen, was falsch läuft“ und „wir bauen etwas, das wirklich funktioniert“. Diese Lücke wird mit Tool-Konfiguration gefüllt, obwohl dort Design hingehört: ausdrückliche Entscheidungen zu Operating Model, Entscheidungsrechten, Workflow-Verantwortung, Wissensarchitektur, Technologie-Integration, Governance, Messung und Übergabe der Verantwortung. Architektur ist Entscheidungsinfrastruktur und keine Foliensammlung. Diese Seite behandelt die acht Designebenen einer vollständigen Architektur, die Verteilung der Verantwortung zwischen Menschen und KI, das, was Architect liefern muss, bevor Build beginnen kann, und die Fehler, die aus Architektur eine teure Dokumentationsübung machen, die niemand nutzt.

## Das Wichtigste in Kürze

- Architektur ist ein Satz ausdrücklicher Designentscheidungen und kein Zielbild-Diagramm.
- Acht verbundene Ebenen reichen vom Geschäftsumfang bis zur Übergabe der Verantwortung. Wer eine Ebene auslässt, hinterlässt eine Lücke, die Build auf die harte Tour entdeckt.
- Jede wesentliche Entscheidung wird mit ihrer Begründung dokumentiert, nicht nur mit dem Ergebnis.
- Für kontrollierte Pilotprojekte gibt es eine Minimum Viable Architecture: Nicht jede Organisation braucht vom ersten Tag an Dokumentation im Konzernmaßstab.
- Architect ist von der Liefermethodik [Strategic Architecture](../../en/methodology/ai-marketing-strategic-architecture.md) zu unterscheiden. Diese [Methodik](../../en/methodology.md) spezifiziert einzelne Arbeitspakete innerhalb des Operating Models, das Architect festlegt.

## Was ist die Architect-Phase?

Architect nimmt, was Diagnose als Evidenz erarbeitet hat, und wandelt es in ein Design um. Diagnose beantwortet „was stimmt über unseren Ist-Zustand“. Architect beantwortet „wie soll der Zielzustand aussehen, und zwar so konkret, dass er gebaut, gesteuert, gemessen und schließlich vom eigenen Team des Unternehmens betrieben werden kann“. Das Ergebnis ist keine Vision. Es ist ein Satz miteinander verknüpfter, dokumentierter Entscheidungen, die Build direkt umsetzen kann.

## Warum Architektur vor Automatisierung kommt

Häufig gehen Organisationen von der [Diagnose](./ai-marketing-diagnosis-and-readiness-assessment.md) direkt in die Tool-Konfiguration über und überspringen den Designschritt komplett. Das erzeugt ein erkennbares Muster: unverbundene Automatisierungen, die jeweils ein enges Problem lösen, ohne in ein stimmiges Ganzes zu passen; unklare Verantwortung dafür, wer wofür zuständig ist, wenn etwas ausfällt; schwache Wissensgrundlagen, weil niemand entworfen hat, was das KI-System eigentlich wissen soll; uneinheitliche Prüfung, weil Governance nicht von Anfang an eingebaut wurde; und Kennzahlen, die erst nach dem Start hinzukommen, weil Messung nicht Teil des ursprünglichen Designs war.
Architektur schließt diese Lücke, indem sie die Beziehungen zwischen diesen Teilen vor der Umsetzung ausdrücklich macht und nicht erst, nachdem im Betrieb etwas schiefgegangen ist.

## Benötigte Inputs aus Diagnose

Architect startet mit dem Decision Package aus Diagnose: dem Evidenzregister, dem Reifegradprofil, dem priorisierten Chancen-Backlog und der ausdrücklichen Entscheidung darüber, was ein Design verdient. Fehlt einer dieser Inputs oder ist er unvollständig, sollte der erste Schritt von Architect die Rückkehr zu Diagnose für genau diese Lücke sein und kein Design um eine Annahme herum. Eine Architektur auf Basis einer unvollständigen Diagnose liefert tendenziell ein gut dokumentiertes Design für das falsche Problem.

## Die acht Ebenen der KI-Marketing-Architektur

![Diagramm der KI-Marketing-Architektur in acht übereinanderliegenden Ebenen, von Geschäftsergebnis und Umfang bis zu Enablement und Übergabe der Verantwortung](https://kodokalabs.com/assets/media/2026/08/kodokalabs-framework-architect-phase-eight-layer-ai-marketing-architecture.webp)

Der **Architecture Decision Stack** von kōdōkalabs gliedert die Designarbeit in acht verbundene Ebenen. Es ist die eigene Methodik von kōdōkalabs und kein extern standardisiertes Architektur-Framework. Für jede Ebene legt die Designarbeit die nötigen Inputs, die eigentlichen Designentscheidungen, die Outputs, die Freigebenden und das fest, wovon Build auf dieser Ebene abhängt.

### Geschäftsergebnis und Umfang

Welchem Geschäftsergebnis soll diese Architektur dienen, und was liegt ausdrücklich außerhalb des Umfangs? Ein Design ohne klare Grenzen wächst tendenziell, bis es versucht, alle Probleme aus Diagnose auf einmal zu lösen, und das heißt meist, dass es keines davon gut löst.

### Operating Model und Entscheidungsrechte

Wer entscheidet was, auf welcher Ebene und mit welcher Befugnis? Diese Ebene legt die organisatorische Struktur fest, in der der Rest der Architektur arbeitet. Ohne sie haben die folgenden Ebenen keine klare Verantwortung.

### Workflow und Verantwortung zwischen Mensch und KI

Welche konkreten Workflows werden neu gestaltet, und wie wird die Verantwortung in jedem davon zwischen menschlichem Urteil und KI-Unterstützung verteilt? Das Modell, das diese Ebene anwendet, beschreibt der eigene Abschnitt weiter unten.

### Wissens- und Datenarchitektur

Auf welches Wissen braucht das System Zugriff, in welcher Struktur, mit welchen Zugriffskontrollen, und wie bleibt es aktuell? Diese Ebene entscheidet, ob KI-gestützte Arbeit im fertigen System verlässlich ist oder selbstsicher plausibel klingende Fehler produziert.

### Technologie- und Integrationsarchitektur

Welche [Tools](../../en/tools.md) und Systeme sind beteiligt, wie hängen sie zusammen, und welche technischen Einschränkungen ergeben sich daraus? Die Architektur behandelt einzelne Tools als austauschbare Bausteine im Dienst des Designs und nicht umgekehrt.

### Governance, Datenschutz, Sicherheit und Qualitätskontrollen

Welche Prüfanforderungen, Risikoklassen und Qualitätskontrollen gelten für diesen Workflow, und an welcher Stelle im Prozess greifen sie? Siehe „Governance by Design“ weiter unten.

### Messung und Wertbeitrag

Wie wird die Leistung dieses Workflows im Betrieb tatsächlich gemessen, und gegen welche Ausgangsbasis? Messung, die erst nach der Umsetzung entworfen wird, misst tendenziell, was sich bequem messen lässt, und nicht, worauf es ankommt.

### Enablement, Dokumentation und Übergabe der Verantwortung

Was muss das Team des Unternehmens wissen und können, um dieses System eigenständig zu betreiben, und welche Dokumentation macht diese Übergabe möglich? Diese Ebene verbindet das Design aus Architect mit der Phase [Enable](./ai-marketing-enablement-and-capability-transfer.md), die auf Build folgt.

## Wie die Verantwortung zwischen Menschen und KI gestaltet wird

In der Ebene zu Workflow und Verantwortung zwischen Mensch und KI wendet Architect das [Human + AI Execution Model](../ai-marketing-framework.md) und die risikobasierte Prüflogik an, die an früherer Stelle im kōdōkalabs Transformation System festgelegt wurden. Arbeit wird in vier Kategorien eingeteilt: menschlich verantwortet, KI-unterstützt, von der KI unter Aufsicht ausgeführt sowie untersagt oder eingeschränkt. Maßgeblich sind Risiko, Umkehrbarkeit, Sensibilität der Fakten, Markenwirkung und finanzielle Folgen, nicht das, was sich technisch automatisieren lässt. Dass eine Aufgabe automatisierbar ist, macht ihre Automatisierung noch nicht zur richtigen Designentscheidung. Das hängt vom Risikoprofil ab, das Architect für jeden einzelnen Workflow bewertet.

## Anforderungen an die Workflow-Architektur

Jede Workflow-Spezifikation aus Architect umfasst: Trigger (was den Workflow auslöst), Inputs (was er zum Laufen braucht), Schritte (die eigentliche Abfolge der Arbeit), Verantwortliche (wer an jedem Schritt rechenschaftspflichtig ist), Systeme (welche Tools beteiligt sind), Wissen (auf welche Informationen der Workflow zugreift), Ausnahmen (was passiert, wenn der Normalweg nicht gilt), Freigaben (wo eine menschliche Abnahme nötig ist), Outputs (was der Workflow erzeugt), Nachweise (wie Qualität und Korrektheit geprüft werden) und Kennzahlen (wie die Leistung gemessen wird). Fehlt eines dieser Felder, ist die Spezifikation unvollständig, so detailliert die vorhandenen Teile auch sein mögen. Ausnahmen und Freigaben werden am häufigsten übersprungen, und ihr Fehlen macht im realen Betrieb die meisten Probleme.

## Wissens- und Kontextarchitektur

Diese Ebene entscheidet, auf welche strukturierte Wissensdatenbank die neu gestalteten Workflows zugreifen, wer sie aktuell hält, welche Zugriffskontrollen gelten und wie Lücken oder Widersprüche in diesem Wissen aufgelöst werden. Eine Workflow-Architektur kann auf dem Papier gut entworfen sein und in der Praxis trotzdem scheitern, wenn die Wissensebene darunter unvollständig, veraltet oder so aufgebaut ist, dass KI-Systeme daraus nicht verlässlich abrufen können.

## Governance by Design

Governance wird in die Architektur eingebaut, an der Stelle, an der jeder Workflow spezifiziert wird, und nicht nachträglich als Compliance-Prüfung aufgesetzt. Das heißt: Risikoklasse, nötige Prüfstufe und Freigabeschranke jedes Workflows sind Teil seiner Spezifikation, im Einklang mit dem Marketing AI Governance Control Stack. Sie werden nicht erst später entdeckt, wenn Recht oder Sicherheit fragen, wie ein bereits gebauter Workflow ein bestimmtes Risiko tatsächlich handhabt.

## Messung vor der Umsetzung

Jede Workflow-Spezifikation legt fest, wie ihre Leistung gemessen wird, bevor der Workflow gebaut wird, und knüpft direkt an die Ausgangsbasis aus Diagnose an. Wird Messung erst nach der Umsetzung entworfen, entstehen tendenziell Kennzahlen, die gewählt werden, weil sie sich leicht aus dem gerade vorhandenen System ziehen lassen, und nicht, weil sie beantworten, ob der Workflow den beabsichtigten Wert schafft. Dieses Problem muss Architect vermieden haben, damit die Phase Measure funktionieren kann.

## Deliverables der Architektur

Architect verlangt einen bestimmten Satz an Deliverables, bevor Build beginnen kann: ein Ziel-Operating-Model, Workflow-Spezifikationen für jeden neu gestalteten Workflow, eine Verantwortungsmatrix, eine Wissenslandkarte, einen Integrationsplan, eine Governance-Matrix, einen Messplan, ein priorisiertes Umsetzungs-Backlog, einen definierten Pilotumfang, einen Dokumentationsplan und einen Plan für den Capability Transfer. Für jedes Deliverable gibt es eine feste freigebende Instanz: Die Architektur gilt nicht als fertig, wenn sie geschrieben ist, sondern erst, wenn sie von denen freigegeben ist, die für ihre Ergebnisse geradestehen.
Das priorisierte Umsetzungs-Backlog verdient besondere Aufmerksamkeit, denn dort trifft Architektur auf die Reihenfolge. Nicht jeder spezifizierte Workflow muss gleichzeitig gebaut werden: Das Backlog ordnet die neu gestalteten Workflows nach einer Kombination aus Nutzen, Risiko, Abhängigkeit und Bereitschaft und gibt Build so einen vertretbaren Startpunkt statt einer undifferenzierten Liste von allem, was die Architektur umfasst. Ein Backlog, das „zuerst bauen“ nicht von „irgendwann bauen“ unterscheidet, führt tendenziell zu einer [Build-Phase](./build-an-ai-marketing-system-with-governed-workflows.md), die entweder stockt, weil alles gleichzeitig versucht wird, oder einen willkürlichen Startpunkt wählt, der mit den tatsächlichen Prioritäten nichts zu tun hat.

## Architektur-Review und Freigabeschranken

Bevor Build beginnt, durchläuft die Architektur die Prüfung durch die Rollen, die an dem Entworfenen ein Interesse haben: Der Executive Sponsor bestätigt, dass das Design weiterhin dem ursprünglichen Geschäftsergebnis dient. Governance-Stakeholder bestätigen, dass Risikoklassifizierung und Prüfanforderungen ausreichen. Die Workflow-Verantwortlichen, die das System später betreiben, bestätigen, dass das Design für ihr Team tatsächlich betreibbar und nicht nur technisch elegant ist. Und eine finale freigebende Instanz zeichnet das gesamte Paket ab. Wird eines dieser Reviews übersprungen, tauchen die Bedenken der ausgelassenen Seite tendenziell später in Build auf, wenn ihre Behebung teurer ist.
Diese Reviews laufen bewusst nacheinander und nicht als eine gemeinsame Abnahmesitzung. Wenn das Governance-Review vor dem Review durch die Workflow-Verantwortlichen stattfindet, werden Risiko- und Compliance-Bedenken geklärt, solange das Design noch beweglich ist, und nicht erst, nachdem die Betreibenden bereits Erwartungen an eine Version aufgebaut haben, die Governance später ändern lässt. Und weil das Review der Workflow-Verantwortlichen vor der finalen Freigabe liegt, zeichnet die freigebende Instanz ein Design ab, das bereits als wirklich betreibbar bestätigt ist und nicht nur auf dem Papier schlüssig.

## Abschlusskriterien von Architect

Architect ist abgeschlossen, wenn jede der acht Ebenen dokumentierte Entscheidungen mit benannten Freigebenden hat, der Architecture Decision Record die Begründung jeder wesentlichen Entscheidung festhält, für jeden Workflow im Umfang Spezifikationen vorliegen und Build alles hat, was es braucht, um mit der Umsetzung zu beginnen, ohne Designentscheidungen spontan treffen zu müssen. Wenn Build mitten in der Umsetzung eine Designentscheidung zum ersten Mal treffen muss, ist das ein Signal, dass Architect nicht wirklich fertig war.
Das heißt nicht, dass jeder denkbare Sonderfall vor dem Start von Build vorhergesehen werden muss: Eine Minimum Viable Architecture für ein kontrolliertes Pilotprojekt ist ein legitimer Weg, die Abschlusskriterien mit geringerer Detailtiefe zu erfüllen. Es heißt aber, dass die getroffenen Entscheidungen, so klein ihr Umfang sein mag, für diesen Umfang vollständig und dokumentiert sind und nicht halb spezifiziert für Build zum informellen Auffüllen liegen bleiben.

## Typische Fehler in der Architektur

- **Tool-getriebenes Design:** Es wird um die Fähigkeiten eines bestimmten Tools herum entworfen statt um Geschäftsergebnis und Workflow-Anforderungen, und die Tool-Wahl wird dann rückwärts begründet. Das ist der direkteste Weg zurück in das Muster, das Architect verhindern soll: Das Tool-zuerst-Denken, das Diagnose unterbrechen sollte, taucht eine Phase später unter dem Etikett „Architektur“ wieder auf.
- **Ungeklärte Verantwortung:** Ein Design legt fest, was geschehen soll, nicht aber, wer verantwortlich ist, wenn es nicht geschieht. Lücken in der Verantwortung sind im Architekturdokument meist unsichtbar und werden erst sichtbar, wenn ein Workflow zum ersten Mal ein unerwartetes Ergebnis liefert und niemand klar dafür zuständig ist, es zu lösen.
- **Überengineering:** Für einen Workflow, der nur eine Minimum Viable Architecture für ein kontrolliertes Pilotprojekt gebraucht hätte, werden Dokumentation und Governance im Konzernmaßstab aufgebaut. Überengineering bremst tendenziell die Umsetzung, ohne das Risiko im gleichen Maß zu senken, denn die zusätzliche Dokumentation deckt selten Szenarien ab, die die schlankere Version übersehen hätte.
- **Fehlende Behandlung von Ausnahmen:** Eine Workflow-Spezifikation beschreibt den Normalweg ausführlich, sagt aber nie, was passiert, wenn etwas außerhalb davon liegt. In der Praxis besteht ein beachtlicher Teil des realen Aufkommens eines Workflows aus Ausnahmen und nicht aus dem dokumentierten Idealfall. Eine Architektur, die nur den Idealfall spezifiziert, lässt die reibungsreichsten Fälle völlig ungeplant.
- **Verdeckte Datenbewegungen:** Wissen oder Daten fließen zwischen Systemen auf Wegen, die die Architektur nicht dokumentiert und die das Governance-Review deshalb gar nicht bewerten kann. Das kommt besonders bei KI-Tools vor, die im Normalbetrieb stillschweigend Kontext an eine Drittanbieter-API senden, ohne dass die Workflow-Spezifikation das ausdrücklich nennt.
- **Schwache Evidenz:** Designentscheidungen werden mit Behauptungen begründet statt mit der Evidenz, die Diagnose tatsächlich geliefert hat. Eine Designentscheidung, die sich nicht auf einen Befund aus Diagnose oder auf eine klar gekennzeichnete, noch zu validierende Annahme zurückführen lässt, beruht auf den Vorlieben der Entwerfenden und nicht auf Evidenz.
- **Keine Messbasis:** Es geht in Build, ohne dass festgelegt wurde, wie die Leistung des entstehenden Workflows gemessen wird. Das erzeugt zuverlässig das Problem nachträglicher Kennzahlen, das Diagnose auf Organisationsebene vermeiden sollte.
- **Ein Design, das das Team des Unternehmens nicht betreiben kann:** Die Architektur ist technisch solide, setzt aber ein Maß an laufender technischer Raffinesse voraus, das das tatsächliche Team nicht hat und das Enable nicht aufbauen soll. Ein elegantes Design, das auf Unternehmensseite niemand eigenständig pflegen kann, ist nach dem Maßstab von kōdōkalabs keine gelungene Architektur, wie gut es am ersten Tag auch läuft.

## Von Architect zu Build

Architect übergibt Build den vollständigen Satz an Deliverables: Ziel-Operating-Model, Workflow-Spezifikationen, Verantwortungsmatrix, Wissenslandkarte, Integrationsplan, Governance-Matrix, Messplan, priorisiertes Backlog, Pilotdefinition, Dokumentationsplan und Plan für den Capability Transfer. Build setzt um, was Architect spezifiziert hat. Es ist nicht der Ort, an dem fehlende Designentscheidungen zum ersten Mal getroffen werden.

## Häufige Fragen zur Architect-Phase (FAQ)

### Was muss entworfen sein, bevor ein KI-Marketing-System gebaut wird?

Alle acht Ebenen des Architecture Decision Stack: Geschäftsergebnis und Umfang, Operating Model und Entscheidungsrechte, Workflow und Verantwortung zwischen Mensch und KI, Wissens- und Datenarchitektur, Technologie- und Integrationsarchitektur, Governance und Qualitätskontrollen, Messung und Wertbeitrag sowie Enablement, Dokumentation und Übergabe der Verantwortung.

### Was ist der Unterschied zwischen Architect und Strategic Architecture?

Architect legt das Ziel-Operating-Model für den gesamten Umfang der Transformation fest. Strategic Architecture ist die wiederholbare Liefermethode, mit der kōdōkalabs innerhalb dieses bereits freigegebenen Operating Models ein einzelnes Arbeitspaket, einen Workflow oder ein Content-System spezifiziert: enger im Umfang und in Build wiederholt angewendet.

### Braucht es wirklich die volle Architektur mit acht Ebenen?

Die acht Ebenen gelten in jeder Architektur in irgendeinem [Maßstab](./scale-ai-marketing-workflows.md), die Tiefe unterscheidet sich aber: Eine Minimum Viable Architecture für ein kontrolliertes Pilotprojekt dokumentiert jede Ebene weniger detailliert, als es eine Neugestaltung des Operating Models im ganzen Unternehmen verlangen würde.

### Wer gibt die Architektur frei?

Der Executive Sponsor, die relevanten Governance-Stakeholder, die Workflow-Verantwortlichen, die das Ergebnis betreiben, und eine benannte finale freigebende Instanz. Siehe „Architektur-Review und Freigabeschranken“ weiter oben.

### Was, wenn Architect eine Lücke aus Diagnose aufdeckt?

Richtig ist die Rückkehr zu Diagnose für genau diesen Bereich und kein Design um eine Annahme herum: Eine Architektur auf Basis unvollständiger Evidenz liefert tendenziell ein gut dokumentiertes Design für das falsche Problem.

### Kann man mit Architect weitermachen, bevor die Governance vollständig freigegeben ist?

Governance ist eine der acht Ebenen und kein optionaler Zusatz: Risikoklasse und Prüfanforderungen eines Workflows sind Teil seiner Spezifikation und keine separate Freigabe, die erst eingeholt wird, wenn das Design ansonsten fertig ist.

### Wie lange dauert die Architect-Phase?

Das hängt stark vom Umfang ab: Die Architektur eines Pilotprojekts mit einem Workflow und die Neugestaltung eines unternehmensweiten Operating Models verlangen deutlich unterschiedlichen Designaufwand. Darum gibt es die Minimum Viable Architecture als definierte, schlankere Option.

## Bereit, Ihr KI-Marketing-Operating-Model zu entwerfen?

Wenn Sie genug von zersplitterten, Keyword-zentrierten Strategien haben, ist es Zeit für ein Fundament, das Algorithmus-Änderungen übersteht. Wir beginnen mit dem Entwurf, der eine Umsetzung mit hohem ROI sicherstellt.[Kontakt aufnehmen](#contact)