Guardrails

What guardrails are

Guardrails are the limits built into an AI workflow that set what it may do on its own and when a person steps in. The site’s audit method names four of them: oversight, logging, escalation and the point at which a person takes over. They are designed into the build rather than added once something has gone wrong.

This page uses that meaning. It does not describe how to configure any one tool. It explains what guardrails are for, where they sit in a workflow, how they decide what an AI may do alone, and why the person who owns the process should settle them before anything is built.

The idea is simple to say and easy to skip. An AI tool that drafts, sorts or acts will sometimes be wrong. Guardrails do not stop that. They decide what happens next: who sees it, how fast, and whether the mistake reaches a customer.

What guardrails cover in an AI Workflow

The how we audit page gives the list. In the Implement and Scale step, oversight, logging, escalation and the point at which a person takes over are designed into the build. Each one answers a different question.

Oversight answers who is watching. Logging answers what happened, so a run can be reconstructed afterwards. Escalation answers what the workflow does when it should not decide alone. The point at which a person takes over answers where the work stops being the AI’s and becomes a human’s.

Built-in guardrails are also one of the four principles in the well-scoped workflow article: a clear objective, a defined scope, built-in guardrails and a business impact that can be shown. The AI workflow page describes the repeatable process that those guardrails surround.

Guardrails are drawn in, not added

A workflow that gains steps carried out on its own also gains places where a mistake can travel unseen. That is why the site treats the review point as part of the design and not as something added after a problem.

The workflow design page says the guardrails are drawn in before a prototype exists, so the place where a person looks is decided on purpose and not found by accident once something has gone out the door. The same pages call this the difference between an automation the organisation can run and one that only whoever wrote it can run.

An agent shows why this matters. The agent article points out that in a chat you see a wrong answer and correct it, but in an agent a wrong early step can feed into later steps, and the error grows without anyone noticing. A guardrail is how you make sure someone notices.

The three moments to check

The output-checking article turns the review point into something you can find in your own process. It says to look for the moment where the AI’s output stops being a draft and becomes an action, and it names three moments that cover most small businesses.

The first is before a customer sees a reply. A reply drafted by AI is held until a named person releases it, and the article calls this the most visible checkpoint and the one most worth keeping strict. The second is before a label drives a decision. When AI sorts enquiries, tags complaints or scores leads, the label decides who sees the item and how fast, and a wrong label rarely looks like an error. It looks like a customer who waited a week. The third is before a summary is acted on, because a summary a person decides from has become the evidence.

Each of these is a guardrail in the site’s sense: a checkpoint designed in, with a named person, at a place chosen on purpose. The human in the loop page makes the same point from the other side. A rule that says a person should check the output is a hope, not a control, so the checkpoint has to be actually staffed.

What goes to a person

Escalation is the guardrail that decides which cases a person sees. The output-checking article says most mature set-ups use some mix of review before a response goes out, correction after it, and escalation to a person when the AI is unsure. For a small business it says the first and third are the ones worth building, because correction after the fact is what you do when the first two have failed.

The customer support article shows what escalation looks like in practice. It suggests writing a short list of triggers: a customer says the word complaint, mentions a refund, asks for a manager, repeats a question twice, or sounds upset. It adds topics that are always off limits, such as legal advice or medical claims. It says these rules matter more than any setting for tone of voice, and that they are what turns a mistake into a handover.

Planning them in advance is exception handling. That page says the right answer names an owner, a queue or a notification, and says whether the action is reversed or held. A vague answer about the model being very accurate is not a plan.

What an AI may do alone

The other half of the design is how much each step may do without a person. The task and decision article sorts every step onto a four-level ladder: Assist, Recommend, Execute or Never delegate. The delegation ladder page sets out the test, which depends on volume, consequence, reversibility, how clear the rules are, and whether the decision needs legitimacy a model cannot supply.

Only high-volume, reversible steps governed by clear rules move to Execute. Ambiguous or judgement-heavy steps stay at Assist or Recommend with a named person accountable. Hiring, dismissal and anything with legal, safety or rights implications stay off the ladder entirely, whatever the technology could do.

Reversibility carries much of the weight. The first-task article calls keeping a step reversible the cheapest form of safety there is: a draft nobody has sent is fully reversible, and a sent email is not. A guardrail that holds a draft until someone releases it turns an irreversible step into a reversible one.

Guardrails in the Prompt

Some guardrails live in the instructions given to the AI. The hallucinations article lists three that lower the odds of an invented answer. Allow the AI to say it does not know, so it has an alternative to guessing. Tell it to answer only from the documents you supply. Ask it to quote the passage behind each claim, and drop any claim it cannot support.

The article is careful about the limit. A prompt lowers the odds of an invented answer without removing them, so the output still needs checking. That is why a prompt is one guardrail among several and not a substitute for a person at the checkpoint. A hallucination can still get through an instruction that told the AI not to make things up.

Guardrails and access

What an AI can reach is a guardrail too. The agent article says an agent that reads documents or reaches systems is a decision about data: what it may see, where that information goes and who can read the results all need an answer before the build. The vibe coding article makes the same point about software built with AI, saying the tool should reach only what it needs and nothing that would cause harm if it were wrong.

The MCP vs API review turns access into a short routine for a connected assistant. Start read-only, so the assistant can look before it can change anything. Connect one thing at a time. Keep a person approving the actions that matter, such as sending, deleting and paying. Know who can connect what, and decide it as an AI governance question with a named owner. Log what the assistant does.

Logging and the Audit trail

Logging is the guardrail that lets you answer for what happened. The audit trail page defines it as the record a workflow keeps of each run: the input, what the model returned, what was approved and by whom, and what changed downstream. It is what lets any single run be reconstructed after the fact.

That page also says the record can be light for a smaller organisation: a log, a named owner and a person checking the risky steps. A chatbot keeps a transcript, which shows what was said and not what was done, so a workflow a business can answer for keeps a record of the work itself.

For a business that deploys a high-risk system, the documentation obligation page notes, citing the ownership article, that the system’s logs must be kept for at least six months. Whether or not that applies to you, the principle is the same: you cannot review what you did not record.

What they do not change

Guardrails do not make an answer correct. They decide what happens when it is not. A mistake can still be made; the guardrail makes sure it reaches a person before it reaches a customer.

They do not remove the person. Every guardrail on this page ends in a named person at a chosen moment, and the human in the loop page is explicit that the checkpoint has to be staffed.

And they do not last without an owner. The drift page says an AI tool does not stay as it was installed, so a review done at launch describes a tool that no longer exists in quite that form. The audit method answers this by asking for an internal owner for each workflow that goes live, and for staff trained to run and change what was built, so the operation belongs to the organisation and not to whoever built it.

A worked example

An illustration, not a case study. A small business wants an assistant to draft replies to customer enquiries from its own approved answers.

The guardrails are decided before the build. The assistant drafts and a named person releases every reply, which is the first checkpoint. A short list of triggers sends a case straight to a person: a complaint, a refund, a request for a manager, or a customer who has asked the same thing twice. Legal advice and medical claims are off limits. The assistant may read the folder of approved answers and nothing else, and it cannot send anything on its own, so every step is reversible until a person releases it. A log records each draft, who released it and what was sent.

An operations lead is named as the owner. For the first weeks they read a sample of the drafts each day, and they note each failure. A repeated failure on the facts means the approved answers need fixing, and a repeated promise the business cannot keep means the instructions need tightening. The guardrails are what let them see those patterns early.

Mix-ups worth avoiding

Four confusions come up often enough to name. The first is treating guardrails as a feature of the model, when the site uses the word for the design of the workflow around it. The second is treating a rule that says a person should check as a control, when the checkpoint has to be staffed. The third is adding them after launch, when they are meant to be drawn in before a prototype exists. The fourth is treating them as finished, when an unowned workflow drifts and the checking has to keep moving.

How we use it

In the Implement and Scale step of how we audit, oversight, logging, escalation and the point at which a person takes over are designed into the build. Scaling happens one proven workflow at a time. Your side names an internal owner for each workflow that goes live, and what comes out is workflows in production with their oversight defined.

If you want to know where a person should sit in a process you already run, a discovery call is a quick way to start.

Sources

• How we audit: oversight, logging, escalation and the point at which a person takes over designed into the build, the Implement and Scale step, an internal owner for each workflow that goes live, and staff trained to run and change what was built.
• Well-scoped AI workflow: the four principles, built-in guardrails among them, and the review point in the choice of the first process.
• How to check AI output before it goes to a customer: the three moments to check, and review before, correction after and escalation when the AI is unsure.
• AI customer support for small business: triggers that send a case to a person, topics that are always off limits, and guardrails turning a mistake into a handover.
• The difference between automating a task and automating a decision: the ladder and what stays off it.
• How to reduce AI hallucinations: allowing the AI to say it does not know, restricting it to the documents supplied, asking for the quote, and a prompt lowering the odds without removing them.
• What is an AI agent?: errors compounding across steps, and access being a decision about data.
• MCP vs API and Vibe coding for business: starting read-only, a person approving actions that matter, logging, and the tool reaching only what it needs.
• Workflow design, AI workflow, Exception handling, Delegation ladder, Reversibility, Audit trail, Documentation obligation, Drift and Human in the loop: the neighbouring terms this page links to.