Back to Blog
AIOps9 min read

When Your AI Application Starts Lying: Observability and Monitoring for Canadian SMBs in Production

By Anton Kuznetsov

Deploying a custom AI application is not the finish line. It is the starting gun.

A language model your business deployed in the spring of 2026 is already different from what it was at launch — not because the software changed, but because the world around it did. The documents in your knowledge base are older. The customer questions hitting it are different. The third-party APIs it calls have been updated. Regulatory interpretations of what it is permitted to do have evolved. And someone, somewhere, has tried to feed it a prompt designed to make it do something you did not intend.

Most Canadian SMBs building AI applications have not yet built the monitoring layer that would tell them any of this. They are flying the aircraft without instruments.

That is no longer a defensible position in 2026.

What Actually Goes Wrong After Deployment

The failure modes of production AI applications are fundamentally different from traditional software failures. A traditional application either works or it does not — the error is visible, reproducible, and usually debuggable. AI application failures are frequently invisible, gradual, and difficult to attribute.

Model drift is the most common. As the context around your model changes — new customers, new topics, new edge cases in incoming data — the model's responses gradually degrade. A customer service chatbot that answered correctly 95% of the time in June may be at 87% in September, with no single identifiable cause and no error log recording the problem. The application is still running. The degradation is only visible if you are measuring it.

Hallucination frequency is the second failure mode. Large language models produce confident-sounding incorrect answers. In a controlled deployment with a well-defined knowledge base, hallucinations can be minimized — but not eliminated, and the rate is not static. The same query that returned accurate information last quarter may hallucinate on a subtle variation today. Without a monitoring system tracking accuracy against ground truth, you will not know until a customer reports the problem.

Adversarial inputs are the third failure mode, and increasingly the most consequential. Prompt injection holds the number one position on OWASP's Top 10 for LLM Applications across every published edition. A prompt injection attack embeds malicious instructions in content your AI system processes — a document, an email, a web page — causing the model to act on the attacker's instructions rather than yours. In 2025–2026, production AI systems from Microsoft, GitHub, and OpenAI were all exploited through prompt injection in real-world incidents, including CVE-2025-53773, which enabled remote code execution through a hidden injection in GitHub Copilot with a CVSS severity score of 9.6. This is an active, documented threat class — not a theoretical concern.

Runaway costs are the fourth. Poorly bounded AI applications can trigger unexpectedly large inference runs — thousands of API calls for a single user action, loops that do not terminate, or queries that consume far more tokens than designed. At cloud AI pricing, a single monitoring gap in an agentic workflow can produce a billing surprise that arrives at the end of the month with no warning.

Gartner reported in April 2026 that 89% of AI agent pilots fail to reach production, with 40% of agentic AI projects expected to be cancelled by 2027 due to runaway costs, unclear ROI, and governance failures. The projects that survive are the ones built with operational discipline from the start — and operational discipline means monitoring.

The Three Dimensions of AI Observability

AI observability addresses these failure modes through continuous measurement across three distinct dimensions.

Performance observability tracks whether the AI application is doing what it was designed to do:

  • Response accuracy: Comparing model outputs against a ground-truth test set, or using an AI-as-judge approach to flag responses that deviate from expected answers
  • Latency: Response time percentiles (P50, P95, P99) — model degradation often appears as latency changes before accuracy changes do
  • Groundedness: For retrieval-augmented applications (those that query a knowledge base before generating), tracking whether the generated response is actually supported by the retrieved content, not invented by the model

Safety and security observability tracks whether the AI application is being abused or behaving unsafely:

  • Prompt injection detection: Scanning incoming queries and retrieved content for adversarial injection patterns in real time
  • Output policy monitoring: Flagging responses that violate content policies — a security concern, a brand risk, and a potential regulatory obligation under Canadian human rights law
  • Anomalous usage patterns: Identifying users or sessions querying in patterns inconsistent with normal use, which is an early signal of systematic probing or abuse

Cost and resource observability tracks whether the application is running within its designed resource envelope:

  • Token consumption per query: Average and outlier tracking to catch pathological queries before they produce billing surprises
  • API error rates and retry storms: Upstream API failures often trigger retry logic that dramatically inflates costs
  • Context window utilization: For applications that pass large amounts of context, monitoring window usage prevents both cost overruns and the accuracy degradation that comes from overlong contexts

What the CCCS Is Now Requiring

The Canadian Centre for Cyber Security published *Top 10 Artificial Intelligence Security Actions: A Primer* (ITSAP.10.049) in May 2026 — the first CCCS guidance document specifically addressed to organizations deploying AI systems. The guidance complements the existing IT security baseline (ITSM.10.089) with controls specific to AI-enabled infrastructure.

Three of the CCCS's ten actions directly address the operational monitoring problem:

  • Understand your AI system's trust boundaries: The CCCS recommends documenting what inputs the model accepts, what systems it connects to, and what it is permitted to do with outputs. This boundary documentation is the prerequisite for meaningful monitoring — you cannot detect boundary violations if the boundaries are not defined.
  • Monitor for anomalous or malicious AI use: The CCCS identifies post-deployment monitoring as a mandatory security control, not an optional enhancement. This includes monitoring for unusual query volumes, adversarial input patterns, and output policy violations.
  • Maintain oversight of AI decision-making: For AI applications making consequential decisions — approval, classification, routing — the CCCS recommends maintaining human oversight mechanisms and logging sufficient data to audit decisions after the fact.

The CCCS guidance is explicit that deploying AI without an operational monitoring layer undermines the security posture of the organization, regardless of how carefully the model was built and tested before deployment.

The Canadian Compliance Dimension

For Canadian SMBs, AI monitoring also carries a regulatory dimension that goes beyond security.

Bill C-36 (the Protecting Privacy and Consumer Data Act), tabled in June 2026, introduces an explicit transparency obligation for automated decision-making systems — including AI applications that influence decisions affecting individuals. Organizations using AI in customer-facing contexts must be able to explain how the system reached a determination and provide audit trails on request. An AI application with no monitoring layer has no audit trail to produce.

For organizations in regulated sectors, the Office of the Superintendent of Financial Institutions (OSFI) published a Technology Risk Bulletin on Generative and Agentic Artificial Intelligence requiring federally regulated financial institutions to implement monitoring controls before deploying generative AI in production. The bulletin's framing — that unmonitored AI in production constitutes unacceptable operational risk — reflects the direction of Canadian regulatory thinking more broadly.

The NIST AI Risk Management Framework, which the CCCS cites as aligned with its own guidance, includes a dedicated MANAGE function for post-deployment monitoring. The AI RMF treats ongoing monitoring as the mechanism by which all risk management work done before deployment remains meaningful over time. A model evaluated and approved in January that runs unmonitored through December has not had its risks managed — they were assessed once and then ignored.

A Practical Monitoring Stack for Canadian SMBs

Gartner predicts that 40% of organizations deploying AI will use AI observability to monitor model performance by 2028 — up from roughly 10% today. The organizations building this capability now are doing so with tools that are affordable and already available.

For Canadian SMBs building on Microsoft Azure:

  • Azure AI Foundry provides built-in model evaluation, content safety filtering, prompt flow monitoring, and grounding metrics. For applications built on Azure OpenAI Service, it is the most integrated starting point. Content safety filtering detects adversarial injection patterns and policy violations in real time at the query level, at no additional cost beyond the underlying inference usage.
  • Azure Monitor and Application Insights provide latency, error rate, and cost telemetry for the application layer. Custom metrics can track AI-specific signals including token consumption per session and cache utilization.

For teams using AWS or multi-cloud architectures:

  • Amazon CloudWatch with custom metrics provides cost and performance observability. Amazon Bedrock Guardrails handles content safety and prompt injection filtering for Bedrock-hosted models.
  • Datadog LLM Observability provides cross-platform AI application monitoring with vendor-neutral telemetry, semantic similarity scoring for drift detection, and dashboards designed specifically for generative AI workloads.

For teams that want open-source foundations:

  • LangSmith provides tracing, evaluation, and deployment monitoring for applications built on LangChain.
  • OpenTelemetry with the OpenLLMetry instrumentation library provides standards-based observability that integrates with most monitoring platforms without vendor lock-in.

A minimum viable monitoring setup for a Canadian SMB AI application:

1. Enable content safety filtering at the inference layer (built into Azure AI Foundry and AWS Bedrock Guardrails at no additional licence cost)

2. Log every query and response with a session identifier, timestamp, and token cost metrics — stored where they can be retrieved for audit

3. Run a weekly automated evaluation against a fixed ground-truth test set to track accuracy over time

4. Set cost alerts — both per-session and total monthly — in your cloud provider's billing console before you enable production traffic

5. Review your CCCS ITSAP.10.049 trust boundary documentation quarterly and update it as the application evolves

None of this requires a dedicated machine learning team. The tooling handles the instrumentation. What it requires is the deliberate decision to build monitoring in at the architecture stage — not retrofitted after the first incident.

Statistics Canada's Q2 2026 survey found that 19.2% of Canadian businesses now use AI to produce goods or deliver services — triple the rate of two years ago. As more Canadian SMBs build and deploy AI applications, the organizations that manage them operationally will look very different from the ones that deploy and walk away. That difference will not be visible at launch. It will be visible six months later, when the model has drifted and the questions have changed and the adversaries have had time to find the gaps.


Sources


Cloud Forces builds and manages AI applications for Canadian SMBs — and every application we deploy includes a monitoring layer with content safety filtering, cost alerting, and scheduled accuracy evaluation from day one. Explore our AIOps services or contact us to discuss adding observability to your existing AI application before it runs into a problem you cannot see coming.

Anton Kuznetsov
Founder & Principal Engineer

Anton Kuznetsov is the founder and principal engineer of Cloud Forces, the Toronto firm he started in 2018 to make custom software and AI practical and affordable for Canadian SMEs. He works hands-on across application development, cloud architecture, and the production systems Cloud Forces runs for its clients.

Ready to bring AI to your business?

Book a free AI Readiness Consultation — no commitment required.

Book Free Consultation