Know where your data goes, and who operates your system
Before a project starts, we map data paths, access rights, update routes and shared responsibilities with your team. The boundary depends on the architecture and contract; this page is a decision aid, not a blanket security guarantee.
Data boundary — make each path explicit
The proposed default is to keep business payload inside the customer's environment. Every exception is named, approved and recorded for the deployment.
| Data or activity | Proposed default location | Conditions to agree |
|---|---|---|
| Images, documents, prompts and answers | Inside the customer's system | External connector or cloud path is an explicit exception |
| Application and audit logs | Inside the customer's logging boundary | Redaction, retention and named readers |
| Health metrics and telemetry | Inside the customer's monitoring boundary | Only approved fields may leave the site |
| Package and model updates | Approved channel or offline import | Connected update, checksum and rollback path |
| Support session and remote access | Disabled until customer approval | Approver, least privilege, expiry and audit record |
| Backup and restore artefacts | Location named in the delivery scope | Encryption, retention, restore test and cost owner |
Public examples never include real IP addresses, hostnames, credentials, vulnerability details or an unapproved customer diagram.
Deployment options carry different outbound paths
Offline, connected on-premise and hybrid are separate architecture choices. A status is recorded per mode as proposed, tested or supported; evidence for one mode does not automatically cover another.
Offline inference
proposedInference can run without an external API call during the workflow when the model, runtime and dependencies are installed locally.
Outbound activity still needs a plan for installation, offline updates, backup and approved support.
Connected on-premise
testedProcessing remains in the organisation while a controlled connection may support package updates, approved health signals or remote assistance.
Each destination, field, approver, retention and failure behaviour is tested and recorded.
Hybrid
supportedLocal and external components are combined for a named integration, with payload and responsibility boundaries documented per flow.
Hybrid is not fully local: every external payload, reason, dependency and fallback needs an agreed owner.
Access, operations and component controls
Controls are configuration and contract decisions to verify for the deployment, not claims that every project has the same control set.
Access approver and permission
Name the customer approver, role, least-privilege permission and business reason before an operator or support person can access the system.
Access configuration and approval record
Session age and revocation
Time-box support sessions, record start and end, and revoke access when the approved window or work item closes.
Session log, expiry and revocation check
Backup, restore and rollback
Define what is backed up, who can restore it, how a rollback trigger is chosen and which RTO/RPO or exception is agreed.
Restore test and rollback runbook
Ownership and handover
Separate business data, custom code, model artefacts, configuration, operations and acceptance. Handover is recorded rather than assumed.
Delivery inventory and receiving owner
Component and model licence
Record source, version, licence, usage limits and replacement path for third-party code, runtimes, models and weights.
Component/model inventory and licence notices
Limitations and dependencies
Keep untested modes, label quality, hardware, network, safety and third-party dependencies visible until evidence or a contract decision closes them.
Risk register with owner and review date
Trust questions we answer before the workshop
Does local AI mean data can never leave the organisation?
It depends on the installation and integrations. We map business payload, logs, telemetry, updates and support before confirming the boundary.
Do customers receive all source code and model artefacts?
The delivery inventory separates custom code, third-party components, model artefacts and configuration. Rights and licences are agreed item by item.
Does running a model locally have no usage cost?
It may avoid an API token charge for inference, but hardware, electricity, maintenance, licences, updates and replacement still need an owner and budget.
Will customer data train a shared provider model?
The proposed default is no. Any different purpose requires a separate purpose, permission and contract boundary; it is never implied by a local deployment.
Review the boundary before choosing a build
Bring the workflow, data categories, existing systems, access approver and decision owner. We will start with a scoped architecture or operations conversation and link the legal documents that govern the work.
Review metadata: proposed content structure; confirm deployment-specific controls, owner and review date in the architecture pack or contract.