You're on OneTrust: OneTrust Records What You May Do with Personal Data. Data Workers Makes Sure Your Pipelines Honour It
On OneTrust for consent, data use governance and CORIE? Keep it as the record of what you may do with personal data. Data Workers makes sure your pipelines honour each choice and proposes the fixes, behind approvals.
Your privacy office runs on OneTrust. Customers make their choices at collection points: the consent banner on the web shop, the preference center in the app, the toggles by channel and topic. Universal Consent & Preference Management keeps those choices in a real-time profile per known customer, each choice with its consent receipt, version history and timestamp. Data Use Governance (early access) ties every project to a purpose and pushes policy down to column masking and row filters in Snowflake and Databricks. AI Governance inventories your models and agents; CORIE, introduced Sep 29, 2026, checks an agent's tool call against policy before the model sees the data; and the MCP Gateway and Conversational Consent are in private preview this fall. OneTrust records what your company may do with personal data. Data Workers owns whether your data pipelines actually honour it: it finds every table, model and sync a consent choice has to reach, catches the load that dropped one, and proposes the fixes to the people who own them, behind approvals.
A consent receipt is only as good as the last pipeline that read it. When a withdrawal reaches OneTrust but not the table your audiences are built from, the record says one thing and the email says another.
Key takeaways
- •OneTrust keeps its job. Consent and preferences, consent receipts, Data Use Governance, AI Governance and CORIE stay where they are. Data Workers works with OneTrust from day one.
- •OneTrust stays the record. OneTrust connects over its API today. Data Workers changes nothing in it and never edits a consent record; the privacy team owns every choice and every request.
- •Every consent copy gets traced. Data Workers follows the consent tables in your warehouse through dbt to the models and the syncs that read them, so the team knows where each choice has to land.
- •A dropped withdrawal gets caught before the send. A drop in the withdrawals your load records is flagged against its baseline, traced to the run that skipped them and to every audience they feed.
- •Fixes arrive as proposals. The reload, the code fix and the sync hold go to their named owners; Data Workers queues the approved rerun and writes a receipt the privacy team can file.
- •Start with a pilot on one consent flow, read-only first, from L0 manual toward L4 autonomous.
OneTrust is the record of what you may do. Data Workers is the operator that makes your pipelines honour it.
OneTrust answers the privacy question: what did this person agree to, for which purpose, and when? Data Workers answers the operations questions around it: which copies of that choice live in the warehouse, which models and syncs read them, did last night's load bring every change, and what has to change, in which system, when one didn't?
Here is a weekend at a meal-kit subscription company selling in the US and the EU. Customers manage their email preferences in a OneTrust preference center inside the app. The data team does not use a pre-built connector for the warehouse: a Prefect flow, onetrust_consent_sync, calls OneTrust's REST API every night at 01:00, pages through the consent changes since its last watermark and appends them to Snowflake raw_privacy.consent_events. dbt Core, run by a second Prefect deployment at 02:00, builds int_consent__latest (one row per data subject and purpose) and mart_winback_audience, which excludes anyone without active email-marketing consent. Hightouch syncs that audience to a Salesforce Marketing Cloud data extension every Monday at 06:00, and a win-back journey sends at 10:00. A post-load task in the flow records the day's withdrawal count to Data Workers with monitor_metrics, and the team has recorded a context-graph note that links the mart to the Hightouch sync. This is an illustrative example.
| Time | System | What happens |
|---|---|---|
| Fri, all day | OneTrust | 1,140 consent changes land in the preference center, 312 of them withdrawals of email-marketing consent. OneTrust records each with a consent receipt |
| Sat 01:00 | Prefect | onetrust_consent_sync starts. Its first task writes the new watermark, then the flow pages through Friday's changes |
| 01:14 | Prefect | Page 6 of 9 fails after its retries are exhausted. Pages 1 to 5 are already in Snowflake; pages 6 to 9, holding most of the afternoon's withdrawals, are not. The flow run ends Failed |
| 02:00 | dbt Core in Snowflake | The dbt deployment builds int_consent__latest and mart_winback_audience from what landed. Nothing in the models looks wrong |
| 07:32 | Prefect | The on-call engineer retries the failed run. It starts from the advanced watermark, finds nothing new and ends Completed |
| 07:41 | Snowflake and Data Workers | The post-load task records 58 withdrawals for Friday. monitor_metrics flags it against a baseline of about 340 a day |
| 07:55 | Prefect | Data Workers reads the flow run and its task runs: the watermark task completed before the page task failed, so the green retry read an empty window. Diagnosis: about seven hours of consent changes never loaded |
| 08:05 | dbt and Spellbook | trace_cross_platform_lineage follows raw_privacy.consent_events through the dbt manifest to int_consent__latest, mart_winback_audience and two reporting models. The team's context-graph note adds the Hightouch sync, due Monday 06:00 |
| 08:10 | Slack and Spellbook | One change set goes to three named owners: for the platform owner, a reload of the Prefect deployment for Friday 01:00 to Saturday 01:00; for the flow's engineer, a diff that writes the watermark only after the last page commits; for the marketing ops owner, a request to hold the Monday sync until the reload is verified |
| 08:31 | Spellbook | The platform owner approves the reload. Marketing ops sets the hold in Hightouch |
| 08:52 | Prefect | Data Workers queues the flow run with the approved window through Prefect and reads its status until it ends Completed |
| 09:40 | Snowflake and Prefect | After approval, Data Workers queues the dbt deployment. The post-load task records 352 withdrawals for the window, back within baseline, and run_quality_check confirms int_consent__latest has no null or duplicate subject_purpose_id keys |
| 10:05 | Spellbook | Data Workers writes the receipt: the trigger, the skipped window, the runs before and after, the counts, both approvers and the undo path. The privacy team gets it as evidence for their OneTrust record |
| Mon 06:00 | Hightouch and Salesforce Marketing Cloud | Marketing ops lifts the hold. The sync sends the rebuilt audience, without the 312 people who withdrew |
OneTrust did its job: every withdrawal was recorded with its receipt. The gap sat in a flow the data team wrote, a retry that looked healthy and an audience two hops downstream, each with its own owner. On Monday the engineer merged the watermark fix, and the journey went out to the people who still wanted it.
| Job | What OneTrust does | What Data Workers does |
|---|---|---|
| The choice | Collects consent and preferences at every collection point and keeps a receipt per purpose | Leaves every choice and every consent record to OneTrust and the privacy team |
| Downstream systems | Pushes consent signals to the systems its connectors serve | Traces the warehouse copies of consent through dbt to every model and sync that reads them |
| The load | Serves consent changes through its API | Reads the orchestrator's runs, flags a withdrawal count that falls off its baseline and diagnoses the skipped window |
| The fix | Records the policy and the purpose | Proposes the reload, the code diff and the sync hold to their owners; queues the approved rerun and verifies it |
| Purpose and access | Data Use Governance ties projects to purposes and pushes masking and row filters | Drafts the model or grant change a purpose decision needs; applies Unity Catalog grants only after approval |
| Agents | CORIE checks each agent tool call against policy before the model sees the data | Runs its own agents behind per-domain guardrails, approvals and receipts |
| The proof | Consent receipts, the Evidence Ledger and Governance Command Center | A receipt per fix: trigger, window, runs, counts, approvers, undo |
Why doesn't OneTrust just do this itself?
Because OneTrust's job is to be the trusted record of what people agreed to and what the company may do, and that record has to stay independent of the systems it judges. Its own AI follows the same line: CORIE allows an agent's action, stops it or flags it for human review, and the Evidence Ledger captures which policy applied. Data Use Governance pushes policy into the platforms' native controls. Each makes the decision sharper and the evidence stronger, a sensible product line to hold.
Fixing the pipelines that carry consent is a different product with a different liability. It needs context about your Prefect flows, dbt models, warehouse and activation syncs; blast radius across systems; a named owner's approval per change; a rollback path; and proof the fix held. A privacy platform that rewrote your pipelines would be grading its own homework. Data Workers is the product on the other side of that line, and it hands every consent and policy decision back to the privacy team.
Every tool owns a slice. Data Workers covers the whole lifecycle
OneTrust owns its slice: the record of consent and purpose, what the company may do with personal data. Each point tool adds another console, contract and handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail, and builds on the choices you record in OneTrust.
| Stage | Data Workers | OneTrust | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 5 | OneTrust inventories AI systems, datasets and vendors and classifies data in business, regulatory, consent and data contexts. Data Workers joins context to lineage, runs, schema changes and usage in one graph. |
| Analytics & Insights | 8 | 2 | Governance Command Center shows risk posture, decisions and exceptions. Data Workers answers questions about the data itself from governed context and checks the numbers behind them. |
| Data Quality | 8 | 2 | OneTrust governs how data may be used, not whether a table is correct. Data Workers checks nulls, keys and row counts after runs and takes failures to the cause. |
| Observability & Incidents | 8.5 | 2 | OneTrust records consent changes and governance decisions. Data Workers detects, diagnoses and verifies data incidents across systems, with a receipt for each. |
| Pipelines & Ingestion | 8.5 | 1 | OneTrust's connectors push consent signals to the systems they serve; it does not run your pipelines. Data Workers reads orchestrator runs and queues reruns after approval. |
| Schema & Migration | 8 | 1 | OneTrust leaves warehouse schemas to the data team. Data Workers assesses the impact of a schema change and drafts migrations with rollback SQL for the owner. |
| Governance & Access | 8.5 | 8.5 | Purpose-based Data Use Governance (early access) turns documented policy into masking and row filters in Snowflake and Databricks. Data Workers proposes the access change a fix needs and applies Unity Catalog grants after approval. |
| Security & Privacy | 8 | 9 | OneTrust's home stage: consent and preference management, consent receipts with version history, privacy programs and CORIE checks at the agent's tool call. Data Workers traces where each consent choice has to reach in your pipelines. |
| Cost / FinOps | 8 | 1 | OneTrust does not manage warehouse spend. Data Workers traces Snowflake credits to the dbt model behind them and reads AWS Cost Explorer. |
| MLOps & Models | 7.5 | 5 | AI Governance inventories models and agents and assesses them against the EU AI Act and NIST AI RMF. Data Workers keeps the training and feature data under models healthy. |
How OneTrust and Data Workers work together
Your people stay where they are: privacy in OneTrust, marketing in Hightouch and Salesforce Marketing Cloud, engineers in Claude, Cursor or GitHub Copilot. Spellbook Data Catalog (in preview) is where the data team looks: each finding, proposed change, blast radius, approver and rollback, with approval requests reaching people in Slack or email. Underneath, Data Context Wizard keeps one governed context graph, the Data-Agents Swarm does the work with more than 20 specialist agents, and the Autonomous Data-Conductor runs each fix end to end (detect, diagnose, fix, review, verify, remember) behind per-domain guardrails.
Where OneTrust fits. OneTrust connects over its API today and stays the system of record for consent, purposes and policy. Its MCP Gateway (announced Sep 30, 2026; private preview this fall) is for your own assistant, side by side with Data Workers' MCP servers; Data Workers' agents do not call it. Data Workers' agents work from what Data Workers reads natively, among 50+ connectors: Snowflake checks, the dbt manifest, Prefect, Airflow and Dagster runs and the Context Wizard graph. Agents get one governed view through explain_table, trace_cross_platform_lineage and blast_radius_analysis, and for open incidents, get_incident_history.
What Data Workers writes, and where. To OneTrust, nothing: consent records, purposes and policies belong to the privacy team. Reruns are queued through your orchestrator after approval. Code and dbt fixes go to the owner as a diff to merge. Activation syncs are held and resumed by their owners. Access changes a purpose decision needs are drafted for the owner; on Unity Catalog, Data Workers applies the grant or revoke once a named person approves, and on other platforms the owner applies it. Masking arrives as a dry run, and no agent can promote it to run on its own. Data cleanups, such as removing a withdrawn subject's rows from a copy, are proposed for the owner to approve and run. Data Workers' pull request review flags new columns whose names or annotations look sensitive; it reads names, not values. request_governance_review opens a trackable review when a change needs the privacy team's decision, and generate_audit_report gathers the receipts for an audit.
Setup today. For your assistant, Data Workers' agents come from the open-source repository: clone it and add start-agent.sh entries to your client config, as the client setup docs show.
// Example: .mcp.json for Claude Code
{
"mcpServers": {
"dw-context-catalog": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-context-catalog"]
},
"dw-incidents": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-incidents"]
},
"dw-governance": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-governance"]
}
}
}List the tools with your client's own command (/mcp in Claude Code), then ask "which models and syncs read raw_privacy.consent_events, and which of them build an audience?"
One request, L0 to L4. The autonomy ladder is set per domain, so the consent domain can sit at a different level from Finance.
- •L0 manual. Connected, not acting.
- •L1 observe. Data Workers reports each flagged load with its lineage and owners, and logs what each action would have needed.
- •L2 propose. Data Workers drafts the reload, the code diff and the sync hold. Owners approve before anything runs.
- •L3 act reversibly. For proven classes, such as queuing a reload of a skipped window, Data Workers acts, verifies and records it.
- •L4 autonomous. For a scoped, trusted class in one domain, Data Workers runs the loop end to end and posts the receipt. Masking always needs a person.
Read more on safety, how approvals work, the autonomy levels, where your data goes, how Data Workers handles PII and SOX, HIPAA, GDPR and the EU AI Act. The same build-on pattern holds for Securiti, Immuta and BigID; for the pipeline side of this incident, see You're on Prefect.
What changes for your team
Privacy and data teams lose much of their week to the seam between them: the load nobody checked, the audience built from a stale copy. With Data Workers, those jobs run on autopilot at the level you set.
- •Incidents. A broken consent load arrives traced to the run, the cause and every audience it feeds.
- •Data quality. Keys, nulls and row counts on consent tables are checked after each run, and drops in the counts your loads record are flagged against their baseline.
- •Cloud spend. Snowflake credits are traced to the dbt model behind them, and the fix goes to that model's owner.
- •Access. A purpose decision arrives with the grant and model changes drafted for their owners, and Unity Catalog changes are applied after approval.
- •Audits. Each fix links the trigger, the window, the approvers, the counts and the undo path.
- •Migrations. When a platform moves, each wave is planned with its parity checks, and the owner signs off before it closes.
The privacy office keeps its week for what only people decide. The data governance leads guide covers that role, and who owns the agents covers the agents on your side of the line.
Keep OneTrust, or consolidate?
Keep OneTrust if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
Most privacy programs keep OneTrust as the record of consent and purpose, especially across many regions and brands. What they consolidate is the tooling around it: the scripts that compare consent counts between systems, the spreadsheet of tables that hold a purpose, and the ticket queue between privacy analysts and flow owners. For the agent side, read AI agents and data access governance risks and handling PII in AI agent workflows. Building this layer yourself? Read build it ourselves with Claude Code and MCP servers: calling OneTrust's API is the easy part; approvals, rollback and receipts are the work.
The case for your CFO
The outcome: when a customer withdraws consent in OneTrust, every pipeline that builds an audience honours it, and a load that drops withdrawals is caught before the next send.
The risk story is plain. Data Workers changes nothing in OneTrust and never edits a consent record. Reruns are queued only after a named approver says yes, code fixes land through your Git review, syncs stay with their owners, and each change leaves a receipt with the trigger, diff, approver, checks and undo path. Unanswered requests expire and escalate; they never auto-grant. No agent can promote its own work. Autonomy is set per domain from L0 manual to L4 autonomous, and an org-wide stop halts all autonomous dispatch. The agents run in your infrastructure; your data stays in your systems, and the hosted Conductor sees workflow metadata only. Zero migration.
Why now: consent choices feed more systems than ever, from audiences to AI agents, so a dropped withdrawal reaches more people, faster. The first win: one consent flow, read-only, reporting every load whose withdrawal count falls off its baseline and every audience it feeds. What stays the same: your OneTrust licence, purposes, collection points and privacy team. Data Workers produces the evidence; your privacy and legal teams make the compliance calls. For the numbers, see the ROI of agentic data operations.
The sentence to repeat upstairs: "OneTrust records what our customers agreed to; Data Workers makes sure our pipelines honour it, and every fix comes with an approval and a receipt."
Getting started
Start with a pilot. Pick the consent flow your privacy office cares about most, connect Data Workers read-only to the warehouse tables, dbt project and orchestrator runs behind it, have your loads record their withdrawal counts, and let it report for a few weeks before turning on the first fix class. The pilot path and plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
Does Data Workers sync consent from OneTrust? No. OneTrust and your own flows move consent data. Data Workers makes sure the copies in your warehouse are complete and that every model and sync built on them honours each choice.
Does Data Workers handle data subject requests? No. Requests stay in OneTrust with the privacy team. Data Workers can trace which tables and models hold a person's data, and any cleanup is proposed for the owner to approve and run.
How is this different from CORIE? CORIE governs what an agent may do at its tool call, inside the OneTrust Platform. Data Workers runs the data operations around your pipelines, under the approvals you set. The two fit together.
Will Data Workers touch our Hightouch or Salesforce Marketing Cloud setup? No. Activation syncs and journeys stay with marketing ops. Data Workers traces which syncs read a consent-dependent model and asks the owner to hold one when the data under it is wrong.
Does Data Workers make us GDPR compliant? No tool does that alone. Your privacy and legal teams make compliance decisions. Data Workers produces evidence they can use: receipts, the audit log and reports that show what changed, who approved it and when.
Where does our data go? The agents run in your infrastructure and hold the credentials. Your data stays in your systems; the hosted Conductor sees workflow metadata only, such as table names, proposals and approvals, never rows, credentials or model keys.
Sources
- •OneTrust, OneTrust Introduces CORIE to Govern AI Agents at Machine Speed (Sep 29, 2026), https://www.onetrust.com/news/onetrust-introduces-corie-to-govern-ai-agents-at-machine-speed/ (checked Oct 3, 2026)
- •OneTrust, OneTrust Unveils Platform and Product Innovations to Govern AI at Enterprise Scale (Sep 30, 2026; MCP Gateway and Conversational Consent in private preview), https://www.onetrust.com/news/onetrust-unveils-platform-and-product-innovations-to-govern-ai-at-enterprise-scale/ (checked Oct 3, 2026)
- •OneTrust, Consent and Preference Management, https://www.onetrust.com/solutions/consent-and-preference-management/ (checked Oct 3, 2026)
- •OneTrust, Data Use Governance (early access), https://www.onetrust.com/solutions/data-use-governance/ (checked Oct 3, 2026)
- •OneTrust, AI Governance, https://www.onetrust.com/solutions/ai-governance/ (checked Oct 3, 2026)
- •OneTrust, OneTrust Appoints John Heyman as Chief Executive Officer (Feb 9, 2026), https://www.onetrust.com/news/onetrust-appoints-john-heyman-as-chief-executive-officer-to-drive-ai-ready-governance-platform-innovation/ (checked Oct 3, 2026)
- •OneTrust, Newsroom, https://www.onetrust.com/news/ (checked Oct 3, 2026)
- •Data Workers, Client setup (open-source docs), https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)
- •Data Workers open-source repository, agent tools and start-agent.sh, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 3, 2026)