How NeoBram designs industrial AI to operate inside a client-controlled security boundary: identity, least privilege, agent permissions, logging, versioning, rollback and a written responsibility matrix. This page describes design practice. It is not a certification claim, and it does not guarantee compliance with any regulation - those judgements belong to the client's qualified security, quality and legal owners.
Control areas
AI workloads live on the IT side of a defined boundary. Reads from OT systems go through approved interfaces - historians, OPC UA servers, an industrial DMZ - and write-back to control systems is off by default and separately approved when needed.
AI services integrate with the client's identity provider. Access to models, data and outputs follows the same joiner-mover-leaver controls as any other system; shared or anonymous access is not used for consequential workflows.
Every service account, agent and integration gets the minimum read or write scope it needs, reviewed against the workflow it supports rather than granted broadly for convenience.
When AI agents can call tools, each tool is an explicit permission: what it may read, what it may change, and which actions always require a human decision. Permission tests are part of validation, not an afterthought.
Consequential actions - changing a record, sending a communication, adjusting a plan - keep a named human approver. The system prepares work; responsible people decide.
Credentials, keys and tokens live in the client's secrets store, not in prompts, code or configuration files. Rotation and revocation follow the client's existing policy.
Where data may live, which boundary it may cross and how long it is kept are documented before implementation. Retention for AI logs and intermediate data follows the same policy as the source systems.
Private cloud, on-premises, edge and fully offline or air-gapped designs are compared for the real requirement. Offline operation still needs identity, logging, patching, backup and support paths - isolation is not a substitute for controls.
Inputs, outputs, model and prompt versions, approvals and overrides are logged so any AI-supported decision can be reconstructed. Logs live inside the client boundary.
Prompts, models, retrieval indexes and configuration are version-controlled. Any change is traceable to a version, an author and a reason - and can be rolled back.
Base models, libraries and connectors are third-party software: provenance, licence terms, update cadence and known vulnerabilities are reviewed like any other dependency.
Model licences decide what can be deployed offline, fine-tuned or transferred to the client. Licence review happens during architecture, not after delivery.
AI services are placed in the network zone that matches their data sensitivity, with an industrial DMZ pattern between plant and enterprise networks where OT data is involved.
Models, indexes, configuration and data pipelines are backed up on the client's schedule, and rolling back to a previous known-good version is a rehearsed procedure.
Drift, anomalous outputs, permission violations and availability feed the client's existing monitoring and incident process. An AI incident is handled as an operational incident, with the same severity discipline.
Who patches the operating system, the runtime, the model server and the application layer is written down per component - especially for on-premises and air-gapped deployments where updates are manual.
Responsibility matrix
Governance is reviewed on an agreed cadence - typically alongside the client's existing change-control or management-review rhythm - covering incidents, drift, permission changes, licence changes and open risks.
Primary sources
U.S. National Institute of Standards and Technology
U.S. National Institute of Standards and Technology
U.S. Cybersecurity and Infrastructure Security Agency
International Society of Automation / IEC
These references describe the frameworks that inform NeoBram's design practice. Citing them does not imply certification against them or endorsement by their publishers.
Related reading
A practical next step
If security or data boundaries are the reason an AI project is stalled, bring the constraint. We will help you compare deployment boundaries and write the responsibility matrix before any platform decision.
Discuss one industrial AI use case