Skip to main content

Why we treat privacy as a product decision, not a compliance requirement

Picture of Matt Lievertz

Matt Lievertz

VP of Engineering at Cloverleaf

Table of Contents

Reading Time: 7 minutes

A few years ago, I sat down with the compliance team at an arm of a Fortune 500 company. We were trying to expand a deal. I came in ready to talk about how we were meeting the information security challenge — the things I knew how to talk about. What happened next is seared into my memory.

It turned out I was prepared for the wrong conversation. New regulations made Privacy a whole new discipline. By the end of the conversation I realized I didn’t even understand what I didn’t understand.

That conversation led me down a path that changed how I think about building.

Cloverleaf handles some of the most sensitive data that flows through a workplace — behavioral assessment data, personality profiles, coaching interactions, relationship dynamics across teams. We knew going in that this data was private in ways that went beyond the legal definition of personally identifiable information.

People see their own personality data as deeply personal, regardless of how it’s classified by statute. And if they’re getting coached on that data, actually exploring how they think and behave and relate to the people around them — they need to know that’s protected.

The question we had to answer wasn’t just “are we compliant?” It was “are we above reproach?”

Get the 2026 AI coaching playbook to see how organizations are implementing AI coaching at scale.

Privacy by design vs. minimum compliance:

What the difference are between ai powered coaching platforms

Most software companies approach privacy the same way. They hire someone to run through a compliance framework, GDPR, CCPA, SOC 2, check the boxes, get the certifications, and call it done. There’s a separate effort, off to the side of the actual product, that exists to satisfy auditors.

The problem with that approach is what it looks like from the inside. If your privacy and security practices are bolted on rather than built in, then everything you’ve constructed is a guardhouse. It looks impressive from a distance. Someone is standing there. Visitors see it. But if anyone stops looking at the guardhouse and starts looking at your actual product, the data model, the architecture decisions, what gets sent where, everything can fall apart at once. You’ve been doing compliance on paper, not in code.

The alternative is to make privacy a design principle rather than a compliance program. That means it shows up in the actual decisions: how data is structured in your database, what gets transmitted to AI processors and what doesn’t, how user consent is built into the product flow, how you handle a request to delete someone’s data. These aren’t policy documents. They’re engineering choices.

One concrete example is separating personally identifiable information out at the data level, which we’ve started doing as a normal architectural step.

When someone requests deletion, it propagates automatically through the entire data structure. It’s not a complex, hard-to-maintain search-and-destroy operation that someone has to run manually. It’s how the database works. The difference between those two approaches is the difference between a feature and an architectural property. One can fail. The other is harder to break than to maintain.

The same logic applies to how we handle behavioral data before it ever reaches an AI processor. AI wants as much context as possible, more data means better outputs. But privacy requires the opposite: data minimization. We built filters that strip identifying information before it’s sent to AI consumers.

The coaching Cloverleaf delivers is personalized, but the data that enables it has been processed so that the person is as de-identified as possible on the way in. That’s a harder thing to build than just sending everything over. It’s also the only responsible way to do it.

Why Cloverleaf chooses to surpass the minimum requirement in each jurisdiction

After that Fortune 500 conversation, we made a decision: we were not going to trace the minimum requirement in each jurisdiction and build just enough to satisfy what the law said today. We were going to treat privacy as a core way the platform worked, full stop.

Part of what drove that decision was the direction the law was moving. In 2022, companies were still working out what GDPR meant in practice. CCPA was just starting to be talked about.

The pattern was obvious: privacy regulation was going to compound, not stabilize. Jurisdictions were adding requirements. Court cases were shifting what the law effectively meant even without new legislation.

The EU AI Act, which came into formal effect in 2024 with high-risk AI obligations for HR systems phasing in through 2026, was already in development. The companies that built privacy into their platforms early are now watching competitors scramble through fire drills as each new regulation arrives. We’re not. When the EU AI Act requirements started hitting enterprise compliance programs, we had very little to adjust for.

That’s not because we got lucky. It’s because we had built to a philosophical standard rather than a legal checklist.

There is also a practical benefit. If we maintain bare legal compliance, that might technically pass. But we sell to companies on the Fortune 10/50/500 who have compliance teams working very hard to keep their companies safe. It’s hard to convince those audiences when you are doing the bare minimum.

If we built to the minimum, their job was to find the gap between the minimum and what was actually safe. If we built above reproach, their job became validating that we were who we said we were.

See How Cloverleaf’s Platform Works

Why building privacy in early made our system simpler, not more complex

The honest answer is that building privacy in early has made things simpler, not harder. That might sound counterintuitive. The common objection is that privacy-first means slower development, you’re building for requirements you don’t have yet, adding complexity that isn’t justified. We heard that internally. And for any single decision in isolation, it can look true.

When you’re adding a new data store and you also need to think about PII segmentation, that’s one more thing in an already complex conversation. It’s one more item to defend when someone is asking why we’re not building the more visible feature instead.

But when you step back and look at the system as a whole, what you find is that building privacy in at the architectural level eliminates entire categories of ongoing complexity.

You stop writing workarounds throughout the codebase to handle special cases. You stop maintaining manual scrubbing processes as a layer on top of the database.

You stop catching the bugs that appear when someone builds a new feature without realizing it has implications for a legacy carveout.

The system works one way. Everything gets simpler, and simpler systems ship faster and break less.

We saw this play out clearly when we overhauled our partner channel architecture. We had a model where partners and their customers were handled through a set of special cases wired throughout the product. It was hard to maintain, limited what partners could offer their customers, and was a constant source of bugs when someone built a new feature without knowing about the edge cases.

When we rebuilt that into a clean federation model, where every account works the same way with a defined relationship between them, we eliminated the workarounds. Everything just worked. The partner channel, which had been stagnant for five years, doubled the following year. Architectural simplicity had a direct business impact.

Privacy built into architecture is the same category of decision. The upfront investment produces compounding returns as the system grows, because every new capability inherits the correct properties automatically rather than requiring a special audit to verify it.

Questions to ask any AI coaching vendor about data privacy

Here’s what I’ve noticed in enterprise sales: when we get into the detailed compliance conversations with customers, something shifts. For a new customer, we’re initially just another SaaS vendor. But then we’re sitting with their compliance team, talking about how we’ve approached PII handling at the data model level, how we’ve thought about data minimization in the context of AI processing, how we’ve worked through the IAPP frameworks and what they mean in practice for behavioral data.

The conversation changes. Instead of the usual back-and-forth, the litigious haggling over a specific point in the contract, they realize they’re talking to someone who actually understands what they’re trying to protect their organization from. We have the same objectives. We’re not adversaries. We’re partners.

63% of HR leaders cite data security as their top concern when implementing AI tools. And yet most vendor evaluations stop at certifications. Certifications tell you the vendor passed an audit. How they explain their architectural decisions tells you how they actually think about your data.

If you want to understand how Cloverleaf’s AI coaching platform actually handles behavioral data, a few questions cut through the marketing language quickly.

Ask about data minimization.

Specifically, how they handle the tension between giving AI enough context to produce useful coaching and not sending more data than necessary. A vendor who has thought about this will give you a specific answer about how they process data before it reaches AI consumers. A vendor who hasn’t will tell you about their encryption.

Ask what happens when an employee leaves the organization and their data needs to be removed.

A vendor with privacy built into the architecture will describe how the data structure handles it automatically. A vendor with privacy bolted on will tell you about their offboarding process.

Ask whether their approach to privacy has required them to make tradeoffs in other areas of the product.

A vendor who has actually built to a high standard will be able to name specific decisions where privacy won. A vendor doing minimum compliance will tell you there were no tradeoffs.

For a broader view of what to look for, Cloverleaf’s talent leader’s guide to vetting AI coaching covers the five features that separate real coaching systems from rebranded chatbots. And for the enterprise procurement process, this guide on asking the right questions in AI coaching evaluations walks through what to ask about coaching methodology, integration depth, and data practices in a way that actually surfaces meaningful vendor differences.

The regulatory environment is not going to get simpler. Every year, AI-specific requirements get more specific, jurisdictional requirements compound, and enterprise compliance teams get more sophisticated in what they’re asking. The vendors who built for the minimum are going to keep having fire drills. The vendors who built above suspicion are going to keep having partnership conversations.

That’s the choice we made in 2022. Not because it was easy to defend at the time, it wasn’t. But because we understood what we were handling and what our customers were trying to protect. Thirteen licensed assessment partnerships. Two approved patents. 45,000 teams. Sixty-five million coaching moments. None of that works if people don’t trust us with their data.

See how Cloverleaf handles your data

Cloverleaf is the only AI coaching platform offering a free trial, so your team can start getting coaching built on validated behavioral science today. To explore our security and integration architecture, visit our integrations and security overview, or book a demo to talk through how we approach behavioral data with your team’s specific requirements.

Picture of Matt Lievertz

Matt Lievertz

Matt Lievertz is the Vice President of Engineering at Cloverleaf, where he leads product and platform strategy, engineering operations, and AI innovation. With experience spanning startups, enterprise, and government, Matt is passionate about building high-performing teams and solving the right problems—especially when it drives meaningful impact for people and organizations. He believes great software starts with great communication and thrives at the intersection of thoughtful strategy and hands-on execution.