A demonstration that answers questions fluently is a satisfying milestone. It is also, in our experience, roughly a tenth of the work required to put AI safely in front of customers, citizens or staff. The remaining effort is less visible: deciding where the system runs, who is accountable for it, how it is protected, what it must never say, and whether it fits the infrastructure it will live on.
We call the discipline of doing that work Fenced AI. The idea is simple. A capable model sits at the centre, and a series of rings around it constrain, protect and support it. Each ring answers a different question, and skipping any of them creates a risk that the model's capability cannot compensate for.
The six rings
1. Capability
Does the model do the job well enough?
This is the ring most teams start and stop with. It covers model selection, prompt design, retrieval over your own content, fine-tuning where justified, and above all evaluation. Good evaluation means a representative test set built from real tasks, clear pass criteria agreed with the business, and measurement across the languages and user groups you serve. "It looked good in the demo" is not an evaluation.
2. Architecture
How does the model fit into the wider system?
A model is one component in a chain that includes data sources, orchestration, user channels, logging and fallbacks. Architecture decisions determine latency, cost, resilience and portability. Questions to settle here include where inference runs, how requests are routed between models, how the system behaves when a dependency is unavailable, and how hard it would be to replace the model in future.
3. Governance
Who decides, who is accountable, and how do we know it is working?
Governance turns good intentions into a repeatable process. It includes a risk classification for each use case, named owners, approval gates before go-live, documentation of intended use and known limitations, and ongoing monitoring for accuracy, bias and drift. For decisions that materially affect people, such as credit, employment, benefits or health, it also means meaningful human oversight and a way for people to challenge outcomes.
4. Security
How could the system be attacked or misused?
AI systems introduce threats that conventional application security does not cover. Prompt injection can turn a helpful assistant into a channel for exfiltrating data. Retrieval systems can expose documents to users who should not see them. Training data can be poisoned. This ring covers threat modelling for AI-specific risks, red-teaming before launch, least-privilege access to tools and data sources, secrets management, and logging that allows investigators to reconstruct what happened.
5. Content Safety
What must the system never produce, and how do we enforce that?
Even a secure, well-governed model can generate content that is harmful, inaccurate, off-brand or legally risky. Content safety defines the boundaries: topics to decline, claims the system must not make, tone and disclosure requirements, and how to handle sensitive subjects. Enforcement combines instructions to the model, input and output filters, grounding answers in approved sources, and escalation to a human when confidence is low.
6. Infrastructure Fit
Will this run reliably and affordably where we need it to?
The final ring checks that the solution matches its operating environment: hosting location and data residency obligations, power and connectivity conditions, available compute, operational support and total cost of ownership in local currency. A system that is excellent in a test environment but unaffordable or unreliable in production has not been delivered.
Why the rings matter together
The rings are interdependent. A strong governance process cannot compensate for an architecture that sends confidential data to an unvetted endpoint. Excellent security does not help if content safety is absent and the assistant gives harmful advice. Treating each ring as a separate checklist owned by a separate team tends to leave gaps at the boundaries, which is where most real incidents occur.
In practice, we find it useful to review all six rings together at three points:
- At use-case approval, to decide what level of control the risk warrants.
- Before go-live, to confirm that each ring has been addressed and evidence exists.
- On a regular cycle in production, because models, data, threats and regulation all change.
A proportionate approach
Not every use case needs the same depth in every ring. An internal tool that summarises public documents carries less risk than a customer-facing assistant handling account information. The point of Fenced AI is not to slow every project down, but to make the level of control a deliberate, documented decision rather than an accident.
Where to start
If you already have AI in production or in pilot, a useful first exercise is to take one system and ask the six questions above. For each ring, note what is in place, what evidence exists, and who owns it. Gaps are normal. What matters is knowing where they are and deciding, consciously, which ones to close first.
A working model is a genuine achievement. Making it trustworthy, secure and sustainable is the other ninety per cent, and it is the part that determines whether the investment pays off.
