Concepts / Enterprise Willingness to Adopt LLMs

Enterprise Willingness to Adopt LLMs

Enterprise willingness to adopt LLMs varies by use case, and the source notes that companies are more willing to deploy internal-facing applications.

  • Programming

Why Willingness Depends on the Use Case

When a company considers using a large language model, the question is rarely a simple yes or no. Enterprises differ in how willing they are to use LLMs, and that willingness depends heavily on which use case is being considered. A company may be eager to try an LLM for one kind of task and far more cautious about another.

This article follows one idea through a short chain of questions. First, how do we measure willingness at all? Second, what does a measured rate actually count? Third, which kinds of use cases tend to show greater willingness, and why is it still hard to know which use cases will matter next? Each step builds on the one before it.

Tracing a Use Case from Experiment to Production

Think of a single use case as moving along a path. It starts in experimentation, where an enterprise tries the LLM on a particular task. From that point, the use case either advances into production deployment or stops short of it. Experimentation and production deployment are distinct stages, and the measure that describes the movement between them is the deployment rate.

ExperimentingLLM tried on one taskReached productionDeployedStopped beforeproductionNot deployedadvancesdoes not advance
After an enterprise starts experimenting with a use case, does that use case reach production or stop short of it? The deployment rate measures the share that complete the advance.

The diagram is deliberately simple. Real projects may involve more steps, but the deployment rate only asks about the transition between these two points: did a use case that was being experimented with reach production?

Measuring the Deployment Rate

Definition

The deployment rate for a given use case is the percentage of enterprises experimenting with that use case who have deployed it to production. It is computed within that one use case.

Rule

Notice what the denominator is. The rate does not count every enterprise in the market. It counts only the enterprises already experimenting with a given use case. An enterprise that has never tried that use case is outside the calculation entirely. For this reason, the deployment rate is a measure of conversion: of the organizations that began exploring a use case, what fraction managed to move it into production?

What do you think happens?

Forty enterprises are experimenting with a document-summary use case, and 26 of them have deployed it to production. Before reading on, what is the deployment rate for this use case?

Reveal answer
Answer:

65%

Divide the 26 enterprises in production by the 40 enterprises experimenting: 26 divided by 40 is 0.65, which is 65% when expressed as a percentage.

Computing Rates for Two Use Cases

The example below is invented for practice and does not describe any real enterprise survey. Its purpose is to show that the rate is always computed within one use case. If a company runs several use cases, each one has its own experimenting group and its own deployment rate, and those rates can differ widely.

Worked example

Comparing deployment rates across two use cases

A hypothetical group of enterprises tracks two use cases. Use case A, an internal meeting-notes tool, has 40 enterprises experimenting and 26 in production. Use case B, a public-facing chat assistant, has 30 enterprises experimenting and 6 in production. Compute the deployment rate for each use case.

  1. 1
    Identify the group for use case A

    The denominator is the 40 enterprises experimenting with use case A. Only these enterprises are counted, regardless of how many enterprises exist in total.

  2. 2
    Compute the rate for use case A

    26 divided by 40 equals 0.65, so the deployment rate for use case A is 65%.

  3. 3
    Identify the group for use case B

    The denominator for use case B is the 30 enterprises experimenting with that use case. The 40 enterprises from use case A are not included.

  4. 4
    Compute the rate for use case B

    6 divided by 30 equals 0.20, so the deployment rate for use case B is 20%.

  5. 5
    Interpret the difference

    Both use cases started with experimentation, but a much larger share of use case A's experimenting group reached production. Each rate describes only its own use case.

Result

Use case A has a deployment rate of 65%, and use case B has a deployment rate of 20%. The two rates come from different experimenting groups and should be read separately.

Why Internal-Facing Applications Show Greater Willingness

The source states a clear pattern about willingness: companies are more willing to deploy internal-facing applications. An internal-facing application is one used inside the organization rather than by outside users. Willingness is not uniform across the landscape of LLM applications. Internal-facing applications sit at the more willing end, and this distinction is one of the core factors shaping enterprise adoption.

Internal-facingapplicationUsed inside theorganizationExternal-facingapplicationUsed by outside users
The two groups differ in who uses the application. The source associates internal-facing applications with greater company willingness to deploy them.

Why Future Use Cases Are Hard to Predict

Adoption is not only about measuring current use cases. The most important applications may not yet be visible. New and unexpected AI use cases continue to emerge, so current use cases are a snapshot rather than a complete forecast. The source describes repeatedly encountering new AI applications that surprise its author, even after reviewing hundreds of them.

For an enterprise planning adoption, this means that a list of today's use cases is not a reliable list of tomorrow's. Emerging use cases can change which applications matter most, so a company that evaluates only the use cases it already knows about may miss important opportunities. The source's closing hope, that the surprise will be a good one, reflects this open-ended view.

Mistakes When Reading Adoption Rates

  • Common mistake

    Using the total number of enterprises as the denominator of the deployment rate

    What it looks like

    Dividing 26 production deployments by 100 enterprises in a market, even though only 40 of them were experimenting with the use case.

    Why it fails

    The deployment rate counts only enterprises already experimenting with that use case. Enterprises that never tried the use case are outside the calculation.

    Do this instead

    Use the experimenting group for that specific use case as the denominator.

  • Common mistake

    Comparing deployment rates from different use cases as if they describe the same group

    What it looks like

    Concluding that a company is more successful overall because one use case shows 65% and another shows 20%, without noticing their experimenting groups differ.

    Why it fails

    Each rate is computed within one use case, so the rates describe separate groups of enterprises.

    Do this instead

    Read each rate on its own terms and note the use case it belongs to.

  • Common mistake

    Treating current use cases as a complete forecast of future adoption

    Why it fails

    New and unexpected use cases continue to emerge, so the current list is only a snapshot.

  • Common mistake

    Assuming all LLM applications have the same willingness to deploy

    Why it fails

    Willingness varies by use case, and the source associates internal-facing applications with greater willingness.

    Do this instead

    Check whether a use case is internal-facing or external-facing before drawing conclusions.

Testing Your Reading of a Deployment Rate

EASY

A team reports that 12 enterprises are experimenting with an internal knowledge-search use case, and 3 of them have moved it into production. Compute the deployment rate for this use case, and explain why the other enterprises in the market do not appear in your calculation.

Hints
  • Identify the experimenting group first. It is the denominator.
  • 3 divided by 12 gives a decimal you can convert to a percentage.
  • Enterprises that have not tried this use case are excluded from the group.

Summary of Key Ideas

  1. 1
    Enterprise willingness to adopt LLMs varies by use case, so a single yes-or-no answer does not describe adoption.
  2. 2
    The deployment rate is the share of enterprises experimenting with a given use case who have deployed it to production, computed within that use case.
  3. 3
    Internal-facing applications, used inside the organization, are associated with greater enterprise willingness to deploy than external-facing applications.
  4. 4
    Future use cases are hard to predict because new and unexpected applications keep emerging, so current use cases are a snapshot rather than a forecast.

At a glance

  • Enterprise willingness to adopt LLMs varies by use case, so adoption must be read use case by use case.
  • The deployment rate equals the enterprises that reached production divided by the enterprises experimenting with that same use case.
  • Internal-facing applications sit at the more willing end of the adoption picture, according to the source's pattern.
  • Current use cases are a snapshot, and new applications continue to emerge, so future use cases remain hard to predict.

More concepts starting with E