Four Terms, Four Different Boundaries

Four terms get used interchangeably in AI procurement, and they represent four different technical boundaries. Getting them confused is how organisations end up with a deployment that satisfies a marketing requirement and fails an audit question.

The axis that separates these is not where the data sits. It is who can technically reach the model and the data — as distinct from who has contractually promised not to. That is a control question, and control questions are the ones that survive an audit.

Who Actually Needs the Strict Version

Air-gapped deployment is expensive relative to an API call. It is justified in a narrow but growing set of circumstances, and it is worth being honest about which you are in.

If none of those apply, a well-governed cloud deployment with proper contractual and technical controls is usually the correct answer. Sovereignty theatre — an isolated deployment procured to satisfy a stakeholder's instinct rather than a requirement — is real cost for no control benefit.

What You Give Up, Stated Honestly

Vendors selling private AI tend to skip this section. It is the section that determines whether the project succeeds.

The Architecture, in Control Terms

Described as controls rather than components, an air-gapped deployment needs:

  • Local inference: Open-weight models served on your hardware, inside your boundary, with no external call path at runtime.
  • Local retrieval: Documents embedded and indexed on your infrastructure, enforcing the source system's least-privilege permissions.
  • Scoped tool access: Any action-taking capability constrained to least privilege, with identity tied to the requesting user rather than a shared service account.
  • Full audit trail: Prompts, retrievals, tool calls, and outputs logged and retained inside the boundary.
  • A controlled update path: Documented, authorised, verified, and logged.

Where the Regulatory Picture Is Heading

The EU AI Act's transparency obligations under Article 50 became applicable on 2 August 2026, with the marking and detection requirement reaching systems already on the market from 2 December 2026. High-risk obligations were deferred by Regulation (EU) 2026/1744 — published in the Official Journal on 24 July 2026 — to 2 December 2027 for standalone Annex III systems and 2 August 2028 for AI embedded in Annex I regulated products. The deferral buys documentation time; it does not remove the documentation.

In the UK, the Cyber Security and Resilience Bill, introduced in November 2025, cleared the Commons and entered the Lords in June 2026. It puts managed service providers and designated critical suppliers into a statutory regime with expanded incident reporting duties, and it places the NCSC's Cyber Assessment Framework on a firmer footing.

For AI deployment decisions, the practical read is this: the questions your clients will ask about your AI systems are converging on the questions regulators ask about your other systems. Where does the data go, who can reach it, what did the system do, and can you prove it. An isolated deployment answers the first two structurally. The last two you still have to build.

Further reading: Tokenisation vs Encryption Under UK GDPR: Which Protects Personal Data Better, and When? and ISO/IEC 42001 Readiness: A Practical Guide for UK Organisations Building an AI Management System.

Where the Pyralink Products Fit

Pyralink builds products for secure AI adoption. AI Paste Guard checks text pasted into AI chat tools locally in the browser.

Request a Demo ↗

Sources: Regulation (EU) 2024/1689 (EU AI Act) and Regulation (EU) 2026/1744 (Digital Omnibus on AI, in force 27 July 2026); Cyber Security and Resilience (Network and Information Systems) Bill, UK Parliament; OWASP GenAI Security Project agentic risk taxonomy.