Should you build your own compliance AI, or buy?

Honest answer first: you can absolutely build your own compliance AI — the first version, in weeks. An agent that reads your policies, drafts answers to a questionnaire, and files evidence into folders is well within reach of a good engineer with agentic coding tools. If that surprises the software vendors, it shouldn't: McKinsey's State of AI survey (published 25 August 2026) found that 32% of organizations decided against buying at least one software product because they could build it themselves with agentic coding tools — most often in technology and healthcare. Prospects raise this with us directly, and it deserves a real answer rather than vendor hand-waving. The real answer is about what happens after the first version.

What the build actually is

Scope it honestly and the v1 is genuinely modest: a document store, a set of framework requirements, an LLM pass that drafts assessment answers and policies from your internal context, and somewhere to keep evidence. Weeks, not quarters — the 32% are not wrong. The parts that look hard (the drafting, the summarizing, the questionnaire answers) are exactly the parts modern models do well.

That is also why "we could build this" feels so compelling in the meeting. Everything visible in a compliance product demo is the part you can rebuild. The parts you cannot see in a demo are where the math turns.

The maintenance argument

A compliance system's core asset is not the AI — it is the requirements and their interpretation, kept current. That asset decays constantly:

• Frameworks revise (ISO 27001's 2022 edition restructured every control; transition deadlines forced every certified company to remap).
• Regulations stage in over years — the CRA alone has obligations landing in 2026 and 2027, with guidance still being issued.
• Enforcement practice moves: what an auditor accepted last year gets rejected this year, and interpretations shift under NIS2's national transpositions across 27 member states.

An internal build handles the first version; then someone owns tracking six changing frameworks indefinitely — reading amendments, updating mappings, re-testing drafts against new expectations. That is not a side project; it is a standing role. The build-vs-buy question is really "do we want to hire regulatory-content maintenance as a permanent internal function?" For a compliance vendor, that maintenance is the product and amortizes across every customer. For you, it amortizes across one.

The audit-trust problem

The second structural issue: your compliance AI's output has to convince someone whose job is skepticism. Auditors and customers accept evidence chains they recognize — named human sign-off on each verdict, versioned policies, a Statement of Applicability whose logic they can follow, an export in a shape they have seen before. A homegrown system can build all that, but it starts with zero recognition, and every audit becomes a meta-audit of the tool itself. There is also a quieter risk: an internal AI that grades its own homework tends toward optimism, and nobody inside has the incentive to challenge it until an auditor does.

When building is the right call

The honest list, because it exists:

• You are the special case. A niche regulatory regime no platform covers, or requirements so entangled with proprietary systems that no external tool can see them.
• Compliance tooling is strategically yours. You are a GRC company, or plan to sell what you build.
• Genuine scale. At thousands of assessments a year with a platform-engineering org, internal amortization can work.
• A hard data boundary. If policy forbids any external processor touching security documentation, buying is off the table anyway — though check what your auditors then expect of the internal alternative.

Outside those, the pattern the McKinsey finding will likely produce — and worth naming now — is a wave of internal v1s built in 2026 that become unowned liabilities by 2028, still mapped to framework editions nobody updated.

A fair way to decide

Run the comparison on the full timeline, not the demo:

1. Cost the maintenance function, not the build: who reads the amendments, updates six frameworks, re-validates outputs — for years.
2. Ask your auditor, before building, what they would need to rely on an internal tool's evidence. Their answer is your real spec.
3. Price the buy option honestly too — which requires vendors who publish prices. Ours are on the pricing page; most of the category makes you call sales, which tells you something about how these comparisons usually go.
4. Whatever you choose, keep the sign-off human and named. That is the part neither builders nor buyers get to automate away.

ZeroRisk's position in this debate is transparent: we are the "buy" side, and our pitch is precisely the maintenance argument — the agent does the drafting and monitoring, our team maintains the six frameworks so yours doesn't, and every verdict carries a human signature an auditor can interrogate. If you are weighing a build, the free gap report is a useful benchmark either way: it shows you in ten minutes what the platform sees, which is exactly the bar your internal version would need to beat.