Secure data sharing

I worked with a manufacturer that wanted to get smarter about how it planned supply, orders, and delivery. They already had good forecasting models and a wide view of their market. What they were missing was the part of the picture that lived inside their customers’ systems: how their products were actually being used, day to day, out in the real world. And their customers had every reason to keep that to themselves.

The tricky part was never the analysis. It was getting anyone comfortable enough to share the data in the first place.

The challenge

Coming out of the last few years of supply-chain chaos, a lot of these customers were still playing defense. Their nightmare was running out of something critical at the wrong moment, so they did the sensible thing and hoarded: extra inventory, information held close, all of it just in case. The trouble is that when everyone does that, it backfires. All that caution turns into bottlenecks upstream, and planning gets harder for everybody, the exact thing they were trying to avoid.

The manufacturer could see a way out. If customers shared detailed usage data, everyone could plan ahead instead of stockpiling out of fear. But that data (the volumes, the product mix, the timing) is exactly what a customer never wants its supplier to have. That’s not paranoia, it’s leverage. Whoever holds that data has the advantage the next time contracts come up.

So every early conversation played out the same way. People loved the planning idea right up until we got to the data question, and then everything stopped. Saying “we’ll only use it for the analysis” didn’t help much: it’s a promise from the one party with the most to gain by breaking it, and everyone in the room knew it.

The insight

What finally worked was taking the whole thing out of the realm of trust and putting it into the architecture. Instead of “we won’t look,” the answer became “we can’t look.” If the thing customers are afraid of is impossible rather than merely against the rules, they don’t have to trust anyone; they can inspect the system and confirm it for themselves.

That one change turned a sales problem into a design problem. After that, every decision had a simple test attached to it: does this take away a reason to say no?

How it works

The shape of it is simple. The customer decides what to share and when, and holds their own encryption keys. The manufacturer adds a small, fixed slice of its own data. The platform sits in the middle, combines the two inside a controlled computation, and hands back insights without ever exposing or holding onto the raw inputs.

Each piece below answers a specific worry.

The customer owns the keys

The worry: you’ll keep our data and read it later.

Everything is encrypted with keys the customer creates, rotates, and revokes inside their own Azure Key Vault. Encryption and decryption happen through Key Vault, and the key material never leaves the customer’s subscription. The platform has no standing access of its own. If a customer revokes the key, the door closes, and nobody has to ask permission for that to happen.

The customer picks the columns

The worry: you’ll grab more than we agreed to.

Customers whitelist the exact fields allowed to leave their environment. Anything not on that list simply never moves. It’s data minimization built into the schema itself, rather than a policy someone has to remember to follow.

The customer sets the schedule

The worry: you’ll pull data whenever it suits you.

Sharing runs on the customer’s clock: manual, daily, or whatever interval they set. The manufacturer never reaches in to grab anything; the customer pushes it out, on their own terms.

Excel is a real way in, not a fallback

The worry: taking part means building infrastructure we don’t have.

Not every company has the engineering muscle to stand up an API integration, and if we’d required one, we’d have quietly shut out some of the partners whose data mattered most. So uploading a spreadsheet is a first-class path in its own right. A customer can export from whatever system they already use, apply their whitelist, and upload through the portal, running through the same validation, encryption, and middleware as anything arriving over the API. It works today, and it leaves an easy road to automation later.

Nothing sensitive sticks around

The worry: where does the raw data actually end up?

The platform reads and validates everything in memory, runs the analysis inside short-lived containers, and keeps only the aggregated, non-identifiable results. The raw inputs are never written down anywhere. What goes in disappears; what comes back is a dashboard.

The intelligence layer

Once the middleware has produced those encrypted, whitelisted aggregates, Azure AI Foundry does the real analysis. It looks for patterns in stock velocity, replenishment cycles, shifting demand, and anomalies, then turns them into what the manufacturer actually came for: forecasted inventory needs, SKU-level movement, seasonality, and alerts when something looks off. All of it comes from privacy-preserving aggregates, never raw records.

Where it’s headed

What shipped serves one customer. The more interesting thing is what the same setup makes possible later. Because the controls are all standardized (the whitelisted columns, the customer-set schedules, the customer-owned keys), the model isn’t tied to a single relationship. You could bring in more customers, and eventually more suppliers, all feeding the same secure layer. That would open up a shared view of demand and inventory trends across partners, without anyone having to expose raw data to get it.

That part is still in the exploring stage rather than something that’s been built. But it’s the obvious next step, and the architecture was put together with it in mind.