Your company has an AI platform, and soon everyone will use it every day. They will paste contracts into it, ask it about customers, and sooner or later someone will ask it what a colleague earns. How smart the model is will not decide whether this goes well. What decides it is what stops the model from doing something your company will regret.

That is what AI guardrails are for. Every vendor says they have them. Few can tell you where they run or who controls them. This post is for the people who have to answer for the rollout: IT, security, legal, data protection and the department heads whose teams will use it.

What an AI guardrail is, and what it is not

A guardrail is a technical control that limits what an AI system can receive, do or return. It sits around the model: it filters inputs, limits which tools and data the model can reach, checks outputs, and logs what happened. The system enforces it. The model is not asked to comply.

That difference matters. A line in a system prompt saying "never reveal confidential data" is a polite request to a probabilistic system, nothing more. Your employees will not be the only ones testing its limits. Curious colleagues will test it, and so will tired ones. Eventually someone who means harm will too.

The research explains why. Wei et al. (2023), in Jailbroken: How Does LLM Safety Training Fail?, show that safety training fails in two predictable ways: when a model's goals compete with each other, and when a prompt falls outside what the training covered. Zou et al. (2023) showed that automatically generated adversarial suffixes could push aligned models into harmful output, and that those attacks transferred between models. Safety that lives only inside the model can be argued with. That is the whole case for putting controls outside it.

Internal AI risks: what can go wrong inside your own walls

Most internal risks are ordinary. That is what makes them dangerous: they scale with every new user.

Start with access. Connect an AI to your document stores with broader permissions than the person asking has, and it will happily answer from files that person was never meant to read. OWASP's Top 10 for LLM Applications (2025 edition) files this under excessive agency: the system can reach more than the task needs.

Then there is content that carries hidden instructions. Greshake et al. (2023) described indirect prompt injection: instructions buried in a web page, an email or a shared document that the AI later reads and obeys, without the employee ever seeing them. A supplier's PDF can become an instruction to your assistant.

And there are confident wrong answers, which need no attacker at all. Colleagues act on what the system tells them, especially when it sounds sure.

A guardrail that only scans the chat box misses most of this. Real guardrails sit at every boundary: what goes in, what the model may retrieve, what it may do and what comes out.

Who is liable when an AI chatbot gets it wrong? Ask Air Canada

If you think an AI mistake is the model's problem, ask Air Canada. In Moffatt v. Air Canada (2024 BCCRT 149), a customer received wrong information about bereavement fares from the airline's website chatbot. The airline argued, in effect, that the chatbot was its own entity and the company was not responsible for what it said. The tribunal rejected this:

"It makes no difference whether the information comes from a static page or a chatbot."

That case involved a customer facing bot, but the principle travels inside the company too. When an employee sends a client an AI-drafted answer, or acts on an AI-generated summary, the organisation owns the result. That responsibility does not pass to the model, and it does not pass to the vendor either.

EU AI Act deployer obligations: Articles 4, 14 and 15

The EU AI Act (Regulation (EU) 2024/1689) does not only address the companies that build AI. It also places duties on the organisations that use it, called deployers. Article 4 requires measures to ensure "a sufficient level of AI literacy" among staff and others who operate and use AI systems on the organisation's behalf. Your people need to know how to use this safely, and the platform should make that easier rather than harder.

For high-risk systems, Article 14(1) goes further and requires that they are:

"designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use."

Article 15(1) adds that such systems must achieve "an appropriate level of accuracy, robustness, and cybersecurity" and "perform consistently in those respects throughout their lifecycle."

Not every internal use case is high-risk, but the direction is clear. Effectively overseen. Throughout their lifecycle. These describe controls that work every day and that someone in your organisation can inspect. A promise made once at procurement does not meet that bar.

The NIST AI Risk Management Framework (AI RMF 1.0) lands in the same place. It describes trustworthy AI as valid and reliable, safe, secure and resilient, accountable and transparent, explainable and interpretable, privacy-enhanced, and fair with harmful bias managed. Most of that list is about the system around the model, which is the part you are buying.

Why AI guardrails and data sovereignty belong together

If your guardrails run in someone else's environment, under someone else's jurisdiction, with rules someone else can change overnight, your safety layer is just another dependency. The risk has moved. It has not gone anywhere.

Control over where your data lives and control over how your AI behaves are the same question asked twice: who decides? For your organisation, the answer should be you.

What enterprise AI guardrails should look like

A platform your employees can rely on should pass a short list of tests. Controls are enforced outside the model, where a clever prompt cannot easily argue with them. They cover every boundary, including what the model retrieves and which tools it calls, and not just the chat window. Access mirrors your organisation, so the AI only reaches the data a given employee is already allowed to see. The rules are yours: your administrators configure policies for your sector, your data classification and your risk appetite. Every block and every override is logged where your own team can see it. Red teaming is on the calendar, and stays there after launch. And people stay in the loop wherever the consequences justify it.

Questions to ask an AI vendor about guardrails

Ask any AI vendor where the guardrails run and what exactly they enforce. Ask who in your organisation can change the rules, and who at the vendor can. Ask how the platform stops an employee from reaching data they are not allowed to see. And ask how the guardrails are tested, and whether your own security team can test them too.

If the answers are specific, you are talking to someone who has built a control. If they are vague, you have been handed a policy and a pitch.

If your organisation cannot inspect the AI, your employees should not be asked to trust it. Guardrails are something you should be able to see and test. Belief is not a control.

GLBNXT builds EU-hosted, ISO 27001:2022-certified AI infrastructure for regulated organisations, with guardrails configured and controlled by the client's own administrators. www.glbnxt.com

Sources

• Wei, A., Haghtalab, N., Steinhardt, J. (2023). Jailbroken: How Does LLM Safety Training Fail? https://arxiv.org/abs/2307.02483

• Zou, A., Wang, Z., Kolter, J. Z., Fredrikson, M. (2023). Universal and Transferable Adversarial Attacks on Aligned Language Models. https://arxiv.org/abs/2307.15043

• Greshake, K. et al. (2023). Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection. https://arxiv.org/abs/2302.12173

• OWASP, Top 10 for Large Language Model Applications (2025): https://owasp.org/projects/top-10-for-large-language-model-applications

• Moffatt v. Air Canada, 2024 BCCRT 149 (British Columbia Civil Resolution Tribunal): https://www.canlii.org/en/bc/bccrt/doc/2024/2024bccrt149/2024bccrt149.html

• Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 4: https://artificialintelligenceact.eu/article/4/

• Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 14: https://artificialintelligenceact.eu/article/14/

• Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 15: https://artificialintelligenceact.eu/article/15/

• NIST (2023), Artificial Intelligence Risk Management Framework (AI RMF 1.0): https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf