AI observability is the discipline of instrumenting LLM and ML applications so operators can see what they are doing, why, what they cost, and when they fail. It adapts the three pillars — logs, traces, metrics — for probabilistic AI systems, adding dimensions like token counts, model versions, drift, and guardrail activations. Mid-market deployments without it fly blind.

Observability is the property of a system that lets operators understand its internal state from external signals. In traditional software, that means logs, traces, and metrics rich enough to diagnose a problem without attaching a debugger. The discipline matured through the 2010s as distributed systems made the “what just happened in production” question harder to answer. AI observability extends that discipline to AI systems — particularly large language models, where the question is harder still.

An LLM application fails in ways traditional software does not. It hallucinates. It drifts as the underlying model updates or as input distributions shift. It consumes tokens unpredictably, driving cost volatility that can surprise finance teams. It can be injected with attacker-supplied instructions. It can produce outputs that violate compliance or reveal confidential information. It can be right most of the time and catastrophically wrong occasionally. None of those failure modes show up on a CPU utilization graph. AI observability is the toolkit that makes them visible.

The Observability Gap — the growing distance between enterprise AI deployment velocity and enterprise AI monitoring capability — is the thesis behind the entire AI security and managed-intelligence category. Organizations that deploy LLM applications without commensurate observability investment are operating production systems whose behavior they cannot see, cannot audit, cannot debug, and cannot defend. That is not a viable operating posture for any regulated enterprise.

Logs for LLM Applications

Every LLM interaction should produce a structured log entry. At minimum: user identity, timestamp, session ID, prompt template ID, system prompt hash, user input hash, retrieved grounding documents with source IDs and hashes, tool call invocations with argument hashes, model name and version, output completion text (or hash if raw content cannot be retained), guardrail activations, latency, input tokens, output tokens, and cost. The shape of the log is the biggest design decision — inconsistent logs across applications make cross-application analysis impossible, so standardize early.

Traces for LLM Applications

Most production LLM applications are not single calls to a single model. They are chains and agents that invoke multiple models, make retrievals, call tools, and assemble final outputs through several steps. Tracing shows the end-to-end path: which user query triggered which retrievals, which model handled which sub-step, which tool calls were executed with which arguments, where latency accumulated, where errors occurred, where guardrails triggered. Without tracing, debugging an agent failure is guesswork.

Metrics for LLM Applications

Aggregate the logs and traces into time-series metrics that drive dashboards and alerts. Essential metric families: latency distributions (p50/p95/p99), token counts (input, output, total) by model and route, cost per request and per user and per tenant, error rates by category, guardrail trigger rates, quality scores where sampling or LLM-as-judge evaluation is running, drift indicators, and user-level behavior anomalies. These metrics are the day-to-day operational pulse of an LLM application and the primary feed to executive dashboards that track AI cost and risk.

Beyond the three pillars, LLM applications have a set of monitoring dimensions that have no clean equivalent in traditional software. Each deserves dedicated instrumentation.

Input Prompts and System Prompt Versioning

The system prompt is the foundational behavior specification of an LLM application. When a change to the system prompt produces unexpected behavior, you need to know which version was running when. Hash every system prompt version, log the active version with every interaction, and treat prompt changes as code changes — pull request, code review, staged rollout.

Output Responses and Quality Sampling

Sample a representative slice of outputs for quality review. Manual review is the gold standard for low-volume applications. LLM-as-judge (a secondary LLM evaluating the primary LLM’s outputs against a rubric) scales better for higher volumes. Quality sampling catches hallucination, tone drift, and policy violations that do not trigger automated guardrails.

Model Versions and Provider Changes

LLM providers update models. Sometimes silently. “GPT-4” in 2024 behaved differently than “GPT-4” in 2025. Pin to specific versioned endpoints where providers support it, log the specific version with every call, and monitor for quality or latency changes that coincide with provider updates. An LLM application that worked on Tuesday and misbehaves on Thursday may have encountered a silent provider update.

Token Usage and Latency

Token economics drive LLM cost. Monitor input and output token distributions by application, route, and user. Detect outlier sessions — users or applications consuming disproportionate tokens, which can indicate prompt-engineering inefficiency, abuse, or injection attempts. Latency matters both for user experience and for capacity planning against rate limits.

AI systems degrade over time. Input distributions shift as user populations and business contexts change. Underlying models update. Retrieved content in RAG systems evolves. A model that was 95 percent accurate at launch can degrade silently to 85 percent six months later with no error logs, no alerts, no reason for anyone to look. Drift detection is the observability response to this failure mode.

Three drift types warrant distinct instrumentation. Input drift tracks changes in the distribution of incoming queries — new topics, new phrasings, new user demographics. Output drift tracks changes in the distribution of model responses, which can reveal model updates or systemic degradation. Performance drift tracks changes in measurable quality — accuracy against a golden dataset, user-reported satisfaction, task completion rates, guardrail trigger rates. Well-instrumented applications run all three continuously and alert on significant deviations.

LLM cost observability is a governance problem that surprises mid-market finance teams. A prompt that was free to send last month may cost measurable dollars at scale. A runaway loop in an agent can consume thousands of dollars of tokens in a single session. A popular internal tool can suddenly drive a five-figure monthly bill. Observability is the only way to make LLM cost predictable and allocable.

Effective cost monitoring requires three dimensions of attribution. Per-call cost ties every interaction to a price, revealing cost outliers and enabling cost budgets at the application level. Per-user cost surfaces heavy consumers — sometimes legitimate power users, sometimes abusers, sometimes indicators of inefficient workflows that training could address. Per-department or per-tenant cost enables chargeback, budget accountability, and executive-level ROI discussions. Without these dimensions, LLM cost appears as an undifferentiated line item that finance cannot reason about.

Security observability for LLMs extends the conventional SOC toolbox into AI-specific territory. The SIEM integrations, detection rules, and analyst playbooks that work for web applications need analogs adapted for the way LLM applications fail.

The priority signals are prompt injection detection (input patterns, output anomalies, system prompt leakage), jailbreak detection (known attack phrasings, role-play escape attempts, encoded payloads), guardrail trigger rates (sudden increases suggest probing), tool call anomalies (unexpected arguments or destinations), and cross-session behavioral anomalies (users suddenly exploring unusual topics or driving disproportionate token usage). Each should produce telemetry consumable by a SIEM or dedicated LLM security platform, with detection rules tuned to the specific application and analyst playbooks documented for response.

Auditors, regulators, and large customers are increasingly asking AI-specific questions: Can you produce an audit log of every interaction a given user had with your AI system over a given period? Can you demonstrate that PII was not submitted to an external LLM? Can you show the grounding sources for a specific AI-generated output? Can you produce evidence of human review for AI-assisted decisions affecting customers? These questions are answerable only with purpose-built compliance observability.

The operational requirements are retention (log retention periods that match the longest applicable regulatory obligation, often seven years for financial and healthcare contexts), searchability (the ability to pull all interactions for a given user, topic, or grounding source on demand), integrity (evidence that logs have not been tampered with), and content inspection (the ability to detect PII, PHI, or other regulated content flowing through AI pipelines). Compliance observability is often the most demanding dimension of an AI observability program and the one with the strongest business case for an enterprise platform.

Armorstack does not sell a proprietary AI observability platform. Our position is vendor-neutral: the right platform is the one that fits the client’s existing stack, ML maturity, and operating model. Our SENTRY portfolio operates whatever platform the client has chosen, integrates the telemetry into the client’s SIEM, tunes detection rules and alert thresholds for the client’s applications, and runs the analyst workflows that convert raw telemetry into meaningful security and operational signals. VERITY sets the governance layer — what observability is required, what retention, what reporting.

The philosophical commitment is that observability is a capability, not a product. Buying Arize does not give you AI observability any more than buying Splunk gives you security. The capability is the consistent instrumentation of LLM applications, the integration of AI telemetry with the rest of the enterprise observability stack, the analyst workflows that convert data into decisions, and the executive reporting that connects LLM activity to cost, risk, and business outcomes. Armorstack builds and operates the capability. The tooling serves the capability, not the reverse.