AI cost optimisation: govern spend, improve execution, prove value
Research cutoff: 9 October 2026, Europe/Berlin. Audience: Knauf Digital technology leadership. Format: 25-minute presentation plus 5 minutes for questions on 29 October. Status: internal preparation material; no Halbach proprietary mechanisms included.
Governing recommendation
Manage AI as a portfolio of business workloads: assign an owner and measurable outcome to each workload, make its full cost visible, and optimise execution subject to quality and service constraints.
Three supporting arguments structure the presentation:
- Accountability makes spending controllable. Budgeting requires demand assumptions, attribution and an agreed response when consumption exceeds expectations.
- Engineering choices determine unit economics. Workflow, model, runtime and deployment changes affect the cost of delivering a successful task, not merely the price of a token.
- Evidence determines whether to scale. Compare baseline and intervention at equivalent quality and service levels; distinguish capacity released, expenditure avoided and realised financial benefit.
These are recommendations derived from the research, not claims that Knauf currently lacks these capabilities.
Situation, complication, question, answer
Situation: AI appears in employee tools, APIs, data platforms and internally hosted systems, each with different purchasing and consumption models.
Complication: One invoice cannot explain which business activity created the cost, whether an agent’s extra steps were useful, or whether a cheaper model increased review effort. Lower unit prices can coexist with higher total expenditure.
Question: How can leadership enable useful adoption while keeping cost ownership, forecasts and benefits transparent?
Answer: Establish a common workload ledger, enforce proportionate operational limits, and evaluate optimisation using cost per accepted business outcome alongside quality and latency.
What the evidence supports
| Finding | Evidence | Appropriate interpretation |
|---|---|---|
| AI financial management has become a mainstream FinOps responsibility | State of FinOps 2026: 1,192 community respondents; 98% report managing AI spend S03 | Evidence about surveyed FinOps practitioners, not 98% of all enterprises |
| Adoption and individual productivity do not automatically become enterprise financial impact | McKinsey’s August 2026 survey reports 37% attributing positive EBIT impact to AI S24 | Self-reported attribution; no causal proof that AI increased EBIT |
| Serving configuration affects economically useful capacity | Sarathi-Serve and DistServe, OSDI 2024 S17 S18 | Mechanisms and measurement approach remain useful; old speedup factors are not comparisons with today’s runtimes |
| Verification and selective escalation are active research directions | OSCAR, submitted 1 October 2026 S20 | Task-specific benchmark evidence; suitable for an appendix, not an enterprise savings promise |
Read the pack in this order
| File | Purpose |
|---|---|
| 01_cost_anatomy.md [local reference omitted] | Cost drivers, forecast equations and financial distinctions |
| 02_governance_and_budgeting.md [local reference omitted] | Ownership, allocation, controls and management cadence |
| 03_monitoring_and_attribution.md [local reference omitted] | Telemetry architecture, token accounting and invoice reconciliation |
| 04_optimisation_landscape.md [local reference omitted] | Mechanisms, prerequisites, trade-offs and benchmark protocol |
| 05_deployment_and_market.md [local reference omitted] | API versus dedicated versus self-hosted economics and market categories |
| 06_roi_and_case_evidence.md [local reference omitted] | Empirical cases, a worked illustration and pilot design |
| 07_sources_and_october_updates.md [local reference omitted] | Annotated source register, dates, confidence and rejected claims |
| 08_presentation_storyline.md [local reference omitted] | Conclusion-first slide sequence, timings and questions |
| 09_provider_eligibility_tokens_and_tco.md [local reference omitted] | GDPR deployment eligibility, exact usage fields, comparison protocol and full lifecycle costs |
| 10_navigara_approach_and_gap_assessment.md [local reference omitted] | Navigara’s approach, useful workshop additions, numerical checks and remaining gaps |
| 11_navigara_public_page_inventory.md [local reference omitted] | Public-page coverage, access failures and source scope |
Comparison readiness as of 9 October
The pack provides a source-backed comparison method, not measured provider-by-provider task costs or a completed hardware TCO. The deployment break-even and document-processing figures are hypothetical. Missing inputs include representative task runs, acceptance/review results, approved configurations, contract/hardware quotes, usable throughput, utilisation and operating effort.
GDPR and DSGVO are the same regulation. Assess the specific service, contract and data flow before comparing eligible deployments at matched quality and service levels. Provider nationality or an EU storage label alone is insufficient. Chapter 09 documents the assessment boundaries and primary sources. Do not claim a universal GDPR premium or a measured local-versus-cloud winner.
Evidence discipline
Targeted additions after reviewing Navigara
Make provisioned employee-tool seats and induced compute costs explicit; link spend to a funded objective or operating mandate; allow bounded budget exceptions; and monitor review/release constraints after generation improves. Coding-tool telemetry must also reconcile with actual charges. These additions fit the existing slots and script; the five-minute Q&A remains protected. Navigara’s public material supplies management patterns, not the missing comparative task measurements or hardware TCO. See chapters 10 and 11 for the full assessment and coverage limits.
- Documented capability: official implementation documentation. It establishes behaviour, not independently measured savings.
- Empirical research: distinguish randomised experiments, observational studies and laboratory systems benchmarks.
- Survey: retain population, fieldwork dates and self-report limitations.
- Preprint: emerging evidence; no assumption of peer review or independent replication.
- Illustration: author-created numbers and calculations; never present as a customer result.
- Recommendation: our synthesis; identify it as judgment rather than a published finding.
October freshness means information available by the cutoff. Undated live documentation is not labelled an October publication. No later October announcements are included. Refresh price sheets and deployment capabilities before 29 October.
Relevance to Knauf Digital
Knauf Digital describes its mandate around commercial excellence, marketing, sales, service and customer-facing software across the construction value chain. S39 Use an illustrative technical product-information assistant as a running example: retrieve approved documents, generate a grounded answer, check it and escalate uncertain cases. This is a proposed teaching example, not a confirmed Knauf deployment.
Explain each optimisation through mechanism, conditions, evidence and decision. Connect engineering changes to resource effects and the action needed to realise financial benefit. Distinguish the levers available through a managed API from the additional execution controls and responsibilities of self-operated inference. Keep the workshop focused on the cost of operating AI.
Implications for Halbach
Lead with useful decisions and one approved, measurable engineering case. Describe delivered capabilities, pilots and research separately. Share public optimisation principles and evidence; reserve unpublished mechanisms, partner traces and implementation recipes for a separately scoped discussion.
The useful commercial outcome is an introduction to a workload owner and a bounded assessment with agreed baseline, access and success criteria. The session itself should leave attendees able to make better decisions even if they never engage Halbach.