Chapter 2
Scope and Definitions
Defines what the policy governs and what it does not. A principle stated in terms of an AI system is only as clear as the organization's agreement on what an AI system is, so this chapter fixes that agreement: an AI system is technology that depends on a large language model's inference, and the chapter supplies a usable test for the boundary cases the definition does not settle on its own.
The Boundary of the Policy
Chapter 1 established the principle on which this policy rests: AI is a technology tool not capable of accepting delegation, and as with all other technologies, accountability for the output of an AI system flows to the human who used it, to the custodian for the domain it affects, and to the organization that deployed it. A principle stated in terms of an AI system is only as clear as the organization’s agreement on what an AI system is. This chapter directly addresses that agreement by defining what the policy governs and what it does not.
For the purposes of this policy, an AI system is any technology that depends on a large language model to interpret inputs and generate outputs. These systems determine their responses through the model’s capacity for inference rather than through deterministic, hard-coded rules. Where a conventional program produces an output by executing instructions written in advance, an AI system in this sense produces an output by interpreting the input against patterns learned during training. The definition applies uniformly regardless of the model’s size, its provider, or where it runs. A large third-party frontier model accessed through any interface and a small model capable of being deployed on a desktop or laptop corporate device are both in scope. The defining characteristic is dependence on a language model’s inference, not the scale of the model or what device hosts execution.
Categories of Governed AI Systems
Within this scope, AI systems take three forms that recur across the enterprise. The policy governs all three. Their requirements differ in later chapters according to what each form is permitted to do, but the scope of the policy does not bend to accommodate any of them. The three forms are as follows:
A generative assistant produces new content in response to a prompt, whether text, code, analysis, or images, and presents that content to a person who decides what to do with it. The output may include: an analysis, a summary, a draft document, forecasts, a simple application, spreadsheet, or another image. A human reviews it before deciding what action to take next.
A retrieval-augmented system generates output constrained to a specific, designated body of source material rather than from the model’s general training. It retrieves relevant source content, constructs its answer from that content, and can usually point the reader to where the answer came from. The value of this system is that it narrows the model’s range to an approved corpus, which makes its output easier to check against sources.
An agentic system can take actions on files and other systems rather than just producing output for review. It sends messages, changes records, calls other systems, or modifies state, acting on its interpretation of a defined goal. The distinction that matters here is that an agentic system can place its output into the enterprise (e.g., databases, file systems, corporate email) or external systems without a human in the loop between the system and the consequence.
These three forms differ in how far a person sits from the consequence of the output. A generative assistant hands its work directly to the person reviewing its output. A retrieval-augmented system does the same while constraining itself to pre-approved sources. In this case, the person may have directly provided the sources and therefore can be considered even more tightly coupled to the AI output. An agentic system may act before any reviewer sees the result, effectively putting the person at the farthest distance to the consequence of any output. These differences drive the requirements the policy places on each, which is the subject of the trust model that Chapter 4 creates and discusses. The difference does not change what is in scope. All three are AI systems under this policy.
Holding the Line at the Language Model
The definition rests on one thing: dependence on a large language model’s inference. Technologies that classify, score, or predict using statistical models trained on structured data are not AI systems under this policy. This excludes a broad set of capabilities the industry commonly calls AI, including credit and fraud scoring, demand forecasting, image classification, recommendation engines, and the wider fields of classic machine learning, computer vision, and predictive analytics. Some of these systems make consequential automated decisions but they remain out of scope here.
This is a deliberate choice, and it is the right one. The seemingly narrowed view gets its support from two reasons.
First, today’s disproportionate focus on AI systems within the enterprise is justified by its disproportionate risk. AI models promise unprecedented leaps in employee productivity, yet a steady stream of real-world failures demonstrates that their autonomy can carry severe, far-reaching risks for both organizations and individuals. A definition broad enough to capture every statistical model in the organization would pull decades of existing automated decisioning under a policy written for a different problem, and it would dilute the attention this policy is meant to command and control.
Second, the accountability problem this policy solves is specific to inference-driven data generation. A classic machine learning model performs a narrow, predefined task. It returns a score or a forecast within bounds set when it was built or configured, and its behavior can be tested against that task. A large language model interprets structured and unstructured input and generates statistically driven output. The same model may even generate different outputs from the same input if executed repeatedly. The fundamental design of LLMs, a model’s broad training data, and its programming to provide confidently complete answers, are the unfortunate cause of trusting AI to route around the role-holders who would normally have produced or reviewed the work. This is the dynamic Chapter 1 identified as the reason this policy is needed. The scope is drawn around precisely the systems that create the problem the policy addresses.
Drawing the line here means that some automated systems with real consequences are governed by other parts of the organization’s policy framework rather than by this one. That is acceptable. This policy does not claim to be the organization’s entire approach to automated decision-making. It governs the AI systems that interpret and generate data through a language model, where a human may or may not act on the output and, under the Accountability Principle, answers for it.
A Test for Boundary Cases
The definition resolves most questions on its own. The one question it does not completely settle by itself is the hybrid system; a deployment that combines a language model with components that are out of scope. The following test provides a way to settle it in most cases.
A system is in scope if a large language model interprets an input or generates output that a person relies on, regardless of other components the system contains. A system is out of scope if no large language model participates in interpreting input or generating output.
Applied to the common hybrids: a conversational interface that accepts a question or prompt in natural language, calls a predictive model as part of its workflow, and returns the result in natural language is in scope because the language model interprets the input and generates the output the person reads, even though the prediction itself comes from an out-of-scope component. A workflow in which a language model calls an out-of-scope component as one of its tools is in scope, because the language model remains in the path. Any system or tool marketed as artificial intelligence yet has no language model included in its architecture, that directly acts on input or output, is out of scope.
The principle behind the test is that scope follows function, not labeling or marketing. The presence of a language model in the path that interprets input or generates output determines if this policy applies. What a vendor or an internal team chooses to call a system, product, or service, does not.