What 220 Controls Teach About Building AI Governance Frameworks

Most governance conversations happen in the abstract. Principles, pillars, taxonomies. The word “framework” gets thrown around until it means nothing more than “a document we wrote.”

Two stories from the past week offer something rarer: governance frameworks meeting reality. One is an infrastructure company that built 220 controls and then measured what happened. The other is an AI reimplementation that rewrote a GPL-licensed library in five days, producing code with 1.3% similarity to the original. Together they reveal a pattern that matters far more than either story alone.

Governance works when it fits. When it does not fit, people route around it.

GitLab’s 220 Controls

GitLab Security Compliance, led by Davoud Tu, started where most organizations start: with an existing standard. NIST SP 800-53 is the default playbook for security frameworks. It is comprehensive, well-documented, and trusted by auditors worldwide.

It was also wrong for GitLab.

Not wrong in principle. Wrong in fit. NIST was designed for federal information systems. Its control families assume a certain organizational shape, a certain threat model, a certain audit cadence. GitLab is a DevSecOps platform serving millions of developers across public cloud, dedicated instances, and FedRAMP environments. The standard’s assumptions did not match the company’s reality.

The team’s response was not to abandon standards. It was to build a custom framework that mapped to standards without being dictated by them. The GitLab Control Framework now contains 220+ active controls organized across 18 custom domains, with 1,300+ mapped certification requirements supporting 8 certifications: SOC 2, ISO 27001/27017/27018/42001, PCI DSS, TISAX, Cyber Essentials, and FedRAMP.

The results tell the real story. SOC controls dropped by 58% for GitLab.com and 55% for GitLab Dedicated. Four separate audit request lists collapsed into one (a 44% reduction). The team did not achieve compliance by adding controls. They achieved it by removing the ones that did not belong.

Tu’s observation deserves quoting directly: “Implementing unnecessary controls doesn’t improve security; in fact, too many can make an environment less secure as individuals find ways to circumvent overly restrictive or irrelevant controls.”

That sentence contains the entire argument for custom governance frameworks. More controls create more surface area for circumvention. The goal is not maximum coverage. It is accurate coverage.

Five Steps, Not Five Hundred

GitLab’s methodology was a five-step cycle: analyze existing certifications, review control applicability, create custom domains, build the control hierarchy, and iterate. Each step reduced scope rather than expanding it.

The “create custom domains” step is where most organizations flinch. Custom means you cannot point to a standard and say “we followed it.” Custom means you have to defend your choices. But custom also means your controls actually describe your environment, your threats, your operations.

In Claude’s Constitution, we examined how Anthropic moved from a 2,700-word rule list to a 23,000-word reasoning framework. The principle was the same: generic rules fail because they cannot anticipate specific contexts. Anthropic’s solution was to explain the why behind each constraint so the system could generalize. GitLab’s solution was to build controls that describe their actual infrastructure so auditors could verify what actually matters.

Different domains. Same insight. Governance that does not fit the governed system is governance in name only.

The Copyleft Rewrite

Now for the second story, which operates in territory no existing framework covers.

The chardet Python module handles character encoding detection. It has 170 million downloads. It is licensed under GPL, which means any software that incorporates it inherits GPL obligations: source disclosure, derivative work licensing, the full copyleft chain.

Someone used Claude to rewrite chardet from scratch in five days. The resulting code has 1.3% similarity to the original, verified through automated plagiarism detection. Clean-room implementation. New code, same functionality, no GPL obligations.

Five days. One AI model. A library that took years of human effort to build and maintain, functionally replicated with near-zero legal entanglement.

The article that reported this asked a provocative question: “How long before the Linux kernel itself is rewritten?” That question is premature. The Linux kernel is orders of magnitude more complex than a character encoding library. But the underlying dynamic is real. Companies will increasingly choose a week of AI reimplementation over years of GPL compliance management.

The Governance Frontier Nobody Mapped

Here is what makes this relevant to governance practitioners, not just open-source lawyers.

Every existing code governance framework assumes a stable relationship between code and its provenance. You audit dependencies. You track licenses. You verify that the code in production matches the code that was reviewed. These are solved problems with mature tooling.

AI-generated clean-room implementations break that assumption. The code is new. It was never copied, never forked, never derived in any way that existing license tracking would flag. But it exists only because the original existed. The AI learned from a corpus that included the original. The specification (what the code should do) came from observing the original’s behavior.

Is that a derivative work? Current law says probably not, if the clean-room process was genuine. But “current law” is a phrase with a short shelf life when the technology changes this fast.

As we argued in Agent Specs Are Governance Artifacts, the specifications that drive AI systems are themselves governance surfaces. The spec that told Claude “replicate chardet’s functionality” is an auditable artifact. Who wrote it? What constraints did it include? Was there a review process? These questions matter because the code itself reveals nothing about its origins. Only the process documentation does.

Code provenance governance is about to become as important as code security governance. Organizations that build AI-assisted development pipelines need to track not just what code was generated, but what prompted its generation and what existing code informed the specification.

GitLab and the chardet rewrite seem unrelated. One is about security compliance. The other is about intellectual property. But they share a structural lesson.

Both demonstrate that governance frameworks fail when they assume a static environment. NIST assumed a federal IT shape; GitLab’s infrastructure did not match. GPL assumed that reimplementation would take prohibitive effort; AI eliminated that assumption. In both cases, the old framework did not become wrong. It became irrelevant.

GitLab’s response was to build a framework that maps to their actual environment. The open-source community has not yet built its equivalent response. The chardet rewrite is still a novelty. But the pattern will repeat, faster each time, as AI coding tools improve.

The organizations that will handle this well are the ones that treat governance as a living system. GitLab iterates their control framework. They review, prune, and update. They do not treat the framework as a document that gets written once and filed. That iterative discipline is what produced the 58% reduction. And it is what will be required to govern AI-generated code provenance, because the rules for that domain do not exist yet. They will have to be built, tested, and revised in real time.

The Practical Takeaway

If you are building a governance framework for AI (security, compliance, IP, or all three), GitLab’s five-step method is a better starting template than any industry standard used raw.

Analyze what certifications and obligations actually apply to you. Review whether standard controls are relevant to your environment. Create domains that match your operations, not someone else’s taxonomy. Build the hierarchy. Then iterate, because the first version will be wrong.

The 58% reduction is not a GitLab-specific number. It is a signal about what happens when you replace borrowed frameworks with ones built for purpose. Most organizations are carrying controls that do not improve their security posture. Those controls consume audit cycles, create compliance fatigue, and (as Tu noted) incentivize circumvention.

For code provenance specifically: start tracking it now. Document the prompts, specifications, and reference materials that inform AI-generated code. Build the audit trail before regulators require it. The chardet rewrite is a proof of concept. The regulatory response will follow.

This analysis synthesizes How We Built the GitLab Control Framework by Davoud Tu (March 2026) and The Death of Copyleft from LowEndBox (March 2026).

Victorino Group builds governance frameworks that fit your actual environment, not someone else’s template. Let’s talk.