MarTech unter der Haube, Teil 3: Data Governance wird ausgeschaltet ausgeliefert

Teil 1 und 2 sind sieben Stationen abgegangen: ob die Daten ankommen, ob sie modelliert sind, ob sie sich zu einer Person auflösen, ob die Fragmente ein Profil werden, wie schnell eine Regel beantwortet werden kann, wo eine Entscheidung fallen kann und wie lange sie bis zu einem Kanal braucht. Sieben Stationen, die entscheiden, ob Sie handeln können.

Dieser Teil behandelt, ob Sie handeln dürfen – und ob hinterher irgendjemand sagen kann, was sich dadurch verändert hat. Jede Data Governance Policy wird ausgeschaltet ausgeliefert – auch Adobes eigene Core Policies – und Adobe dokumentiert das auf zwei verschiedenen Seiten. Dann zwei Fragen, die um die neun Stationen herum sitzen statt in ihnen: was es kostet, die Daten im Warehouse zu lassen, und was ein KI-Agent tatsächlich sieht.

Wie zuvor ist Adobe Experience Platform das durchgerechnete Beispiel, weil Adobe seine Grenzen öffentlich dokumentiert. Jede Zahl verlinkt auf ihre Quelle; alle Seiten wurden am 11. September 2026 abgerufen. Nichts davon ist eine rechtliche Einschätzung – das ist ein Gespräch für den Datenschutzbeauftragten, nicht für einen Architekturartikel.

Station 8 – Steuern

Jedes Architekturdiagramm hat einen Governance-Kasten. Er ist meist als Band an der Seite oder unten gezeichnet, anders eingefärbt, beschriftet mit „Data Governance & Privacy“. Es ist der Kasten, auf den im Lenkungsausschuss alle zeigen und den niemand öffnet.

Öffnen wir ihn. Adobes Rahmenwerk hat drei Teile:

• Labels klassifizieren Daten. Sie kommen in drei Kategorien: Contract mit den Codes C1 bis C12, Identity mit I1 und I2, und Sensitive mit S1 und S2 neben Labels für zulässige sensible personenbezogene Daten und regulierte Gesundheitsdaten.
• Policies beschreiben, was mit gelabelten Daten geschehen darf.
• Enforcement wendet diese Policies am Punkt der Aktivierung an.

Labels propagieren nützlich: Zielgruppen erben automatisch die Labels der Datensätze, aus denen sie gebaut wurden. Die Durchsetzung ist, wenn aktiv, echt – ein Verstoß blockiert die Aktivierung und zeigt einen Lineage-Graph mit genau den Datensätzen, Merge Policies, Zielgruppen und Destinations, die beteiligt waren.

Und dann ist da dieser Satz. Er steht, Wort für Wort, auf zwei verschiedenen Adobe-Seiten: „All data usage policies (including core policies provided by Adobe) are disabled by default. In order for an individual policy to be considered for enforcement, you must manually enable that policy.“ Neu angelegte Policies sind ebenfalls standardmäßig deaktiviert.

Das ist ein vertretbarer Entwurf – eine Durchsetzung, die Aktivierungen ab dem Moment blockiert, in dem man die Plattform einschaltet, würde jede Implementierung mit einem Ausfall beginnen lassen. Aber sie erzeugt einen spezifischen und gefährlichen Ausfallmodus: nichts scheitert. Eine nicht durchgesetzte Policy erzeugt keine Fehler, keine Warnungen, keine Warteschlange. Als eingeschränkt gelabelte Daten aktivieren genauso reibungslos wie nicht eingeschränkte. Das einzige Signal, dass Governance aus ist, ist das Fehlen eines Signals – und das ist das Schwerste, was eine Organisation bemerken kann.

Was eine Data Governance Policy tatsächlich abdeckt

Drei weitere Tatsachen entscheiden, ob der Kasten, einmal geöffnet, das tut, was alle annehmen.

• Marketing Actions allein schränken nichts ein. Sie „must be included in enabled data usage policies“, um zu wirken. Daten zu labeln und Marketing Actions zu definieren, ohne eine Policy zu aktivieren, erzeugt Dokumentation, keine Durchsetzung.
• Governance ist keine Zugriffssteuerung. Adobe ist deutlich: Data Governance befasst sich nur damit, wie Daten genutzt oder aktiviert werden, „regardless of the user performing the action“. Einzuschränken, welche Personen welche Felder sehen, ist ein anderer Mechanismus – Attribute-based Access Control – dokumentiert als Limited Availability für Kunden, die Healthcare und/oder Privacy Shield kaufen.
• Object-level Access Control hat eine eigene Voraussetzung. Adobe dokumentiert Object-level Access Control für Datensätze als seit dem 18. August 2026 allgemein verfügbar, ebenso für Destination-Dataflows. Die Zugriffssteuerung auf Datensatzebene verlangt zusätzlich, dass die Default-Label-Based-Access-Control-Policy aktiv ist – „without this policy, Adobe Experience Platform does not evaluate dataset access labels.“

Die Consent-Lücke

Consent Policies sind eine lizenzierte Fähigkeit, und sie haben eine dokumentierte Lücke. Sie sind nur mit Healthcare Shield oder Privacy & Security Shield verfügbar. Ihre Logik ist die Umkehrung der Governance Policies: Adobe beschreibt Consent Policies als „inclusive in nature“ – sie bestimmen, welche Profile einbezogen werden dürfen – während Governance Policies gelabelte Attribute von der Aktivierung ausschließen.

Und dann dies, aus Adobes Aktivierungs-Dokumentation: „Consent policy evaluation is currently not supported in exports to the three enterprise destinations – Amazon Kinesis, Azure Event Hubs, and HTTP API“ – und deshalb „profiles which have not consented to being targeted are included in the exports to these three destinations“.

Drei Destinations in Adobes eigenem Katalog, alle drei in Unternehmensarchitekturen üblich, in denen die Consent-Prüfung nicht läuft. Adobe dokumentiert das offen. Das spricht für Adobe, und es macht die Seite nicht weniger lesenswert, bevor Sie eine davon anschließen.

Eine verwandte Grenze auf der Erfassungsseite: im Web SDK wird nur die Datenerfassungs-Berechtigung collect.val automatisch durchgesetzt. Jedes andere Einwilligungssignal, das Sie erfassen, muss von etwas durchgesetzt werden, das Sie nachgelagert selbst bauen.

Einen Fall haben wir angeschaut (auf Englisch), in dem ein Label eine Paid-Social-Aktivierung aktiv blockiert – die Variante davon, die wie vorgesehen funktioniert.

Station 9 – Messen

Der Rückweg ist die dünnste Station dieser Serie, weil er die dünnste in der Dokumentation ist. Das ist selbst schon der Befund.

Veröffentlicht ist, was das Abfragen betrifft:

• Ad-hoc-Queries sind bei 10 Minuten Ausführungszeit gedeckelt.
• Sie geben 100 Zeilen in der Oberfläche und bis zu 50.000 über einen Client zurück.
• Batch-Queries laufen bis zu 24 Stunden.
• Der beschleunigte Speicher erlaubt vier gleichzeitige Query-Slots.
• Data Distiller ist ein separates Paket mit einem Teil der Plattformfunktionalität.

Was die Guardrails nicht beschreiben, ist die Schleife selbst: wie Engagement-Ergebnisse zu neuen Signalen werden, wie schnell, mit welcher Identität. Das muss entworfen statt konfiguriert werden – und es ist der Teil der Architektur, der am häufigsten auf „Phase zwei“ verschoben wird, weshalb so viele Programme beschreiben können, was sie gesendet haben, aber nicht, was es verändert hat.

Wenn die Wahrheit im Warehouse liegt

In den meisten Unternehmen liegen die maßgeblichen Kundendaten nicht in einer Marketingplattform. Sie liegen in Snowflake, BigQuery, Databricks oder Redshift, verwaltet von einem Datenteam, das eine Meinung zu Kopien hat.

Adobes Antwort heißt Federated Audience Composition und baut Zielgruppen aus Daten in einem externen Warehouse, ohne sie zu kopieren. Die eigene FAQ ist deutlich, was sich bewegt: „Federated Audience Composition only stores metadata (schema descriptions). No customer data is transiting.“ Sieben Warehouses werden unterstützt: Redshift, Azure Synapse, Databricks, BigQuery, Snowflake, Vertica Analytics und Microsoft Fabric.

Für jeden, der ein Jahr damit verbracht hat, mit einem Security-Team eine Ausnahme für eine Datenkopie zu verhandeln, ist das eine erhebliche Fähigkeit. Aber es gibt einen Handel, und er steht in derselben FAQ statt in irgendeiner Vergleichstabelle.

Zwei operative Anmerkungen: so importierte Zielgruppen verfallen standardmäßig nach 30 Tagen, und die Fähigkeit setzt Real-Time CDP und/oder Journey Optimizer auf Prime- oder Ultimate-Stufe voraus, plus eine spezifische Berechtigung „Manage Federated Data“.

Was KI-Agenten verändern

Jeder Hersteller liefert inzwischen Agenten aus, und die interessante Frage ist nicht, was sie tun können, sondern was sie sehen können.

Adobes agentische Schicht ist der Adobe Experience Platform Agent Orchestrator – ausgeschrieben; „AEP Agent Orchestrator“ ist nicht der Produktname. Er wird beschrieben als „the new agentic layer in Adobe Experience Platform“, der, in Adobes Worten, „with human oversight“ arbeitet. Zu den benannten Agenten gehören Audience Agent, Data Insights Agent, Experimentation Agent, Journey Agent, Product Support Agent und der Adobe Marketing Agent für Microsoft 365 Copilot.

Woraus sie schöpfen, wird beschrieben als „structured and unstructured data sources, including Adobe product documentation, customer metadata about business objects, and analytics data“.

Lesen Sie diese Liste noch einmal darauf, was nicht drinsteht. Die Wissensbasis besteht aus Dokumentation, Metadaten über Geschäftsobjekte und Analysedaten – nicht aus dem Kundendatensatz selbst. Ein Agent, der Ihnen beim Bauen einer Zielgruppe hilft, arbeitet auf der Beschreibung Ihrer Daten, nicht auf den Menschen darin.

In einer regulierten Umgebung ist das keine Einschränkung, um die man herum konstruiert. Es ist die Bedingung, unter der ein Agent überhaupt laufen darf – und es erklärt, warum ein Agent Ihnen sagen kann, wie Ihre Zielgruppen aufgebaut sind, aber nicht, wer darin ist.

Eine Namenskorrektur, weil sie falsch kursiert: Adobe Brand Concierge ist kein Experience-Platform-Agent. Es ist ein eigenes Produkt, das Experience-Platform-Daten konsumiert; der darin arbeitende Agent ist der Product Advisor Agent. Ihn zum Kreis des Agent Orchestrator zu zählen ist ein Kategorienfehler, der in vielen Zusammenfassungen aus zweiter Hand auftaucht.

Der Bauplan: zwölf Fragen

Wenn Sie eine Sache aus dieser Serie in ein Meeting mitnehmen, dann diese. Eine pro Station, plus drei quer darüber.

1. Welcher Namespace ist Ihre Personenidentität – und ist er als eindeutig deklariert?
2. Wie viele Identitäten trägt Ihr durchschnittlicher Identity Graph heute?
3. Hat jemand die Normalisierung der E-Mail-Groß-/Kleinschreibung über jede schreibende Quelle geprüft?
4. Welche Ihrer Zielgruppenregeln greifen weiter zurück als 24 Stunden?
5. Wie viele Edge- und Streaming-Zielgruppen sind aktiv, gegen Adobes empfohlene 150 und 500?
6. Sind für jede zugesagte Echtzeitentscheidung die benötigten Daten an die Edge projizierbar?
7. Wie hoch ist die Aktivierungslatenz jedes Kanals in Ihrem aktuellen Kampagnenplan?
8. Welche Data Usage Policies sind in Ihrer Produktiv-Sandbox aktiviert – heute, nicht im Designdokument?
9. Welche Destinations erhalten Profile, deren Einwilligung nie ausgewertet wurde?
10. Wie hoch ist Ihr Event-Volumen pro Profil, gegen Adobes 5.000-Event-Guardrail für die Segmentierung?
11. Welche Daten brauchen wirklich aufgelöste Identität, und welche nur einen verlässlichen Schlüssel?
12. Wer hat die primäre Identität Ihrer profilaktivierten Schemas freigegeben, und wann?

Wenn acht der zwölf einen Verantwortlichen und eine Antwort haben, haben Sie eine Omnichannel-Architektur. Wenn vier es haben, haben Sie eine Omnichannel-Roadmap. Beides sind legitime Positionen. Das eine für das andere zu halten ist das, was den Stillstand nach achtzehn Monaten erzeugt.

Häufige Fragen

Was ist eine Data Governance Policy?

Eine Data Governance Policy ist eine Regel, die sagt, was mit Daten geschehen darf, die bestimmte Labels tragen – und sie wird am Punkt der Aktivierung durchgesetzt, nicht am Punkt des Zugriffs. In Adobe Experience Platform klassifizieren Labels die Daten, Policies beschreiben die erlaubte Nutzung, und die Durchsetzung blockiert eine verstoßende Aktivierung und zeigt die Lineage dahinter. Was Teams übersehen: jede Data Governance Policy, auch die von Adobe bereitgestellten Core Policies, ist standardmäßig deaktiviert und muss von Hand aktiviert werden.

Wo wird Einwilligung in einem MarTech-Stack durchgesetzt?

An mehreren Punkten, und nicht einheitlich. Einwilligung kann bei der Erfassung aufgenommen, im Profil gespeichert und bei der Aktivierung ausgewertet werden. Bei Adobe setzen Consent Policies eine Healthcare-Shield- oder Privacy-&-Security-Shield-Lizenz voraus, und Adobe dokumentiert, dass die Consent-Auswertung für Exporte an Amazon Kinesis, Azure Event Hubs oder die HTTP-API-Destination nicht läuft. Im Web SDK wird nur die Datenerfassungs-Berechtigung automatisch durchgesetzt. Alles andere muss von etwas durchgesetzt werden, das Sie selbst bauen.

Sehen KI-Agenten in einer Marketingplattform Kundendaten?

In Adobes dokumentierter Architektur wird die Wissensbasis des Agent Orchestrator als Produktdokumentation, Metadaten über Geschäftsobjekte und Analysedaten beschrieben – nicht als die Kundendatensätze selbst. Ein Agent kann beschreiben, wie Ihre Zielgruppen aufgebaut sind, ohne zu sehen, wer darin ist. Prüfen Sie das pro Hersteller und pro Agent, statt anzunehmen, dass es sich verallgemeinern lässt.

Wie arbeiten eine CDP und ein Data Warehouse zusammen?

Zwei Muster. Kopieren – die Daten in die CDP bewegen, wo sie vollständige Identity Resolution und Profilbehandlung bekommen. Oder föderieren – sie im Warehouse lassen und Zielgruppen dagegen komponieren, ohne zu kopieren, wie Adobes Federated Audience Composition es tut. Der Handel ist explizit: föderierte Daten werden über einen Schlüssel verbunden, den Sie definieren, statt über Identity Resolution, sie bekommen also kein Cross-Device-Stitching. Die meisten Unternehmen fahren am Ende beide Muster für verschiedene Daten.

Was ist der Unterschied zwischen einer Customer Data Platform und einem Data Warehouse?

Ein Warehouse speichert alles für die Analyse, optimiert auf große Scans über lange Historien. Eine CDP speichert ein Arbeitsprofil, optimiert auf Abruf in Millisekunden während einer laufenden Interaktion, mit eingebauter Identity Resolution und Aktivierung. Bei Adobe sind es buchstäblich verschiedene Technologien – Cosmos DB für den Profilspeicher, Azure Data Lake Storage für den Lake. Die meisten Unternehmen brauchen beides, verbunden, statt dass eines das andere ersetzt.

Weiterlesen: Teil 1 – nichts funktioniert, bevor die Daten eine Person sind · Teil 2 – Echtzeit ist eine Eigenschaft der Regel · Wenn ein Label eine Paid-Social-Aktivierung blockiert (auf Englisch) · Die Salesforce-Seite: Data 360 startet mit einer „Allow All“-Policy.

Die Zahlen in diesem Artikel stammen aus Adobes öffentlicher Dokumentation und verlinken auf ihre Quelle; alle Seiten wurden am 11. September 2026 abgerufen. Guardrails ändern sich mit Releases, und Adobe unterscheidet zwischen systemseitig erzwungenen Grenzen und Performance-Empfehlungen – prüfen Sie gegen Ihren eigenen Tenant, bevor Sie auf eine Zahl hin entwerfen, auch auf diese. Nichts hiervon ist eine Rechtsberatung. Quellen: Data Governance overview · Data usage policies · Data usage labels reference · Attribute-based access control · Activate streaming profile destinations · Query Service guardrails · Federated Audience Composition FAQ · Agent Orchestrator. Adobe, Adobe Experience Platform und Adobe Real-Time CDP sind Marken von Adobe Inc. Dies ist eine unabhängige Analyse; keine Partnerschaft mit oder Billigung durch Adobe.