- Part 1Collect · Model · Resolve
- Part 2Unify · Segment · Decide · Activate
- Part 3 · you are hereGovern · Measure · Warehouse · AI agents
Enforcement you never switched on fails the same way a graph does: silently, and with no error to find.
- OffAll data usage policies, including Adobe’s own core policies, are disabled by default. Newly created ones too.
- ThreeEnterprise destinations in Adobe’s catalogue where consent policy evaluation does not run – and non-consented profiles are included in the export.
- No IDsFederated composition joins on a key you define. Data that stays in the warehouse gets no identity resolution at all.
30 seconds to here · 5 minutes for the four sections.
Parts 1 and 2 walked seven stations: whether the data arrives, whether it is modelled, whether it resolves into one person, whether the fragments become a profile, how fast a rule can be answered, where a decision can be made, and how long it takes to reach a channel. Seven stations that decide whether you can act.
This part covers whether you are allowed to – and whether anyone will be able to say afterwards what it changed. Every data governance policy ships switched off – including Adobe’s own core policies – and Adobe documents that on two separate pages. Then two questions that sit around the nine stations rather than inside them: what it costs to leave your data in the warehouse, and what an AI agent can actually see.
As before, Adobe Experience Platform is the worked example because Adobe documents its limits publicly. Every figure links to its source; all pages were retrieved on 11 September 2026. None of this is a legal assessment – that is a conversation for privacy counsel, not an architecture article.
Labels classify data, policies describe what may be done with it, enforcement applies them. Enforcement is real when active – a violation blocks the activation and shows a lineage graph. But every policy, including Adobe’s own core policies, is disabled by default and has to be enabled by hand. An unenforced policy produces no errors and no warnings: restricted data activates exactly as smoothly as data that is not.
Source: Data usage policies overview
What is published concerns querying: ad-hoc queries capped at 10 minutes, returning 100 rows in the interface and up to 50,000 through a client; batch queries up to 24 hours; four concurrent slots on the accelerated store. What the guardrails do not describe is the loop itself – how engagement outcomes become new signals, how quickly, with what identity. That has to be designed rather than configured.
Source: Query Service guardrails
Federated Audience Composition builds audiences from data in an external warehouse without copying it – its own FAQ states that it only stores metadata, and no customer data is transiting. The trade sits in the same FAQ rather than in any comparison chart: federated composition does not use Identity Service. Joins run on a key you define, so that data gets no cross-device stitching and no namespace priority.
The Adobe Experience Platform Agent Orchestrator draws on structured and unstructured sources described as product documentation, customer metadata about business objects, and analytics data. Read that list for what is not in it: the customer record. An agent that helps you build an audience works on the description of your data, not on the people in it.
Source: Agent Orchestrator
08 Govern09 MeasureWarehouseAI agents
Station 8 – Govern
Every architecture diagram has a governance box. It is usually drawn as a band across the side or the bottom, coloured differently, labelled “Data Governance & Privacy”. It is the box everyone points at in the steering committee and nobody opens.
Open it. Adobe’s framework has three parts:
- Labels classify data. They come in three categories: Contract, carrying the codes C1 through C12; Identity, with I1 and I2; and Sensitive, with S1 and S2 alongside labels for permitted sensitive personal data and regulated health data.
- Policies describe what may be done with labelled data.
- Enforcement applies those policies at the point of activation.
Govern
Deciding what may be done with which data, and enforcing it.
Data GovernanceLabels propagate usefully: audiences inherit the labels of the datasets they were built from automatically. Enforcement, when active, is real – a violation blocks the activation and shows a lineage graph of exactly which datasets, merge policies, audiences and destinations were involved.
Then there is the sentence. It appears, word for word, on two separate Adobe pages: “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.” Newly created policies are also set to disabled by default.
Activation completes. Every profile in the audience reaches the destination, including the ones whose datasets carry a restricted label. No error, no warning, no queue.
Activation is blocked. The violation names the datasets, merge policies, audiences and destinations involved, in a lineage graph.
This is the state a new sandbox is in. Adobe: “All data usage policies (including core policies provided by Adobe) are disabled by default.”
Enforcement is real once it is on. It is also a switch that someone has to find and flip – and nothing anywhere reports that it is off.
Source: Data usage policies · retrieved 11 Sep 2026
This is a defensible design – enforcement that blocked activations the moment you turned the platform on would make every implementation start with an outage. But it produces a specific and dangerous failure mode: nothing fails. An unenforced policy generates no errors, no warnings, no queue. Data labelled as restricted activates exactly as smoothly as data that is not. The only signal that governance is off is the absence of a signal, which is the hardest thing for any organisation to notice.
The only signal that governance is off is the absence of a signal.
A brand-new sandbox. Labels are applied, marketing actions are defined, nobody has touched the policy screen. What is enforced?
All data usage policies, including the core policies provided by Adobe, are disabled by default, and an individual policy must be enabled manually to be considered for enforcement. Marketing actions alone restrict nothing – they “must be included in enabled data usage policies” to have any effect.
A labelling project can be completed, signed off and reported as done while enforcing nothing. The artefact looks identical either way: labels applied, actions defined, activations running. Only the policy screen tells you which it is.
What a data governance policy actually covers
Three further facts decide whether the box, once opened, does what people assume it does.
- Marketing actions alone restrict nothing. They “must be included in enabled data usage policies” to have any effect. Labelling data and defining marketing actions without enabling a policy produces documentation, not enforcement.
- Governance is not access control. Adobe is explicit that data governance is only concerned with how data is used or activated, “regardless of the user performing the action”. Restricting which people can see which fields is a different mechanism – attribute-based access control – documented as being in limited availability for customers who purchase Healthcare and/or Privacy Shields.
- Object-level access control has its own precondition. Adobe documents object-level access control for datasets as generally available since 18 August 2026, and for destination dataflows. Dataset access control additionally requires the
Default-Label-Based-Access-Control-Policyto be active – “without this policy, Adobe Experience Platform does not evaluate dataset access labels.”
The consent gap
Consent policies are a licensed capability, and they have a documented gap. They are available only with Healthcare Shield or Privacy & Security Shield. Their logic is the inverse of governance policies: Adobe describes consent policies as “inclusive in nature” – they determine which profiles may be included – while governance policies exclude labelled attributes from activation.
And then this, from Adobe’s activation documentation: “Consent policy evaluation is currently not supported in exports to the three enterprise destinations – Amazon Kinesis, Azure Event Hubs, and HTTP API” – and therefore “profiles which have not consented to being targeted are included in the exports to these three destinations.”
Three destinations in Adobe’s own catalogue, all of them common in enterprise architectures, where the consent check does not run. Adobe documents this openly. That is to its credit, and it does not make the page any less worth reading before you connect one.
A related limit on the collection side: in the Web SDK, only the data collection permission collect.val is automatically enforced. Every other consent signal you capture has to be enforced by something you build downstream.
Your architecture streams profiles to an HTTP API destination. Whose consent has been checked?
Consent policy evaluation is not supported in exports to Amazon Kinesis, Azure Event Hubs and the HTTP API destination, and Adobe states that profiles which have not consented to being targeted are included in exports to those three. Consent policies also require a Healthcare Shield or Privacy & Security Shield licence to exist at all.
These three are enterprise plumbing – the destinations a data team reaches for when a channel has no native connector. The enforcement point you are relying on has a documented boundary, and knowing where it runs is a precondition for designing around it. What follows from that is a question for privacy counsel, not for an architecture article.
We looked at one case where a label actively blocks a paid-social activation – the version of this that works as intended.
I ask for a screenshot of the policy list in the production sandbox, filtered to enabled, with the date visible. Not the design document, not the labelling plan – the screen. Then I list every destination against whether consent evaluation runs for it. Both take twenty minutes and they are the two questions I have never had answered from memory in a first workshop.
Christopher Dettinger · MarTech and omnichannel architect
- Someone can name, today, which data usage policies are enabled in your production sandbox.
- Someone knows which destinations receive profiles whose consent was never evaluated.
- The team knows that governance policies and access control are two different mechanisms with two different licences.
Station 9 – Measure
The return path is the thinnest station in this series, because it is the thinnest in the documentation. That is itself the finding.
Measure
Turning what happened back into a signal the stack can use.
Query Service · Customer Journey AnalyticsWhat is published concerns querying:
- Ad-hoc queries are capped at 10 minutes of execution time.
- They return 100 rows in the interface and up to 50,000 through a client.
- Batch queries run up to 24 hours.
- The accelerated store allows four concurrent query slots.
- Data Distiller is a separate package offering a subset of platform functionality.
What the guardrails do not describe is the loop itself: how engagement outcomes become new signals, how quickly, with what identity. That has to be designed rather than configured – and it is the part of the architecture most often deferred to “phase two”, which is why so many programmes can describe what they sent and not what it changed.
They can describe what they sent. Not what it changed.
I ask one question at design time and write the answer into the architecture document: which event, written by which system, with which identity, tells this stack that the thing we sent worked. If there is no answer, the measurement layer is not late – it does not exist, and deferring the design is what makes it never arrive. Building it later is fine. Designing it later is not.
Christopher Dettinger · MarTech and omnichannel architect
- The measurement design exists before go-live, even if it is built after.
- You can name the event, the writing system and the identity that closes the loop.
- Nobody has confused “we report on sends” with “we measure outcomes”.
When the truth lives in the warehouse
For most enterprises the authoritative customer data is not in a marketing platform. It is in Snowflake, BigQuery, Databricks or Redshift, governed by a data team who have opinions about copies.
Adobe’s answer is Federated Audience Composition, which builds audiences from data in an external warehouse without copying it. Its own FAQ is blunt about what moves: “Federated Audience Composition only stores metadata (schema descriptions). No customer data is transiting.” Seven warehouses are supported: Redshift, Azure Synapse, Databricks, BigQuery, Snowflake, Vertica Analytics and Microsoft Fabric.
For anyone who has spent a year negotiating a data-copy exception with a security team, that is a significant capability. But there is a trade, and it is in the same FAQ rather than in any comparison chart.
You compose an audience federated against Snowflake. What identity resolution is applied to that data?
Federated Audience Composition does not use Identity Service. Joins across sources run on a key you define, not on the resolved identity graph – so federated data gets no cross-device stitching and no namespace priority. It gets exactly the matching quality of the key someone chose.
That is the real price of “we don’t copy anything”, and it is almost never the one discussed. The question is not copy or federate. It is which data needs resolved identity and which only needs a reliable key – two answers that point at two different architectures, and most enterprises need both.
Not copy or federate. Which data needs an identity.
Two operational notes: audiences imported this way expire after 30 days by default, and the capability requires Real-Time CDP and/or Journey Optimizer at Prime or Ultimate tier, plus a specific “Manage Federated Data” permission.
I split the source inventory into two columns before anyone argues about copying: data that needs a resolved identity, and data that only needs a reliable key. Then I check that the key in the second column actually exists in both systems with the same format and the same case. That second check is where federated designs quietly lose their match rate, and it is cheaper to run now than after the first audience comes back half the expected size.
Christopher Dettinger · MarTech and omnichannel architect
- You know which data genuinely needs resolved identity, and which only needs a reliable key.
- The join key exists in both systems with the same format and the same case.
- Someone has accounted for the 30-day default expiry on imported federated audiences.
What AI agents change
Every vendor now ships agents, and the interesting question is not what they can do but what they can see.
Adobe’s agentic layer is the Adobe Experience Platform Agent Orchestrator – spelled out; “AEP Agent Orchestrator” is not the product name. It is described as “the new agentic layer in Adobe Experience Platform” operating, in Adobe’s phrase, “with human oversight”. The named agents include the Audience Agent, Data Insights Agent, Experimentation Agent, Journey Agent, Product Support Agent, and the Adobe Marketing Agent for Microsoft 365 Copilot.
What they draw on is described as “structured and unstructured data sources, including Adobe product documentation, customer metadata about business objects, and analytics data.”
Read that list again for what is not in it. The knowledge base is documentation, metadata about business objects, and analytics – not the customer record itself. An agent that helps you build an audience works on the description of your data, not on the people in it.
It works on the description of your data. Not on the people in it.
In a regulated environment that is not a limitation to engineer around. It is the condition under which an agent is allowed to run at all – and it explains why an agent can tell you how your audiences are structured but not who is in them.
One naming correction, because it circulates wrongly: Adobe Brand Concierge is not an Experience Platform agent. It is a separate product that consumes Experience Platform data; the agent operating inside it is the Product Advisor Agent. Treating it as part of the Agent Orchestrator roster is a category error that shows up in a lot of secondhand summaries.
For any agent a vendor proposes, I ask for the documented description of its knowledge base and I read it for what is absent rather than what is listed. Then I ask which of the nine stations the agent depends on, because an agent reasoning over metadata inherits every gap in that metadata. I verify this per vendor and per agent – nothing here generalises across products, and the summaries circulating secondhand are wrong often enough to be worth ignoring.
Christopher Dettinger · MarTech and omnichannel architect
- You have read the documented description of what each agent’s knowledge base contains – and what it does not.
- You know which of the nine stations each agent depends on.
- Nobody is treating a separate product’s agent as part of the platform’s roster.
The blueprint: twelve questions
If you take one thing from this series into a meeting, take these. One per station, plus three that cut across.
- Which namespace is your person identity – and is it declared unique?
- How many identities does your average identity graph carry today?
- Has anyone checked email case normalisation across every source that writes one?
- Which of your audience rules reach further back than 24 hours?
- How many edge and streaming audiences are active, against Adobe’s recommended 150 and 500?
- For each real-time decision you have promised, is the data it needs projectable to the edge?
- What is the activation latency of every channel in your current campaign plan?
- Which data usage policies are enabled in your production sandbox – today, not in the design document?
- Which destinations receive profiles whose consent was never evaluated?
- What is your event volume per profile, against Adobe’s 5,000-event segmentation guardrail?
- Which data genuinely needs resolved identity, and which only needs a reliable key?
- Who signed off the primary identity on your profile-enabled schemas, and when?
If eight of the twelve have an owner and an answer, you have an omnichannel architecture. If four do, you have an omnichannel roadmap. Both are legitimate positions. Confusing one for the other is what produces the eighteen-month stall.
Frequently asked questions
What is a data governance policy?
A data governance policy is a rule that says what may be done with data carrying particular labels – and it is enforced at the point of activation rather than at the point of access. In Adobe Experience Platform, labels classify the data, policies describe the permitted use, and enforcement blocks a violating activation and shows the lineage behind it. The part teams miss: every data governance policy, including the core policies Adobe provides, is disabled by default and must be enabled by hand.
Where does consent get enforced in a martech stack?
At several points, and not uniformly. Consent can be captured at collection, stored on the profile, and evaluated at activation. In Adobe’s case, consent policies require a Healthcare Shield or Privacy & Security Shield licence, and Adobe documents that consent evaluation does not run for exports to Amazon Kinesis, Azure Event Hubs or the HTTP API destination. In the Web SDK, only the data collection permission is enforced automatically. Anything else has to be enforced by something you build.
Do AI agents in a marketing platform see customer data?
In Adobe’s documented architecture, the Agent Orchestrator’s knowledge base is described as product documentation, metadata about business objects, and analytics data – not the customer records themselves. An agent can describe how your audiences are structured without seeing who is in them. Verify this per vendor and per agent rather than assuming it generalises.
How do a CDP and a data warehouse work together?
Two patterns. Copy – move the data into the CDP, where it gets full identity resolution and profile treatment. Or federate – leave it in the warehouse and compose audiences against it without copying, as Adobe’s Federated Audience Composition does. The trade is explicit: federated data is joined on a key you define rather than through identity resolution, so it gets no cross-device stitching. Most enterprises end up running both patterns for different data.
What is the difference between a customer data platform and a data warehouse?
A warehouse stores everything for analysis, optimised for large scans across long histories. A CDP stores a working profile optimised for millisecond retrieval during a live interaction, with identity resolution and activation built in. In Adobe’s case they are literally different technologies – Cosmos DB for the profile store, Azure Data Lake Storage for the lake. Most enterprises need both, connected, rather than one replacing the other.
If enforcement in your sandbox turns out to be off, the next question is which policies you actually need – and that is a business decision before it is a technical one. Working that out with marketing, legal and IT in the same room is what I do, for teams in pharma, medical and finance.
Get in touch →Related reading: Part 1 – nothing works until the data is one person · Part 2 – real time is a property of the rule · When a label blocks a paid-social activation · The Salesforce side: Data 360 starts with an “Allow All” policy.
Figures in this article are drawn from Adobe’s public documentation and link to their source; all pages were retrieved on 11 September 2026. Guardrails change with releases, and Adobe distinguishes between system-enforced limits and performance recommendations – verify against your own tenant before designing to any number, including these. Nothing here is legal advice. Sources: 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 and Adobe Real-Time CDP are trademarks of Adobe Inc. This is an independent analysis; no partnership with or endorsement by Adobe.
