Topic starter
11/11/2026 6:01 pm
TL;DR: AI observability, according to Logz.io, now splits between tracing AI apps for quality and cost, and using AI agents to investigate incidents across production signals. Practitioners need one pipeline that supports evaluation and operational root cause work without duplicating instrumentation.
Editorial analysis by NHI Mgmt Group, based on content published by Logz.io: “Best AI Observability Tools of 2026: Monitoring the AI You Build and the AI That Runs Your Ops”.
Key questions
Q: Why do AI agents need least-privilege access to telemetry data?
A: AI agents need least-privilege access to telemetry data so they can read only the logs, metrics or traces required for their task, rather than broad observability data that may expose credentials, customer content or operational details.
Q: How should teams separate LLM evaluation from incident investigation?
A: Teams should separate LLM evaluation from incident investigation by using distinct datasets, permissions and workflows, so benchmark prompts and scored outputs do not mix with live forensic evidence.
Q: What is the difference between OpenTelemetry and an AI observability platform?
A: OpenTelemetry is the telemetry collection and export layer, while an AI observability platform is the system that stores, visualises, tests, alerts on, and operationalises that data.
Practitioner guidance
- Separate evaluation from operations on purpose Use one toolchain for prompt, trace, and dataset evaluation, and a different governed path for incident investigation so quality checks do not become ad hoc production access.
- Instrument AI workloads with OpenTelemetry GenAI spans Standardise spans for model inference, agent runs, tool calls, and retrieval so evaluation tools and observability platforms consume the same telemetry.
- Constrain agent access to observability data Limit which logs, metrics, traces, dashboards, and alerts an AI agent can read, and require audit trails for every tool invocation and response path.
Bottom line: AI observability now spans both AI quality control and incident investigation, and treating those as separate problems leaves blind spots between model behaviour and runtime failure.
Glossary terms: AI observability, OpenTelemetry GenAI semantic conventions, Model Context Protocol, Agentic observability
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/11/2026 6:06 pm
AI observability has become a governance split, not a single category: tracing AI applications and investigating production with AI solve different problems, use different data, and create different control boundaries. Teams that buy only one side of the stack will either see quality issues without operational context or see incidents without AI-specific evidence. The practical conclusion is that observability architecture now needs a policy model for what the agent can inspect, what it can do, and what gets retained.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: What is MCP in the context of AI security?
A: MCP is a standard way for AI agents to connect to tools and data sources through a client-server pattern. For security teams, the important point is that MCP does not remove identity controls. It still relies on secrets, scopes, and lifecycle management for every connected system.
👉 Read our full editorial: AI observability splits into app tracing and incident investigation