Working on what matters now means building systems others rely on. From greenfield engineering to AI consent design, this story shows how owning foundational work creates real impact.

Aarti Jivrajani joined Veeam in late 2024 as a Staff Software Engineer on the VDC-AI Engineering team. She contributed to several projects involving the Control Plane and planet-scale data pipelines, until one day she took ownership of building the consent system that became a cornerstone of Veeam’s AI intelligence initiatives, shaping the organization’s approach to trust and user transparency.

What problem were you solving, and why did it matter?

At the beginning of 2026 I took on an impactful project: the consent system that underlies every AI-powered intelligence feature Veeam ships — ransomware detection, malware scanning, and the foundation for Veeam Intelligence and Agents coming down the line.

What made this challenge more than just engineering?

Veeam cannot process customer data through AI systems without explicit consent and getting that right required more than engineering. The hardest part came before a single line of code was written. Consent had to live somewhere in the user journey, and where you place it matters enormously. The wrong placement — technically compliant but poorly timed — creates friction at exactly the moment a customer is trying to get value.

How did collaboration shape the outcome?

Legal, product, and the business each came in with different instincts. Keeping customer empathy front and center while satisfying compliance requirements was the real design challenge, and it took patience and a lot of teamwork to land in the right place. Even the caching strategy had real compliance implications — get the TTL wrong and an opt-out doesn't take effect when a customer expects it to.

Once we had alignment, I led the engineering design end to end. The consent service and its consumers lived in separate Azure subscriptions with no existing authentication bridge — an interesting challenge that pushed me to think carefully about cross-subscription identity and trust.

How did you enable other teams to move faster?

Because the services that check consent are written in Go, Python, and Java, I built a consistent client library in all three languages so every team could integrate without friction.

What impact does this work have today?

What I come back to is the leverage. This system is the infrastructure other engineers at Veeam are building on top of right now. That kind of foundational impact is what I came here for — and at Veeam, if you're willing to own things, you get to do it early.

What do you enjoy outside of work?

Outside of work I lean toward hands-on things — collecting rare books, painting, and working through complex Lego sets. There's something about starting with a thousand loose pieces and ending with something that didn't exist an hour ago. That satisfaction of building carries over into everything I do.

Want to work on what matters now? Join our teams and build foundational work that others rely on every day. Explore roles in our technical teams.

Pipeline

Here's a tension that doesn't get talked about enough in data engineering: the features that make your product smarter often require the exact kind of data access your customers are most nervous about. Veeam protects enterprise data. Backups, snapshots, recovery points — the safety net that exists so that when ransomware hits, organizations can get back on their feet. Customers hand us the keys to their most sensitive systems because they trust us to keep that data safe. Now imagine you're building ML-powered threat detection on top of that. Malware scanning. Ransomware pattern analysis. Features that get better the more data flows through them. You can see the problem: "we'd like to use your backup metadata to train our models" is a sentence that needs to be earned, not assumed. So we built a consent system — an enforcement layer that gates every single event before it touches an ML pipeline.

What We Actually Built

Veeam Data Cloud is multi-tenant. Thousands of organizations, each with their own customer workloads, each with their own feelings about data sharing. Consent had to work per-organization, in real time, across multiple independent services. The system spans two independently deployed planes:

The control plane is where consent decisions live. Organization admins grant or revoke consent through the product UI, and those decisions are persisted behind a role-based authorization layer. We support multiple consent types, each with its own rules about who's allowed to grant them. The same data is exposed through an internal API so that downstream services can check consent programmatically.

The data plane is where those decisions have teeth. Two event-driven threat detection services — one for malware, one for ransomware — consume events from Azure Event Hubs. Before either service processes a single event, it checks: did this customer's organization say yes?

Bridging the two is a shared consent client library. In a multi-tenant system, a customer workload doesn't map directly to a consent decision. The client first resolves the workload to an organization, then fetches that organization's consent status — two authenticated service-to-service calls, secured with machine-to-machine tokens sourced from a secrets vault at startup.

The Part We're Most Opinionated About

Every ambiguous state is a "no." Consent API unreachable? Event goes to the dead-letter queue — not processed. Tenant doesn't exist? Denied. Admin hasn't been asked yet? Denied. The only path to processing is an explicit opt-in. We call this fail-closed, and it's nonnegotiable.

Caching was a real design problem. Consent checks run on every event, so we couldn't afford a network round-trip each time. The client caches at two levels — workload-toorganization lookups are long-lived, consent status refreshes more frequently — so the hot path stays fast. But errors are never cached. A failed check always retries fresh. We'd rather pay the latency than serve a stale permission that's been revoked.

Same Contract, Every Service

Both threat detection services enforce the exact same behavior. Same fail-closed logic. Same dead-letter routing on errors. Same structured logging. Both refuse to start if the consent client isn't initialized. Inconsistency in consent enforcement is a breach of trust.

Why This Matters

Nobody's going to tweet about your consent system. It doesn't demo well. Product marketing isn't putting it on a slide. But it's the kind of work that tells you something about an engineering team. It says: we'd rather build a gate that slows us down than take a shortcut with someone else's data. At Veeam, where the entire product is built on the promise that your data is safe with us, we think that's just the job.