Guardrails.

Language models are powerful but not reliable in the way classic software is. They can hallucinate, be talked round by cleverly worded input or overlook a rule in the system prompt. Guardrails therefore operate outside the model: they are rules and checks in the surrounding system that apply whatever the model happens to 'think'. The term comes from road building, where a crash barrier does not steer the vehicle but stops it leaving the road.

Broadly, there are four kinds. Input checks filter requests, such as prompt injection attempts or topics the assistant is not responsible for. Output checks review answers before they are shown, for personal data, prices outside the list or missing sources, for example. Action limits restrict which tools an agent may use and with which rights, read-only for instance. And approvals require a person to confirm sensitive steps, see human-in-the-loop.

Guardrails matter more the more a system can do on its own. A chatbot or voice agent that only answers questions can damage trust with a wrong answer. An AI agent that sends emails or changes data through an MCP connector, or operates a user interface via computer use, can do real damage. Hence the principle of least privilege: an agent gets only the tools and data it needs for its task, and critical actions are technically tied to approval.

Guardrails are also about being able to demonstrate control. If you use AI in customer contact, you should be able to show which rules apply, how they were tested and what happens when something goes wrong. For providers with an EU connection, the EU AI Act requires transparency and controls depending on the risk class; in Switzerland the principles of the Federal Act on Data Protection (FADP, SR 235.1) apply. This is context, not legal advice.