LLM Glossary: AI Terms Every Business Leader Needs

Every board meeting, vendor pitch, and budget review now comes with a vocabulary problem. Someone says “we need to check the context window before we commit to this vendor” or “our RAG pipeline keeps hallucinating on customer data,” and half the room nods along without being sure what was actually just decided. A large language model (LLM) is an AI system trained on massive amounts of text to predict and generate human-like language — it’s the technology behind tools like ChatGPT, Claude, and Gemini, and increasingly the engine behind the software your company already uses. This glossary exists so you can walk into that meeting, understand exactly what’s being proposed, and ask the one follow-up question that changes the decision.

77% of business leaders say the need for AI skills across their organization is urgent (Zapier), yet most of that urgency is aimed at technical hiring, not executive fluency. That’s backwards. The people approving AI budgets, signing vendor contracts, and setting governance policy are rarely the people who understand what “fine-tuning” actually costs or why a “hallucination” isn’t a bug you can just patch. This guide closes that specific gap — not by teaching you to build models, but by making sure you’re never the person in the room nodding along.

Context windows alone have grown from roughly 4,000 tokens in early-generation models to well over a million tokens in 2026-era systems (LocalAIMaster) — a change that quietly rewrote what vendors can promise you about document analysis and long-running conversations. Terms like this aren’t academic. They show up directly in contracts, pricing tiers, and the promises sales teams make you. Knowing what they mean is the difference between evaluating a vendor claim and just trusting it.

How This Glossary Is Organized

You don’t need all 43 terms today. Use the jump list below to go straight to the category relevant to your current decision — a vendor evaluation, a governance policy, a budget conversation — and come back for the rest later. Each term is explained the same way: what it means in plain English, why it matters to a business decision, and a concrete example. No jargon explaining jargon.

• 1. Foundational Concepts — what an LLM actually is
• 2. How LLMs Process Language — the mechanics behind the output
• 3. Customizing and Grounding a Model — making a model useful for your data
• 4. Agentic and Advanced Capabilities — where AI is heading in 2026
• 5. Risk, Safety and Governance — the terms your legal and compliance teams use
• 6. Business and Deployment Terms — contracts, cost, and infrastructure
• Quick-Reference Cheat Sheet — the 10-second version of every term
• Terms That Sound Similar But Aren’t — the mix-ups that cause real confusion
• Emerging Terms to Watch — 2026’s newest vendor vocabulary

1. Foundational Concepts

Start here if you’re new to this space entirely. These seven terms describe what a large language model actually is, before you get into how it works or how to customize it — the vocabulary you need before any of the rest of this guide will make sense.

Large Language Model (LLM)

A large language model is an AI system trained on enormous volumes of text — books, websites, code, conversations — to predict what word (or part of a word) comes next in a sequence. That simple prediction task, scaled up with billions of examples, produces a system that can write, summarize, translate, reason through problems, and hold a conversation. For a business leader, the practical takeaway is that an LLM doesn’t “know” facts the way a database does — it generates plausible language based on patterns, which is exactly why concepts like hallucination and RAG (both covered below) matter so much when you deploy one on real business data.

Parameters

Parameters are the internal numerical values a model adjusts during training to get better at its prediction task — think of them as millions or billions of tiny dials the model tunes as it learns from data. Model size is usually described in parameter count (a “70-billion-parameter model” or “1-trillion-parameter model”), and more parameters generally mean more capability, but also more compute cost and slower response times. When a vendor advertises parameter count as a headline feature, the business question isn’t “is bigger better” — it’s whether that extra capability actually moves the needle on your specific use case, because you’ll pay for it either way in cost or latency.

Training Data

Training data is the text (and increasingly images, audio, and code) a model learns from before it’s ever deployed. The quality, breadth, and recency of that data directly determines what the model knows and how current its knowledge is — a model trained on data through a certain date won’t natively know about anything after that cutoff unless it’s connected to live information through RAG or a search tool. For procurement conversations, ask vendors directly what their training data cutoff is and whether your industry or region is well represented in it; a model trained mostly on English-language, US-centric data will underperform on specialized regional or vertical-specific tasks.

Weights

Weights are the specific values assigned to a model’s parameters after training — essentially, the finished, trained “brain” of the model saved as a file. When people talk about “open-weight” models (like some releases from Meta or Mistral), they mean the trained weights are publicly downloadable, so a company can run the model on its own infrastructure rather than only through a vendor’s API. This distinction matters for data governance: open-weight models give you more control over where data goes, while closed models keep the weights (and therefore the exact reasoning) proprietary to the vendor.

Tokens

Tokens are the chunks of text a model actually reads and generates — not quite whole words, not quite letters, usually somewhere in between (a token is roughly four characters of English text). Every input you send and every response you receive is measured, priced, and limited in tokens, not words or pages. This is the single most practical term in this glossary for budget owners, because nearly every AI vendor prices its API by the token, and understanding token counts is how you’ll estimate cost before you commit to a deployment (see Inference Cost, in the Business Terms section, for the pricing mechanics).

Model Size (Small, Mid, Large)

Model size describes a model’s parameter count and, roughly, its capability tier — small models are fast and cheap but handle simpler tasks, large (“frontier”) models are slower and more expensive but handle complex reasoning, nuance, and long documents better. Most vendors now offer a family of sizes (for example, a “mini” or “flash” tier alongside a flagship model) specifically so businesses can match cost to task complexity. The practical move for most companies is to route simple, high-volume tasks (like tagging support tickets) to a small model and reserve large models for complex, lower-volume work (like drafting a board memo) — using the flagship model for everything is the single most common way businesses overspend on AI.

Pre-training vs. Fine-Tuning

Pre-training is the initial, extremely expensive process of teaching a model general language ability from massive datasets — this is the stage that costs vendors hundreds of millions of dollars and produces the “base” model. Fine-tuning (covered in more depth in Section 3) is a much smaller, cheaper second stage where that base model is further trained on a narrower, specific dataset to specialize it for a task or domain. Business leaders rarely need to worry about pre-training directly — no company should be building a model from scratch — but understanding the distinction clarifies why fine-tuning your own model is a realistic project while training one from zero almost never is.

2. How LLMs Process Language

These seven terms explain the mechanics behind what a model actually does when it reads your prompt and writes a response. This is the vocabulary that shows up directly in vendor pricing tiers and technical limitations — knowing it changes how you read a spec sheet.

Context Window

The context window is the maximum amount of text (measured in tokens) a model can “see” and hold in working memory at once — your prompt, any documents you’ve attached, and the model’s own response all count against this limit. Context windows have grown dramatically, from roughly 4,000 tokens in early models to over a million tokens in some 2026-era systems (LocalAIMaster), which is why some vendors can now analyze an entire contract or codebase in one pass while others still require you to break documents into chunks. When evaluating a vendor for document-heavy work — legal review, financial analysis, long transcripts — context window size is one of the first specs to check, because a model with a small window will silently forget the beginning of a long document by the time it reaches the end.

Tokenization

Tokenization is the process of breaking your text into tokens before the model can process it — it’s the translation step between human language and the numbers a model actually computes with. Different models tokenize differently, which is why the same document can cost more tokens (and more money) on one vendor’s platform than another’s, and why languages other than English sometimes tokenize less efficiently, quietly inflating cost for multilingual businesses. You don’t need to manage tokenization yourself, but if your non-English content is costing noticeably more per word than expected, this is usually why.

Embeddings

Embeddings are numerical representations of text (or images) that capture meaning — two pieces of text with similar meaning end up with mathematically similar embeddings, even if they don’t share a single word in common. This is the technology that powers “search by meaning” rather than “search by exact keyword,” and it’s the foundational piece underneath RAG, semantic search, and recommendation systems. If a vendor tells you their search or retrieval feature “understands intent” rather than just matching keywords, embeddings are almost certainly the mechanism doing that work.

Attention Mechanism

The attention mechanism is the core technical innovation that lets a model weigh which parts of the input matter most when generating each part of its response — it’s literally what “attention” means: the model learns to focus on relevant words and ignore irrelevant ones, even across a long document. You won’t need to explain this to your board, but it’s worth knowing as the underlying reason modern LLMs can maintain coherence across long, complex prompts in a way that older AI systems couldn’t. If someone on your technical team mentions “transformer architecture,” this mechanism is the “transformer” part.

Temperature

Temperature is a setting that controls how predictable or creative a model’s output is — low temperature (near 0) produces consistent, focused, repeatable answers; high temperature produces more varied, creative, sometimes unpredictable ones. This is a genuinely useful lever for business deployments: a customer service bot answering policy questions should run at low temperature (you want the same correct answer every time), while a marketing brainstorm tool benefits from higher temperature (you want variety). If your AI tool is giving inconsistent answers to the same question, ask your technical team what temperature it’s running at before assuming the model itself is unreliable.

Latency

Latency is the time between sending a prompt and receiving a complete response — and it’s one of the most underrated factors in whether an AI tool actually gets adopted by your team. A model that’s more accurate but takes 12 seconds to respond will lose to a slightly less accurate model that responds in 2 seconds for most real-time, customer-facing use cases (chat support, live search), even though accuracy is the metric everyone evaluates in the demo. When piloting a vendor, test latency under realistic load, not just in a quiet demo environment, since response times often degrade noticeably once real traffic hits the system.

Throughput

Throughput is how much volume a model or system can process in a given time — think requests per second, not the speed of any single request. This matters at scale: a model that performs beautifully for one user in a pilot can bottleneck badly once your whole customer service team is using it simultaneously. Before signing an enterprise contract, ask the vendor directly what throughput they guarantee under your expected concurrent usage, and get it in writing as part of the SLA (covered in Section 6) rather than taking a pilot’s performance as representative of production load.

3. Customizing and Grounding a Model

A general-purpose LLM knows a lot about the world and almost nothing about your business. These eight terms cover the techniques companies use to connect a model to their own data and make it behave the way they need it to — this is the section most relevant if you’re currently evaluating an AI vendor or planning an internal deployment.

Prompt Engineering

Prompt engineering is the practice of crafting the instructions you give a model to get better, more reliable output — specifying format, tone, constraints, and examples rather than asking a vague open-ended question. It sounds like a technical skill, but in practice it’s closer to writing an unusually clear brief for a very literal new employee: the more specific and structured your request, the better the result. Companies that invest even modest time training staff on prompt engineering fundamentals typically see faster, more consistent results from the same AI tools than companies that don’t, without spending anything extra on technology.

System Prompt

A system prompt is a set of standing instructions given to a model before any user interaction begins — it defines the model’s role, tone, boundaries, and behavior for an entire deployment, rather than being typed fresh each time. This is how a company turns a general-purpose model into “our customer service assistant that only discusses our products, never gives medical or legal advice, and always offers a human handoff option.” If you’re deploying any customer-facing AI tool, the system prompt is one of the most important governance documents in the project, and it deserves the same review rigor as a customer-facing policy document, because in practice, that’s what it is.

Retrieval-Augmented Generation (RAG)

Retrieval-augmented generation is a technique that connects a model to an external, current knowledge source — your company’s documents, product catalog, or knowledge base — so it retrieves relevant information at the moment of answering, rather than relying only on what it learned during training. This is the single most important concept for any business deploying AI on internal data: RAG is how you get a model to answer questions about your specific policies, products, or customer history accurately, and it dramatically reduces hallucination because the model is grounding its answer in retrieved facts rather than generating from memory alone. If a vendor pitches an AI assistant for your internal knowledge base, ask specifically how their RAG pipeline is built and how often the underlying data refreshes — a RAG system pointed at stale data is only marginally better than no RAG at all.

Fine-Tuning

Fine-tuning is the process of taking a pre-trained model and further training it on a smaller, specific dataset to specialize its behavior — teaching it your company’s writing style, a specialized vocabulary, or a narrow task it needs to perform consistently. It’s more expensive and slower to set up than RAG or prompt engineering, and it’s the wrong first move for most businesses: RAG solves “the model doesn’t know our data” far more cheaply than fine-tuning does. Fine-tuning earns its cost when you need to change how a model behaves or reasons, not just what facts it knows — for example, training a model to consistently follow a complex, multi-step internal process rather than just retrieve information.

Few-Shot and Zero-Shot Prompting

Zero-shot prompting means asking a model to complete a task with no examples, relying entirely on its general training. Few-shot prompting means including a handful of examples of the input/output pattern you want directly in your prompt, which typically improves accuracy and consistency significantly for structured tasks. In practice, if your team is getting inconsistent output from a repeated task — categorizing support tickets, extracting data from invoices — the fastest and cheapest fix is usually adding 3-5 good examples to the prompt (few-shot) before reaching for fine-tuning, which solves the same problem at a fraction of the cost and time.

Vector Database

A vector database is specialized storage built to hold and quickly search embeddings (the numerical meaning-representations covered in Section 2) rather than traditional rows and columns. It’s the infrastructure piece that makes RAG possible at scale — when a model needs to retrieve relevant company documents, it’s searching a vector database for the closest semantic matches, not scanning a folder of files in real time. If you’re building or buying an internal AI knowledge tool, the vector database is usually the component that determines both retrieval accuracy and ongoing infrastructure cost, and it’s worth a direct question in any vendor evaluation.

Semantic Search

Semantic search is search based on meaning and intent rather than exact keyword matching — a search for “reduce staff turnover” can surface a document titled “employee retention strategies” even though they share almost no words. This is a direct upgrade over traditional keyword search for internal knowledge bases, customer support, and document discovery, and it’s one of the most immediately useful, lowest-risk AI applications a business can deploy, because it augments existing search rather than replacing a decision-making process. If your internal search tool still requires employees to guess the exact right keyword, semantic search is a strong, low-risk first AI project to evaluate.

Grounding / Knowledge Base Connection

Grounding refers broadly to any technique that anchors a model’s output in verified, specific information rather than letting it generate purely from its trained knowledge — RAG is the most common grounding technique, but the general concept also covers connecting a model to live databases, APIs, or structured company data. When you hear a vendor say their AI is “grounded in your data,” this is the concept they mean, and it’s worth asking exactly which grounding technique they use and how current that data source is, since “grounded” is increasingly used as a marketing term without technical specificity behind it.

4. Agentic and Advanced Capabilities

This is where the terminology gets newer and the marketing gets louder. These seven terms cover the current frontier of what LLMs can do beyond answering questions — the capabilities most likely to show up in a 2026 vendor pitch deck.

Agentic AI

Agentic AI describes systems that can take multi-step action toward a goal with limited human oversight — rather than just answering a single question, an agentic system can plan a sequence of steps, use tools, check its own work, and adjust course, closer to delegating a task to a capable employee than asking a question of a search engine. This is the most hyped capability in AI marketing right now, and also the one most likely to be overstated: a genuinely agentic system that can independently execute a multi-step business process (book a trip, process a refund end-to-end, reconcile an invoice) is meaningfully different from a chatbot that just answers questions well, and vendors don’t always draw that line clearly in their pitch.

Function Calling / Tool Use

Function calling (also called tool use) is a model’s ability to recognize when a task requires an external action — checking a database, calling an API, running a calculation — and trigger that action itself rather than just describing what should happen. This is the technical mechanism that turns a conversational model into an agentic one: an AI assistant that can actually check your calendar and book the meeting, not just tell you it would if it could. When evaluating an “AI agent” product, ask specifically which tools and systems it can call, because a system’s real capability is defined entirely by what it’s been connected to, not by the model underneath it.

Chain-of-Thought Reasoning

Chain-of-thought reasoning is a technique (and, in newer “reasoning models,” a built-in behavior) where a model works through a problem in explicit intermediate steps rather than jumping straight to an answer — similar to showing your work in a math problem. This meaningfully improves accuracy on complex, multi-step tasks like financial analysis or logical problems, at the cost of slower response time and higher token usage (since the “thinking” itself consumes tokens). If a task your business needs done involves multiple logical steps rather than a single lookup, a reasoning-capable model is usually worth the extra latency and cost.

Multimodal Models

A multimodal model can process and generate more than one type of content — text, images, audio, and sometimes video — within a single system, rather than requiring separate tools for each. Practically, this means a business can now hand a model a photo of a damaged product, a screenshot of an error message, or an audio recording of a customer call and get a text response grounded in that visual or audio input, in the same conversation. Multimodal capability is increasingly table stakes among frontier vendors rather than a premium add-on, so it’s worth confirming exactly which input types your specific use case needs before paying extra for capabilities you won’t use.

Reasoning Models

Reasoning models are a class of LLM specifically trained to “think” through hard problems using extended chain-of-thought before answering, trading speed for accuracy on complex tasks — they’re built for depth, not for quick conversational responses. Most vendor lineups in 2026 now offer both a fast, general-purpose model and a slower, reasoning-optimized model, and choosing correctly between them is a genuine cost lever: routing simple customer questions to a reasoning model wastes money and time, while routing complex financial modeling to a fast general model risks lower-quality output. Match the model tier to task complexity, not the other way around.

Orchestration / Agent Framework

Orchestration is the layer of software that coordinates multiple AI calls, tools, and steps into a single working process — it’s the “project manager” sitting on top of one or more models, deciding what happens next, in what order, and handling errors along the way. This is the infrastructure that makes a genuinely agentic, multi-step workflow reliable rather than a fragile demo; most production AI agent deployments fail or succeed based on the quality of their orchestration layer, not the underlying model. If you’re building an internal AI agent rather than buying one, budget real engineering time for this layer — it’s typically underestimated relative to the model integration itself.

Model Context Protocol (MCP)

The Model Context Protocol is an open standard, introduced by Anthropic in late 2024 and widely adopted across the industry through 2025-2026, that lets AI models connect to external tools, data sources, and applications in a consistent, standardized way — rather than every vendor building a custom, incompatible integration for every tool. For business leaders, the practical significance is portability and reduced lock-in: MCP-compatible AI tools can connect to your company’s existing software (CRM, project management, internal databases) through a common protocol rather than requiring bespoke, expensive custom integration work for every new AI tool you adopt. If a vendor’s product is MCP-compatible, that’s a meaningful point in favor of easier future integration.

5. Risk, Safety and Governance

These seven terms are the vocabulary your legal, compliance, and risk teams already use — or should be using — when evaluating any AI deployment. Understanding them is not optional if you’re the one signing off on AI use in your organization.

Hallucination

A hallucination is when a model generates information that sounds plausible and confident but is factually wrong or entirely fabricated — a fake citation, an invented statistic, a confidently incorrect answer to a factual question. This isn’t a rare glitch; it’s an inherent characteristic of how LLMs generate text (predicting plausible language, not retrieving verified facts), which is exactly why RAG, grounding, and human review processes matter so much for any customer-facing or high-stakes AI deployment. The business risk isn’t that a model might occasionally be wrong — every system is sometimes wrong — it’s that hallucinated answers are delivered with the exact same confident tone as accurate ones, so your review process has to catch what your users can’t.

Guardrails

Guardrails are technical and policy controls put in place to keep a model’s behavior within defined, safe boundaries — preventing it from discussing certain topics, taking certain actions, or responding in ways that violate company policy or legal requirements. These range from simple content filters to sophisticated systems that check every output against a rulebook before it reaches a user. Guardrails are the difference between deploying an AI tool responsibly and deploying it recklessly, and any vendor who can’t clearly explain what guardrails are built into their product — and what happens when one is triggered — deserves a harder look before you sign a contract.

Alignment

Alignment refers to the broader effort to make an AI system’s behavior match human intentions and values — ensuring a model is genuinely helpful, honest, and avoids harmful outputs, not just technically capable. It’s a major research field at every frontier AI lab and also a practical, day-to-day concern for businesses: an unaligned deployment (a customer service bot that technically works but gives misleading answers to look helpful, for example) can create real reputational and legal exposure. When a vendor discusses their “safety” or “alignment” work, ask for specifics rather than accepting the term as a general reassurance — what specific behaviors were they aligning against, and how do they test for it.

Bias

Bias in an AI system means the model produces systematically skewed outputs, usually as a reflection of imbalances or patterns in its training data — underrepresenting certain groups, favoring certain outcomes, or reflecting historical inequities present in the data it learned from. This is a direct legal and ethical risk for any business using AI in hiring, lending, pricing, or other decisions that affect people, and regulators globally are increasingly requiring documented bias testing for exactly this reason. Before deploying AI in any decision that affects customers or employees, ask your vendor (or internal team) what bias testing was performed and on what population, and treat “we haven’t seen bias issues” as an incomplete answer if it’s not backed by actual testing.

Data Privacy / PII Handling

Data privacy in AI deployments concerns how a system collects, processes, stores, and potentially exposes personally identifiable information (PII) — names, contact details, financial information, health data — that passes through it. This is one of the highest-stakes governance areas for any business AI deployment, because the wrong data handling policy can create GDPR, CCPA, HIPAA, or other regulatory exposure, and because many AI vendors’ default settings retain and may use submitted data for further model training unless you explicitly opt out. Before deploying any AI tool that will touch customer or employee data, get written confirmation of the vendor’s data retention policy, whether your data is used for training, and where the data is physically processed and stored.

Model Drift

Model drift is the gradual degradation of a model’s accuracy or relevance over time, either because the world has changed since training (concept drift) or because a vendor has updated the underlying model in ways that subtly change its behavior on your specific use case. This is a genuinely underappreciated operational risk: an AI workflow that was carefully tuned and validated six months ago can quietly become less reliable without any visible error, especially when a vendor pushes a model update behind the scenes. Any production AI deployment needs a periodic re-validation process — spot-checking outputs on a schedule — rather than a “set it and forget it” assumption that day-one accuracy holds indefinitely.

Explainability (XAI)

Explainability refers to how well a human can understand why an AI system produced a specific output — which factors it weighted, what reasoning (if any) it followed. LLMs are notoriously difficult to fully explain even by the researchers who build them, which creates a genuine tension for regulated industries (finance, healthcare, hiring) where decisions often legally require a documented rationale. Chain-of-thought reasoning (Section 4) has partially improved this by making a model’s intermediate steps visible, but “the model showed its work” is not the same as true explainability, and this distinction matters directly in any compliance conversation about AI-assisted decisions.

6. Business and Deployment Terms

The final seven terms are the ones that show up in contracts, invoices, and infrastructure decisions — the practical vocabulary of actually buying and running AI in a company, not just understanding how it works.

API (Application Programming Interface)

An API is the technical interface that lets your software communicate directly with an AI model, sending it requests and receiving responses programmatically rather than through a chat window. Almost every business AI deployment beyond individual employee chat use happens through an API — it’s how a model gets embedded into your CRM, your website chatbot, or your internal tools. When a vendor’s pricing page lists “API access” as a plan feature, that’s the tier that lets your engineering team actually build AI into your products and workflows, distinct from a consumer-facing chat subscription.

Inference / Inference Cost

Inference is the process of a trained model actually generating a response to a real request — as opposed to training, which happens once (or periodically) before deployment. Inference cost is what you pay for that generation, almost always priced per token, and it’s the ongoing operational cost of running AI in production, distinct from any upfront setup or subscription fee. This is the number that determines whether an AI feature is actually profitable at scale: a workflow that looks cheap in a small pilot can become a significant recurring cost once it’s processing your full transaction or ticket volume, so model any deployment at expected production volume before committing to a vendor.

Open-Source vs. Closed-Source Models

Open-source (or open-weight) models have their trained weights publicly available, letting a company download and run them on its own infrastructure. Closed-source models (like most flagship offerings from major AI labs) are only accessible through the vendor’s own API, keeping the model itself proprietary. The tradeoff is control versus convenience: open models give you more say over data handling, cost structure, and customization, but require real infrastructure and expertise to run well; closed models are easier to adopt and typically more capable at the frontier, but tie you to a vendor’s pricing, policies, and uptime.

On-Prem vs. Cloud Deployment

On-premises (on-prem) deployment runs AI infrastructure on servers your company owns and controls directly. Cloud deployment runs it on infrastructure owned by a vendor (AWS, Google Cloud, Azure, or the AI provider itself) and accessed remotely. Most businesses default to cloud deployment because it requires far less specialized infrastructure investment, but heavily regulated industries or companies with strict data residency requirements sometimes need on-prem or private cloud options specifically to keep sensitive data from leaving their own controlled environment. This is a question worth raising early in any vendor conversation if your industry has specific data residency or sovereignty requirements, since not every AI vendor offers an on-prem option.

Vendor Lock-In

Vendor lock-in is the difficulty (and cost) of switching AI providers after you’ve built workflows, integrations, and institutional knowledge around a specific vendor’s tools. This risk is genuinely elevated in AI compared to typical software, because prompts, fine-tuned models, and custom integrations are often not portable between vendors without significant rework. Before committing deeply to a single AI vendor, it’s worth deliberately asking how portable your investment would be if you needed to switch — standards like MCP (Section 4) are specifically aimed at reducing this risk, but portability still varies significantly by vendor and by how deeply you’ve customized your deployment.

SLA / Uptime

An SLA (service level agreement) is a contractual commitment from a vendor about performance guarantees — typically uptime (what percentage of time the service is available), response time, and support response commitments, often with financial penalties if the vendor fails to meet them. For any AI tool that becomes part of a customer-facing or business-critical workflow, the SLA is not boilerplate to skip past — it’s the actual guarantee of reliability you’re buying alongside the technology itself, and “99.9% uptime” sounds similar to “99% uptime” but represents roughly 8 hours versus 87 hours of expected annual downtime, a meaningful difference for any process that can’t tolerate interruption.

Shadow AI

Shadow AI is employee use of AI tools without formal IT approval, oversight, or governance — an employee pasting confidential customer data into a free consumer chatbot to draft an email, for example. This has become one of the fastest-growing data security risks for companies in 2025-2026, precisely because AI tools are so easy to access individually that employees adopt them faster than governance policies can keep up. The realistic fix isn’t banning AI use (which mostly just pushes it further underground) — it’s providing approved, governed AI tools that are good enough that employees don’t feel the need to reach for an ungoverned alternative, paired with clear policy about what data can and can’t be entered into any AI tool.

Quick-Reference Cheat Sheet

Bookmark this table for the next time a term comes up in a meeting and you need the 10-second version rather than the full explanation above.

Terms That Sound Similar But Aren’t

A handful of these terms get used interchangeably in casual conversation, sales pitches, and even internal memos — and the confusion isn’t harmless. Mixing up the following pairs is one of the most common ways business leaders misjudge what a vendor is actually offering.

AI vs. Machine Learning vs. LLM vs. Generative AI

Artificial intelligence (AI) is the broadest umbrella term for any system that performs tasks normally requiring human intelligence. Machine learning (ML) is a subset of AI where systems learn patterns from data rather than following explicit rules — this includes everything from spam filters to fraud detection, most of which has nothing to do with language. An LLM is a specific type of ML model focused on language. Generative AI is a broader category than LLMs that includes any AI producing new content — text, images, audio, video — meaning an LLM is one kind of generative AI, but not all generative AI is an LLM (image generators like Midjourney are generative AI but not language models). When a vendor says “we use AI,” ask which of these four they actually mean — the honest answer changes what the product can and can’t do.

RAG vs. Fine-Tuning (Revisited)

These two get confused constantly because both are ways of customizing a model for your business, but they solve different problems. RAG gives a model access to current, specific facts it didn’t have during training — use it when the problem is “the model doesn’t know our data.” Fine-tuning changes how the model behaves, reasons, or writes — use it when the problem is “the model knows the facts but responds the wrong way.” Most businesses need RAG first, and many never need fine-tuning at all; if a vendor recommends fine-tuning before you’ve exhausted what RAG and good prompt engineering can do, ask them to justify why.

Hallucination vs. Bias

Both are risk terms, and both produce “wrong” output, but the failure mode is different. Hallucination is a model confidently fabricating information that isn’t true — a made-up statistic or a citation that doesn’t exist. Bias is a model producing output that’s systematically skewed in a particular direction, often reflecting patterns in its training data, even when every individual fact stated is technically accurate. A hallucination is usually caught by fact-checking; bias often isn’t caught by fact-checking at all, because the output can be factually correct while still being unfairly skewed — which is exactly why bias testing requires a different review process than accuracy testing.

Agentic AI vs. Traditional Automation (RPA)

Traditional automation (often called RPA, or robotic process automation) follows fixed, pre-programmed rules — it executes the same steps the same way every time, and breaks when something unexpected happens. Agentic AI can reason about a goal, adapt its approach, and handle variation and ambiguity that would break a rules-based system. The tradeoff is predictability: RPA is boring and reliable, agentic AI is flexible but less predictable, and the right choice depends entirely on whether your process is genuinely stable and repetitive (a strong case for RPA) or full of edge cases and judgment calls (where agentic AI has a real advantage). Don’t let a vendor sell you agentic AI’s flexibility for a task that’s actually simple and stable enough for cheaper, more predictable automation.

Open-Source vs. Open-Weight

These are often used as if they mean the same thing, and technically they don’t. A model is open-weight if its trained weights are publicly downloadable, letting anyone run it. A model is genuinely open-source only if the training data, training code, and methodology are also published — a much higher bar that very few major models actually clear. Most models marketed as “open” in 2026 are open-weight, not fully open-source, and the distinction matters if transparency about training data (for legal, ethical, or bias-review reasons) is important to your evaluation criteria.

Which Terms to Know Before Your Next AI Vendor Meeting

You don’t need all 43 terms fluent for a single meeting. If you’re heading into a vendor evaluation this week, this is the shortlist that actually changes the conversation.

Start with context window and token pricing — together, these tell you what the tool can realistically handle and what it will actually cost at your volume, not the volume in the vendor’s demo. Ask for their pricing per 1,000 tokens and estimate your expected monthly volume before the meeting, not after.

Next, ask directly whether their offering uses RAG to ground answers in your data, or whether it’s relying purely on the base model’s training. This single question separates vendors who’ve built a real integration from vendors who’ve wrapped a general-purpose model in your branding and called it a product.

Then get specific about data privacy: where is data processed, is it used for further model training, and what’s the retention policy. Get this in writing, not verbally — verbal assurances don’t hold up in an audit.

If the pitch includes the word “agentic,” ask exactly which actions the system can take autonomously and which tools it’s connected to via function calling. Vague answers here (“it can do a lot, we’re adding more integrations”) are a signal the capability is more roadmap than reality.

Finally, ask about their SLA and what happens when the model hallucinates or produces an incorrect output in your specific workflow — what’s the review process, what’s the escalation path, and who’s accountable when it happens. Every vendor’s answer to this last question tells you more about whether they’re ready for your business than anything else in the pitch.

None of these five questions require a technical background to ask. They require knowing what the words mean — which, if you’ve made it this far, you now do.

Emerging Terms to Watch

These five terms haven’t earned a full entry above yet — either because they’re still settling into consistent industry definitions, or because they’re relevant to a smaller slice of businesses — but they’re showing up in enough vendor conversations and industry coverage in 2026 that you should recognize them on sight.

Small language models (SLMs) are compact, efficient models — often under a few billion parameters — built to run fast and cheap, sometimes even on a laptop or phone, in exchange for less general capability than a frontier model. Businesses are increasingly deploying SLMs for narrow, high-volume tasks (tagging, routing, simple extraction) and reserving expensive frontier models for genuinely complex work.

AI washing is the practice of marketing a product as “AI-powered” when the actual AI component is minimal, superficial, or barely functional — a rebranding exercise more than a technical one. Regulators, including the U.S. Securities and Exchange Commission, have already brought enforcement actions against companies for AI washing claims made to investors, which makes this a genuine due-diligence term, not just a cynical observation.

Prompt injection is a security vulnerability where malicious instructions are hidden inside content a model processes — a document, an email, a webpage — attempting to hijack the model into ignoring its original instructions. This is an emerging security risk specifically tied to RAG and agentic systems that read external content, and it’s worth a direct question to any vendor whose AI agent processes untrusted inputs like customer emails or uploaded documents.

Synthetic data is artificially generated training data, created by another AI system rather than collected from real-world sources, increasingly used to supplement or substitute real data where it’s scarce, sensitive, or expensive to collect. It’s a practical solution to real data-scarcity and privacy problems, but it also raises a legitimate question worth asking any vendor: how much of their model’s training relied on synthetic data, and what quality controls existed around it.

Context engineering is an evolving successor concept to prompt engineering — rather than crafting a single clever prompt, it’s the discipline of designing the entire information environment a model operates in: what documents it can retrieve, what tools it can call, what memory it carries between turns. As agentic systems become more common, this discipline is increasingly considered more important to production reliability than prompt wording alone.

A Living Glossary in a Fast-Moving Field

New terminology enters this space faster than almost any other area of business technology — a phrase that didn’t exist eighteen months ago (Model Context Protocol, agentic AI as a distinct category from chatbots) is now standard vendor vocabulary, and the same will be true again eighteen months from now. Treat the 43 terms above as your working foundation, not a finished list: the concepts underneath them (how models process language, how they’re grounded in data, how they’re governed) will stay stable even as the specific product names and marketing terms built on top of them keep changing. When you hit a term in a vendor conversation that isn’t covered here, the fastest gut-check is to ask which of the six categories above it belongs to — foundational, processing, customization, agentic capability, risk, or business/deployment — because that alone usually tells you what question to ask next, even before you know the exact definition.

More from CorporatePlaybookPro.com

→ How to Use Claude AI for Business: The Complete 2026 Guide
→ Claude vs ChatGPT for Small Business: Which AI Actually Fits Your Workflow? (2026)
→ What is The Agentic AI? Complete Guide with Real-World Examples
→ Types of AI Agents: A Simple Guide for Business Leaders
→ What is AI? Basics of Machine Learning, Deep Learning & Gen AI : A Business Guide
→ An Easy Guide to Concepts of Gen AI in SMEs
→ The AI Maturity Assessment Framework Every Business Leader Needs
→ Top 10 AI Use Cases That Are Transforming Small & Medium Business in 2025

Frequently Asked Questions

What does LLM stand for?

LLM stands for large language model — an AI system trained on massive amounts of text to understand and generate human-like language. It’s the underlying technology behind tools like ChatGPT, Claude, and Gemini.

What is the difference between AI and a large language model?

AI is the broad umbrella term for any system performing tasks that normally require human intelligence, while a large language model is one specific type of AI focused on understanding and generating language. Every LLM is AI, but most AI — fraud detection, image recognition, recommendation engines — isn’t an LLM at all.

Is ChatGPT considered an LLM?

ChatGPT is a product built on top of an LLM (from OpenAI’s GPT model family), not the model itself — the LLM is the underlying technology, and ChatGPT is the chat application interface people use to interact with it. The same distinction applies to Claude (built on Anthropic’s models) and Gemini (built on Google’s models).

What is a hallucination in AI?

An AI hallucination is when a model generates information that sounds confident and plausible but is factually incorrect or entirely made up, such as a fake statistic or a citation that doesn’t exist. It happens because LLMs generate the most statistically likely next words, not verified facts, which is why grounding techniques like RAG are used to reduce it.

What does RAG mean in AI?

RAG stands for retrieval-augmented generation — a technique that connects an AI model to an external, current knowledge source (like your company’s documents) so it retrieves relevant facts before answering, instead of relying only on what it learned during training. It’s the standard way businesses get accurate AI answers about their own data.

What is the difference between machine learning and an LLM?

Machine learning is the broader field of systems that learn patterns from data rather than following fixed rules, covering everything from spam filters to demand forecasting. A large language model is a machine learning model specifically trained and optimized for language tasks — so an LLM is a subset of machine learning, not a synonym for it.

What context window size do I need for reviewing long business contracts with AI?

For reviewing lengthy contracts, look for a context window of at least 100,000-200,000 tokens, which comfortably covers most standard commercial contracts and lets the model analyze the whole document in a single pass rather than splitting it into chunks. For very long documents or multi-document analysis, some 2026-era models now offer context windows exceeding a million tokens.

Should a small business use fine-tuning or RAG to customize an AI tool?

Most small businesses should start with RAG, not fine-tuning — it’s significantly cheaper, faster to set up, and solves the most common problem (the AI doesn’t know your company’s specific data). Fine-tuning is worth the added cost and complexity only when the issue is how the model behaves or reasons, not simply what facts it has access to.

What AI terms should a non-technical manager learn before a vendor demo?

Before a vendor demo, a non-technical manager should be comfortable with context window, token pricing, RAG, hallucination, and SLA — these five terms cover what the tool can handle, what it will cost, how it’s grounded in accurate data, what its failure mode looks like, and what guarantees back it. Everything else in this glossary can be learned as it becomes relevant to a specific decision.

What is agentic AI?

Agentic AI refers to systems that can take multi-step action toward a goal with limited human oversight — planning steps, using tools, and adjusting course — rather than just answering a single question. It’s the most-discussed AI capability in 2026, though the term is also frequently overstated in vendor marketing.

What is prompt engineering?

Prompt engineering is the practice of writing clear, specific instructions for an AI model to get more reliable and useful output — including format, tone, constraints, and examples. It’s a free, immediately usable skill that typically improves AI output quality more than switching to a more expensive model.

What is a token in AI?

A token is the basic unit of text an AI model reads and generates — roughly four characters of English text, not quite a full word. Nearly all AI vendors price their services per token, which makes understanding token counts essential for estimating the real cost of an AI deployment.