MarTech-Architektur für Marketing-KI richtig planen

Eine belastbare MarTech-Architektur beantwortet vor der Integration fünf Fragen: Welches System ist für welche Art von Daten die massgebliche Quelle? Welche Daten dürfen zu welchem Zweck fliessen? Wie werden Personen, Ereignisse und Inhalte eindeutig referenziert? Wer behandelt Fehler? Und wie lässt sich eine Komponente abschalten oder ersetzen? Erst wenn diese Antworten dokumentiert sind, sollte ein KI-Dienst in einen Marketingprozess eingebunden werden. Ein Architekturdiagramm allein genügt nicht; entscheidend sind die zwischen den Systemen vereinbarten Datenformate, Bedeutungen, Zugriffsregeln und die Behandlung von Fehlern.

Architektur beginnt mit Verantwortungsgrenzen

Listen Sie nicht zuerst Produkte auf, sondern fachliche Funktionen: Kontakte verwalten, Inhalte freigeben, Kampagnen ausspielen, Einwilligungen respektieren, Ereignisse erfassen, Ergebnisse analysieren. Ordnen Sie jeder Funktion genau eine fachlich verantwortliche Person und, wo möglich, ein führendes System zu. «Das CRM und die Marketingplattform kennen beide den Kontakt» ist noch keine Entscheidung. Geklärt werden muss, welches System die primäre Identität hält, welches Änderungen annehmen darf und wie Konflikte aufgelöst werden.

Diese Grenze verhindert, dass ein KI-Dienst unbemerkt zu einem zweiten führenden System wird. Ein Modell kann etwa einen Betreff vorschlagen oder einen Datensatz klassifizieren. Es sollte aber nicht allein bestimmen, ob eine Einwilligung gültig ist, einen Vertragsstatus überschreiben oder eine Identität zusammenführen. Solche Zustandsänderungen brauchen deterministische Regeln, Autorisierung und eine nachvollziehbare Quelle.

Die fünf Ebenen einer Integrationskarte

Die erste Ebene enthält die Quellsysteme. Dazu können CRM (Kundenbeziehungsmanagement), CMS (Redaktionssystem für Inhalte), DAM (Verwaltung digitaler Medieninhalte), Shop, Analytics oder Werbeplattform gehören. Pro Quelle werden die Datenverantwortlichen, der Aktualisierungstakt und bekannte Qualitätsgrenzen notiert. «Kundendaten» ist zu unscharf. Benennen Sie konkrete Felder und ihren Zweck: Kontakt-ID, Sprache, Produktstatus oder freigegebener Textbaustein.

Die zweite Ebene ist die Identität. Menschen, Unternehmen, Kampagnen, Assets und Ereignisse brauchen stabile Schlüssel. E-Mail-Adressen sind veränderbar und sollten nicht unbesehen als universelle Identität dienen. Definieren Sie, welcher Schlüssel systemübergreifend verwendet wird, wie Dubletten erkannt werden und welche Zusammenführungen verboten sind. Kann eine Identität nicht zuverlässig abgeglichen werden, braucht es einen ausdrücklichen Halte- oder Stopp-Pfad; eine anonymisierte Verarbeitung ist nur zulässig, wo sie für den Zweck erlaubt ist.

Die dritte Ebene bildet der Datenvertrag. Er beschreibt nicht nur ein JSON-Schema, sondern auch Bedeutung, Herkunft, Zweck, Aktualität und Qualitätsregel eines Feldes. Ein Feld «score = 0.8» ist ohne Modellversion, Skala und Gültigkeitszeitpunkt kaum nutzbar. Ein Vertrag sollte Pflichtfelder, erlaubte Werte, Versionierung, Löschregel und Verhalten bei unbekannten Feldern enthalten. So wird eine Schnittstelle prüfbar, bevor ein Modell daraus Schlussfolgerungen zieht.

Die vierte Ebene ist die Orchestrierung. Sie entscheidet, ob ein Prozess synchron auf eine Antwort wartet, ein Ereignis asynchron verarbeitet oder eine Stapeldatei periodisch austauscht. Diese Wahl hat Folgen. Eine synchrone Kette kann bei einem Ausfall den sichtbaren Prozess blockieren. Ein asynchrones Ereignis braucht eine Regel zur Vermeidung oder Erkennung von Dubletten und eine definierte Reihenfolge. Die Daten eines Stapels können veraltet sein; der Stapelmechanismus selbst ist deshalb nicht obsolet. Die Architektur sollte den fachlichen Bedarf benennen, nicht einfach die technisch modernste Variante wählen.

Die fünfte Ebene umfasst Beobachtbarkeit und Betrieb. Für jeden Übergang braucht es einen technischen Status, eine Korrelations-ID, einen Zeitstempel und eine Warteschlange mit klar zugewiesener Zuständigkeit. Logs müssen helfen, einen Vorgang zu erklären, dürfen aber keine unnötigen Personendaten oder Prompts offenlegen. Ein Dashboard ohne klar zugewiesene Zuständigkeit ist nur eine Anzeige. Definieren Sie, wer bei welchem Fehler reagiert, welche Verarbeitung sicher wiederholt werden kann und wann der Prozess gestoppt wird.

Point-to-point, Integrationsschicht oder modulare Komponenten?

Eine direkte Verbindung zwischen zwei stabilen Systemen kann ausreichend sein. Das Problem entsteht, wenn jede Anwendung jede andere direkt kennt: Änderungen vervielfachen dann Tests, Zugangsdaten und Abhängigkeiten. Eine Integrationsschicht kann Formate übersetzen, Ereignisse verteilen und Zugriffe zentral beobachten. Sie darf jedoch nicht zum undokumentierten Monolithen werden, der sämtliche Fachlogik versteckt.

Die MACH Alliance beschreibt offene, komponierbare und verbundene Architektur als Zusammenspiel dokumentierter, portabler Komponenten, unabhängig ersetzbarer Funktionen und interoperabler Verbindungen, die nach dem API-first-Ansatz gestaltet sind (API = Schnittstelle für Anwendungsprogramme). Das kann für Organisationen mit vielen unabhängigen Funktionen nützlich sein, ist aber kein Selbstzweck. Ein kleines Team kann mit wenigen gut abgegrenzten Systemen, stabilen APIs und sauberem Betrieb besser fahren als mit Dutzenden Microservices. Die Entscheidung richtet sich nach Änderungsfrequenz, Teamstruktur, Risiko und Betriebsfähigkeit.

API-first bedeutet in diesem Kontext: Die Schnittstelle wird wie ein Produkt mit verbindlichen Zusagen zu ihrem Funktionieren behandelt. Sie hat eine verantwortliche Person, eine Version, dokumentierte Fehler, Berechtigungen, Limits und eine Regel für das Abkündigen älterer Versionen. «Es gibt eine API» ist kein ausreichendes Auswahlkriterium. Entscheidend ist, ob der benötigte Datenfluss vollständig, sicher und testbar abgebildet werden kann.

Eine KI-Komponente braucht eine engere Grenze

Bei einem klassischen Regelservice ist dieselbe Eingabe meist eng mit derselben Ausgabe verbunden. Ein generatives Modell kann variieren. Der Integrationsvertrag muss deshalb zusätzlich Modell- oder Dienstversion, Promptvorlage, erlaubte Wissensquellen, Ausgabeformat, Validierungsstatus und menschliche Freigabe transportieren. Speichern Sie nicht nur das Ergebnis, sondern die für eine spätere Prüfung nötige Provenienz, soweit dies datenschutz- und aufbewahrungsrechtlich zulässig ist.

Ein Modell darf keine Rechte erhalten, die es für seine Aufgabe nicht braucht. Wenn es einen Text entwirft, braucht es nicht automatisch Schreibzugriff auf das CMS. Wenn es eine Kampagne analysiert, braucht es nicht automatisch Mutationsrechte. Vorschlag und Ausführung sollten über getrennte technische Identitäten und Endpunkte laufen. Der Ausführungspfad prüft Autorisierung, Version und Freigabe unabhängig vom Modell.

Zugangsdaten gehören weder in Prompts noch in versteckte Systemanweisungen. OWASP weist darauf hin, dass ein Systemprompt kein Geheimnis und keine Autorisierungsschicht ist. Geheimnisse gehören in einen dafür vorgesehenen Speicher; der Zugriff sollte, wo dies unterstützt wird, zeitlich begrenzt und nach dem Prinzip der minimalen Rechte vergeben werden. Der Modellkontext erhält nur die Informationen, die für die konkrete Aufgabe nötig sind.

Datenschutz wird am Datenfluss geprüft

Die Frage «Ist das Tool DSG-konform?» ist zu grob. Geprüft wird eine konkrete Bearbeitung: Zweck, Datenkategorien, Herkunft, Empfänger, Speicherorte, Aufbewahrung und Rechte der betroffenen Personen. Der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte (EDÖB) hält fest, dass das Schweizer DSG direkt auf KI-gestützte Personendatenbearbeitung anwendbar ist. Sind die Voraussetzungen erfüllt, ist eine Datenschutz-Folgenabschätzung gesetzlich vorgeschrieben.

Zeichnen Sie deshalb im Architekturplan nicht nur Pfeile, sondern beschriften Sie jeden Pfeil mit Zweck und Datenklasse. Markieren Sie, ob Daten die Organisation oder das Land verlassen, ob ein Unterauftragnehmer beteiligt ist und wie Lösch- oder Auskunftsanfragen weitergegeben werden. Diese Karte ersetzt keine Rechtsprüfung, macht sie aber konkret.

Fehlerpfade sind Teil der Architektur

Planen Sie mindestens: Zeitüberschreitung, ungültige Antwort, Teilverarbeitung, doppeltes Ereignis, veraltete Eingabe, widerrufene Berechtigung und nicht verfügbaren Drittanbieter. Für jeden Fall braucht es einen sicheren Zustand. Ein Retry darf keine doppelte Nachricht oder doppelte Änderung erzeugen. Eine «Dead-letter»-Warteschlange braucht eine verantwortliche Person und eine Aufbewahrungsfrist. Ein Fallback darf die Schutzmassnahme nicht umgehen.

Planen Sie von Anfang an, wie ein Dienst ersetzt oder verlassen werden kann. Können Daten, Vorlagen, Prüfprotokolle und Konfigurationen exportiert werden? Welche proprietären IDs müssen übersetzt werden? Was geschieht, wenn eine API-Version endet oder ein Modell zurückgezogen wird? Aktuelle offizielle UK-Leitlinien zur Einführung und Beschaffung von GenAI-Werkzeugen betonen organisatorische Risiken, Training, Support und laufendes Monitoring. Diese Fragen machen es möglich, Anbieter oder Komponenten zu wechseln, ohne die Kontrolle über den Prozess zu verlieren.

Architekturentscheide und Verträge gemeinsam testen

Dokumentieren Sie wesentliche Entscheide in kurzen Architekturentscheiden (Architecture Decision Records, ADR): Kontext, Optionen, gewählte Lösung, abgelehnte Alternativen, Folgen und Revisionsdatum. Ein solcher Eintrag ist keine Rechtfertigung im Nachhinein. Er zeigt dem nächsten Team, warum ein synchroner Aufruf, eine Integrationsschicht oder eine bestimmte Verantwortung für die führenden Identifikatoren gewählt wurde und bei welcher Änderung die Entscheidung überprüft werden muss.

Ergänzen Sie Diagramme durch automatisierte Schnittstellen-Vertragstests. Ein Test kann prüfen, ob Pflichtfelder vorhanden sind, unbekannte Schema-Versionen abgelehnt werden, Schreibzugriffe ohne Freigabe scheitern und wiederholte Ereignisse keine doppelte Wirkung erzeugen. Ein weiterer Test simuliert den Ausfall eines Drittanbieters und verifiziert den sicheren Zustand. Solche Tests beweisen nicht die gesamte Architekturqualität, machen aber kritische Annahmen reproduzierbar.

Planen Sie auch Kapazität und Limits. Ein Modell- oder API-Dienst kann langsam, gedrosselt oder teurer als erwartet werden. Die Architektur braucht Obergrenzen pro Zeitraum, Warteschlangen und eine Regel, welche Vorgänge bei Engpässen priorisiert oder gestoppt werden. Kostenwarnungen sind operative Signale, keine Berechtigung, Qualitäts- oder Datenschutzkontrollen zu umgehen.

In kleinen, rückgängig machbaren Schritten migrieren

Ein «Big Bang» verbindet zu viele Annahmen. Beginnen Sie mit einem lesenden Datenfluss und synthetischen Testfällen. Danach kann ein Schattenlauf Ergebnisse erzeugen, ohne den operativen Prozess zu beeinflussen. Erst wenn Identität, Schema, Fehlerbehandlung und Review stabil sind, folgt eine begrenzte schreibende Aktion. Jede Stufe hat messbare Abnahmekriterien und einen Rollback.

Der Architekturentscheid ist bereit, wenn die Übersicht der fachlichen Funktionen, die führenden Systeme, Identitäten, Datenverträge, Berechtigungen, die Verantwortlichen für Fehler, Logs, Aufbewahrung und Ausstieg dokumentiert sind. Fehlt das, sollte keine zusätzliche KI-Komponente die Unklarheit verdecken. Diese Checkliste hilft bei der Planung; sie bedeutet nicht, dass eine MarTech-Umsetzung im Produkt Google Ads enthalten ist. Betrifft ein abgegrenzter Teil ausschliesslich Google Ads, kann dessen bestehender Zustand separat read-only auditiert werden; eine externe CRM- oder Website-Prüfung ist damit nicht verbunden.

Wie maitiq hilft: Den vollständigen Weg eines Leads durch alle Systeme verfolgen

Zeichnen Sie den Weg von der Anfrage über das CRM bis zur Vertriebsrückmeldung auf. Pro Übergang werden Identifikator, benötigte Felder, verantwortliches System und Fehlerbehandlung festgelegt. Ein fehlgeschlagener Transfer muss sichtbar werden; ein erneuter Versuch darf nicht denselben Lead doppelt anlegen.

In einer vereinbarten Vorabklärung lässt sich klären, welche Übergaben und Datenflüsse wirklich nötig sind; eine daran anschliessende Umsetzung wird separat vereinbart. Eine gute Integration reduziert manuelle Übertragungen und erhält die Bedeutung der Daten. Der Erfolg wird an vollständigen Übergaben, der Fehlerquote und der manuellen Nacharbeit gemessen, nicht an der Anzahl verbundener Tools.

Wie ein erster Pilot mit maitiq beginnt

Eine vereinbarte Vorabklärung zeigt, welche Verbindung wirklich nötig ist, wo unnötige Daten- oder Rechteausweitung entsteht und was eine kontrollierte Umsetzung erfordert. Sie erhalten einen klar abgegrenzten Anwendungsfall und eine Aufzeichnung der offenen Daten- und Kontrollfragen sowie einen Pilotplan und die Kriterien für einen späteren Betrieb. Eine allfällige Umsetzung wird separat vereinbart.

Entscheidungsregel: Zeichnen Sie zuerst den minimalen Datenfluss und die erlaubte Aktion; wählen Sie Technik erst danach.

Quellen und Einordnung

Der EDÖB erläutert als Datenschutzbehörde die Anforderungen des DSG an KI; OWASP beschreibt Sicherheitsrisiken und Gegenmassnahmen; die MACH Alliance formuliert als Branchenverband Grundsätze für komponierbare Architekturen. Jede Quelle ist entsprechend ihrem Zweck einzuordnen. Angaben zur Arbeitsweise von maitiq finden Sie auf maitiq.com.

Lassen Sie Ihren konkreten Fall von maitiq prüfen.