Stop Asking “Where Can We Use AI?”

One of the questions I encounter frequently in conversations about artificial intelligence (AI) is deceptively simple: what exactly do we mean when we call something an “AI use case”? The term is now used to describe an unusually broad range of activities. An employee using Gemini to summarize an email may be described as an AI use case. So might a developer using AI to build an application, a system using Optical Character Recognition (OCR) to extract information from engineering documents, an analytical tool using AI to interpret operational data, or an agent coordinating several steps of a business process. All of these descriptions can be reasonable, but they refer to meaningfully different roles for AI. Treating them as though they are interchangeable makes it harder to understand what capability is actually being expressed, what infrastructure it depends on, what risks it introduces, and what kind of organizational support it requires.

I have found it more useful to think of an AI use case as a bounded place in individual work, system development, analysis, or a business process where AI contributes a useful cognitive, perceptual, interpretive, generative, analytical, or inferential capability. The word bounded matters because AI does not need to operate an entire process for that process to contain an AI use case. A largely deterministic workflow can contain a probabilistic AI component. AI can perform one narrow interpretive function inside a conventional software system. It can also help someone understand, design, prototype, test, or build a system without appearing anywhere in the finished production runtime. In other words, the presence of AI in the final application is not the only way AI can materially contribute to the business.

There is also a layer underneath many AI use cases that is easy to overlook: readiness. Organizations often begin with an idea for an AI capability and discover that the immediate obstacle is not the model at all. The necessary data may be inaccessible, identifiers may be inconsistent across systems, important information may be trapped in spreadsheets or email, integration pathways may not exist, business processes may vary between teams, or nobody may be entirely certain which system is authoritative. A team may want AI to analyze customer issues, for example, only to discover that customer and product identifiers do not reliably align across the systems containing the relevant information. At that point, the primary problem is data quality and integration rather than AI.

This distinction matters because AI initiatives can expose common infrastructure requirements that are otherwise easy to miss. Several apparently unrelated use cases may depend on the same data source, API, permissions model, integration pathway, or system of record. Viewed individually, they appear to be separate AI projects. Viewed as a portfolio, they may reveal a shared architectural problem that should be addressed once, rather than repeatedly worked around. AI-use-case discovery is therefore useful even when it concludes that AI is not yet the thing an organization needs. Sometimes the most important finding is that the immediate constraint is information, process, access, and/or infrastructure.

The most familiar role for AI is as a personal cognitive tool. In this form, AI assists an individual with work such as summarization, drafting, research, brainstorming, planning, critique, translation, meeting synthesis, or email. The human remains responsible for the work and for the final judgment, while the AI reduces some of the effort required to understand information or produce an initial result. A project manager might use an AI assistant to summarize meeting notes, identify unresolved decisions, and prepare a draft status update. The value is straightforward: AI helps the person work with information more efficiently. This is also where much of organizational AI adoption begins because employees can experiment with the technology without redesigning an entire business process.

A second and somewhat different use of AI is as a development tool. In this case, AI helps people understand, design, prototype, code, test, document, or otherwise create a business capability. The resulting application may contain very little AI, or none at all. Someone who understands a repetitive operational process may historically have needed substantial development support to turn that knowledge into working software. AI can help translate the process into requirements, trace the flow of information, prototype an interface, generate code, test behavior, and document how the resulting system is intended to work. The production application can then perform most of its business logic deterministically.

This has been one of the most important ways I have used AI in my own work. The pattern often begins with an operational problem and moves through process understanding, data-flow discovery, requirements development, AI-assisted prototyping, validation, and finally an operational tool. What AI changes is not necessarily the production runtime. It changes the distance between understanding a problem and being able to make that understanding concrete. A prototype can make process logic, intended behavior, data relationships, and user experience visible much earlier than a traditional requirements document alone. Enterprise technology teams can then focus on the work they are uniquely positioned to do: architecture, integration, security, lifecycle management, support, and productionization. In this kind of use case, AI helps build the system rather than becoming the system.

A third role appears when AI performs a bounded function inside a larger runtime process. Some problems are difficult to solve cleanly with deterministic rules because the inputs themselves are heterogeneous or ambiguous. Documents, images, email, free text, and inconsistent layouts are common examples. AI can be useful for OCR, metadata extraction, classification, semantic matching, normalization, or interpretation of these kinds of inputs. The result does not need to be treated as authoritative simply because AI generated it. A process can allow AI to produce candidate structured information and then pass that information into deterministic validation and business logic. The AI handles the part of the problem that requires probabilistic inference; the surrounding system controls what is permitted to happen with the result.

That pattern is important because it avoids an unnecessary choice between probabilistic and deterministic computing. They are good at different things. If AI is better at interpreting an irregular document, it can perform that function without also being given authority over the business consequences of its interpretation. A model can extract a part number without being allowed to modify the system of record. It can classify a document without being allowed to approve it. It can propose a normalized value while deterministic rules determine whether the value is valid. The useful architectural question is therefore not whether a process should be “AI-driven” or “deterministic,” but which parts of the process are appropriately handled by each.

A fourth role for AI is analytical and interpretive. Many organizations already have established statistical methods, thresholds, calculations, KPIs, alarms, and business rules that identify conditions reliably. If those mechanisms work, there may be little reason to replace them simply because a generative model is available. The more interesting opportunity often begins after the rule has triggered. A deterministic system may be able to tell us that efficiency changed, that a process deviated from its expected behavior, or that a quality threshold was crossed. Understanding why the condition occurred may require examining production history, maintenance activity, operating context, previous incidents, notes, communications, and other information distributed across several systems.

AI can add value at that point by helping a person navigate the surrounding evidence. A useful analytical pattern might begin with operational data and an established rule, use the trigger to identify the relevant information space, and then allow AI to synthesize relationships and supporting evidence for a human decision-maker. I generally prefer this approach to replacing deterministic analysis with AI where the deterministic method already performs the calculation well. AI becomes useful when the next step requires searching, reading, comparing, synthesizing, and understanding context. The analytical output should ideally communicate not merely a conclusion, but the information considered, the relationships identified, and the evidence supporting the interpretation. That preserves an important distinction between helping someone understand a complex information space and asking a model to become the final authority over it.

The fifth role is the one receiving perhaps the most attention now: AI as a governed agent or process participant. In this form, AI may work across several steps of a process. It can inspect state, reason about what should happen next, use permitted tools, observe the result, and continue working toward an objective. This introduces a different class of questions because the system is no longer performing a single isolated inference. It is participating in the workflow itself. The important distinction, however, is that autonomous reasoning does not require autonomous authority. An agent can reason about the next action while policy, validation, permissions, deterministic controls, or a human determine whether that action is allowed to occur.

A system might classify an incoming request, retrieve relevant information, prepare a response, route an exception, and maintain workflow state without being granted unrestricted authority over every consequence. The AI can propose the next step while another mechanism determines whether the step is permitted. That separation becomes increasingly important as systems move from producing answers to taking actions. The more material the consequence, the more important it becomes to distinguish reasoning from authority.

These different roles should not be interpreted as levels of maturity. A governed agent is not inherently more valuable than a personal cognitive tool, and an application containing runtime AI is not inherently more sophisticated than a deterministic system that AI helped someone build. The appropriate role depends on the problem. A single business initiative may also contain several of these patterns at once. A quality-management initiative, for example, could require foundational work on reliable product and customer data, allow employees to use AI for research and summaries, use AI-assisted development to prototype an operational platform, apply AI to interpret unstructured quality records, retain deterministic statistical rules for detecting conditions, and use AI to synthesize contextual evidence for engineers. A future agent might eventually coordinate some low-risk administrative steps. These are not stages on a ladder toward autonomy. They are different functions that AI can perform within the same broader capability.

This is why I increasingly think that “Where can we use AI?” is the wrong starting question. It makes the technology the objective and encourages organizations to search for places to insert it. A better approach begins with the business need, then examines the process, the information required, the readiness of the underlying environment, the components that should remain deterministic, the components that genuinely require interpretation, the appropriate role for AI, and finally the controls and authority surrounding that role. The sequence matters because it forces the technology to justify its place in the system rather than assuming that its presence is itself evidence of progress.

Sometimes that process will lead to a personal AI assistant. Sometimes AI will materially reduce the effort required to build an application. Sometimes a narrow inference inside a larger deterministic workflow will solve a problem that traditional computation handles poorly. Sometimes AI will help a person understand a complicated body of information. In some cases, a governed agent may be able to coordinate several steps safely. In others, the appropriate conclusion will be that AI is not needed in that part of the process. That should not be considered a failure of AI adoption. It may instead indicate that the organization has understood the problem well enough to choose the appropriate tool.

AI adoption is therefore broader than increasing usage of an AI chat interface. It includes the ways AI can expand individual cognition, change how systems are constructed, perform bounded inference, support analytical interpretation, and participate in governed processes. It also includes recognizing when data, integration, process definition, or infrastructure must be addressed before AI can provide meaningful value. Distinguishing these roles gives organizations a clearer vocabulary for discussing AI, but more importantly, it makes it possible to ask better questions about what they are actually trying to accomplish.

The goal should not be to find as many places as possible to use AI. It should be to understand a business capability well enough to know where probabilistic intelligence provides genuine value, where deterministic systems should remain authoritative, where human judgment belongs, and what conditions must exist before any of those pieces can work together.