Turning Regulation into Code: What a16z Got Right (and What They Missed)

The a16z Thesis Is Right, But Undersells the Technical Difficulty

Andreessen Horowitz's "Everything, Everywhere is Compliance" (May 2026) names "Turn Regulation into Code" as the #1 strategy for the next wave of compliance tooling. They back this with real numbers: $40B per year in compliance labor, 400,000 workers dedicated to it, and a track record of spectacular failure. TD Bank paid a $3B fine after 70,000 suspicious activity alerts went unreviewed — not because they lacked software, but because their software generated noise that humans couldn't process at scale.

The a16z framing is correct: the old model of "hire more compliance people" hits a wall at volume. You can't staff your way out of an alert backlog that grows faster than headcount. Something has to change in how compliance rules are represented and enforced.

Where the framing goes thin is the technical specifics. "Regulation into code" sounds like a slogan until you've actually tried to do it — and discovered that most attempts stop at the wrong layer. They digitize documents without making them executable. They build dashboards without wiring them to the enforcement path. They treat compliance as a reporting problem when it's actually a runtime problem.

This post explains what "regulation into code" actually requires technically, and what it looks like when it works.

The Wrong Way to Do It (and Why Everyone Does It)

The most common interpretation of "regulation into code" is putting a PDF into a database. You take the HIPAA Security Rule, break it into numbered controls, store them in a GRC tool, and have people click checkboxes. This is better than a spreadsheet. It is not "regulation into code."

The second most common interpretation is writing compliance checks as one-off scripts that run in CI. Someone writes a shell script that greps for AES-256 and calls it "encryption enforcement." This is closer, but it breaks down because the scripts are disconnected from the regulatory text, not versioned with the regulation, and brittle against codebase changes.

Both approaches share a core problem: the regulation and the enforcement mechanism are different artifacts. When HIPAA publishes guidance that changes what "audit logging" means, nothing in your CI pipeline knows about it. When a new CVE makes a previously-acceptable crypto primitive unsafe, your compliance scripts don't update.

Real "regulation into code" requires three properties that most tools don't have simultaneously:

The Three Properties That Actually Matter

1. Executable

An executable rule runs automatically on every commit, in every branch, against the actual code. Not a checklist. Not a quarterly review. Not a scan you run before a release. Every. Commit.

This means the rule has to be machine-readable and scoped to specific file patterns. It can't just say "implement encryption" — it has to know what encryption looks like in Python versus Java, what files are in scope, and what the pass/fail condition is. A HIPAA audit logging rule that only checks *.py files in an api/ directory and looks for specific logging patterns is executable. A paragraph in a policy document is not.

2. Versioned

Regulations change. GDPR gets updated. NIST publishes new guidance. The EU AI Act enforcement timeline shifts. If your compliance rules aren't versioned alongside the regulation they encode, you have no way to know when you fell out of compliance — or why.

Versioned rules mean you can diff them. You can run:

$ sentrik pack-changelog hipaa

Pack: hipaa v1.4.0 → v1.5.0
  MODIFIED  HIPAA-164.312-a2-iv  (encryption-at-rest)
    - pattern: AES-(?:128|192|256)
    + pattern: AES-256|ChaCha20
    note: AES-128/192 removed per updated NIST SP 800-111 guidance
  ADDED     HIPAA-164.312-e2-ii  (transmission-security-integrity)
    new rule: TLS version enforcement (TLS 1.3 required)

You can look at that diff and immediately know: two things changed in HIPAA enforcement this quarter, here's exactly what, and here's when. Your audit trail has an automated answer for "what was the state of your HIPAA controls on January 1st?" — because the rules themselves are versioned in git.

3. Attributed

Every finding maps to a specific regulatory clause. Not "security issue." Not "policy violation." HIPAA §164.312(a)(2)(iv) — Encryption and Decryption — violation at api/patients.py:88.

Attribution matters because it changes the audience for the finding. A generic "SQL injection vulnerability" goes to the security team. A finding attributed to "PCI-DSS Requirement 6.3.1 — SQL injection prevention" goes to the PCI QSA. An "EU AI Act Article 10 — training data documentation obligation" finding goes to the AI governance team. Attribution routes findings to the right people and maps remediation directly to regulatory text.

It also makes the evidence map work. When a rule is attributed, a passing scan isn't just "no violations found" — it's positive evidence that a specific regulatory requirement is satisfied. That's a fundamentally different artifact for an auditor.

How Sentrik Implements This

Sentrik ships 22 regulatory standards packs — HIPAA, SOC 2, IEC 62304, OWASP Top 10, EU AI Act, PCI-DSS, GDPR, and 15 others — as YAML rule files. Here's a simplified example of what a rule looks like:

id: HIPAA-164.312-b
name: Audit Controls — Access Logging
standard: HIPAA
clause: "§164.312(b)"
type: required_pattern
applies_when:
  keywords: [patient, ePHI, health_record, medical]
pattern: "import logging|AuditLog|audit_trail|access_log"
scope: "**/*.py"
severity: critical
message: >
  HIPAA §164.312(b) requires audit controls that record
  and examine activity in systems containing ePHI.

This rule is executable (runs on sentrik scan), versioned (lives in a pack with a semantic version), and attributed (the finding cites HIPAA §164.312(b)). The applies_when condition means it only fires in codebases that actually handle patient data — no false positives in a fintech project that happened to use the word "health" in a variable name.

When a codebase satisfies the rule, the evidence map records where — which files, which lines, which pattern matched. The result isn't just "no violation." It's:

$ sentrik compliance-map --framework hipaa

HIPAA-164.312-b (required_pattern): MET
  → middleware/audit.py:14 — Implements audit-logging-required: import logging
  → api/patients.py:3 — Implements audit-logging-required: import logging

HIPAA-164.312-a2-iv (regex): MET
  → api/encryption.py:22 — Uses AES-256 (compliant cipher)

HIPAA-164.308-a1 (documentation_obligation): MET
  → docs/risk-analysis.adoc:14 — Documentation found matching: risk, analysis, vulnerabilities

That output is auditable. It has file paths, line numbers, and rule attribution. An auditor can verify it. It can be exported, signed, and submitted.

Generating Rules from Specs

One thing the a16z article doesn't address: where do the rules come from in the first place? For established regulations, curated packs handle this. But what about your own internal policies, or an API contract that has compliance implications?

Sentrik can generate rules from OpenAPI specifications and protobuf definitions:

$ sentrik import-spec openapi.yaml --framework hipaa --out .sentrik/custom-rules/

Generated 12 rules from openapi.yaml:
  api-auth-required         → 8 endpoints require authentication
  phi-response-fields       → 3 response schemas contain PHI fields
  audit-log-mutations       → POST/PUT/DELETE endpoints need audit logging
  ...

Your API spec becomes your compliance spec. If the OpenAPI schema defines a patient_record response type, Sentrik generates a rule requiring that endpoints returning that type have audit logging. The spec is the source of truth; the rules follow from it.

The AI Agent Angle: Before, Not After

Here's where the a16z thesis connects to something they didn't explicitly call out: AI agents.

When a human developer writes code, catching compliance issues at commit time is sufficient. The feedback loop is tight enough — the developer sees the finding in CI and fixes it before it ships. But when an AI agent writes code autonomously — running in a loop, opening PRs, merging changes — "flag violations after the fact" is too slow. You need the agent to query compliance rules before writing code, not get flagged after.

Sentrik ships an MCP server that exposes compliance rules as tools any AI agent can call. Before writing a patient data endpoint, an agent can query:

$ sentrik check-inline --context "writing a REST endpoint that returns patient records" \
    --framework hipaa

Applicable rules for this context:
  HIPAA-164.312-b   CRITICAL  Audit logging required for ePHI access
  HIPAA-164.312-e1  HIGH      Transmission security — use HTTPS/TLS
  HIPAA-164.514-b   HIGH      Minimum necessary — limit PHI fields in response
  HIPAA-164.308-a4  MEDIUM    Access control — authenticate before returning PHI

Recommendation: implement audit logging at middleware layer before writing endpoint logic.

The agent gets the relevant rules before writing, not a violation report after. This changes the compliance model from reactive to proactive — which is the only model that works at agent-generated-code scale.

This also solves a governance problem that a16z hints at but doesn't name directly: when an AI agent writes code that causes a compliance violation, who is responsible? With attribution at the rule level and task binding at the session level, Sentrik records which agent session produced which code change and which rule it violated. The audit trail includes the agent's identity, not just the commit SHA.

What This Changes for Auditors

The traditional audit evidence sprint looks like this: auditors arrive, request evidence for ~200 controls, and spend six weeks watching your team pull logs, annotate screenshots, and write control descriptions from memory. The team hates it. The auditors hate it. Everyone is pretending the process is more rigorous than it is.

When compliance rules are executable, versioned, and attributed, the sprint becomes a command:

$ sentrik attest --framework soc2 --save

Attestation generated for commit a3f9c12
  Framework:  SOC 2 Type II
  Coverage:   91.4% (187/205 controls met)
  Signed:     HMAC-SHA256 (key: machine-derived)
  Saved:      .sentrik/local/attestations/a3f9c12.json

$ sentrik auditor create --name "Jane Smith" --email jane@auditor.com
  Auditor portal: https://sentrik-portal.fly.dev/audit/tok_...
  Expires: 30 days, read-only access

The attestation is cryptographically signed against a specific commit. It records exactly what version of each rule pack was active, what the coverage was, and which controls had violations. The auditor gets a read-only portal with time-limited access. No codebase access required. No six-week sprint.

This isn't just faster — it's more honest. The evidence is generated from the actual codebase, not assembled by a team that knows which drawers to open. If coverage is 91.4%, that's the real number, not the number someone curated for the auditor package.

What a16z Missed

The a16z thesis is right that "regulation into code" is the unlock. What it underweights is how much of the value comes from the negative space — the evidence that a requirement is met, not just the alert that it's violated.

Every security tool on the market tells you what's wrong. That's table stakes. The harder problem — and the more valuable one — is telling you what's right, with enough precision that an auditor will accept it. That requires attributed rules, positive evidence collection, and a signing layer that makes the evidence tamper-evident.

The compliance industry's real unlock isn't replacing compliance workers with dashboards. It's making the evidence generation automatic so that the humans who remain can spend their time on judgment calls — the ambiguous cases, the novel risks, the things that genuinely require human interpretation — instead of assembling evidence packages for controls that passed cleanly six months ago.

Getting Started

Sentrik covers 22 regulatory frameworks — OWASP, SOC 2, HIPAA, IEC 62304, EU AI Act, PCI-DSS, GDPR, and more — with full evidence mapping, versioned pack updates, and clause-level attribution. The MCP server and sentrik check-inline let AI agents query compliance rules before writing code.

Get Early Access →