Trace the complete data path

An AI workflow can send information through inference services, retrieval systems, tool endpoints, logs and backups. The location of the model is one part of that path. A local agent can still disclose data through an external tool or collaboration service.

For an ISP, the material may include subscriber records, network topology, fault logs and service availability. The deployment needs to identify which data may enter each system, who may access it, how long it remains there and which transfers are authorized.

Cloud offerings differ in their regions, access controls, retention terms and processing arrangements. Local infrastructure gives an operator direct control over more of the environment, while making the operator responsible for securing and maintaining it.

Local inference and authorized connections

XSI LodeStone’s local inference approach keeps the core model execution inside the operator’s environment. Network controls and policy checks determine which information can cross that boundary through tools, telemetry or integrations.

A connection to Microsoft 365, Google Workspace or another external service is a data path in its own right. The operator can permit selected operations while keeping unrelated network and subscriber data local.

Local execution can support continuity during a WAN disruption for tasks whose required models, data and tools remain available locally. Tasks that depend on an external service still depend on that service.

Every connection is a data path
Local inference and external integrations have separate data paths, each governed by the operator’s policy.

Cloud boundaries are specific to the deployment

A customer-controlled cloud environment can use private inference endpoints, network restrictions and regional storage. Those controls need to cover the surrounding services as well as the model: support access, diagnostics, backups and identity administration can all affect the boundary.

The useful distinction is the actual processing and access arrangement. A private-cloud label alone does not establish isolation, and use of a third-party API alone does not establish that access is unauditable.

Regulated data requires the relevant controls

CPNI protections apply to covered telecommunications and interconnected VoIP providers and the information within their scope. They are not a blanket requirement that every ISP record remain inside a building. The FCC’s CPNI guidance describes the covered providers and their privacy obligations.

HIPAA also permits cloud processing under applicable conditions. HHS guidance describes business associate agreements, risk analysis and safeguards for cloud services handling electronic protected health information. Owning the server does not, by itself, establish compliance.

For each workflow, the applicable obligations and the organization’s own policy should determine permitted data use, access and transfer. The resulting configuration can then be checked against those requirements.

Control that can be inspected

A deployment record should connect the selected model and tools to their authorized data paths, access controls and retention settings. Logs should show relevant policy decisions and transfers without collecting unnecessary sensitive content.

XSI’s approach combines local execution, governed interfaces and an account of what the agent was allowed to do. That gives the operator concrete controls to inspect and maintain as the workflow changes.

Map the services around the model

Select diagram to enlarge
A deployment inventory should cover inference, retrieval, tools, logs and backups. For each service, record where data resides, who can access it, how long it is retained and which transfers are permitted.
Rhyan J. Neble
Rhyan J. Neble
Founder & CEO, Extended Systems Intelligence