Local or external AI for operational data?
Run AI locally when detailed operational context must remain under your control. An external model API may be appropriate for approved, limited information. In either case, inspect the entire data path, including the services around the model.
An operator asks an AI assistant: "Why did PACKER-07 stop yesterday?" A useful answer might need sensor readings, alarm history and maintenance records. The question is short, but the context needed to answer it can reveal quite a lot about the business.
The operator asked for an explanation, not a surprise data export. Which parts should the assistant be allowed to see, and which parts may leave the organisation?
Follow the data, not the model's label
An external model API may receive much more than the original question. Selected measurements, retrieved document excerpts, database results and outputs from tools may all become part of its context. Review the actual payload before deciding whether an external service is appropriate.
Whether that payload may leave your environment depends on company policy, security requirements and the provider's terms. The UK's secure AI guidance calls for controls on data sent outside an organisation and due diligence on external providers.
An open-weight model can run on your own infrastructure or through an external provider. Model availability and deployment location are separate choices. What matters here is where inference runs and what data crosses the boundary.
Local means the whole path
A model running inside the plant does not automatically make the entire assistant local. If document retrieval or RAG is involved, check where documents are processed, embeddings are generated, vector indexes are stored, and prompts, responses and logs are written. The server room is not a magic circle.
For PACKER-07, one architecture might keep the full maintenance and production history on site while allowing only a carefully scoped, approved summary to reach an external API. Another might keep the entire investigation local. Both can be valid choices. Neither should happen by accident.
The application needs to connect PACKER-07's readings, alarms and maintenance records before presenting them to a model. Defining those relationships once lets different assistants and applications reuse the same context.
What information leaves your environment?
Keep operational context independent of the model
A Unified Namespace (UNS) gives systems a shared way to identify equipment and interpret its operational data. Different applications and AI models can reuse that context without redefining what the equipment, measurements and relationships mean.
A UNS does not decide which information is sensitive or which data may leave the organisation. Those policies and access controls still have to be enforced by the systems around it.
UNS OpenHub's public Runtime provides a self-hosted foundation for organising and exposing this operational context. Our Assistant runtime is still in private development and is not part of the public Runtime.
Before trusting any model with production data, ask three questions: What evidence does it need? Where will each piece of that evidence go? And who has approved that path?