Build vs Buy: The AI Governance Platform Decision (2026)

For most regulated mid-market and lower-enterprise companies, an honest 12-month total cost of ownership analysis lands between 1.5 million USD and 3.2 million USD to build an AI governance platform in-house, against a 90,000 to 250,000 USD annual subscription to buy a control plane and 1 to 2 weeks to deploy. Build is the right answer in two narrow scenarios; buy is the right answer in every other mid-market case. McKinsey's State of AI 2025 reports that 78 percent of organizations use AI in at least one business function, which makes the build-versus-buy question the most expensive decision a CISO will make this year. Updated 2026-05-20.

The build-versus-buy question for AI governance is not new, but the calculus changed sharply between 2024 and 2026. Three forces converged. First, the regulatory perimeter widened: the EU AI Act took effect 1 August 2024, the Colorado AI Act takes effect 1 February 2026, the NIST AI RMF Generative AI Profile (AI 600-1) landed in July 2024, and DORA's AI implications are now clear (see our DORA + AI guide). Second, AI adoption inside enterprises crossed the 75 percent threshold according to McKinsey's State of AI 2025. Third, the available platform market matured: there are now 25-plus credible AI governance platforms, each with different scope, depth, and pricing models.

The combination means that for a 500-employee regulated company, an in-house build is now a multi-year, multi-FTE programme that competes directly against shrink-wrapped platforms that deploy in days. The question is not whether to invest in AI governance - that is settled - but whether to invest in building one or in operating one.

The honest answer is workload-specific. The rest of this post walks through the realistic numbers, the criteria that flip the decision, and the open-source middle path that some teams correctly choose.

The numbers below are modelled for a 500-employee regulated mid-market company - the typical Areebi prospect profile. They are conservative estimates based on engagement experience plus public salary, vendor, and cloud cost data. They assume the company already has a CISO, an existing SIEM, and existing identity infrastructure, so neither side absorbs core platform costs.

Three lines on the table matter more than the headline totals. First, the engineering FTE line assumes a small team can ship an enforcement-grade platform inside 12 months. In reality most build attempts ship a prototype in months 6 to 9 and the first audit-grade enforcement layer in month 14 to 18. Second, the platform subscription line for buy is the all-in vendor cost - some vendors price the policy engine, the audit log, and the DLP add-on separately, and the line aggregates those. Third, the open-source line presumes the team picks well-supported components (typically a combination of an open-source LLM gateway, an open-source policy engine, and a homegrown audit log on object storage) rather than a fully bespoke build.

Forrester's 2024 Total Economic Impact methodology, applied to comparable cybersecurity platform decisions, consistently shows that the integration burden inside a build path is underestimated by approximately 40 percent at the planning stage. Apply that discount to the build column above and the gap widens further.

There are two scenarios in which building an in-house AI governance platform is the correct answer, even with the TCO gap above. Both are narrow and both depend on conditions most companies do not meet.

Scenario 1: A FedRAMP, IL5, or sovereign-cloud boundary requirement that no commercial platform meets today. If the AI workload must run inside a US federal authorisation boundary, a UK SC or DV cleared environment, or a sovereign-cloud envelope (such as the German C5-aligned BSI footprint or the Australian PROTECTED ISM-aligned IRAP environment), the commercial vendor list shrinks dramatically. Several leading commercial platforms are not yet authorised at those levels, and the timeline from procurement to authorisation can exceed the timeline to build a focused internal capability. In that case the answer is to build the minimal viable governance layer inside the boundary while continuing to evaluate commercial vendors as their authorisation programmes mature.

Scenario 2: A deep customisation requirement tied to a unique business model. A small number of organisations - typically large financial trading firms, sovereign research labs, intelligence agencies, and hyper-scaled defence contractors - have AI use cases so unusual that no commercial platform supports the policy primitives required. A high-frequency trading firm enforcing per-microsecond trade-decision policies, a sovereign research lab enforcing classification boundaries that map to its national security regime, or a defence prime running multi-INT fusion under specific clearance constraints will not find an off-the-shelf product that fits. In those cases the build is justified by the specificity of the requirement, not by cost.

Outside those two scenarios, the build case is much weaker than internal teams typically argue. The most common build justification - "we need full control over our security posture" - does not hold up because every credible commercial platform now ships with SOC 2 Type II, ISO 27001, and increasingly ISO 42001 attestations, plus the ability to deploy in customer VPC or on-prem.

For most regulated mid-market companies the buy case is the correct answer, and the supporting argument has four parts.

Argument 1: Compounding compliance leverage. A commercial platform that already maps controls to NIST AI RMF, ISO/IEC 42001, the EU AI Act, the Colorado AI Act, DORA, and SOC 2 represents thousands of person-hours of compliance engineering you do not have to repeat. The Areebi platform, for example, ships with policy templates and audit log schemas pre-aligned to the frameworks our customers ask about most often. The same alignment work, done in-house, takes a compliance engineer 4 to 6 months per framework.

Argument 2: Velocity of platform evolution. Foundation model providers shipped breaking changes to their tool-use, structured-output, and safety APIs roughly every quarter through 2024-2025. A commercial platform absorbs that churn; an in-house build inherits it. Gartner's research on the build-versus-buy decision in adjacent categories (cybersecurity, identity, observability) consistently shows that platform-vendor velocity is the single largest cost saver over a 3-year horizon.

Argument 3: Recruiting math. The cohort of engineers who can ship a credible AI governance platform - meaning they have shipped real-time policy enforcement against LLM APIs at scale, with audit logging that passes a Big Four audit - is small. MIT Sloan's 2024 research on AI talent supply indicates that AI-specialist hiring cycles for senior staff engineers now run 4 to 9 months. A platform vendor absorbs that hiring risk by spreading those engineers across hundreds of customers.

Argument 4: Buyer-side network effects. The CISO of a regulated company will eventually face customer security questionnaires (SIG, CAIQ) and procurement reviews from larger customers asking "what AI governance platform do you use?" A named commercial platform with public SOC 2 and ISO attestations answers that question faster than a paragraph describing an internal build. Our AI governance vs AI security post covers the buyer-side framing in more depth.

For most companies the right move is to buy the platform, retain a small internal team to own the integration and the policy authorship, and reinvest the saved engineering capacity into the business AI workloads themselves.

Between full build and full buy sits an open-source assembly path that some teams correctly choose. The pattern is to combine an open-source LLM gateway, an open-source policy engine, and a homegrown audit log on object storage, with light commercial wrappers for the gaps. The TCO table above shows this path at roughly 1.1 to 1.8 million USD year-one - cheaper than full build, more expensive than buy.

The open-source path is the right answer when three conditions hold simultaneously. First, the team already operates open-source security infrastructure in production (so the operational muscle exists). Second, the AI workloads are concentrated in a small number of well-defined use cases (so the policy surface is small and stable). Third, the compliance scope is one or two frameworks rather than five (so the cross-framework mapping burden stays manageable).

The open-source path is the wrong answer when the team is treating it as a cost optimisation against the buy path. In that case the integration and operational burden quickly consumes any subscription savings, and the audit-evidence story is weaker than either full build or full buy.

A specific implementation note: Areebi itself is built on the open-source AnythingLLM project. Areebi customers who want to inspect the underlying engine can do so directly via the GitHub repository. The Areebi commercial layer adds the policy engine, audit log schema, DLP enforcement primitives, compliance dashboards, and pre-aligned framework mappings that the bare open-source path does not provide.

The framework below is the one Areebi recommends prospects use when presenting the build-versus-buy decision to a CFO or board risk committee. It deliberately keeps the number of factors small and weighted so the decision does not collapse under analysis paralysis.

At Areebi, we routinely tell prospects to use this framework against us. When the factors tilt toward build we say so - the open-source AnythingLLM project is free to use, and we would rather lose a deal honestly than win one that does not fit. When the factors tilt toward buy, the commercial Areebi platform is engineered specifically for the mid-market case the framework usually surfaces.

Pitfall 1: Underestimating the integration burden in the build column. Build estimates routinely capture the engineering FTE cost but miss the integration points - identity provider, DLP backbone, SIEM forwarder, ticketing, change management, procurement workflow, and so on. Each integration typically takes 1 to 3 engineer-weeks. A realistic build estimate scales the FTE column by approximately 40 percent to absorb this; Forrester's TEI methodology shows the same gap in adjacent categories.

Pitfall 2: Comparing a "free" open-source path against a fully featured commercial subscription. Free is a software-licence statement, not a TCO statement. The operational, integration, audit-readiness, and incident-response burden of the open-source path lands on the customer's payroll. The honest comparison shows open-source at roughly 60 percent of the build cost, not zero.

Pitfall 3: Treating the decision as one-time and irreversible. The build-versus-buy decision is reversible. Companies that started with an in-house build through 2022-2023 routinely migrated to commercial platforms in 2024-2025 once the market matured and the audit pressure increased. The corollary is that a buy decision today is also reversible if a credible internal alternative emerges later. Frame the decision in 24-month horizons, not 7-year strategic commitments.

Areebi is the commercial layer on top of the open-source AnythingLLM engine - which means we are honest with prospects about which build, buy, or assembly path is right for them.

If the open-source path is the right answer, AnythingLLM is free, and we can recommend implementation partners. If the buy path is the right answer, Areebi packages the policy engine, audit log, DLP, multi-tenant administration, compliance dashboards, and pre-aligned framework mappings into a deployment that takes 1 to 2 weeks rather than 9 to 14 months. If the build path is the right answer, we will say so on the call and direct the CISO to the technical resources they need.

The Areebi AI Governance Assessment includes a build-versus-buy scoring module aligned to the framework table above, completed in approximately 25 minutes by a CISO or Head of AI. It produces a documented recommendation a CFO will accept, regardless of which side the result falls on.

The references below underpin the cost, talent, and market dynamics cited above. All URLs verified at publication.

• McKinsey State of AI 2025 - adoption data and AI use case distribution by industry.
• Forrester Total Economic Impact methodology overview - TEI framework used to discount build-side integration estimates.
• Gartner build-versus-buy framework - the canonical buy-versus-build decision criteria across enterprise software.
• MIT Sloan Ideas Made to Matter AI research portal - talent supply and adoption dynamics underpinning the recruiting argument.
• NIST AI Risk Management Framework portal - the canonical reference for the compliance mapping costs cited.
• AnythingLLM open-source repository - the open-source engine cited in the open-source assembly path.

To go from decision framing to platform evaluation, work through this cluster.

• AI governance vs AI security - the canonical scope-and-ownership reference before vendor evaluation.
• Build an AI governance programme - the operating model that wraps whichever platform path you choose.
• AI control plane vs AI gateway - the architectural lens that informs vendor shortlists.
• AI compliance checklist enterprise - the audit-evidence list that both build and buy paths must produce.
• AI governance ROI business case - the CFO-facing return calculation that complements the TCO table above.