Compliance and data have been in a long relationship, and like most long relationships, it started awkwardly. This is the first of a three-part series tracing that relationship from its earliest, clumsiest days to where it’s headed with the arrival of AI-driven real-time monitoring. Part 1 covers how the profession first tried to capture data about its own programs and figure out whether any of it actually worked. Part 2 will cover the shift to systems built for expedited auditing and continuous monitoring. Part 3 will cover where real-time AI capability is taking us now, and why data privacy, cybersecurity, and AI risk themselves have been the forces pushing this evolution forward at every stage.

Compliance Started as a Program You Could Describe, Not a Program You Could Measure

Go back to the early years of the modern compliance function, really the period following the Foreign Corrupt Practices Act’s initial enforcement wave and the development of the U.S. Sentencing Guidelines’ framework for an “effective compliance program” in the 1990s. Compliance programs in that era were built and evaluated almost entirely through description rather than data. Did the company have a code of conduct? Did it have a policy on gifts and entertainment? Did it conduct training? These were binary, checkbox-style questions, and answering yes to enough of them was largely treated as evidence of program adequacy.

The problem, obvious in hindsight, was that none of this told you whether the program actually worked. A company could have an elegant code of conduct that nobody read, a training program that employees clicked through without absorbing, and a hotline that nobody trusted enough to call. Compliance was assessed the way you’d assess whether a house had a fire extinguisher, not whether the fire extinguisher would work if a fire actually broke out. There was no meaningful way to measure whether misconduct was being deterred, detected, or addressed, because the profession simply wasn’t capturing the kind of data that would let you answer that question.

The First Real Data Sources: Hotlines and Training Completion

The earliest genuine compliance data sets came from two unglamorous sources: hotline call and case volumes, and training completion rates. Both were tracked mostly because they were easy to track, not because anyone had a sophisticated theory of what the numbers meant. A rising number of hotline reports could mean a workforce that trusted the reporting system, or it could mean a genuine spike in misconduct. A falling number could mean things were improving, or it could mean people had stopped trusting the system enough to bother calling. Training completion rates told you who clicked through a module, not who learned anything or changed their behavior as a result.

This was a real advance over having no data at all, but it also planted a trap that took the profession years to fully recognize: the tendency to treat the presence of a metric as proof of program effectiveness, regardless of what the metric actually measured. A company with strong hotline volume and 100 percent training completion could still have a compliance program that was failing in every way that mattered, and for a long stretch, there was no good way to tell the difference from the outside, or sometimes even from the inside.

Regulators Started Asking Better Questions

The turning point came as regulators, particularly the Department of Justice, began explicitly asking companies to demonstrate not just that a compliance program existed, but that it was being tested, measured, and improved based on actual data. DOJ’s evolving guidance on evaluating corporate compliance programs pushed this shift directly, asking questions that earlier eras of enforcement simply hadn’t asked: Does the company track and analyze the data its own compliance program generates? Does the company benchmark its metrics over time and against peers? Does the company actually use what it learns from its data to revise policies, training, and controls?

This mattered enormously, because it reframed data from something compliance functions collected defensively, in case a regulator ever asked, into something regulators actively expected companies to be using proactively to run a better program. A compliance function that could show a rising trend in substantiated investigations being resolved faster, or a training program whose completion data was tied to actual behavioral change, was suddenly demonstrating something meaningfully different from a function that could only show static, checkbox-style attestations.

What Was Still Missing

Even as this shift took hold, the underlying infrastructure for actually doing this well lagged well behind the ambition. Compliance data in this era typically lived in disconnected systems: hotline data in one platform, training records in a learning management system, third-party due diligence files in spreadsheets, transaction records buried inside finance or procurement systems that compliance had limited visibility into at all. Pulling together a genuinely integrated picture of program effectiveness required enormous manual effort, and by the time a report was assembled, the underlying data was often already stale. Compliance was, at best, looking in the rearview mirror at what had happened months earlier, not building any real capability to catch a problem while it was still developing.

That gap, between what regulators were starting to expect and what existing systems could actually deliver, is exactly what pushed the next phase of this relationship forward: purpose-built systems designed to make auditing and monitoring faster, more integrated, and closer to real time. That’s where Part 2 of this series picks up.