Why can on-premises AI be safer?
Control the routes by which your data can leave
Practical Guides: Part 3
“Is this AI secure?” This is often the first question when you propose introducing generative AI at work. It is understandable if you cannot answer immediately: security can sound like a specialist subject. A useful place to start is a simpler question: where does the data travel, and where does it arrive? This article explains that approach and gives you practical wording for internal discussions, without specialist jargon.
Propose generative AI internally and someone is likely to ask, “Is it secure?” or “How do we know personal information will be protected?” It can be tempting to reply only that the vendor says it is safe.That answer gives decision-makers too little evidence.This article helps you explain the relevant boundary in your own words.
- What you will learn: 1 A way to discuss security without being a technical specialist
- What you will learn: 2 How the controls and responsibilities differ between cloud and on-premises AI
- What you will learn: 3 How to support an internal decision without promising that a breach is impossible
The key idea
An important benefit of properly configured on-premises AI is that the local workflow can keep data inside your organization.Think of cloud AI as sending a document to an outside translation company. The document leaves your premises, so contracts, safeguards and evidence of the provider’s practices matter. Local AI is closer to having a translator working at an internal desk. The external transfer is avoided, but you still need to decide who may see the document and how copies, access and output are controlled.
Why “Is it secure?” is hard to answer
The difficulty is not necessarily a lack of expertise. The question needs a defined scope before it can be answered responsibly.
You cannot prove that no breach will ever occur
One incident demonstrates that a breach is possible. Showing that it can never happen, under every future condition, is a much stronger claim. Technical specialists cannot honestly make that universal promise either. Define the system, the threats and the controls you can actually verify.
In practical terms: Treat an unconditional guarantee of “no leaks ever” with caution. Ask what specific boundary and evidence the statement refers to.
Security is treated only as a technical discussion
Encryption, authentication and vulnerability management quickly introduce specialist vocabulary. Those details matter, but an internal proposal can begin with a concrete question: where will this information go? Establish that data path first, then connect it to the controls that protect it.
In practical terms: A question that sounds purely technical often includes a question about destination. You can explain the intended destination while specialists validate its implementation.
The explanation relies only on reassurance
Cloud services may commit not to train on inputs or disclose them to others. Assess those commitments alongside configuration, certifications, audit evidence and contractual remedies. If you have gathered none of that evidence, your explanation can stall at “the vendor says so.”
In practical terms: A sound approval case needs evidence appropriate to the service and the risk, whether the deployment is cloud or local.
Start with the data path
A disclosure occurs when information becomes available outside the people or systems authorized to receive it. Understanding the paths by which that could happen is a useful starting point. Closing an external network route removes that route; other paths, such as endpoints, removable media or misuse, still need controls.
Cloud conversational AI
In this typical cloud workflow, the entered text is sent to the provider’s environment for processing. Your assessment must therefore cover transmission security, retention, access, training use and the provider’s controls and commitments.
On-premises conversational AI
In the illustrated closed-network workflow, inputs travel over the internal network and are processed on the appliance. No external AI service is required. Questions about access and interception are therefore addressed within your organization’s network and endpoint controls.
This is why a defined aspect of on-premises AI security can be checked directly. It is not a proof that nothing can ever leak. Your IT team can inspect routes, firewalls, wireless connections and system behavior, document the findings and provide the same evidence to auditors.
How do you explain the security of your office equipment?
A helpful starting point is to describe on-premises AI as another managed system on your internal network, alongside file servers and office equipment
. Contracts and customer lists pass through printers; management records live on file servers. When asked about their security, you would explain their placement, access controls and operating rules, rather than promise that a breach is impossible.Use the same grounded approach for local AI, then account for its specific risks.
A familiar location
Printers, file servers and on-premises AI may all sit on the internal network. Whether outside access is possible depends on the routes, firewall rules, remote access and device configuration.
A familiar control framework
Physical access, accounts, passwords and permissions already have owners in many organizations. Extend those controls to AI, and add any necessary rules for document access, prompts, external tools and generated outputs.
A familiar way to explain the system
You can begin with the existing server-review process instead of treating AI as wholly unfamiliar. The review still needs to cover model and application behavior, sensitive-data access and any AI-specific threats.
“This AI appliance sits on our internal network, alongside our other managed systems. In the approved local configuration, inputs are not sent to an external AI service. We apply our internal security controls and verify the configuration and remaining risks.”」
Three questions to prepare for
Three questions provide a useful starting point for an approval discussion or a customer explanation. They do not replace a full security review, but answering them clearly helps establish the scope.
Where does the input data go?
To the appliance in our internal environment, for the approved local workflow.Processing and storage take place there without sending the input to an external AI service. Also identify any copies on client devices, backups, logs and exported results, so retention is understood throughout the workflow.
Who can see the data?
People whose access your organization authorizes, subject to the configured controls.The company manages accounts and can revoke access when someone leaves. In the isolated local configuration, inputs are not automatically sent to FIXER. Review any support access or diagnostic sharing separately, and verify administrative privileges and endpoint security.
Could the data be used to train an outside AI model?
Not through a workflow that does not send it to that outside provider.With cloud AI, check the service’s terms, settings and evidence governing training use. With isolated local AI, the external transfer can be avoided. Internal model training and document-reference retrieval are separate questions that should still be clearly defined.
Common assumptions and the practical reality
| Common assumption | Practical reality |
|---|---|
| If you cannot promise zero leaks, it is not secure | Nobody can promise absolute protection under every condition.Describe the specific boundary, the evidence supporting it and the remaining controls. That is more useful to auditors and business partners. |
| Cloud AI with training disabled is identical to local AI | The setting addresses training use under the service’s terms and controls.It does not change the fact that processing occurs outside your premises. |
| A major cloud provider is always safer than internal management | Strength of controls and location of processing are different questions.A provider may have strong safeguards, while your requirement may still call for local processing. Compare the relevant threats and your ability to operate each option securely. |
| On-premises AI is inherently too difficult to manage | Many management tasks are familiar from servers and office systems.Use existing physical-access, account and permission processes, then address AI-specific data access, updates and application behavior. |
| Without the internet, AI cannot do anything | Local models perform inference on the appliance.After initial setup, supported writing, summarization and internal-reference tasks can operate without continuous internet access. Web search and other external services need a separate connection and data-handling decision. |
| Only a specialist can explain security | Anyone can explain the intended data path.Have specialists document the encryption, vulnerability management and other technical details. Clear roles make the overall explanation stronger. |
| If AI is on-premises, any employee can safely use it | Internal misuse and excessive access remain possible.Use individual accounts, appropriate permissions and relevant records. Local processing and proper internal use are separate requirements. |
Avoid absolute promises: remaining risks and who manages them
Local processing does not eliminate every risk. An explanation that states its limits is more credible.The following four examples have clear operational owners. They are not an exhaustive threat assessment.
Theft or unauthorized removal of the appliance
Like an internal PC or server, the appliance needs a controlled location and physical-access procedures. Its SSD supports self-encryption, but protection after theft depends on the actual encryption, authentication and key-management configuration. Verify those controls rather than relying on the drive specification alone.
Owner: Your facilities and device-management teams
Internal misuse or excessive permissions
Even if data stays inside, it can be exposed to someone who should not see it. Issue individual accounts, restrict access to the necessary documents and retain appropriate event records. Revoke access promptly when staff leave.
Owner: Your IT and information owners
Reused or shared passwords
Sharing credentials makes it harder to establish who used a system. On-premises AI is no exception. Apply your account and password policies, including appropriate authentication controls, rather than treating the appliance as a shared anonymous tool.
Owner: Each user, supported by your identity-management team
Enabled external connections
If optional web search or cloud-model integration is enabled, information used by that feature may be sent outside. The local workflow does not require those options. Define the permitted departments, purposes and data before enabling them, and verify what is actually transmitted.
Owner: The people approving your AI use and connection policies
Demonstrate local operation
A practical demonstration can help people understand the architecture. Set up a controlled test after the required initial installation.Disconnect the test environment from all internet paths, including wireless or alternate routes, while preserving the local access needed to use the appliance. Then ask the AI a question.
- A response without internet access demonstrates local capability: the tested function can complete within the isolated environment. It does not establish that the system never communicates externally when reconnected, or that every other function has the same behavior.
- The demonstration is easy for non-specialists to understand: show management a supported local task working without an internet connection, then explain the scope of what that test demonstrates. Your technical team can provide the network and traffic evidence behind the broader claim.
- Repeat the check after deployment: your team can perform the same controlled test rather than relying solely on a sales explanation. Keep a record of the configuration and results for review.
A cloud-only inference service generally needs a connection to its provider. An offline demonstration therefore helps distinguish local capability, but is not by itself proof that data never leaves in normal use. Pair it with configuration checks and, where appropriate, traffic monitoring during a trial or audit.
Self-check: can you explain your company’s AI data paths?
Select the statements that apply. This self-check does not send your selections to a server.
Eight questions about explaining generative AI security
Check the statements that apply. Suggested next steps depend on your selection count.
How three approaches compare
| Item | Employee-managed cloud AI | Managed cloud AI with training disabled | AI within your appliance |
|---|---|---|---|
| Data path | To an external provider | To an external provider | Internal network for the configured local workflow |
| Basis for assurance | Provider controls and terms; personal accounts may be outside company oversight | Provider controls, contract, settings and available assurance evidence | Verified local configuration plus internal security controls |
| Who can verify it? | Company visibility may be limited | Company reviews settings, terms and available audit evidence | Company inspects local configuration and behavior |
| Use in external model training | Depends on service terms and settings | Excluded according to the applicable service controls and commitments | No transfer through the isolated local workflow |
| When internet access stops | Cloud-dependent functions unavailable | Cloud-dependent functions unavailable | Supported local functions continue after initial setup |
| Evidence for auditors and partners | May be difficult to obtain for unmanaged accounts | Terms, settings and provider assurance materials | Network configuration, controls and relevant operation records |
| Who manages remaining risks? | Responsibilities may be unclear without company oversight | Shared between provider and customer | Primarily the customer for local operation, with vendor responsibilities for the product |
Why we propose locally controlled AI
A universal promise of no leaks cannot be established. A defined local-processing boundary can be inspected. For sensitive workflows, one useful design choice is to avoid unnecessary external data paths from the outset.
Sovereign GaiXer is an AI operating environment running on a compact appliance. After required initial setup, supported local models and document-reference workflows can run on the internal network without continuous internet access. In a closed-network configuration, inputs and internal documents remain within your environment. It is another managed system at your premises, with access, maintenance and AI-specific controls to configure.
AI whose data path you can explain and inspect
Sovereign GaiXer is a generative AI environment running on Lenovo ThinkStation PGX. Local AI processing, storage and internal-document reference workflows run within the appliance. In a closed-network configuration, those documents are not sent to an external AI service.
After initial setup, supported local functions operate over an internal wired or Wi-Fi LAN without continuous internet access
Web search and cloud-AI integration are optional services with separate terms. When enabled, they can send feature-related information outside. Review the actual data path, permissions and service arrangement before use.
Prepare a clear security explanation together
Bring the questions expected in your internal approval or audit process. We can discuss the proposed deployment and demonstrate supported local functions with external connections disabled.
A short glossary
On-premises
Equipment installed within your organization’s premises and network. Local placement alone does not prevent internet access; network configuration determines the boundary.
Cloud AI
An AI service that receives requests at a provider-operated environment and returns answers. Its security depends on the service’s controls, contractual terms and your organization’s configuration and use.
External transmission
Data leaving your internal environment for an outside service. A properly isolated on-premises workflow can avoid this path.
Proving a universal negative
A claim such as “a breach can never occur” is not something an ordinary deployment test can establish. A defined network boundary and its controls can instead be examined.
Training (fine-tuning)
Updating the numerical parameters in a model using supplied material, as discussed in Part 2. Keeping information away from an external provider prevents that provider from receiving it through this workflow.
Closed network
An internal or inter-site network isolated from the internet. Local AI functions can operate within it after required setup.
Self-encrypting SSD
A storage device supporting hardware encryption. Protection against theft depends on encryption configuration, authentication and key management, not simply the presence of a capable drive.
Audit log
A record of events such as user logins and administrative actions. Check its actual coverage and retention; it is useful evidence but does not by itself prove every data transfer or prompt.
External-connection options
Features such as web search or cloud-model integration that contact outside services when enabled. They require a separate data-handling decision.
Frequently asked questions
Why can on-premises AI help protect data?
One important reason is its architecture. In a closed-network configuration, inputs travel across your internal network to an appliance on your premises, without a route to an external AI service. This is a specific, testable boundary, not proof that a breach is impossible. Verify the actual network configuration, access controls and operation rather than relying only on a diagram.
Can we say personal information can never leak?
No. Nobody can responsibly promise absolute protection in every circumstance. A more defensible statement is that the configured local workflow does not send inputs to an external AI service, while remaining risks are addressed through access controls, device security, monitoring and operating procedures. Be precise about the boundary and the evidence supporting it.
Cloud AI can disable use of data for training. Is that insufficient?
That setting can be valuable, and provider contracts, audits and technical controls can support it. However, the data is still processed outside your premises. A properly isolated local workflow addresses a different requirement: avoiding that external transfer in the first place. Evaluate both approaches against your actual information-handling requirements.
Can FIXER, as the provider, view our data?
In the closed-network local configuration, inputs are not automatically transmitted to FIXER. Your organization controls authorized access to the appliance. Any support access, external integration or diagnostic-data sharing should be reviewed and approved separately.
Are there risks even with on-premises AI?
Yes. They include theft of the appliance, misuse or excessive access inside the organization, shared passwords, vulnerabilities, and transfers through enabled external connections. Many controls overlap with those for company PCs and servers, but AI-specific data permissions, prompt injection, output handling and application behavior also need assessment.
Does using the web-search option make the system unsafe?
Enabling an external feature creates a transfer path for information used by that feature. The local configuration does not require it. Before enabling it, decide which departments may use it, for which purposes and with which data, then verify the actual information sent. Explain this boundary when describing local operation.
How can we check that the AI can work without an outside connection?
After completing the required initial setup, isolate the test environment from the internet, including Wi-Fi and any alternative gateways, while preserving the local connection needed to use the appliance. Ask the AI a question. A response demonstrates that the tested function can run locally; it does not alone prove the absence of all outbound traffic in other configurations. Ask your IT team to verify routes and, where needed, traffic records.
How should we answer detailed questions about encryption or vulnerabilities?
Ask the technical team to provide a documented response rather than improvising. Anyone can explain the intended data path, while specialists verify encryption, updates and vulnerabilities. For Sovereign GaiXer, see the security page.
Three points to remember
- Avoid an absolute “no leaks” promise. Explain the local workflow’s data path and the controls that keep it within the intended boundary, then show how those controls were verified.
- On-premises AI can use familiar server-management processes, supplemented by AI-specific review. Start with three questions: where does data go, who can access it, and could it reach an outside training process?
- Identify remaining risks and their owners, including what changes when external options are enabled. Demonstrate local operation, while being clear that an offline response alone is not a complete security test.
Sources
External source links open in a new tab.
Personal information and policy
- Personal Information Protection Commission, Alert on the Use of Generative AI Services (June 2, 2023; Japanese)
- Digital Agency, DS-920: Guidelines for Procurement and Use of Generative AI for the Evolution and Innovation of Public Administration (Japanese)
- Ministry of Economy, Trade and Industry, Protecting and Using Trade Secrets (Japanese)