Build vs buy AI governance: where execution risk now sits

At a glance

What this is: This is a build-versus-buy analysis of AI governance that concludes in-house programmes often miss the runtime enforcement and audit evidence layers auditors now expect.

Why it matters: It matters because IAM, NHI, and AI governance teams increasingly need enforceable controls around model access, policy execution, and evidence generation, not just documentation.

By the numbers:

• Building AI governance in-house typically costs $800K to $1.2M annually and takes 12 to 18 months before producing audit-ready documentation.
• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.

👉 Read Openlayer's analysis of build versus buy AI governance

Context

AI governance becomes an execution problem when organisations move from policy writing to enforcement, evidence, and operational control. In practice, the hard part is not deciding what should be allowed. It is proving what ran, what was blocked, and what evidence exists for auditors when AI systems are already embedded in production.

For teams that also manage IAM, NHI, or agentic AI systems, this is the same governance pattern seen in secrets and privilege management: documentation without enforcement leaves a control gap. The article frames a build-versus-buy choice, but the deeper question is whether the programme can sustain continuous monitoring, versioned evaluation, and runtime policy enforcement without becoming a permanent engineering project.

Key questions

Q: What breaks when AI governance exists on paper but not in enforcement?

A: Policy-only governance fails when teams cannot technically restrict access, log decisions, or revoke permissions in the systems AI actually uses. That creates a false sense of control while data exposure, privilege creep, and untracked actions continue. Effective governance must be enforced through identity, access, and audit mechanisms, not only through policy documents.

Q: Why do AI governance programmes need lineage and audit evidence as much as monitoring?

A: Monitoring shows what a model is doing now, but lineage and audit evidence show why it was allowed to run in the first place. That matters when auditors ask which dataset, version, and approval gate produced the deployed artefact. Without those records, teams cannot prove provenance or reproduce the control decision later.

Q: What do security teams get wrong about secure-by-design AI governance?

A: They often treat secure-by-design as a policy label instead of an enforceable operating model. Real security requires least privilege, logging, data minimisation, and output controls that can be tested and audited. Without those controls, secure-by-design becomes a statement of intent rather than proof that the AI stays inside approved boundaries.

Q: How should organisations decide whether to build or buy AI governance controls?

A: Choose build when the organisation needs deep custom instrumentation, strict data residency, and has dedicated engineering capacity to own the system long term. Choose buy when audit deadlines are close, governance coverage is needed quickly, or enforcement must be delivered faster than an internal team can build it. Hybrid approaches often work best for large enterprises.

Technical breakdown

Model inventory and lineage tracking for AI governance

A usable AI governance stack starts with inventory and lineage. Inventory tells you which models are in production, what risk class they carry, and what evidence was used to approve them. Lineage links a deployed model back to the training run, dataset version, and evaluation gate that produced it. Without that chain, auditors cannot verify provenance, and security teams cannot prove which artefact actually made a decision.

Practical implication: require every production model to have an owned record, version history, and approval evidence before it is allowed to serve users.

Continuous monitoring, drift detection, and output enforcement

Governance is incomplete if it only checks a model before deployment. Continuous monitoring tracks output quality, confidence, fairness, and distribution drift after release, while runtime enforcement blocks unsafe outputs at the API boundary. That distinction matters because a model can pass evaluation at launch and fail later as usage shifts or data changes. Monitoring without blocking still leaves harmful outputs available to downstream systems.

Practical implication: pair post-deployment telemetry with hard enforcement rules so unsafe outputs are stopped, not merely logged.

Audit-ready evaluation pipelines and regulatory evidence

A mature governance process needs repeatable evaluation pipelines that generate structured pass/fail records, metric scores, and named failure modes. Those artefacts become the evidence auditors use to assess conformity, especially where regulations expect controls to be demonstrable rather than implied. Static policy documents are not enough if the actual tests, thresholds, and exceptions cannot be reproduced later.

Practical implication: version the tests, thresholds, and results together so compliance teams can recreate exactly what was approved.

Threat narrative

Attacker objective: The end state is not exfiltration but control failure, where AI decisions run with insufficient evidence, insufficient enforcement, and insufficient accountability.

1. Entry occurs when AI systems are introduced without a complete inventory, so no one can confirm which models are active or what evidence approved them.
2. Escalation happens when monitoring exists but output enforcement does not, allowing unsafe behaviour to continue beyond the policy layer.
3. Impact is regulatory and operational, with auditors facing incomplete evidence and downstream systems consuming outputs that were never blocked.

NHI Mgmt Group analysis

Policy documentation without runtime enforcement is not AI governance. The article correctly separates controls that look compliant on paper from controls that actually stop unsafe behaviour. That distinction matters because auditors and security teams increasingly care about evidence at the point of decision, not just after the fact. In identity terms, this is the same mistake made when access reviews exist but privileges remain standing. Practitioners should treat enforcement as the real control boundary.

AI governance debt is becoming a programme-level risk. Once model registries, evaluation pipelines, monitoring, and reporting live in separate layers, the organisation accumulates brittle dependencies that are expensive to maintain. That creates a governance debt problem similar to secrets sprawl or privilege sprawl in NHI programmes, where every exception increases long-term operational load. The named concept here is governance debt, and teams should budget for it explicitly before the control stack fragments.

Runtime evidence will matter more than policy intent under the EU AI Act. The article is right that documentation alone will not satisfy high-risk obligations if an organisation cannot show how controls were enforced in production. That is already the direction of travel in identity governance, where proof of control increasingly outranks policy language. Practitioners should expect audit requests to focus on logs, thresholds, and exception handling rather than policy PDFs.

Build-versus-buy is really a control ownership question. The deciding factor is not whether a vendor exists, but whether the organisation wants to own the engineering burden of keeping governance current as models, regulations, and use cases change. For security leaders, that parallels the choice between in-house NHI tooling and managed lifecycle controls. Practitioners should align ownership with the pace of change, not with procurement preference.

What this signals

AI governance programmes will increasingly be judged on enforcement depth, not policy volume. Teams that can only produce documentation will struggle to demonstrate control maturity once AI systems are embedded in user-facing and operational workflows. The practical shift is toward evidence that shows what was blocked, by which rule, and under which approved threshold.

Governance debt will look familiar to identity teams. As with NHI lifecycle failures, the cost compounds when inventories, approval logic, and exception handling are maintained in separate tools or spreadsheets. The programme signal is clear: centralise ownership early, or the control stack becomes expensive to reconcile later.

The boundary between AI governance and identity governance is tightening. When models, agents, and automation systems act in production, the questions become who or what is allowed to act, under which constraints, and how that action is revoked. Teams should align AI governance with identity, access, and lifecycle controls rather than treating it as a standalone documentation exercise.

For practitioners

• Define the governance boundary before buying or building Separate documentation, monitoring, and runtime enforcement into distinct requirements so teams can see whether the chosen approach actually blocks unsafe outputs at the API boundary.
• Require lineage for every production model Capture model version, training data provenance, deployment approval, and evaluation evidence in one record so auditors can trace each decision back to an approved artefact.
• Test enforcement, not just evaluation Validate that unsafe outputs are blocked in production conditions, not merely scored in pre-deployment tests, because a pass/fail report without blocking still leaves exposure.
• Plan for governance ownership as an operating model Assign named owners for model registry, monitoring thresholds, exception handling, and regulatory updates so the control stack does not collapse when one team changes priorities.

Key takeaways

• AI governance fails when organisations confuse policy documentation with runtime control.
• The cost of building in-house is driven as much by maintenance and evidence production as by initial engineering effort.
• Practitioners should choose build, buy, or hybrid based on enforcement needs, audit deadlines, and long-term control ownership.

Key terms

• Model Inventory: A central record of all models in use, including owners, purpose, risk tier, lifecycle state, and control history. Inventory is the starting point for governance because organisations cannot validate, monitor, or retire models they cannot reliably identify.
• Lineage Tracking: Lineage tracking records how a model or dataset was created, changed, and reused over time. It gives security, compliance, and engineering teams a defensible history of dependencies, which is essential when proving what was tested, approved, and deployed.
• Runtime Enforcement: Runtime enforcement is the practice of blocking malicious behaviour while software is running, rather than only detecting it after the fact. It monitors process activity, network actions, and privilege changes so a live attack can be interrupted at the point of execution.
• Governance Debt: The accumulation of unresolved identity control weaknesses created when teams prioritise speed over lifecycle design. In NHI environments, it shows up as accounts with unclear ownership, undocumented purpose, stale credentials, and no reliable retirement path, all of which make later security work harder.

What's in the full article

Openlayer's full research covers the operational detail this post intentionally leaves for the source:

• Implementation cost breakdowns for internal build programmes, including staffing, tooling, and legal review assumptions.
• Vendor evaluation criteria for deciding whether a governance platform actually enforces policy at runtime or only documents it.
• The article's fuller decision matrix for regulated organisations, including where hybrid build-buy models fit best.
• The practical trade-offs around data privacy, integration depth, and compliance gap coverage that are only summarised here.

👉 Openlayer's full article covers cost drivers, control boundaries, and the decision matrix in more depth.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and the control decisions security teams need to manage non-human access. It is designed for practitioners who need a shared governance language across identity, AI, and adjacent security programmes.