AI cost governance: measure the work, choose the intervention
Research date: 22 October 2026. Audience: Knauf Digital technology leadership. Session: 29 October 2026, 14:30–15:00, with 20–25 minutes of prepared content. Authors’ use: evidence and decision material for Geoffrey Kasenbacher and Tebjan Halm, not a statement about Knauf’s internal systems or economics.
Recommendation for the talk
Give leaders a practical answer to “Which AI costs deserve our engineering attention?” The preceding Venture Studio session already addresses proving value; the following Momentum session promises a concrete 90% reduction case. Halbach’s distinctive contribution is to show how the technical choices create costs and how to choose the next optimisation without harming the work delivered.
The governance portion needs about three minutes in the middle and two minutes at the end. It should establish one business unit, an owner, and an intervention rule; detailed process belongs in the leave-behind. Geoffrey can explain why cost per accepted outcome differs from cost per token. Tebjan can explain what a run actually does—model calls, retries, retrieval and tools—and why the runtime must have limits. End together with a 30-day pilot proposal.
Main message (our synthesis): optimise the cost of producing a useful, accepted result, subject to quality and service constraints. A cheaper token is an input-price improvement. Whether it improves the business depends on how much work, review and rework it buys.
1. Separate documented facts, interpretation and examples
- Documented: FinOps describes outcome-oriented unit economics; its allocation guidance permits explicit central funding for some shared costs. Its optimisation guidance weighs financial impact against engineering effort and operational risk. G03, G04, G14
- Our analysis: the three views, formulas, pilot sequence, thresholds and decision rules below adapt those ideas into a leadership decision tool. They are proposals, not a FinOps certification requirement.
- Illustrative only: every euro amount, workload count, hypothetical product-data example and threshold below. There is no verified Knauf usage, contract, staffing, budget or savings dataset in this workstream.
2. Three views are needed because they answer different questions
| View | Question | Typical data | Decision it supports |
|---|---|---|---|
| Financial ledger | What did we buy, accrue, commit to and actually pay? | Invoices, effective cost, credits, commitments, SaaS seats, vendor contracts | Budget, cash, renewal, supplier and funding decisions |
| Technical execution | What made the workload expensive? | Model/version, cache class, tokens, tools, runtime, retries, concurrency, idle capacity | Prompt/workflow/model/infrastructure changes and incident controls |
| Business delivery | What accepted work or service did the spend produce? | Stable task ID, acceptance rubric, reviewer effort, rework, latency, adoption, outcome | Scale, optimise, redesign, pause or stop |
Our analysis: a single dashboard cannot manufacture the missing join between these views. Create a stable use-case ID and task/run ID at the point of execution, and propagate them through child calls. Keep invoice reconciliation separate from provisional runtime cost estimates. A sampled trace can explain behavior while being incomplete for accounting; use complete usage counters or reconciled billing for totals.
Anthropic’s documented reporting APIs illustrate available model, workspace, API-key, cache and tool dimensions; its Enterprise SaaS and Console APIs differ. Usage and Cost API, G09. OpenTelemetry offers conventions for client and agent spans, but these documents are still marked Development. Client spans, G11, agent spans, G12
Implementation implication (our analysis): preserve a small stable internal data contract and version its adapter to provider/telemetry conventions. Cost attribution needs IDs and quantities; recording every prompt is unnecessary for this goal and can make retention and access management harder.
3. Define the business denominator before comparing models
For a bounded workflow and time period, calculate:
cost per accepted outcome = (AI service + other variable execution + attributable review/rework + allocated run costs) / accepted outcomes
For a lifecycle investment decision, add build, evaluation, integration, change management and ongoing maintenance costs over an explicit evaluation horizon. Do not silently mix that fully loaded figure with a marginal run-cost measure. Show both when the decision needs both.
A product-data workflow might use cost per product record that passes the agreed validation and review criteria. A support workflow might use cost per resolved case without reopening within the agreed period. These are plausible industrial examples, not confirmed Knauf use cases. An agent step, an answered prompt or a generated record is an intermediate output unless the business accepts it as the relevant outcome.
Measurement choices (our analysis):
- Freeze acceptance criteria before the comparison. Do not let a cheaper variant lower its own success definition.
- Compare like workload mixes: language, document complexity, record length, risk and exception class. Report subgroup quality where errors have different consequences.
- Include all attempts, failures and retries in cost; deduplicate accepted outcomes by task ID. A second attempt is not a second business result.
- Record review/rework effort and escalations, not only API success. A valid JSON response can still be wrong.
- Report latency and tail run cost alongside the average. Averages can hide expensive exceptions and loops.
- Leave missing outcome labels explicit. Unknown outcomes are not successes. A small pilot may require sampled human adjudication and confidence intervals rather than a precise-looking ROI point estimate.
The FinOps Unit Economics page explicitly distinguishes resource and business measures. G03
A compact example worth speaking aloud
Entirely illustrative; fixed 1,000-task evaluation cohort; costs include failed attempts.
| Current workflow | Candidate with cheaper model | |
|---|---|---|
| Model/API cost | €900 | €450 |
| Review and rework | €1,000 | €1,600 |
| Other run costs | €100 | €100 |
| Total cohort cost | €2,000 | €2,150 |
| Accepted outcomes | 900 | 850 |
| Cost per accepted outcome | €2.22 | €2.53 |
The model bill halves while cost per accepted outcome increases about 14%. The alternative also delivers fewer accepted results. This is an arithmetic demonstration, not a forecast that cheaper models will behave this way. A well-chosen smaller model can lower cost while preserving quality; that is precisely what a representative evaluation should establish.
4. Assign decisions to people who can change the result
Recommended operating design (our analysis):
| Accountable role | Owns | Weekly decision |
|---|---|---|
| Business/product owner | Accepted outcome, adoption and value hypothesis | Is the workflow useful enough to continue or scale? |
| Engineering/service owner | Execution design, reliability, controls and optimisation changes | Which intervention improves unit economics inside quality/latency constraints? |
| Finance / FinOps partner | Cost completeness, allocation policy, forecast, benefit classification | Are numbers comparable and is the claimed benefit realisable? |
| Platform / IT procurement owner | Shared services, vendor commitments and SaaS/licence inventory | Which spend can be consolidated, reduced or renegotiated? |
| Leadership sponsor | Funding envelope and unresolved tradeoffs | Scale, optimise, redesign, pause or stop? |
One named service owner should receive each anomaly and have authority to act; a shared mailbox is not an owner. Existing portfolio/finance forums may be sufficient. The FinOps source recommends ownership and incremental funding; a new council is a possible governance pattern, not a prerequisite. Practice operations, G02
Direct, shared and sunk costs need different treatment
- Direct API usage can be mapped to a use case when request metadata exists. Shared platform costs may need a documented proxy, a fixed allocation or deliberate central funding. Allocation, G04
- Our analysis: show shared platform costs separately so unit-cost improvement cannot be manufactured by moving an item into the central budget. Use the same allocation policy in baseline and variant.
- Our analysis: allocated cost is not automatically avoidable cost. Lower usage of a prepaid commitment may create idle committed capacity rather than immediate cash savings. Already incurred build cost is relevant to historical ROI but should not by itself justify continuing a poor workflow.
- FOCUS Effective Cost includes recognised portions of covering purchases and applicable price adjustments; it can differ from Billed Cost. G05
FOCUS helps normalise financial records; it does not provide task acceptance or business value. Its Consumed Unit is provider-specified, so common schema fields do not imply token equivalence. G06. Version 1.4 was available at the default specification link when researched; provider support must be checked. G15
5. Budget approval and runtime protection serve different purposes
A monthly financial budget expresses what leaders authorise and expect. A runtime control decides whether the next call, tool or child agent can run.
Azure Cost Management budgets do not stop consumption; the documented cost-data and evaluation delays mean alerts are retrospective. G07. AWS Budgets also documents billing/notification delay and possible threshold overshoot, while supporting optional actions. G08
Recommended control layers (our analysis):
| Layer | Control | Action and owner |
|---|---|---|
| Experiment envelope | Funding amount, expiry, named owner, review date | Sponsor renews only after learning/quality evidence |
| Use case / team | Rolling spend forecast and anomaly detection | Service owner explains growth and changes limits or workflow |
| Task / agent run | Maximum steps/retries, wall-clock timeout, token/spend envelope, child concurrency | Runtime queues, degrades, escalates or cancels according to agreed service policy |
| Expensive tool / fan-out | Per-operation allowance and maximum child jobs | Orchestrator checks before creating additional work |
| Production continuity | Criticality tier and tested fallback | Service owner prevents an indiscriminate cap from causing a larger outage cost |
Do not describe any software budget as a mathematically exact cap without testing in-flight requests, retries, parallel workers, external tool fees and delayed usage reports. Anthropic’s own SDK documentation describes post-response checks and possible overshoot, including concurrent subagents. Agent loop, G10
Practical takeaway: test the limit under an intentionally looping task and concurrent load before increasing autonomy. Limit policy belongs in runtime code/configuration; a natural-language instruction asking the agent to be economical is insufficient as the only spending control. This is our engineering recommendation.
6. Discover the full spend perimeter without promising perfect visibility
Recommended reconciliation (our analysis): compare cloud/API invoices, procurement and accounts-payable records, expense claims, SaaS contracts, licence inventories and known service identities. Ask teams which tools deliver useful work before removing them. Record unknown/unowned spend as an explicit category and resolve the largest items first.
Network discovery can add clues: Microsoft documents catalog-based detection of generative AI applications. Shadow AI discovery, G13. Our analysis: traffic does not reveal the invoice, contract, actual adoption value or every device. Discovery complements financial records and service ownership. It is not proof of complete spend capture, and no evidence here establishes shadow AI use at Knauf.
7. Optimisation is itself an investment
Our decision rule: first reject options that fail essential quality, latency, availability or operating constraints. Then rank feasible options by conservative net benefit, time to benefit, engineering effort, reversibility and evidence strength. For uncertain benefits, fund a small measurement experiment instead of a large migration.
net benefit over horizon H = avoidable run-cost reduction at matched workload + validated additional business benefit − implementation/evaluation/migration cost − added operation cost − transition/risk allowance
simple payback months = one-time change cost / monthly net avoidable cost reduction
Payback only applies when the denominator is positive; it is a screening tool, not a discounted investment valuation. Keep speculative revenue benefits separate from evidenced run-cost effects. FinOps explicitly recommends weighing savings and avoidance against labor, risk and disruption. Usage Optimization, G14
Illustrative: a €12,000 engineering/evaluation change saving €1,500/month after added operations takes eight months to pay back before discounting and risk. If the workload will be replaced in six months, the intervention cannot recover its cost on those assumptions. A €300/month bill has an absolute annual run-cost savings ceiling of €3,600 before effort—even eliminating it entirely cannot justify unlimited optimisation work. These are arithmetic bounds, not Knauf estimates.
What action follows from the data?
| Observed pattern | Likely next decision, subject to investigation |
|---|---|
| Spend grows; accepted outcomes grow faster; quality holds | Consider scaling within the funding envelope; rising total spend can be healthy |
| Spend grows; accepted outcomes and adoption stay flat | Inspect repeated work, context, retries, unused capacity and workflow design |
| Cost per accepted outcome improves; tail latency/errors worsen | Reassess the tradeoff before rollout; the average is insufficient |
| Low spend; high uncertainty; useful learning | Keep a bounded experiment and defer complex optimisation |
| Material recurring spend; known avoidable waste; easy rollback | Implement the reversible intervention with measured before/after evidence |
| High rework or failure cost; weak acceptance | Improve quality or redesign the workflow before shopping only for cheaper tokens |
| No owner, no useful outcomes, repeated failed evidence gates | Pause or stop; optimisation cannot create a business need |
These are hypotheses and actions to test, not a diagnostic claim from a bill alone.
8. Keep savings claims honest
Recommended reporting policy (our analysis; finance must approve internal accounting):
| Benefit class | Evidence | Do not claim |
|---|---|---|
| Realised cash reduction | Lower paid/contracted outflow, net of transition and replacement costs | An idle prepaid reservation is immediate cash saved |
| Consumption efficiency | Lower matched-workload cost per accepted outcome at comparable quality | The total invoice must fall when volume grows |
| Cost avoidance | Explicit counterfactual of future demand and rates, with assumptions | An avoided forecast is realised historical cash |
| Capacity released | Review/engineering time freed with observed effort change | Every minute saved reduces payroll or becomes revenue |
| Quality/service gain | Better accepted throughput, error rate or latency with measured business relevance | More tokens or completions is automatically business value |
Decompose spend change into workload volume, work mix, unit usage, model/rate mix and fixed/shared effects. Compare the same periods, FX policy and cost scope. Freeze a baseline before the intervention. Do not add overlapping savings percentages: shortening prompts can reduce the volume to which a subsequent price discount applies.
9. A realistic 30-day pilot
This is a recommended sequence, not a promise that every enterprise can instrument an end-to-end workflow in one month.
| Days | Accountable | Deliverable and decision gate |
|---|---|---|
| 1–5 | Sponsor + product + engineering + finance | Choose one meaningful recurring workflow. Define acceptance, service constraints, workload strata, owner, funding envelope and baseline. Explicitly exclude uncertain benefit claims. |
| 6–10 | Engineering with FinOps | Join usage/billing to stable use-case/run IDs; capture review effort and outcome labels. Reconcile major cost items. Investigate unexplained gaps before presenting ROI. |
| 11–15 | Engineering + product | Run a representative baseline; identify dominant drivers and expensive exceptions; rank two or three feasible interventions by conservative value versus effort. |
| 16–23 | Engineering/service owner | Test one or two reversible changes against the baseline; evaluate quality and cost together. Test overspend controls and rollback under failure/concurrency. |
| 24–30 | Sponsor with product/finance/engineering | Decide scale, optimise further, redesign, hold for evidence, or stop. Document realised/avoided/capacity benefits separately, residual uncertainty, next owner and review date. |
Success at day 30: one defensible investment decision, with a repeatable measurement method. A lower invoice is one possible result. A justified decision to spend more on a valuable workflow, or to stop a weak one, can be equally useful.
Source and artifact navigation
- Primary-source register [local reference omitted] and source cards [local reference omitted].
- Measurement schema: field definitions, formulas, owners and caveats.
- Decision record template: reviewable evidence, economics, intervention and pilot decisions.
- No Knauf internal cost or performance data was accessed or inferred in this workstream. Recheck provider controls, documentation versions and pricing before final slides on 29 October.