Contact us
A U.S. data intelligence company needed to analyze its data together with partners' data without either side exposing raw records, and each new collaboration meant building the staging, permissions and masking again. Over four to six weeks, in four phases, we designed and deployed a working AWS Clean Rooms prototype: a governed path from Redshift into the collaboration, two patterns for machine learning inside its boundary, and the runbooks and templates to repeat it for every partner.
Partner deals needed data that couldn't leave its owner.
The company's commercial opportunity depended on combining its data with partners' datasets. Its Redshift environment supported internal analysis well. But each external collaboration needed a fresh approach to staging the data, setting permissions and protecting sensitive fields, done by hand and from nothing. Without defined patterns for masking, hashing and access control, every partnership carried regulatory and reputational risk.
Machine learning raised a harder question. Which computations could run inside the collaboration boundary, and which results had to be prepared beforehand? Either approach could work in theory, but nobody had designed or tested one, so the products built on the company's models couldn't use partner data at all.
We built a pattern the company could repeat for every partner: a governed pipeline from Redshift into a clean room, security designed in before deployment, and documentation good enough that the company's own team could onboard the next partner without us.
5 decisions, in the order we made them. Each one says what we did and why, with what it did drawn beside it.
The engagement began by checking that the foundations were actually ready, rather than assuming they were:
The design covered the whole flow, from Redshift through staging to the collaboration and back out to partners:
Partners join a data collaboration because their data stays private, so the privacy controls were designed before any data moved.
The architecture sets out two patterns: precompute model outputs or embeddings before the collaboration, or run a supported workload inside the Clean Rooms environment. Which path fits depends on the use case, the partner's requirements and the compute the clean room allows. Having both designed means each new use case is a choice between known options rather than a research project.
In a time-boxed implementation sprint, run from an execution runbook, test scripts and acceptance criteria written in advance, the teams deployed the staging pipelines, the collaboration configuration and representative analytic or ML flows against sample datasets. Acceptance tests exercised the data path and the security boundaries, and every deviation became an explicit remediation item.
The company's own engineers worked beside ours throughout the sprint, so the knowledge transferred through doing the work.
The last phase turned the prototype into the company's own capability:
Onboarding partners at production scale, following the delivered roadmap.
This project came before our current offers. Here's how we'd approach the same work now.
Axiom would keep one catalogue on Amazon DataZone, so every staged dataset, and every AI agent that uses it, reads each field the same way, with row-level access through AWS Lake Formation. Before any data moved, we'd approve a data-flow map covering prompts, retrieval, embeddings, caches and logs, and check the real flows against it.
The rule a clean room enforces for people would apply to AI agents too: none would hold private data, read untrusted text and be able to send data out at once, and each would get its own identity, with Cedar policies checked outside the model on every call.
A free workshop: a few hours with the architects who'd do the work, on your own systems. No cost.
Book a free workshop