Pattern 1
Indexed copy of approved content
Approved content is extracted or synchronized, processed, and indexed for retrieval.
- DataCopied into index
- UpdateScheduled or event refresh
- Pilot fitStrong pilot fit
- WriteNo
Architecture & Security
On-Premise AI Architecture Designed Around Your Environment
The final architecture is defined around the customer’s network, identity systems, permissions, data sources, hardware, users, and operational requirements.
Request an Architecture Review- Customer-controlled
- Permission-aware
- Assessment-led
Customer-controlled network boundary
Approved company sources
Files · ERP · SQL · APIs
Identity & permissions
PremisIQ
Private AI runtime
Permission-aware retrieval · local model · source grounding
Employee workflows
Search and chat
Source-linked answers and focused workflows
Reference Architecture
How information moves through the on-premise architecture
The reference architecture shows the main technical stages. The final design, connection methods, permission model, services, and operational controls are defined during assessment.
Approved documents, business systems, and structured data connect through read-only connectors. Information is processed and indexed, identity and permission controls are applied, approved context is retrieved, a local AI runtime generates a source-grounded response, and employees access search, chat, source-linked answers, and focused workflows. Audit logs and service monitoring provide operational evidence across the architecture.
Existing systems
Documents and communication
File server
Email
Archived files
Business systems
ERP
Accounting
Custom APIs
Structured data
SQL database
Controlled views
Exports
Read-only connectors
- Approved access
- Source-specific credentials
- Controlled synchronization
Write-back is not enabled by default.
Data processing
- Ingestion
- Processing and chunking
- Embeddings
- Vector index
Identity and permission controls
- Authentication
- Users and groups
- Workflow roles
- Source-access rules
Permission behavior is mapped per source.
Permission-aware retrieval
- Source filtering
- Context assembly
- Approved context only
Local AI runtime
- Local model
- Context processing
- Response generation
- Source grounding
Employee workflows
Enterprise search
Internal chat
Source-linked answers
Focused workflows
Audit and operational evidence
Audit logs
Usage records
Connector health
Service monitoring
Connection, permission, and synchronization behavior is implemented and validated for each approved source.
Deployment Location
Installed inside a customer-controlled environment
The physical location can differ, but the deployment model remains the same: the server operates on-premise under customer control.
One customer-controlled on-premise deployment model is installed in one suitable customer-controlled physical location: an office server room, a customer data centre, or an existing controlled network environment. Customer network, controlled access, and agreed operating responsibilities remain constant.
Customer network, access, and operational control
One deployment model
Customer-controlled on-premise deployment
Office server room
Inside the customer’s office infrastructure
Customer data centre
Inside the customer’s own data-centre environment
Existing controlled network environment
Inside an existing customer-controlled network
Customer network
Controlled access
Agreed operating responsibilities
The assessment determines the appropriate physical location, infrastructure requirements, network access, and operating responsibilities.
Security Layers
Security and control applied across the complete retrieval path
A private AI workflow is protected by multiple coordinated controls. Each layer has a defined responsibility, and the final design depends on the customer’s environment and connected sources.
Six sequential security layers control the approved environment, user identity, user permissions, source access, retrieval, and local model runtime. Audit, monitoring, and backup operate as a cross-cutting foundation. Users can inspect each layer or view an example permitted or denied retrieval path.
Select a layer for details, or view an example retrieval path.
- teal — permitted path
- muted copper — denied path
- bright edge — selected layer
Layer 01
Physical and network boundary
Permitted retrieval path
An approved request reaches a source-linked response
- Approved environment The request enters through the customer-controlled network boundary.
- Identity and permissions Identity, group, role, and source access are validated.
- Approved retrieval Permitted context is retrieved and restricted information is filtered.
- Local response The local model generates a response from approved context.
- Evidence and source links Sources are attached and the event is recorded.
Denied retrieval path
Restricted information is blocked before it reaches the model
- Request received The user enters through the approved environment and authenticates.
- Source rule fails The requested source or content is not permitted.
- Retrieval blocked Restricted information does not reach retrieval or the local model.
- Denial recorded The blocked event is recorded for operational review.
Data Lifecycle
From an approved source to a source-linked response
The lifecycle separates source connection and indexing from the controls applied when an employee asks a question.
Phase 1
Source preparation
- Approved source connection
- Extraction or synchronization
- Processing and chunking
- Embedding and indexing
Phase 2
Approved user request
- User authentication
- Permission gate
- Permission-aware retrieval
Phase 3
Response and evidence
- Local model response
- Source display
- Logging and monitoring
Indexing behavior, synchronization frequency, and retention are defined for the connected source and use case.
Identity & Permissions
Access is designed around the connected systems and users
Identity and permission behavior is implemented around the customer’s available identity systems, user roles, source permissions, and operational requirements.
Permission behavior is mapped, implemented, and validated for every connected source.
Integration Patterns
Connection patterns selected for each source and workflow
The appropriate pattern depends on the system interface, data type, update frequency, permissions, response-time requirements, and whether any action must return to the source system.
Pattern 2
Live retrieval
The workflow requests approved information from a source system when the user asks a question.
- DataQueried at request time
- UpdateDepends on source
- Pilot fitCase-dependent
- WriteNo
Pattern 3
Structured query
The workflow queries an approved database view, API, or structured source using controlled parameters.
- DataControlled query
- UpdateCurrent source result
- Pilot fitGood for narrow workflows
- WriteNo
Pattern 4
Write-back action
The workflow sends an approved action or update back to a business system.
- DataAction sent to source
- UpdateTransactional control
- Pilot fitUsually not first pilot
- WriteYes, with approval
Initial pilots normally begin with read-only patterns. Write-back actions require separate design, permission, validation, and approval.
Quality & Evaluation
Validated against agreed questions, sources, permissions, and users
Technical quality is measured against the customer’s actual workflow rather than generic demonstration questions.
Retrieval quality
- Correct source retrieval
- Relevant context
- Missing or conflicting information
Answer and evidence
- Answer review
- Source-linked response
- Source validation
Security behavior
- User and role testing
- Permitted and denied retrieval
- Administrative controls
Operational fit
- Response time
- User acceptance
- Repeatability and regression testing
Validation principleAcceptance thresholds and test questions are agreed before validation begins.
Hardware & Capacity
Hardware is specified around the required workload
No fixed server tier fits every implementation. Capacity planning considers the models, users, information volume, operational requirements, and expected growth.
Capacity principlePremisIQ does not publish fixed server tiers until representative workloads and delivery requirements have been tested.
Server and infrastructure specification
Assessment factors
Model size and runtime
Simultaneous users
Document volume and refresh
Availability and growth
Power, cooling, networking
Resulting requirements
Compute
GPU memory
System memory
Storage
Networking
Backup
Redundancy
Power and cooling
Operations & Maintenance
Defined operational controls after installation
The architecture must include the monitoring, recovery, update, and support responsibilities needed to operate the agreed workflow.
PremisIQ operational responsibilities cover infrastructure monitoring, service health, connector and index health, backup and recovery, and controlled updates and support. Responsibilities are agreed for each implementation.
Operational responsibility model
Defined for each implementation
01
Infrastructure
Hardware monitoring, power, temperature, capacity, and storage health where available.
02
Services
Service monitoring, local model runtime, vector database, and authentication services.
03
Connections
Connector health, synchronization status, index refresh, and failed processing.
04
Recovery
Backup, restore testing, and recovery procedures.
05
Change & support
Model updates, connector updates, controlled software updates, incidents, and support responsibilities.
Defined responsibilitiesMonitoring, backup, update, incident, and support responsibilities are agreed for each implementation.
Technical FAQ
Common architecture and security questions
The PremisIQ model is customer-controlled on-premise deployment. The physical location may be an office server room, customer data centre, or existing controlled network environment, but the architecture is reviewed before installation.
Identity integration is designed around the customer environment and technical fit. Available identity signals, authentication methods, administrative access, and session behavior are assessed before implementation.
Read-only integration means PremisIQ can retrieve or index approved information without changing the source system. Initial pilots normally begin this way before any write-back pattern is considered.
Yes, where the source exposes a suitable approved view, API, or query method. Live retrieval and structured query patterns are designed separately from indexed-copy patterns.
Logging can include usage evidence, access decisions, denied events, connector health, synchronization status, service health, and operational records. The exact logging scope is defined for the implementation.
Backup scope, restore testing, recovery procedures, and responsibility split between customer IT and PremisIQ are agreed as part of the implementation and operating model.
Possibly. Existing hardware must be reviewed against the required models, users, document volume, storage, networking, backup, and operating requirements before it is accepted for a pilot or production scope.
Permission-aware retrieval means the workflow limits retrieved context by user, role, group, source permissions, and implementation rules before information reaches the local model.
Indexing prepares a searchable representation of approved content ahead of time. Live retrieval requests approved information from a source system when the user asks a question.
Write-back is considered only after retrieval, permissions, validation, approval, error handling, and operational responsibility are designed separately from the initial read-only workflow.
Local model runtime is the customer-controlled environment where model services, context assembly, inference, monitoring, and operating responsibilities are defined for the workflow.
Future redundancy or high availability can be planned where required, but it depends on workload, budget, infrastructure, operating responsibilities, and the systems connected to the workflow.
Key terms
Architecture terms
These terms explain the main technical choices reviewed before a private AI workflow is piloted or implemented.
- Customer-controlled deployment
-
A deployment where the server, network access, operating responsibilities, and connected systems remain under the customer’s control.
It keeps ownership and operating boundaries clear.
- Permission-aware retrieval
-
Retrieval that limits which information can be used based on users, roles, groups, source permissions, and implementation rules.
It helps prevent answers from using information the user should not access.
- Vector index
-
A searchable representation of processed content that helps retrieve relevant source material for a user question.
It supports fast retrieval across approved documents and records.
- Local model runtime
-
The environment where the AI model runs inside the customer-controlled infrastructure.
It defines where inference, model services, and runtime operations happen.
- Read-only integration
-
A connection pattern where PremisIQ can retrieve or index approved information without writing changes back to the source system.
It is usually the safer starting point for assessment and pilot workflows.
- Write-back action
-
A controlled action where a workflow sends an approved update or instruction back to a business system.
It requires separate design, permissions, validation, and approval.
Architecture Review
Review the Architecture for Your First Private AI Workflow
Bring the workflow, systems, identity requirements, information sources, users, and operational constraints. PremisIQ will review the likely architecture, permission model, integration patterns, and infrastructure requirements.
Architecture Review is preselected in the form.