Why Trust, Not Cost, Is the Biggest Barrier to Machine Learning in FinOps
A survey of twenty-eight FinOps practitioners reveals that the leading obstacle to Machine Learning adoption is subjective, not technical, and that leaders and engineers see the problem differently.
By Sima Niaztalkhouncheh · MSc Data Analytics, BSBI / UCA · Supervised by Dr. Anuj Batta
Machine Learning has been available to FinOps practitioners for years. The algorithms are mature, the tooling is accessible, and the case studies exist. Yet adoption remains selective, cautious, and in many organisations, deferred indefinitely. The obvious explanation is cost: ML is expensive to implement, and finance teams resist expensive experiments. The obvious explanation is wrong. A recent mixed-method study of twenty-eight FinOps practitioners in Hybrid-IT environments identifies lack of trust in automated outputs as the leading barrier to Machine Learning adoption, marginally ahead of cost, organisational resistance, and data quality. Those three further barriers cluster together at almost identical frequencies. The barrier landscape is neither cost-dominated nor cost-neutral. It is trust-led.
The finding: a trust-led cluster
The study asked practitioners to identify the principal barriers preventing their organisation from adopting automated, ML-driven FinOps techniques. Lack of trust in automated outputs was reported by thirty-eight per cent of respondents. Three further barriers, cost of implementation, organisational resistance or culture, and data quality and consistency issues, were each reported by thirty-five per cent. Together, these four barriers accounted for the substantial majority of practitioner-reported obstacles.
The narrow lead held by trust is not statistically decisive on its own. What is analytically significant is the shape of the distribution. No single barrier dominates, but the barrier that comes closest is subjective, not financial or technical. Adoption is not principally gated by budget approval, engineering skill, or data readiness. It is gated by whether decision-makers trust the outputs of a system they did not build and cannot fully audit.
What senior practitioners say
The interview phase of the study surfaced convergent and divergent perspectives on the trust barrier. Two senior interviewees, Beau Nelford, an architect of the FOCUS specification at the FinOps Foundation, and Victor Garcia, editor of FinOps Weekly, were asked the same question: which of the leading barriers is hardest to shift? Their answers diverged in a way that matters.
Victor answered directly. Trust is the hardest, because it is subjective. Cost and data quality are, in his framing, objective and therefore addressable. Trust is neither.
“Trust is the hardest to shift because it’s subjective. Cost and data quality are objective, you can measure them, you can improve them. Trust either exists or it doesn’t.”
Victor Garcia, FinOps Weekly
Beau took a different view. His experience with organisations attempting FOCUS-aligned automation pointed to a different limiting factor: the knowledge cost of implementation. The hours a non-technical team member must invest to understand what an automated system is doing, in his framing, dwarf the sticker cost of the tooling itself. Trust and data quality, in his view, are consequences of implementation quality, not independent barriers.
The two positions are not contradictory in a naive sense. Both practitioners agree that adoption is impeded by more than budget. Where they differ is which barrier receives the highest priority in an intervention strategy. Rob Martin, the FinOps Foundation’s VP of Member Strategy and Education, subsequently offered a reconciling perspective when asked to comment on the survey finding.
“I’m not surprised by those results. I think it depends really on who you’re talking to. Leaders usually don’t worry about cost as much as they do about trust. Finance people also worry more about trust. But at the engineering and product level, the cost of implementation is what dominates.”
Rob Martin, VP Member Strategy & Education, FinOps Foundation
Rob’s segmentation resolves the apparent disagreement between Beau and Victor. The dominant barrier is not fixed. It is role-dependent. Senior leaders and finance functions see the trust deficit first. Engineers see the implementation cost first. Both perspectives are correct within their operational context, and both must be addressed by any serious adoption programme.
Why trust is different from technical accuracy
The most theoretically significant contribution of the interview phase was a convergence between two participants who had no prior communication. Engineer Ahmadi, working in the EPC sector in the Middle East, and Erik Norman, a FOCP-certified CEO based in Belgium, independently articulated the same principle when asked about ML in cost allocation: cost allocation is fundamentally a financial decision, not a technical one. Practitioners do not delegate financial authority to automation, regardless of the underlying accuracy of the model.
“I can’t trust a machine to decide where money is allocated. That’s a financial decision. The machine can support it, but not make it.”
Engineer Ahmadi, EPC sector practitioner
The implication for the trust barrier is significant. Trust in ML for cost allocation is not simply a function of model performance. Even a perfectly accurate model does not resolve the trust deficit, because the objection is structural, not statistical. Cost allocation is a governance activity that belongs to finance, and finance functions do not delegate governance responsibilities to non-deterministic systems, regardless of how those systems perform on out-of-sample validation data.
This has direct implications for how ML should be deployed in FinOps contexts. A human-in-the-loop architecture, in which ML supports allocation recommendations that finance functions review and approve, is not a compromise imposed by trust deficits. It is the correct governance model for a domain where allocation authority remains with finance by design. The trust barrier is not something to be overcome by better models. It is a constraint to be respected in system design.
The data quality finding, a complementary barrier
The survey also examined the relationship between data quality and ML adoption directly. Two separate questions asked practitioners whether their organisation uses ML for cost management and whether they consider their data quality sufficient for ML. Among the thirteen respondents who reported active ML use, only one, eight per cent, reported insufficient data quality. Among the six explicit non-users, one third reported insufficient data quality. The pattern is consistent with self-selection. Organisations with weak data foundations do not attempt ML deployment. They defer it until foundations are stronger.
This complements the trust finding rather than displacing it. Data quality is a technical precondition for ML adoption. Trust is a governance precondition. Both must be present. Organisations that address only the technical precondition, investing in data pipelines while neglecting the governance conversation about who decides what, will find their ML investments blocked at the point of operational deployment. Organisations that address only the governance precondition will find themselves unable to deploy anything meaningful because their data foundations do not support it.
What this means for FinOps teams
Three practical implications follow from the combined survey and interview evidence.
First, ML adoption interventions must be diagnostic before they are prescriptive. Because the dominant barrier is role-dependent, a one-size-fits-all approach, whether it addresses trust, cost, or data quality, will succeed with some stakeholders and fail with others. Adoption programmes should begin by assessing which barrier is most binding within a specific organisation, and target interventions accordingly. A budget-led programme in an organisation where leaders are trust-constrained will not deliver adoption.
Second, human-in-the-loop is not a limitation. It is the architecture. The cross-cultural convergence between an EPC engineer and a European CEO on the framing of cost allocation as a financial decision is empirically robust. FinOps teams designing ML-supported systems should treat human decision authority as a permanent design constraint, not a transitional one. This is a shift from the framing sometimes present in vendor material, in which ML is positioned as replacing manual decision-making. In FinOps, ML supports decision-making. Ownership of the decision itself remains with finance.
Third, transparency is the trust currency. The interviewed practitioners did not describe an appetite for ML systems whose outputs cannot be explained. If ML is to be adopted at scale in FinOps, the systems that deliver it must be designed for auditability from the beginning, not retrofitted with explainability layers once trust deficits emerge. Trust is not a downstream problem to be solved through communication. It is an upstream problem to be solved through architecture.
The broader picture
The trust-led barrier cluster identified in this research reframes a debate that has, in much of the vendor-produced literature, been reduced to a discussion of cost. Cost matters. Data quality matters. Organisational culture matters. But the finding of this study is that trust matters more than any of these individually, and that the specific character of the trust deficit is structural, not statistical.
For FinOps practitioners already operating ML systems, the finding is a challenge. How transparent, auditable, and human-authorised are the systems you have deployed? For practitioners planning adoption, the finding is a caution. Budget approval is the beginning, not the end, of the adoption conversation. And for the FinOps Foundation and its Ambassadors, the finding is an opportunity. The trust barrier is not a permanent constraint. It is a design problem, and one that a mature community can address.
Trust is not the hardest problem in FinOps because it is subjective. It is the hardest because we have not yet designed for it.
About this research
This article summarises one finding from Sima Niaztalkhouncheh’s MSc dissertation, “Developing a Data-Driven FinOps Framework for Automated Cloud Cost Allocation and Variance Analysis in Hybrid-IT Environments using Machine Learning”, supervised by Dr. Anuj Batta and submitted at BSBI (Berlin School of Business and Innovation) in partnership with the University for the Creative Arts (UCA) in July 2026. The empirical work comprised a Machine Learning experiment on FOCUS-aligned Hybrid-IT data, an online survey of twenty-eight FinOps practitioners, and five semi-structured interviews with senior practitioners and standard-setters.
