Running AI Under Governance: An Operating Model for Engineering Organizations

Most AI adoption in engineering organizations is ad hoc. A few teams try a coding assistant, someone wires a language model into a product feature, and within a quarter there is real dependency with no policy behind it, no measured baseline, and no answer when your board asks what happens if the vendor triples the price. The fix is not to slow down. The fix is to run AI the way you run any other vendor risk: under a deliberate operating model, with a written policy, capped spend, measured outcomes, an exit ramp at every layer, and a gate where you stop if the numbers do not hold.

This is the model we deploy with engineering and product organizations. It is built to survive the questions a board, a partner, or an acquirer will actually ask, and it holds across both the product and the way the team builds software.

Three principles of AI governance#

Governance before tooling. Before a single seat is bought, there is an approved AI usage policy, a fixed list of approved tools (each under a data-protection agreement), a data classification that decides what each tool may touch, and an explicit list of prohibited uses. These are not just written rules. The controls are enforced automatically in the tools developers actually use, and an independent automated reviewer inspects every meaningful code change. A policy nobody enforces is theatre; a policy wired into the toolchain is a control.

AI assists, humans own. AI drafts, analyzes, verifies, and reviews under continuous human direction. The human engineer is the author of record on every change: they direct the work, review the result, sign it, and are accountable for it regardless of how much AI was involved. Nothing AI touches bypasses the same quality gates and reviews that human work passes. This is the sentence that answers most of the risk questions before they are asked.

Measured, gated adoption. Capture a baseline before scaling. Hold a 30-day checkpoint and a 90-day outcome gate, and give each gate explicit go or no-go criteria. Spending is capped before it is spent, both per person for development tools and per feature for the product, with automatic shut-offs on cost anomalies. If the measured outcomes do not hold, the program pauses. You scale what the evidence supports and drop what it does not.

In one sentence: run AI the way you run any vendor risk, with an exit ramp at every layer and a gate where you stop if the numbers do not hold.

What happens if the AI tools go away or get too expensive?#

This is usually the sharpest question a board leads with. The honest answer, if the system is designed correctly, is that nothing breaks: a sound design makes AI an accelerator, never a load-bearing wall. There are three layers, and each has its own exit ramp.

Figure 1: Every layer degrades to something the organization controls. No single AI dependency can take the product down.

The product keeps running. The core workflow is built to work without AI first, and to use AI only to fill in the gaps. If every AI service disappeared tomorrow, the product would keep serving customers; only the harder edge cases would fall back to the human reviewers who check the work anyway. Predictive and analytical features run on standard statistical models on your own infrastructure, with no dependency on any AI vendor at all.

Models can be swapped. All of the product’s AI runs through a single internal control point built on a model-neutral interface. Changing from one model to another, including to open-weight models that run on your own hardware, is a configuration change, not a rebuild. Deliberately avoid fine-tuning or building a proprietary model that would lock you to one vendor. There is no model held hostage anywhere.

Development tools affect speed, not the product. The AI tools engineers use affect how fast the team works, not whether the software runs. The code is ordinary, reviewed, tested code in your own repositories; none of it requires AI to maintain. If those tools were removed, the team returns to its previously measured pace, slower and with lighter review, but with no functional loss.

The cost story follows the same shape. Development tooling for a whole engineering team is a few hundred dollars a month, and stays under roughly a thousand a month even at full rollout; product AI features run under fixed monthly ceilings of a few hundred dollars each, with automatic shut-offs if spend spikes. Even a large vendor price increase leaves AI a small line item while the productivity it adds applies to the whole team. Price changes shift the economics gradually; they cannot create a sudden hole.

Should AI run in your cloud or the vendor’s?#

The cloud question answers itself once you make the data-sensitivity choice up front. Everything that touches customer data runs inside your own cloud account: the processing pipeline, any AI steps inside it, and any library of verified examples all stay within your own infrastructure. No customer data sits in an AI vendor’s cloud. The only thing that runs in a vendor’s cloud is developer tooling, which sees source code, never customer data, and is contractually barred from being trained on.

What makes that enforceable rather than aspirational is a data classification with four tiers, where each tier is routed only to the tools permitted for it.

Figure 2: Public and internal data can go to any approved tool. Customer-confidential data is restricted to contracted providers. Regulated data is handled by humans by default.

Customer data and any verified-examples library live in your own cloud and do not leave that account on the production path. Developer tools are restricted to the internal tier and never see customer data at all. Where confidential data would ever need to reach a tool not covered by an agreement, you strip identifying detail first, but the default is simply not to send it.

The model behind any product feature should be the output of an evaluation, not a default: benchmark candidates before you commit, commercial against open-weight, on your own accuracy and cost criteria, and pay for a hosted model only where measured quality or established user trust justifies it over a free open-weight one. Self-hosting your own models to cut cost is then a real option to keep open, not a step to take today: open-weight quality is closing the gap every quarter, and a model-neutral design makes switching cheap when the economics justify it. The point at which self-hosting beats pay-per-use is a computable break-even, worth running as a small study once volume approaches it rather than asserting either way. Re-evaluate it at each gate. Be positioned to move; choose not to move early at a loss.

How do you keep AI spend under control?#

Cost control runs on three mechanisms, all active from day one. Development tools are bought on per-person plans with known monthly costs. Each product AI feature has a fixed monthly budget, with alerts at 70, 90, and 100 percent and an automatic shut-off if daily spending spikes far above normal, for example past roughly five times the daily mean. And because the baseline was measured, you can see whether the spend is buying the productivity and quality you expect, at each gate, before committing to more.

This is what lets you answer the cost question without hand-waving. The spend is bounded structurally, not by good intentions, and every dollar is capped before it is spent.

How do you know AI adoption is working?#

The part that makes the whole model credible is that it is built to be cancelled. A disciplined program runs on a formal measurement spine: a captured pre-adoption baseline, a 30-day checkpoint, and a 90-day outcome review, each with go or no-go criteria.

Figure 3: The program earns its next phase at each gate, or it pauses. Nothing is pre-committed.

The strongest evidence that an eventual productivity number will be real is that the program is built to be cancelled at the gate if the gain does not materialize. A team that will not commit to a kill switch is telling you it does not intend to measure. When a board asks whether management is making sound, risk-based decisions about AI or chasing hype, this is the answer: a gated program with a written plan and a defined end date, fallbacks that work without AI, no vendor lock-in, a data classification that routes sensitive data only to contracted providers, a human approval step on every customer-affecting decision, automatic spending shut-offs, and a measured baseline so any claim of improvement is verifiable rather than asserted.

What is safe to share in AI due diligence?#

One question that comes up late but matters early: when a partner or acquirer does diligence on your AI posture, what do you show them? Decide it the same way you decide data classification. Some things are never shared externally: internal unit economics, per-person productivity data, vendor-internal configuration, and the specifics of security-sensitive code paths beyond the fact that senior human review is mandatory on them. Other things are safe to share and worth volunteering, because they are exactly what a diligent reviewer wants to see: the governance stack, the deterministic-fallback architecture, the gated program with its dates and criteria, the capped-spend posture, and the contractual no-training position on customer data. Share the posture and the controls, never the raw internals the controls protect.

Where this goes#

None of this slows a team down. It removes the failure modes that make AI adoption a liability: unbounded spend, silent vendor lock-in, sensitive data in the wrong place, and productivity claims nobody can verify. The result is an operating posture you can defend in front of any board, partner, customer, or acquirer, while still moving fast where the evidence supports it.

Part 2 turns from the boardroom to the codebase: how AI actually works inside engineering, why quoting a percentage of AI-written code is a vanity metric, the review gates that stay identical whether or not AI was involved, and an honest list of where AI has slowed teams down.

Red Black Tree helps engineering and product organizations adopt AI under governance: written policy, measured outcomes, capped spend, and a defensible quality posture. If you want the full operating model as a board-ready document, get in touch.

Frequently asked questions

What happens if AI vendors disappear or triple their prices?

Nothing breaks in a correctly designed system. The product core works without AI, models are swapped by configuration through a model-neutral interface, and developer tools affect speed, not whether the software runs. Each layer has its own exit ramp.

Should customer data run through an AI vendor's cloud?

No. Everything that touches customer data should run inside your own cloud account. Only developer tooling runs in a vendor cloud; it sees source code, never customer data, and is contractually barred from being trained on.

How do you keep AI spending under control?

Per-person plans for development tools, a fixed monthly budget per product AI feature with alerts at 70, 90, and 100 percent, and an automatic shut-off when daily spend spikes to roughly five times the daily mean.

What is a gated AI adoption program?

A program with a measured pre-adoption baseline, a 30-day checkpoint, and a 90-day outcome review, each with explicit go or no-go criteria. If the measured outcomes do not hold, the program pauses.