Private AI is an operating model, not only a hosting location

On-premises does not automatically mean private

An application can run in a local data centre and still send prompts to an external model, expose documents through weak permissions or depend on unmanaged updates. A cloud service can, in some circumstances, operate within a carefully designed and controlled boundary.

The useful question is not only “Where is the server?” It is “Who can access each part of the service, where does the information travel and who can change that behaviour?”

Follow one request from start to finish

Take a representative user question and trace it. Which identity signs in? What document stores are searched? Is content copied into an index? Which text is sent to the model? What is logged? Does a workflow call another system? Who can support or administer each component?

This simple exercise usually reveals that private AI is a chain of controls rather than a single hosting choice.

Control the complete boundary

• Identity: authentication, roles, source permissions, privileged access and support access
• Information: collection, indexing, derived data, prompts, responses, logs, retention and deletion
• Models: hosting, provider terms, model updates, training use, safety controls and fallback
• Workflows: integrations, actions, approval points, retries, failure handling and audit history
• Operations: monitoring, incidents, backups, continuity, patching, change approval and exit

The National Cyber Security Centre provides guidance on deploying AI systems securely and AI supply-chain risk. Privacy questions should also be considered against current guidance from the Office of the Privacy Commissioner.

Do not forget derived information

Teams may protect source documents but overlook embeddings, extracted text, caches, prompts, responses and execution logs. These can still reveal sensitive content or relationships. They need owners, access rules, retention decisions and deletion processes.

Likewise, removing a source document is not enough if an old indexed copy remains searchable. Test how corrections, permission changes and withdrawals move through the complete system.

Operations decide whether the design stays private

A strong launch design can drift through model changes, new integrations, supplier updates, emergency support or temporary workarounds. Name the people responsible for monitoring, access administration, incident response, change approval and periodic review.

Plan portability and exit before they are needed. The organisation should understand how it retrieves its content and records, changes a provider and removes data from each component.

Questions for a private-AI claim

• Can we draw the complete data path, including logs and supplier systems?
• Which people and organisations have privileged access?
• Do source permissions remain effective after indexing and retrieval?
• Can a model or supplier use our information for another purpose?
• What happens when a document is corrected or withdrawn?
• Who approves changes to models, integrations and retention?
• Can we continue or exit if a component becomes unavailable?

Where Pūnaha fits

Pūnaha supports private-AI deployment choices, including customer-controlled infrastructure and Pūnaha Cloud, with supported local and external models. The implementation architecture still determines the actual control boundary.

Talk to us about private-AI design and governance or review Pūnaha's current technical boundaries.

A note about this article

This is general information from Hot Desk Consultancy Services Limited. It does not certify a service as private, secure, compliant, sovereign or air-gapped and is not legal, privacy, security, architecture or procurement advice.