Large Language Models: Adoption, Economics, Security and Governance

Summary

Large language models (LLMs) are now widely used in business settings, but the evidence on how widely, and with what results, is uneven. An aggregated survey summary estimates that 85 to 90 percent of large enterprises report at least one production LLM deployment ². Usage data point in a different direction: open-source models held 11 percent of enterprise LLM API usage, down from 19 percent a year earlier ¹, while open-weight models reached about 60 percent of token volume on one developer router ¹. Field experiments report productivity gains in software development and customer support ³⁴, but measurement is inconsistent across studies ⁵. Principal risks include prompt injection and insecure plugin design ⁸, unpredictable cost per task ¹⁰, and governance frameworks that remain voluntary in the United States ⁶. The outlook is for continued adoption with rising emphasis on cost control, security and measured results. Buyers should test vendor claims against their own workloads, because independently verified data on total cost, reliability and skills demand is limited.

Key findings

1. 1

   Enterprise adoption is high by one estimate, but the figure is an aggregate

   Aggregated survey averages suggest 85 to 90 percent of large enterprises report at least one production LLM deployment. The source is a secondary summary of several surveys, and the figure is an estimate, not an audited count.

   Confidence: Medium
2. 2

   Open-weight models are gaining developer traffic while enterprise API share of open-source models fell

   Open-source models held 11 percent of enterprise LLM API usage, down from 19 percent a year earlier. On one developer router, open-weight models carried about 60 percent of token volume. These measures cover different populations and should not be combined.

   Confidence: Medium
3. 3

   Controlled field experiments show measurable task gains for AI coding assistants

   Across three field experiments with 4,867 developers, an AI coding assistant was associated with a 26.08 percent increase in completed tasks, with a standard error of 10.3 percent. Less experienced developers gained more. Results are US-based and were observed in specific firms.

   Confidence: High
4. 4

   Price differences between LLM providers are very large for comparable tasks

   One vendor comparison reports that the same task can cost $0.04 per million tokens on one provider and $25.00 on another, a 625 times difference. The comparison is a vendor source using list prices, and it does not normalize for output quality.

   Confidence: Qualitative
5. 5

   Risk guidance in the United States is voluntary, and security risks are well documented

   The NIST AI Risk Management Framework is intended for voluntary use, and its Generative AI Profile lists more than 200 suggested actions across twelve risk categories. OWASP ranks prompt injection as the first critical risk for LLM applications.

   Confidence: High

1Industry definition and scope

This report covers large language models, meaning large neural models trained on extensive text corpora that generate, summarize or transform language. They are delivered through hosted application programming interfaces (APIs), through cloud platforms, through applications built on top of them, and, for open-weight models, through self-hosting. The scope is global, with regional and national data points identified in each citation. The reporting period is the latest available data in the source pack, and sources have different measurement dates, so cross-source comparisons are indicative only.

The sources use terms in different ways. S1 groups open-source and open-weight models together as a category, while the broader industry often separates models whose weights are released from models that meet a stricter open-source definition. This report uses open-weight where the source concerns downloadable weights and open-source only where the source uses that term. Segments covered include frontier proprietary model APIs, open-weight models, developer routers, coding assistants and customer support tools.

This is a descriptive industry report. It does not provide investment, legal, engineering or professional advice, and it does not rank vendors on quality.

Terms follow the wording used in each source. Where a source uses a term without defining it, this report notes the ambiguity rather than resolving it.

2Market size, structure and value chain

No independently verified global market size or revenue figure for LLMs is available in the source pack. Figures found in secondary blogs were excluded because they were not traceable to audited or regulator sources. Market growth rates are therefore not reported.

The value chain includes model developers, cloud and compute providers, API routers, application vendors, systems integrators and enterprise buyers. Revenue is commonly tied to token consumption. A FinOps vendor blog reports token costs from about $0.10 to $10 per million input tokens and up to $50 per million output tokens, and states that output tokens typically cost three to eight times more than input tokens for frontier models ⁹. A vendor comparison lists Claude Opus 4.6 at $5.00 per million input tokens and $25.00 per million output tokens ¹⁰. These are list prices, not realized spend.

Compute costs are a second layer. Only secondary websites were found for GPU rental, which reported a range of $2.85 to $3.50 per hour for an H100 . This figure is not verified against a provider price list and is not used in calculations.

Structure is shaped by usage share. Open-source models held 11 percent of enterprise LLM API usage in one survey-based measure ¹. Router data show open-weight models gaining developer traffic ¹. These measures do not show revenue shares, and the pack does not provide reliable concentration data for the market.

• Open-source share of enterprise LLM API usage 11percent Observed Enterprise, global survey sample, Latest survey period in the source [1]

List prices and survey shares are reported as published. They are not converted into market value because the pack contains no volume baseline.

3Customers, demand and adoption

Enterprise adoption is the most cited measure of demand, but its evidence base is mixed. An aggregated summary of several survey firms estimates that 85 to 90 percent of large enterprises report at least one production LLM deployment, with the lower bound of 85 percent used here ². The same summary estimates that coding workflows are the highest-penetration use case, at about 70 percent of large-enterprise engineering organizations ². These are estimates from secondary aggregation, and the original survey reports were not retrieved.

A broader measure from official statistics shows 19.95 percent of European Union enterprises using AI in the latest period, up 6.47 percentage points on the prior period. Adoption was 55 percent among large enterprises and 17 percent among small enterprises, a gap of 38 points ¹¹. This covers AI in general, not LLMs specifically, so it indicates the size gap in adoption but not LLM penetration.

Demand is supported by measured productivity effects in specific tasks. In a customer support field study of 5,179 agents, access to an AI assistant raised issues resolved per hour by 14 percent on average ⁴. In a preregistered experiment with 453 college-educated professionals, ChatGPT users took 40 percent less time on writing tasks, and their output was rated 18 percent higher for quality ⁴. The support study location is not stated, and the writing sample is not described as national.

Purchasing criteria are not documented in the pack. Cost per token, output quality and data handling are the most visible decision factors in the cited sources, but no survey of buyer criteria was retrieved. Adoption barriers are discussed in the security and governance sections, and the pack contains no verified data on the share of projects that stall.

• Enterprise AI adoption in the European Union, all AI 19.95percent of enterprises Observed European Union, Latest available year in the source [11]

The 85 percent figure is a lower bound from an estimated range and is not a verified count of deployments.

4Competitive landscape and key players

The pack identifies several provider types rather than a ranked set of companies. Frontier proprietary API providers sell access to closed models with usage-based pricing. Open-weight model publishers release weights that buyers can host themselves or access through third parties. Developer routers, such as OpenRouter, sit between applications and multiple models. Cloud platforms bundle model access with infrastructure. Application vendors, including coding assistants like GitHub Copilot, package models into workflows for specific user groups ⁵.

Market shares for named frontier providers are not verified in the pack. Secondary aggregators were the only sources found, and no company annual report or filing was retrieved. The competitive picture is therefore described by provider type and pricing behavior, not by share.

Pricing is one clear point of difference. A vendor comparison reports a 625 times price gap between providers for the same task, with the cheapest at $0.04 per million tokens and the most expensive at $25.00 ¹⁰. This is a vendor claim based on list prices, and it does not show whether the lower-priced output was of equal quality. Buyers should compare cost per completed task, not cost per token.

Open-weight models show a different pattern. Their share of enterprise API usage fell in the cited survey, while their share of router token volume rose to about 60 percent ¹. A plausible reading is that developers test open-weight models through routers while enterprises still concentrate on managed APIs. This is an interpretation, and the sources do not test it directly. Competitive pressure appears to come from price and model choice, but the pack does not quantify how switching costs affect vendor lock-in.

• Open-weight share of token volume on a developer router 60percent Observed Global, developer traffic, Mid-period in the latest data [1]

The competitive analysis is based on provider types and published pricing. Concentration measures are not available in the pack.

5Technology, operations and workforce

The most relevant measured effects concern coding assistants. In three field experiments with 4,867 developers at Microsoft, Accenture and an anonymous Fortune 100 company, an AI coding assistant was associated with a 26.08 percent increase in completed tasks, with a standard error of 10.3 percent ³. Less experienced developers had higher adoption rates and greater gains ³. A separate study covering 1,974 developers at Microsoft and Accenture reports that Accenture pull-request results were mixed, while Microsoft used pull requests as its main productivity measure ⁵. Task completion and code quality are therefore different outcomes, and the evidence does not yet settle the second.

Operational performance is poorly documented. The pack does not include verified uptime, latency or throughput figures for named LLM API providers, and no independent benchmark was found. Defect and hallucination rates in production were also not verified by an independent source. Buyers should not assume service levels from vendor pages.

Cost structure affects architecture. Because output tokens cost three to eight times more than input tokens for frontier models ⁹, designs that produce long responses can raise cost sharply. Self-hosting versus API total cost of ownership was not verified in the pack; only vendor and blog estimates were found.

Workforce data are limited. The pack contains no verified skills demand, talent supply or wage data for LLM roles. The evidence on experienced and less experienced workers ³ suggests that tools may shift the skills profile of software work, but this is an interpretation, not a measured labor market result.

• Change in completed tasks with an AI coding assistant 26.08percent increase Observed US-based field sites at Microsoft, Accenture and a Fortune 100 company, Field experiments in the latest reported period [3]

Productivity figures come from field experiments. Estimates of total cost and operational performance are excluded.

6Regulation, standards, risk and sustainability

In the United States, the NIST AI Risk Management Framework is intended for voluntary use to incorporate trustworthiness into the design, development, use and evaluation of AI systems ⁶. NIST AI 600-1, the Generative AI Profile, was released as a companion to the framework ⁶. Both are voluntary guidance, not binding rules. A concept note for a profile on trustworthy AI in critical infrastructure is a proposal, not a requirement ⁶. The Generative AI Profile provides more than 200 suggested actions across twelve risk categories ⁷.

NIST states that estimating unknown or speculative generative AI risks is challenging because of limited visibility into training data ⁷. This is a substantive gap for buyers, who often cannot inspect the data behind a model they license.

Security risk is documented in the OWASP Top 10 for LLM Applications, which ranks prompt injection as LLM01 ⁸. The project states that manipulating LLMs via crafted inputs can lead to unauthorized access, data breaches and compromised decision-making, and that plugins processing untrusted inputs with insufficient access control risk severe exploits such as remote code execution ⁸. OWASP provides risk categories, not incident counts, so the frequency of LLM security incidents is not known from the pack.

Binding obligations in other jurisdictions, including EU AI Act obligations and ISO/IEC standards for AI management, were not verified in this source pack and are not described here. Privacy rules, environmental reporting and energy use for LLM operation were not covered by any verified source, so these areas are not assessed.

Distinguish binding and voluntary requirements: the NIST materials are voluntary, and the OWASP list is an community risk ranking, not a legal requirement.

7Challenges, opportunities and case examples

The main constraints are cost variability, security exposure, and weak evidence on results. Price gaps of the scale reported in one vendor comparison ¹⁰ make budgeting difficult, and output-heavy designs add cost ⁹. Security risks from prompt injection and untrusted plugin inputs ⁸ mean that connecting models to sensitive systems requires controls beyond the model itself. Measurement is also difficult: the Accenture pull-request results were mixed ⁵, which shows that productivity claims depend on the metric chosen.

Opportunities are concentrated in tasks with measurable throughput. The customer support field study reports a 14 percent rise in issues resolved per hour ⁴, and the software experiments report increased completed tasks ³. The writing experiment reports faster work and higher rated quality ⁴. These results come from specific tasks and samples and should not be generalized to all work.

Case example one is the Microsoft and Accenture coding experiments, which covered 4,867 developers in one study ³ and 1,974 developers in another ⁵. The two studies show a clear average gain in completed tasks but mixed outcomes on pull requests, which underlines the need to define the outcome before buying.

Case example two is the customer support study of 5,179 agents, which showed a 14 percent gain in issues resolved per hour ⁴. The study location is not stated, so the result is not tied to a national market.

Case example three is OpenRouter, where open-weight models reached about 60 percent of token volume by mid-period ¹. The router shows developer demand for model choice, but it does not represent enterprise procurement.

Case examples are drawn only from sources in the pack. Comparable examples were limited, so the examples are described as specific studies rather than market-wide patterns.

8Outlook and strategic implications

In the near term, adoption is likely to continue in coding, support and writing tasks, where the pack shows the clearest measured gains ³⁴. Pricing pressure is likely to persist given the wide price range between providers ¹⁰. Open-weight models may keep gaining developer traffic ¹, while enterprise buyers may continue to favor managed services, but this is an interpretation based on two measures that the pack does not reconcile.

Medium-term uncertainty centers on evidence quality. Total cost of ownership, uptime, defect rates, breach incidence and skills demand are not verified in the pack . Until independent evidence is available, claims about cost savings or reliability should be treated as vendor or estimated figures.

Practical implications differ by stakeholder. Enterprise buyers should run pilots on their own tasks, measure cost per completed task, and apply voluntary frameworks such as NIST AI 600-1 as a structure for risk actions ⁶⁷. Vendors and integrators should design against prompt injection and untrusted plugin inputs ⁸. Policymakers and regulators should close the evidence gaps on incidents, cost and skills before setting binding rules. Workforce planners should track how tool use changes skills for less experienced developers ³.

Outlook statements are interpretations of cited evidence and are labeled as such.

9Conclusion

LLM adoption is broad, and measured productivity gains exist in coding and support tasks ²³⁴. The evidence on cost, reliability and security outcomes is far thinner than the adoption figures suggest. The most defensible takeaways are that buyers should measure outcomes on their own workloads, manage cost per completed task, and treat security as a design requirement ⁸.

How this was built

Sources

1. 1

   Open-Weight vs. Frontier AI Market Share

   Caged AI (citing Menlo Ventures and OpenRouter data) News report

   caged.ai
2. 2

   Enterprise LLM Adoption Statistics (aggregated summary)

   Presenc.ai (aggregating McKinsey, BCG, Gartner, Deloitte, IBM, KPMG surveys) Market research

   presenc.ai
3. 3

   The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers

   Cui, Demirer, Jaffe, Musolff, Peng, Salz (Management Science) Peer-reviewed

   pubsonline.informs.org
4. 4

   Experimental evidence on the productivity effects of generative AI (customer support agents)

   Summary of field experiments by Kemal Büyüktaş (citing Noy and Zhang, Science, and other field studies) News report

   kemalbuyuktas.com
5. 5

   The Productivity Effects of Generative AI: Evidence from a Field Experiment with GitHub Copilot

   MIT Generative AI project (Microsoft and Accenture field experiments) Peer-reviewed

   mit-genai.pubpub.org
6. 6

   Artificial Intelligence Risk Management Framework: Generative AI Profile (NIST AI 600-1) and AI RMF overview

   National Institute of Standards and Technology (NIST) Standard

   nist.gov
7. 7

   NIST AI 600-1 coverage of twelve generative AI risks

   TechPolicy.Press (summary of NIST AI 600-1) News report

   techpolicy.press
8. 8

   OWASP Top 10 for Large Language Model Applications

   OWASP GenAI Security Project Standard

   owasp.github.io
9. 9

   LLM Token Cost by Model: Pricing Data and Optimization Tips

   Finout (FinOps vendor blog) Vendor report

   finout.io
10. 10

    LLM API Pricing Comparison: 30+ Models, Every Provider

    Inference.net (vendor comparison) Vendor report

    inference.net
11. 11

    AI Adoption Index and Eurostat enterprise AI adoption figures (Global AI Adoption Index)

    Alice Labs (citing Eurostat, OECD and Statistics Canada data) Official statistics

    alicelabs.ai