Every compliance officer has had the meeting. Someone on the leadership team, or increasingly someone on the compliance team itself, points out that Claude or ChatGPT can write code now, so why not build the workflow tracker in-house instead of paying a vendor.
It is a reasonable question, and worth taking seriously. AI has genuinely changed what a two-person compliance team can build on a weekend. The problem is not that AI-assisted development is overhyped. The problem is what happens after the demo, when the system has to survive an actual SEC exam, an actual due diligence questionnaire, and an actual busy quarter when nobody has time to debug a broken script.
History repeats itself
Build versus buy has been reopened by every technology that was supposed to settle it. In the 1990s, Visual Basic and Access put a database and an interface in the hands of anyone with a weekend, and financial services firms filled up with homegrown tools built exactly that way. Some are still running. Offshore development, then low-code platforms, made the same promise in turn.
Each wave delivered a real capability increase, and each produced the same conclusion a few years later. What the technology reduced was the cost of the first version. What it never reduced was the cost of the tenth year: the integrations that break, the person who left, the requirements that changed, the documentation nobody wrote. That is why the durable rule survived every wave intact. Firms build where the system is a competitive advantage and buy where it is table stakes. A fund builds its own research infrastructure and risk models, because those are the business. No firm has ever raised capital because its attestation tracker was proprietary.
AI belongs in that lineage. It has cut the cost of the first version by more than any predecessor. It has not changed which side of the line compliance workflow sits on. Five reasons the build usually turns out to be the wrong bet.
1. The bandwidth constraint relocates, it doesn’t disappear
The CCO at a small SEC-registered asset manager, weighing a purpose-built platform against building something with Claude Code and his internal developers, said the real question was not whether the technology could work, but whether “having it all done and the kinks worked out” was worth paying for versus absorbing the cost himself, in dollars or in his own time.
He also named the tradeoff most compliance officers underestimate. His developers were available in theory, but had “gradually been taking on more and more in different areas of the business,” so competing for their time was getting harder, not easier.
The constraint was never whether the code could be written. It was whether a team already stretched across code of ethics, testing, filings, and exam prep has the bandwidth to become a part-time software shop. Writing the system is not the expensive part. Owning it is.
2. The cost comparison is usually done wrong
A compliance team member at a private equity firm described a decision already made. Her firm’s founder had a two-decade preference for building in-house, so the team was building its own workflow and compliance calendar tool. She thought it was the wrong call, saying outright that it was “much more efficient to get a third-party product,” and agreeing without hesitation that the build would cost four to five times what buying would.
A vendor quote looks like a cost. An internal build looks free because the developers are already on payroll. But developer time is not free, and neither is the tooling.
Using a model to draft a memo costs very little. Using an agentic coding tool to build and maintain a production system is a different order of consumption, because these tools read the codebase, reason across it, retry, test, and revise, and each step burns tokens. Teams starting on a consumer seat find the ceiling fast. The CCO above hit exactly that, noting Claude Code’s “only issue is it’s saying usage refreshes in five hours.” Moving to a paid API relationship fixes it, and turns a fixed subscription into spend that scales with how often you touch the system, indefinitely.
3. Day one is the easy part
The demo works. That is what makes this bet easy to take. Then the broker feed changes format and ingestion silently starts dropping records. The person who built the tool leaves, and nobody remaining can explain why a particular workflow rule exists or what it was meant to catch. A regulation changes and the logic has to be revised by someone who did not write it, without documentation, in a codebase generated largely by a model.
Most firms already own a spreadsheet or Access database that a departed employee built, that everyone depends on, and that nobody fully understands. AI does not remove that risk. It increases it, because the volume of code a small team can now produce far outruns what that team can review, document, and carry forward.
4. The system faces an audience the build meeting never considers
Operational due diligence teams ask what systems support the compliance program, who maintains them, whether there is a SOC 2 report, how access is controlled, and what happens if a key person leaves. Standard questions, asked by the institutional investors a firm spends months courting.
“We built it internally” works only if the firm can produce the artifacts that go with it. A tracker maintained part-time by a compliance analyst, with no independent security review, no documented change control, and no succession plan, is a finding waiting to happen. The same applies in an exam, where the staff’s interest is not whether a tool is impressive but whether the firm can evidence that policies were followed consistently. An audit trail showing when something was done, by whom, and against what policy requirement is a domain problem before it is a coding problem.
Buying means those answers arrive with the product. Building means manufacturing them yourself, every year.
5. Building forfeits what the rest of the market is learning
This is the reason with no workaround at any budget.
Buying a platform is not just buying what it does today. It is buying everything hundreds of peer firms have asked for and will ask for. When one client comes out of an exam having been asked for something new, that shapes the roadmap, and every other client benefits without having known to ask. A vendor serving a wide client base is running a continuous survey of what the market is being asked for and what works.
An internal build gets one firm’s perspective: its own. It reflects what its builder knew the day they built it, and has no mechanism for learning that a peer three states away just took a deficiency over something it does not track. That gap is invisible on day one and obvious in year three.
Conclusion
None of this means AI has no place in compliance. It has plenty of uses for research, drafting, and speeding up internal work. But there is a meaningful difference between using AI inside a mature compliance operating system and asking it to become the operating system itself, maintained indefinitely by people whose actual job is compliance.
Every previous wave asked firms to reconsider where the build-versus-buy line sat, and each time it held, because what got cheaper was construction and what stayed expensive was ownership. Compliance infrastructure is a costly place to bet on this wave being the exception.
