Stop treating compliance like a final exam

How healthcare & life sciences leaders can embed compliance into engineering workflows

A life sciences company starts building an AI-powered clinical documentation tool. With the right tools and a small, driven team, it moves from idea to prototype in just a few days. Early results are promising, and it seems the tool could cut EHR documentation time by nearly 40%.

That’s when compliance review comes into the picture.

Suddenly, the team is no longer moving at the speed of experimentation. They are gathering evidence, answering security questionnaires, and waiting for review boards that only meet once a month.

What took days to build can take six to eight weeks to approve. And in that process, the early excitement often fizzles into frustration driven by industry regulations.

This is a familiar story across highly regulated industries. Our recent research featuring 119 product leaders in healthcare and life sciences revealed that 79% of organizations slowed an AI deployment last year due to unexpected regulatory considerations.

However, regulation is not the real issue here. Faster approvals won’t solve this bottleneck because the bottleneck is not the approval meeting. It is the fact that compliance still happens after the work, instead of being built into how the work gets done.

Why AI has raised the cost of late-stage compliance

In April 2026, the FDA sent a landmark warning letter to Purolea Cosmetics Lab over its use of AI agents to support regulatory compliance, criticizing Purolea for relying on AI-generated documents without human review, which was treated as a compliance violation. This was among the issues cited before Purolea ceased its drug manufacturing operations.

This story shouldn’t come as a surprise to anyone. AI has indeed raised the cost of compliance failures because its behavior is less predictable than that of traditional software. Instead of the old way of treating compliance as a checkpoint at the end of the process, this calls for treating compliance as the process. That’s the core idea of compliance as code.

Compliance as code is about moving compliance closer to the work by translating regulatory requirements, security controls, and audit expectations into the same rules that govern your engineering workflows. So, instead of waiting for a final review to discover gaps, you can continuously check whether systems meet the required standards as they are built, deployed, and changed.

In practice, that means you should be able to trace any compliance requirement all the way through to what is happening in production today.

How to embed compliance into your engineering workflows

There are a few specific actions you can take to adopt compliance as code and embed it across your entire engineering lifecycle.

Step 1: Establish environment visibility with telemetry

You cannot automate compliance around systems you cannot see. Turn on the foundational telemetry first: configuration state, API activity, security findings, network logs, and operational events. In an AWS environment, that could mean enabling tools like AWS Config, AWS CloudTrail, AWS Security Hub, VPC Flow Logs, and Amazon CloudWatch.

Step 2: Convert regulatory requirements into versioned controls

When a compliance requirement changes, ideally, your response should not be a chain of emails and manual reviews. The requirement should become a versioned control that you can update once and apply consistently across accounts and environments.

For example, if a regulator introduces a new requirement around data handling, teams can codify that requirement as an AWS Config rule and enforce it through Service Control Policies (SCPs). Every resource is then continuously evaluated against the new standard, eliminating the need for manual verification.

Step 3: Block non-compliant infrastructure in CI/CD

You should check controls such as encryption at rest, logging standards, access policies, and approved network configurations before deployment. The best way to do that is to embed these checks directly into CI/CD pipelines and infrastructure-as-code templates. A deployment that violates an encryption requirement or bypasses logging standards can be blocked automatically before it reaches production.

Step 4: Maintain an auditable record of system behavior

Reconstructing what happened after an event has occurred or after an audit is a harrowing experience for everyone involved. That’s why an auditable history that can be reviewed any time you want is crucial in today’s environment.

Tools like AWS CloudTrail and Azure Activity Log capture API activity, configuration changes, and user actions across the environment. By automatically recording these events, organizations can identify who made changes, when those changes occurred, and which resources were affected.

Step 5: Monitor continuously for drift and control failures

Traditional compliance reviews often discover issues weeks or months after they occur. Continuous monitoring through services such as Amazon CloudWatch and AWS Security Hub helps you identify configuration drift, policy violations, and security findings in near real time.

Step 6: Build traceability into data flows

AI has made traceability non-negotiable. Organizations today need a complete chain of evidence that shows:

• Where the data originated and whether it was approved for the intended use
• How the data moved across systems, vendors, and workflows
• Who accessed, modified, or approved information at each stage
• Which model, version, prompt, and configuration generated a response
• What output was produced, and whether it triggered downstream actions
• What guardrails, policies, human reviews, and controls governed the process

Without that level of traceability, you cannot reliably investigate incidents, demonstrate compliance, or explain how critical decisions were made at scale.

What in compliance should not be automated

So far, we’ve been mostly discussing automation, which can give the impression that compliance as code requires you to automate the entire compliance process. This isn’t necessarily true; in fact, some of the most important compliance decisions should never be automated. A useful rule of thumb is to automate the work, not the judgment.

In 2024, TD Bank agreed to pay more than $3 billion in penalties after regulators uncovered major weaknesses in its anti-money laundering program. The bank had monitoring systems and compliance automation in place, but it still failed to prevent money laundering due to significant control, governance, and oversight deficiencies.

Automation is highly effective at collecting evidence, monitoring controls, and routing issues to the right teams. But some decisions still require human accountability and oversight. Accepting a risk, approving a control exception, interpreting a new regulation, or deciding whether an AI system is being used appropriately all depend on business context and your own risk appetite. Compliance as code works best when automation handles the paperwork, and humans handle the consequences.

5 signs your compliance is in good shape before an audit

Once compliance becomes a part of your engineering workflows, there's no need to wait for an audit to find out whether it’s working or not. You’ll know that you are moving in the right direction when you start noticing these signs:

1. Control failures are discovered during normal operations: You start identifying issues such as misconfigurations, missing encryption, or excessive access as part of day-to-day delivery.
2. Evidence is readily available: Your teams are no longer scrambling through inboxes, spreadsheets, and screenshots to prove compliance because evidence is generated continuously.
3. You can operationalize regulatory changes quickly: New requirements can be translated into controls and enforced across environments without launching a major compliance initiative.
4. Engineers know when they violate a control: Feedback happens during development and deployment rather than weeks later during a review.
5. Compliance conversations focus on risk, not paperwork: Teams spend less time collecting evidence and more time discussing exceptions, tradeoffs, and business decisions.

As you might have noticed, the strongest signal is cultural. Audits stop feeling like fire drills that require last-minute preparation. When controls, evidence, and traceability are built into the workflow, an audit becomes a validation exercise rather than a scramble to reconstruct the past.

Compliance & innovation aren’t at odds

Healthcare and life sciences organizations moving fastest aren't doing so despite rigorous compliance; they've embedded compliance from the very beginning of the development process.

You can build the most proactive compliance function in the world, but if compliance isn't embedded into engineering decisions and delivery workflows, it will remain a bottleneck that slows your progress.

Here is one thing you can do today to adopt compliance as code if you have inherited years of manual compliance debt. Start with visibility and then pick one workload, one compliance framework, or one bounded scope instead of trying to boil the ocean. This alone will put you ahead of organizations that are still treating compliance as a documentation exercise rather than an engineering capability.

The capability already exists in the tools you use; you need only make the decision to begin.

Our research explores how healthcare & life sciences product leaders are scaling AI while balancing ROI, governance, and operational efficiency. Explore the full healthcare and life sciences AI report →

This article was developed with contributions from: Daniel Morales, Security Engineer; Alex Umeh, Security Engineer.