Observability in AI Systems
A guardrail is a function of the system, not a fixed component. The same function can be placed in different parts of the architecture.
A Paste That Nothing Stopped
Picture an employee who is trying to get help with a task. They copy confidential material from their work and paste it into a public AI tool. Nothing in the tool stops the paste, and nothing flags that the text is sensitive. In a single action, the information has left the company's control. This is the kind of event that guardrails exist to prevent.
The source describes a real case of this pattern: a Samsung employee put the company's proprietary information into ChatGPT, accidentally leaking the company's secrets. The lesson is not about one employee. It is about an AI application that had no check standing between the user and the model.
Before reading on, pause and ask yourself a question: if a company wants a safety check on what goes into a model, where could that check be placed in the application? You do not need a precise answer yet. Just think about which parts of an AI application a check could sit in. The rest of this article follows that question through the architecture.
Following One Request Through an AI Application
To see where a safety check can go, trace what happens to a single request. A user sends a message. The message travels through the application's layers until the model produces a result, and that result travels back to the user. Every layer along this path is a possible location for a check.
Consider a customer support chatbot built on a foundation model. At first, the application passes user messages straight to the model and returns whatever comes back. Nothing inspects the message on the way in, and nothing inspects the answer on the way out. The team then decides it needs a check on incoming messages that might contain confidential data. The diagram below shows one possible path a request could take once that check is added. The source does not fix an order among these places, so treat this arrangement as one example rather than the only correct layout.
Read the diagram as a question about interception points. A check that sits before the model sees the message can stop confidential text before it leaves the company. A check placed after the model answers can inspect what the application is about to return. The rest of this article explains the three named places a guardrail can live, and why choosing among them is a design decision rather than a formality.
What a Guardrail Is
A guardrail is a technique used to keep an AI application safe and reliable. It is a function the system performs, and that function can be built into different parts of the architecture.
The important word in that definition is technique. A guardrail is not one specific product, and it is not one fixed piece of code. You can think of it as a job the system must do, namely checking and constraining what goes in and comes out so that the application stays safe and dependable. Because the job is separate from any particular product, you can reason about the guardrail as a function on its own terms before deciding where it lives.
A guardrail is a function of the system, not a fixed component. The same function can be placed in different parts of the architecture.
Guardrails matter because AI applications can fail in ways that are costly to undo. A leaked secret cannot be taken back once it has left the company's control, as the paste example showed. Guardrails aim to reduce the chance of such failures. They do not remove the need to watch for failures that still occur, which is where observability enters the picture later in this article.
Three Places a Guardrail Can Live
The source names three places a guardrail can be implemented. The first is the inference service, the second is the model gateway, and the third is a standalone component. The source does not rank these three, and it stresses that the boundaries between components are fluid. A single guardrail function might fit naturally in more than one of them. Each place is described below.
Comparing the Three Placements
The placement is an architectural decision, and that decision shapes how the rest of the system depends on the guardrail. The diagram sets the three named places side by side, so you can see what each one is.
When you compare the three, notice that the first two are existing parts of the system that a guardrail can be attached to, while the third is a part created for the guardrail. The source does not say which is best. It says the choice shapes dependencies, and that the separation between components is fluid, so one function may fit several places. Keeping the guardrail as a function, separate from its location, lets you move it later without redefining what it does.
Watching a Flagged Response Get Recorded
Guardrails reduce the chance of certain failures, but failures can still happen. The source places guardrails alongside monitoring and observability, which it calls an integral part of any complex system. Observability is defined as understanding how your system fails, designing metrics and alerts around those failures, and ensuring the system is designed so that failures are detectable and traceable.
The sequence below follows a single request through a guardrail that checks input and output, and shows how the event reaches a monitoring record. The records are illustrative, but the principle is the one the source describes: a flagged event must be linked back to the request and component that produced it.
Read the sequence as a set of ordered messages. The guardrail sends the flagged event to the monitoring record in step three, and that record keeps a link to the request. Later, when someone asks why a response was blocked, the team can start from the record and trace back to the request and the component involved. That is what it means for a failure to be traceable.
Why Foundation Models Change Monitoring
The source notes that many observability practices and tools from software engineering and traditional machine learning still apply to AI engineering. Those older practices are not discarded. However, foundation models introduce new failure modes, and those failure modes require additional metrics and design considerations.
The practical consequence is that a team relying only on the older tools may miss failures specific to foundation models. Monitoring must be designed around the failures the system can actually produce, not only around the failures that traditional monitoring was built to catch.
The Trade-Off Every Component Brings
A natural instinct is to add guardrails everywhere. The source warns against reading added components as free improvements. Every added component can make a system more capable, safer, or faster. The same addition also increases the system's complexity and exposes it to new failure modes. Each addition therefore has two sides, and both belong in the design decision.
| Side of the decision | What the addition gives | What the addition costs |
|---|---|---|
| Capability | The system can do more than before | More parts to design and keep consistent |
| Safety | Certain failures become less likely | New failure modes appear inside the new component |
| Speed | The system can be made faster in the ways the design intends | Growing complexity makes the whole system harder to reason about |
| Observability need | Failures in the new part can be detected and traced | Additional metrics and design considerations must be maintained |
Every added component trades gains against complexity and new failure modes
Placing the Check in the Chatbot
Choosing a home for the input check
The support chatbot needs a check on incoming messages that might contain confidential data. The team must decide whether the check belongs in the inference service, the model gateway, or a standalone component.
- 1Name the function
The function is to check incoming messages for confidential data before the model processes them. Keep this separate from any location.
- 2List the three homes
The inference service runs the model, the model gateway is the layer requests to models pass through, and a standalone component exists only to do the guardrail job.
- 3Weigh coupling
A check inside the inference service is tied to how the model runs. A standalone component can be changed without touching that work. The gateway sits between the two in terms of its view of traffic.
- 4Account for the trade-off
Whichever home is chosen, the team must account for the added complexity and the new failure modes it introduces, and must plan how to detect and trace failures in that check.
No single home is declared correct by the source. A reasonable team picks the placement that fits its architecture, documents the dependency it creates, and makes sure the check's events are recorded so failures can be traced.
Mistakes When Adding Guardrails
Common mistake Treating a guardrail as a specific product
Why it failsThe source defines a guardrail as a technique, a function the system performs, not one fixed product or piece of code.
Do this insteadDescribe the safety function first, then decide where it lives in the architecture.
Common mistake Assuming added components are free improvements
What it looks likeA team adds a check in every layer and assumes the application is strictly better.
Why it failsEach component can add capability, safety, or speed, but it also increases complexity and exposes the system to new failure modes.
Do this insteadRecord both sides of each addition and weigh them in the design decision.
Common mistake Relying on prevention alone
Why it failsA guardrail reduces the chance of certain failures, but failures still happen. Without observability, they may go unnoticed.
Do this insteadDesign metrics and alerts around expected failures, and make failures detectable and traceable.
Common mistake Using only traditional monitoring for a foundation model
Why it failsThe source says foundation models introduce new failure modes that require additional metrics and design considerations.
Do this insteadKeep the older practices that still apply, and add monitoring for the failures specific to foundation models.
Applying the Trade-Off to a New Layer
A team proposes adding a second guardrail that checks the model's output before it reaches the user. Using the four sides of the trade-off, describe one likely gain in safety, one likely cost in complexity, and one new failure mode the team should plan to detect. Then say which of the three placements you would start with and why.
Hints
- Start from the definition: a guardrail is a technique that keeps the application safe and reliable.
- Each addition can give capability, safety, or speed, but it also adds complexity and new failure modes.
- Think about how a flagged output would reach a monitoring record, so that the event can be traced back to its request.
Key Takeaways
- A guardrail is a technique that keeps an AI application safe and reliable. It is a function the system performs, not one fixed product.
- The three named places for a guardrail are the inference service, the model gateway, and a standalone component. The source does not rank them, and the placement is an architectural decision.
- Every added component can make the system more capable, safer, or faster, but it also increases complexity and exposes the system to new failure modes.
- Guardrails reduce the chance of certain failures, while observability makes failures detectable and traceable. Foundation models need additional metrics beyond older monitoring practices.