The Language of Enterprise
AI

Artificial intelligence is software that performs tasks normally requiring human judgment, such as understanding language, recognising images, or making decisions under uncertainty. In enterprise use it describes systems that learn patterns from data rather than following rules written by a programmer.

The practical distinction is that a conventional program encodes every rule explicitly, while an AI system derives its behaviour from examples. That makes AI suitable for problems where the rules are too numerous or too fuzzy to write down — reading a contract, judging a customer's intent, or spotting a defect on a production line.

Machine learning is the branch of AI where a model learns a task from example data instead of explicit instructions. Training adjusts internal parameters until predictions match known outcomes closely enough, after which the model is applied to data it has never seen.

Most enterprise machine learning is supervised: you supply labelled examples and the model learns the mapping. Unsupervised methods find structure without labels, and reinforcement learning optimises a sequence of decisions against a reward. The choice is usually dictated by what labelled data already exists.

Deep learning is machine learning using neural networks with many stacked layers. Each layer transforms its input into a slightly more abstract representation, allowing the network to learn complex patterns directly from raw data such as text, audio, or pixels without hand-engineered features.

Depth is what removes the feature-engineering step that dominated earlier machine learning. It is also what makes deep models expensive: they need substantially more data and compute than classical methods, so they are worth reaching for only when the problem genuinely has that complexity.

A neural network is a model built from layers of simple units, each computing a weighted sum of its inputs followed by a non-linear function. Training adjusts the weights so the network maps inputs to correct outputs, learning a function too complex to specify directly.

The non-linearity is essential — without it, any stack of layers collapses mathematically into a single linear transformation. Architecture choices such as transformers, convolutional networks, or recurrent networks describe how the units are wired, and each suits a different shape of data.

Training data is the set of examples a model learns from. Its coverage, accuracy, and balance determine what the model can do and where it will fail, which is why data quality is usually a stronger lever on results than model architecture.

A model cannot learn a case its training data never contained, and it will reproduce whatever bias the data carries. In enterprise projects, the majority of effort typically goes into assembling, cleaning, and labelling this data rather than into modelling itself.

Inference is running a trained model on new input to obtain a prediction. It is distinct from training: training happens once and is compute-intensive, while inference happens on every request and therefore governs the latency and running cost of a production system.

Because inference is the recurring cost, production work concentrates on making it cheaper and faster — quantisation, caching, batching, smaller distilled models, or routing easy requests to a lighter model and reserving the large one for hard cases.

Inference latency is the elapsed time between sending input to a model and receiving its output. It determines whether an AI feature feels immediate or sluggish, and in voice applications it is the single hardest constraint to satisfy.

Latency is usually reported as a percentile rather than an average, because the slow tail is what users notice. Measure p95 and p99: a system averaging 400ms but spiking to four seconds on one call in twenty will be perceived as broken.

Model drift is the gradual decline in a deployed model's accuracy as live data diverges from the data it was trained on. Customer behaviour shifts, products change, and vocabulary moves, so a model that was accurate at launch degrades quietly over time.

Drift is silent by default — the model keeps returning confident answers that are increasingly wrong. Detecting it requires monitoring prediction distributions and holding back a stream of labelled live examples to score against, which should be built at launch rather than after the first incident.

Algorithmic bias is systematic unfairness in a model's outputs, usually inherited from imbalances in training data. A model trained mostly on one population performs worse on others, which becomes a legal and reputational risk in hiring, lending, or healthcare decisions.

Bias is measured, not assumed: evaluate performance separately across the groups a decision affects rather than reading a single aggregate accuracy figure. Mitigation ranges from rebalancing the training set to constraining the model to post-processing its decisions.

A large language model is a neural network trained on very large text corpora to predict the next token in a sequence. That single objective produces broad capability in summarising, translating, reasoning over, classifying, and generating natural language.

Because the model only ever predicts likely continuations, it has no built-in notion of truth. Everything that makes an LLM reliable in production — retrieval, tool access, validation, evaluation — is scaffolding built around that limitation rather than a property of the model.

A token is the unit of text a language model reads and writes — roughly three-quarters of an English word. Models are priced per token and limited by token count, so tokens are the practical currency of both cost and capacity.

A useful rule of thumb is 750 words per 1,000 tokens for English prose; code, markup, and non-Latin scripts consume noticeably more. Estimating token volume per request is the first step in forecasting what a feature will cost to run at scale.

The context window is the maximum number of tokens a model can consider at once, covering the prompt, any retrieved documents, the conversation so far, and the response. Anything beyond the limit must be summarised, truncated, or retrieved selectively.

Larger windows reduce engineering effort but not cost, since every token in the window is paid for on every call. Attention quality also degrades across very long contexts, so targeted retrieval usually beats pasting an entire corpus into the prompt.

A prompt is the input given to a language model: instructions, context, examples, and the user's request. In production the prompt is versioned application code, because a wording change can alter behaviour as substantially as a code change.

Production prompts belong in source control with tests, not pasted into a console. Treating them as configuration that anyone can edit live is one of the most common causes of unexplained regressions in deployed AI features.

A system prompt is the standing instruction that defines a model's role, tone, boundaries, and rules for a whole conversation. It is supplied by the application rather than the user and carries more weight than individual user messages.

It is where guardrails, brand voice, and refusal behaviour are specified. It is not a security boundary on its own: a determined user can still attempt to override it, so anything that genuinely must not happen needs enforcement in code as well.

Temperature is a setting that controls randomness in a model's output. Low values make responses focused and repeatable; higher values make them more varied and creative. It trades consistency against diversity.

Anything that must be parsed, audited, or compared across runs should use a low temperature. Higher settings suit drafting and ideation, where several plausible outputs are more useful than one deterministic answer.

Fine-tuning continues training a pretrained model on a smaller domain-specific dataset, adjusting its weights so it adopts a particular style, format, or specialised behaviour. It changes how the model responds rather than what facts it can access.

Fine-tuning is the wrong tool for supplying knowledge — retrieval handles that better and stays current. Reach for it when you need consistent structure, a specific tone, or a narrow classification task where prompting alone proves unreliable.

RLHF is a training method that aligns a model with human preferences. People rank competing model outputs, a reward model learns those preferences, and the language model is then optimised against that reward.

This is the step that turns a raw next-token predictor into an assistant that follows instructions and declines harmful requests. It is applied by model providers during training rather than by teams building on top of the resulting models.

A hallucination is a fluent, confident model output that is factually wrong. It arises because language models generate statistically likely text rather than retrieving verified facts, so plausibility and accuracy can diverge without any signal to the reader.

Hallucination is reduced by architecture, not by instruction. Grounding answers in retrieved sources, requiring citations, validating structured output against a schema, and abstaining when confidence is low all cut the rate; telling a model not to make things up does not.

Few-shot prompting supplies several worked examples inside the prompt so the model infers the intended pattern before handling the real input. It is the cheapest way to enforce a specific output format or edge-case behaviour.

Two or three well-chosen examples usually outperform a long prose description of the same requirement. Examples covering the awkward cases matter far more than examples covering the obvious ones.

Chain-of-thought prompting asks a model to work through intermediate reasoning steps before giving a final answer. Spreading the computation across more tokens measurably improves accuracy on multi-step arithmetic, logic, and planning problems.

The cost is latency and tokens, since reasoning is generated text like any other. Applications typically request the reasoning, use it internally for validation, and show the user only the conclusion.

A multimodal model accepts or produces more than one type of data — text, images, audio, or video — within a single system. This allows a document, a photograph, and a spoken question to be reasoned about together rather than through separate pipelines.

In practice this replaces brittle chains of specialised models. A single multimodal call can read a scanned invoice, interpret its table, and answer a question about it, where previously OCR, layout parsing, and language understanding were three separate components.

Prompt injection is an attack where hostile instructions hidden in user input or retrieved content cause a model to ignore its original directives. Because instructions and data share one channel, the model cannot reliably tell them apart.

The risk grows with capability: a model that can only reply is limited to saying something wrong, while a model that can call tools or read private data can be manipulated into acting. Mitigation means constraining permissions and validating outputs, never trusting the prompt to hold.

Guardrails are the controls that keep an AI system inside acceptable behaviour: input filtering, output validation, topic restrictions, escalation rules, and schema enforcement. They are implemented in application code around the model, not inside it.

Effective guardrails are deterministic. A regular expression that blocks an account number, a schema that rejects a malformed response, or a rule that hands a conversation to a human are all verifiable in a way that a prompt instruction is not.

RAG is an architecture that retrieves relevant documents from a knowledge base and supplies them to a language model at inference time. The model answers from the supplied sources rather than from memory, so answers stay current and can be cited.

RAG is the standard approach to enterprise question answering because it separates knowledge from the model. Updating an answer means updating a document, not retraining, and every response can be traced to the source that produced it — which is what makes it auditable.

An embedding is a numeric vector representing a piece of text, image, or audio, positioned so that similar meanings sit close together. Comparing vectors allows a system to find related content even when no words match.

Embeddings are what make semantic search work: a query about "staff leave policy" retrieves a document titled "annual holiday entitlement" because the vectors are near each other. The embedding model used for indexing and for querying must be the same one.

A vector database stores embeddings and retrieves the closest matches to a query vector in milliseconds across millions of records. It is the retrieval layer beneath most RAG and semantic search systems.

Distinguishing features are approximate nearest-neighbour indexing for speed and metadata filtering for access control — a search that cannot restrict results to what the current user is permitted to see is unusable in an enterprise setting.

Semantic search retrieves results by meaning rather than keyword overlap, using embeddings to match intent. It finds relevant documents that share no vocabulary with the query, which keyword search structurally cannot do.

The strongest production systems are hybrid: semantic search handles paraphrase and intent, keyword search handles exact identifiers such as part numbers and error codes, and the two result sets are merged and reranked.

Chunking splits documents into passages small enough to embed and retrieve precisely. Chunk size and boundaries strongly affect retrieval quality, making it one of the highest-impact and most underestimated decisions in a RAG system.

Chunks that are too large dilute the embedding with unrelated content; chunks that are too small lose the context needed to answer. Splitting on document structure — sections, headings, table boundaries — outperforms splitting on a fixed character count.

Reranking is a second scoring pass over initial search results, using a more expensive model that reads the query and each candidate together. It reorders a broad shortlist so the most relevant passages reach the language model.

Retrieval and reranking split the work by cost: fast vector search narrows millions of records to perhaps fifty, then a cross-encoder ranks those fifty accurately. This two-stage pattern lifts answer quality more than most prompt changes.

A knowledge base is the curated document collection an AI system answers from — policies, manuals, tickets, contracts, and product data. Its accuracy sets a ceiling on answer quality that no model choice can raise.

The common failure is scale without curation. Indexing every document an organisation holds surfaces superseded policies and contradictory drafts, and the system answers confidently from the wrong version. Ownership and a review cycle matter more than volume.

A knowledge graph stores entities and the typed relationships between them, so a system can traverse connections rather than only match text. It answers questions that depend on structure, such as which suppliers serve a given site.

Graphs complement vector retrieval rather than replacing it. Vectors are strong on unstructured prose and weak on multi-hop relationships; a graph handles the relationships and hands the surrounding text to the model.

Grounding constrains a model to answer only from supplied source material, and to say so when the sources do not contain the answer. It is the primary architectural defence against confident fabrication.

Grounding is enforced, not requested: cite sources with every claim, validate that cited passages exist, and treat an ungrounded answer as a failed response rather than an acceptable fallback.

An AI agent is a system that pursues a goal over multiple steps, deciding which actions to take and calling tools to take them. Unlike a single model call, it observes results and adapts its plan before returning an answer.

The defining property is autonomy over sequence: the agent decides what to do next rather than following a fixed script. That is also the risk, which is why production agents run with scoped permissions, step limits, and audit logs.

Agentic AI describes systems that plan, act, and self-correct across multiple steps toward an objective, rather than producing one response per request. They coordinate tools, external data, and their own intermediate results.

The shift is from AI as a feature answering a question to AI as a process completing a task. Recruitment screening that sources candidates, calls them, scores the conversation, and returns a ranked shortlist is agentic; a chatbot answering a policy question is not.

Function calling lets a language model invoke defined application functions by emitting a structured request that names a function and its arguments. The application executes it and returns the result for the model to use.

This is how a model reaches real systems — checking live inventory, booking an appointment, issuing a refund. The model never executes anything itself; it requests a call, and the application decides whether to honour it, which is where authorisation belongs.

Tool use is a model's ability to call external capabilities — search, databases, calculators, internal APIs — to obtain information or take action it cannot perform from its own parameters alone.

Tools convert a model from something that talks about work into something that does it. Each tool a model can reach is also an expansion of the blast radius if it is manipulated, so tool scope should be the minimum the task requires.

The Model Context Protocol is an open standard for connecting AI models to external tools and data sources through a common interface, so an integration written once works across different models and applications.

It addresses the combinatorial problem of wiring every model to every system with bespoke connectors. An MCP server exposes a capability once, and any compliant client can use it — the same role a standard driver interface plays for hardware.

Orchestration is the coordination layer that sequences model calls, tool invocations, retrieval steps, and error handling into a reliable workflow. It is where retries, timeouts, fallbacks, and state management live.

Most of the engineering in a production AI system sits here rather than in prompts. A well-built orchestration layer degrades gracefully — a failed tool call or a slow model produces a sensible fallback instead of a broken conversation.

Human-in-the-loop design routes certain AI decisions to a person for review or approval before they take effect. It concentrates human attention on high-consequence or low-confidence cases while automation handles the routine majority.

The design question is where the threshold sits, not whether humans are involved. Reviewing everything forfeits the efficiency gain; reviewing nothing forfeits the safety net. Confidence scores and value thresholds are the usual routing criteria.

Voice AI is a system that holds a spoken conversation, combining speech recognition, language understanding, and speech synthesis in a loop fast enough to feel natural. It handles calls end to end rather than routing callers through a menu tree.

The engineering challenge is latency budget. Transcription, model response, and synthesis must complete within roughly a second for the conversation to feel human, which constrains every component choice in the stack.

Automatic speech recognition converts spoken audio into text. It is the first stage of any voice AI system, and its accuracy bounds everything downstream — a misheard word cannot be recovered by later components.

Accuracy varies sharply with accent, background noise, and domain vocabulary. Product names, drug names, and account identifiers usually need a custom vocabulary or phrase hints, because a general model has no reason to prefer them over common words.

Text-to-speech synthesises spoken audio from written text. Modern neural TTS produces natural prosody and can stream audio as it generates, which is what allows a voice agent to begin speaking before its full response exists.

Streaming is the difference between a responsive agent and an awkward one. Waiting for a complete sentence before speaking adds a pause on every turn; emitting audio incrementally hides most of the generation time.

Barge-in is the ability of a voice system to stop speaking the moment the caller interrupts, and to process what they say. Without it a caller must wait for the agent to finish, which is the clearest signal they are talking to a machine.

Implementing it requires listening while speaking and distinguishing genuine speech from the system's own audio bleeding back through the line. It is one of the strongest single contributors to a voice agent feeling natural.

Voice activity detection identifies when someone is speaking versus when the line is silent or carrying background noise. It tells a voice agent when a caller has finished a turn and a response should begin.

Tuning is a direct trade-off. Trigger too early and the agent talks over someone who was pausing mid-sentence; trigger too late and every exchange carries an unnatural gap. The threshold usually needs adjusting per deployment environment.

Word error rate measures speech recognition accuracy as the percentage of words inserted, deleted, or substituted relative to a correct transcript. Lower is better, and it is the standard metric for comparing ASR systems.

Aggregate WER hides what matters. A system with 5% WER that reliably mistranscribes account numbers is worse in practice than one at 8% that handles them correctly, so evaluate on the vocabulary the application actually depends on.

Turn-taking is the logic governing when a voice agent listens and when it speaks. Handling pauses, interruptions, and overlapping speech naturally is what separates a conversational agent from a prompted menu system.

Human conversation tolerates gaps of roughly 200 milliseconds before they feel awkward. Meeting that target end to end, across recognition, generation, and synthesis, is the central constraint of voice agent architecture.

Computer vision is the field concerned with extracting information from images and video — detecting objects, classifying content, reading text, or measuring dimensions — turning visual data into structured output a system can act on.

Enterprise applications cluster around inspection, monitoring, and document processing: defect detection on a line, safety compliance from camera feeds, or converting scanned paperwork into database records.

Object detection locates and classifies multiple items within an image, returning a bounding box and a label for each. It answers where things are, unlike classification, which only labels the image as a whole.

Detection underpins counting, tracking, and inspection tasks. Real-time performance on video is a throughput problem as much as an accuracy one, and often decides whether a model runs at the edge or in the cloud.

Optical character recognition extracts text from images and scanned documents. Modern systems also recover layout — tables, columns, form fields — so structure survives the conversion rather than collapsing into a flat string.

Layout is usually the hard part. Reading characters from an invoice is largely solved; reliably determining which number is the total, across hundreds of supplier formats, is where the engineering effort goes.

Image segmentation classifies every pixel in an image, producing precise region outlines rather than rectangular boxes. It is used where exact shape matters — measuring area, isolating a product from its background, or delineating a defect.

Segmentation is what allows a product to be cleanly separated from a photographed scene and recomposed onto a new background, which is the basis of automated product imagery pipelines.

LLMOps is the practice of running language-model applications in production: versioning prompts, evaluating output quality, monitoring cost and latency, managing model upgrades, and detecting regressions before users encounter them.

It exists because traditional monitoring does not catch the relevant failures. An AI feature can return HTTP 200 with a fluent, entirely wrong answer, so quality has to be measured directly rather than inferred from uptime.

An evaluation harness is a fixed test set of inputs with known-good outputs, run automatically against an AI system to score quality. It is what makes a prompt or model change measurable rather than a matter of impression.

Without one, teams change a prompt, spot-check a few cases, and ship a silent regression. Fifty representative cases scored on every change catch more real problems than any amount of manual review.

Red teaming is adversarial testing of an AI system: deliberately attempting to make it leak data, bypass its instructions, produce harmful content, or misuse its tools, in order to find failure modes before users or attackers do.

It should target the specific consequences that matter for the deployment. For a system with tool access and customer data, the priority is unauthorised action and data exposure rather than generic content policy violations.

PII redaction detects and removes personally identifiable information — names, contact details, account and identity numbers — from data before it is logged, stored, or sent to an external model provider.

Applied at the boundary, redaction lets a team keep transcripts for evaluation and debugging without retaining regulated personal data. It is usually a compliance prerequisite for logging AI interactions at all.

Data residency is the requirement that data be stored and processed within a specified country or region. It constrains which cloud regions and which model providers a system may use, and is frequently non-negotiable in regulated sectors.

For AI systems it applies to inference as well as storage: sending a prompt to a model hosted elsewhere is a cross-border transfer. Meeting the requirement usually means a regional endpoint or a self-hosted model.

Prompt caching stores the processed form of a repeated prompt prefix — system instructions, reference documents, few-shot examples — so subsequent requests reusing it are cheaper and faster than reprocessing the same tokens.

For applications sending a large fixed context on every call, caching is among the largest available cost reductions. It requires ordering the prompt so the stable portion comes first and the variable portion last.

AI observability is the instrumentation that makes model behaviour inspectable in production: recording prompts, retrieved context, tool calls, outputs, latency, and cost for every request, so a bad answer can be reconstructed and explained.

Without the retrieved context and tool results captured alongside the output, a support escalation about a wrong answer is unanswerable. Trace-level capture is what turns an anecdote into a diagnosable defect.

An API is a defined interface through which one software system requests data or actions from another. It sets the contract — available operations, expected inputs, returned shapes — allowing systems to integrate without sharing internals.

APIs are how AI capabilities reach existing business systems. A voice agent that cannot query the CRM and write back to it is a demonstration; the integration surface is what makes it operational.

Microservices is an architecture that splits an application into small independently deployable services communicating over a network. Each can be scaled, updated, and owned separately, at the cost of added operational complexity.

The trade is organisational as much as technical. Independent deployment helps large teams and hurts small ones, and for AI systems it is often worth isolating just the inference workload — whose scaling profile differs sharply from the rest.

Continuous integration and continuous delivery is the automated pipeline that builds, tests, and deploys code on every change. It shortens release cycles and catches regressions before they reach production.

For AI applications the pipeline should include the evaluation harness alongside conventional tests, so a prompt or model change that degrades answer quality fails the build rather than shipping unnoticed.

Server-side rendering generates a page's HTML on the server for each request, so browsers and crawlers receive complete content immediately rather than an empty shell that JavaScript must populate.

It matters for perceived speed and for indexing. Content that exists only after client-side JavaScript executes is unreliable for search engines and invisible to most AI crawlers, which do not run scripts.

Edge computing runs code at locations geographically near the user rather than in one central region, cutting round-trip latency. For AI applications it typically handles routing, authentication, and caching ahead of inference.

Edge runtimes are constrained — limited memory, no long-running processes — so large models rarely run there. The useful pattern is edge for the fast path and a regional backend for the heavy work.

A webhook is an HTTP callback one system sends to another when an event occurs, pushing data as it happens instead of requiring the receiver to poll for changes.

Webhooks are how AI workflows are triggered by business events — a form submission, a completed call, a new support ticket. Reliable implementations verify signatures and handle duplicate deliveries, since retries are normal.

An idempotent operation produces the same result whether performed once or repeated. It is what makes retries safe, preventing a duplicated network call from creating a second order, charge, or outbound message.

It matters more in AI systems than conventional ones because agents retry autonomously. An agent that retries a failed booking without idempotency keys can produce several reservations from one instruction.

Technical debt is the accumulated future cost of implementation shortcuts taken for short-term speed. Like financial debt it carries interest: every subsequent change to the affected area takes longer than it should.

AI features accrue a specific form of it — prompts edited in production consoles, evaluation deferred, retrieval quality never measured. The cost surfaces later as behaviour nobody can explain or safely change.

A minimum viable product is the smallest release that delivers real value and produces evidence about whether the approach works. It exists to reduce uncertainty early rather than to be a smaller version of the eventual product.

For AI projects the right first release usually narrows scope rather than quality: one workflow handled properly, with evaluation and monitoring in place, beats five handled approximately.

Systems integration is connecting separate applications — CRM, ERP, telephony, ticketing, data warehouse — so they exchange data and trigger each other's workflows reliably, including when one of them is unavailable.

It is typically the largest and most underestimated portion of an enterprise AI project. The model is rarely the obstacle; reconciling identifiers, permissions, and failure behaviour across legacy systems is.