A Data To Insight productIntraSage — Private AI for organizational knowledge
IntraSage connects approved company documents, systems, and data sources to provide permission-aware, cited answers, reports, and insights. It is deployed on-premise, in a private cloud, or through a controlled hybrid architecture inside infrastructure owned or controlled by the customer.
Built for organizations that need AI grounded in their own documents.
IntraSage is worth evaluating when an organization needs AI-assisted answers from its own documents and systems — and cannot, or chooses not to, route that content through a public cloud AI service.
Confidential documents cannot go to a shared AI service.
Financial records, medical data, legal files, or client documents that must remain within infrastructure the organization controls.
Employees ask the same questions that are already answered in internal documents.
Policy documents, runbooks, contracts, and reports exist — but finding the right passage takes longer than it should, and answers are often inconsistent.
Department access needs to match document permissions, not a single shared context.
Finance should not see HR records. Legal should not surface client files across matters. Role and department access must be enforced at retrieval, not assumed.
Per-seat cloud AI costs are growing with headcount, with no visibility into return.
A recurring subscription that increases with every hire, without a clear answer on whether the usage justifies the cost — or whether a private deployment would be more economical at scale.
What IntraSage does.
IntraSage is a private, permission-aware organizational knowledge assistant that connects company documents and systems to provide cited answers, reports, and insights while keeping the organization in control of its data, models, infrastructure, and access policies.
On-premise, private-cloud, or hybrid deployment
Local or approved external AI models
Organizational memory and preferences
Microsoft 365, SharePoint, Teams, Slack, Drive, Notion, and Confluence integrations where supported
Configurable retention, backup, and restore
IntraSage runs inside infrastructure you control.
IntraSage is deployed into infrastructure owned or controlled by the customer. Depending on the organization's requirements, it can run on-premise, inside a private cloud account, or in a controlled hybrid architecture.
Servers, virtual machines, or Kubernetes inside the customer's environment.
IntraSage runs on servers, virtual machines, or Kubernetes infrastructure located inside the customer's environment. Documents, vector indexes, databases, model files, logs, and backups can remain under the customer's operational control.
Deployed into the customer's own Azure, AWS, or Google Cloud account.
IntraSage is deployed into the customer's own Azure, AWS, or Google Cloud environment, using private networking, customer-controlled storage, identity services, monitoring, and security policies.
Sensitive data stays inside; approved external models used for selected requests.
Sensitive documents, retrieval, permissions, and storage remain inside the customer-controlled environment, while approved external AI models or services may be used for selected requests according to configured policies.
How IntraSage is installed.
IntraSage must be installed and configured for each customer environment. The deployment format depends on the organization's existing infrastructure, technical team capacity, and operational requirements.
Supported deployment formats
- Docker Compose — smaller environments and initial pilots
- Kubernetes and Helm — larger deployments with availability requirements
- Private virtual machines — single-tenant, customer-managed compute
- Customer-managed PostgreSQL — metadata and configuration storage
- Local, S3-compatible, or Azure Blob storage — document and index storage
- Local model runtimes — for fully offline or air-gapped configurations
- Customer identity providers — SSO, LDAP, Active Directory, or SCIM
- Customer-controlled backup and monitoring — using the organization's existing tooling
The final architecture depends on the number of users, document volume, integrations, security requirements, availability expectations, and selected AI models. Not every installation uses the same configuration.
Restricted and isolated environments
- Local model files — Available now (for supported local models)
- No mandatory external telemetry — Available now
- No forced internet dependency — Available now (in local model configurations)
- Local backup and restore — Available now
- Local authentication or enterprise identity integration — Optional
- Offline installation packages — Planned
- Offline license activation — Planned
- Manual upgrade packages — Planned
Permission-aware retrieval.
IntraSage is designed to return information according to the user's role, department, group memberships, document permissions, and configured access policies.
How access is enforced
Connecting a source does not automatically make all of its content visible to every user. Source permissions and local access policies must be preserved and enforced during retrieval. This means that the permission model of the source system — SharePoint, Google Drive, a file server, or a configured policy — must be carried through to IntraSage's retrieval layer.
Permission behavior is tested during the pilot stage before full implementation proceeds. Validating that users see only what they should is part of the definition of a successful pilot, not an assumption.
Role and department access
Access can be configured by user, role, department, group membership, or document-level policy. Different teams can have access to different document sets, and those boundaries are enforced at query time. An HR document set may be restricted to HR personnel; a finance document set may be restricted by department; a legal document set may be restricted by matter.
You choose where data lives and which models are used.
Where your data is stored
The customer chooses where documents, indexes, databases, logs, model files, backups, and conversation history are stored. IntraSage does not route organizational documents to shared infrastructure or third-party storage by default.
AI model selection and control
IntraSage supports multiple approved AI models, including local, customer-hosted, private-cloud, and optional external providers. Organizations control which models may process each type of information and use case.
External AI providers are optional and must be explicitly approved in deployments that support them. Fully local deployments can use customer-hosted models without sending document content to an external model provider. Hybrid deployments may route selected, non-sensitive requests to approved external models — this is configured explicitly, not enabled by default.
Retrieval is not training
IntraSage uses retrieval-augmented generation. It indexes your documents and retrieves relevant passages to inform responses. This is not the same as training the underlying AI model on your organization's data. The underlying model is not updated or fine-tuned on your documents.
What IntraSage does not claim
Data control depends on the final architecture, selected integrations, and operational practices. IntraSage does not claim to be completely secure, impossible to breach, or fully compliant by default under any regulatory framework. Security review, access design, and compliance assessment are part of the readiness assessment, not assumptions carried into it.
Supported information sources.
IntraSage can be configured to ingest documents and structured data from a range of sources. Connector availability depends on the deployment configuration and integration requirements.
Document files
PDF, Word, Excel, CSV, PowerPoint, and plain text. Scanned documents with OCR where configured.
Microsoft 365 and SharePoint
Documents, sites, and libraries, with permissions carried through from SharePoint access policies where configured.
Microsoft Teams and Outlook
Selected channels and mailboxes where configured and permitted by organizational policy.
Google Drive and Google Workspace
Files and shared drives, with permissions carried through from Google Drive access policies where configured.
Notion, Confluence, and wikis
Internal knowledge bases where an export or API integration is available.
Slack
Selected channels where configured and permitted by organizational policy.
Databases and APIs
Structured data from customer-managed databases or internal APIs, where an approved integration is defined.
Not every connector is available in every deployment configuration. Connector availability and integration scope are confirmed during the readiness assessment.
Security and privacy controls.
Encryption
Encryption at rest and in transit is configured as part of deployment, using the customer's chosen storage and networking infrastructure. The specific configuration depends on the deployment environment and the organization's security requirements.
Audit logs
IntraSage produces audit logs covering queries, document access, administrative actions, and configuration changes. Logs are stored where the customer specifies — in local storage, a customer-managed log aggregation system, or cloud-native logging services in private cloud deployments.
Credential handling
Credentials and access tokens used to connect to source systems are stored in customer-controlled configuration, not in shared infrastructure. Source system access is scoped to read-only, least-privilege credentials wherever the source system supports it.
Data residency
Because IntraSage is deployed into customer-controlled infrastructure, data residency is determined by where the customer's infrastructure is located. In on-premise deployments, data does not leave the customer's physical environment. In private cloud deployments, data residency is determined by the cloud region the customer selects.
Reporting and scheduled insights.
Scheduled document ingestion
IntraSage can be configured to ingest documents from connected sources on a defined schedule, so the knowledge base reflects current content without manual intervention.
Scheduled answer and summary delivery
Recurring reports and summaries can be generated on a schedule and delivered to defined recipients, based on approved queries and document access policies.
Usage and access reports
Administrative reports covering query volume, document access, user activity, and system health are available to authorized administrators.
Administration and governance.
Deployment requirements vary by situation.
What determines infrastructure requirements
Infrastructure requirements for an IntraSage deployment depend on:
- Number of users and concurrent requests
- AI model size and inference requirements
- Document volume and OCR requirements
- Number and type of connected source systems
- Availability and redundancy expectations
- Backup and recovery requirements
- Data residency and security controls
Data To Insight does not publish fixed hardware recommendations as universal requirements, because they are not. The readiness assessment defines the specific infrastructure requirements for each deployment based on the factors above.
Example profiles (illustrative only)
A 15-person professional services firm with a focused document set and light concurrent usage may run comfortably on a single dedicated server or virtual machine. A 150-person organization with multiple document sources, high concurrency, and a large model may require a multi-node Kubernetes cluster with dedicated GPU compute. These are illustrative examples — not specifications.
Four stages. Each one is a decision point.
Nothing later is assumed until the stage before it supports moving forward.
Readiness Assessment
Covers use cases, data sources, permissions, infrastructure, security requirements, model options, deployment approach, integration requirements, and operational ownership. Produces a written recommendation before any deployment begins.
Pilot
Limited deployment against a defined document set for a defined group of users. Validates answer quality, permission enforcement, and operational behavior before full implementation proceeds.
Full Implementation
IntraSage is deployed for the approved use cases across the target departments or user base, with full integration, access controls, and operational documentation. Starting price covers a limited use case. Larger deployments are scoped separately.
Ongoing Support
Model updates, connector maintenance, backup verification, usage reviews, and administrative support. Typically covered under the Technology Cost Governance retainer. Scope is agreed at engagement time.
How IntraSage Assessment and Implementation is priced.
What “starting at $5,900” covers
The starting implementation price covers a limited use case, a defined document set, basic role-based access controls, deployment configuration, and initial user enablement. It does not cover every possible configuration.
Larger document volumes, complex integrations, custom permission models, high availability, specialized hardware, GPU compute, or multi-department rollouts are scoped separately and will increase the fee.
Hardware is billed at cost with no markup and quoted separately based on the architecture the readiness assessment recommends.
Included and not included
- Written readiness assessment — Stage 1, scoped separately
- Pilot against a defined document set — Stage 2, scoped separately
- Full implementation with access controls — included in Stage 3 fee
- Architecture and data-flow documentation — included
- Hardware — billed at cost, quoted separately
- Ongoing monitoring and model updates — Stage 4 / Technology Cost Governance retainer
- Legal or compliance review — not included
- Unlimited custom development — not included
On-premise and private-cloud deployments carry ongoing costs beyond the initial implementation: hardware power and refresh, monitoring, and model updates. Most organizations cover this under the Technology Cost Governance retainer — $750, $1,500, or $2,500 per month depending on company size — rather than as a separate line item.
Common questions about IntraSage.
Is IntraSage a SaaS product?
No. IntraSage is deployed into infrastructure owned or controlled by the customer — on-premise, inside a private cloud account, or through a controlled hybrid architecture. It is not a shared, multi-tenant hosted service. Each deployment is provisioned, configured, and maintained for the specific organization.
What infrastructure is required?
Infrastructure requirements depend on user count, document volume, concurrency, selected AI models, availability requirements, and integrations. Smaller deployments may run on a single server or virtual machine using Docker Compose; larger deployments may use Kubernetes. The readiness assessment defines the specific requirements for each situation. Data To Insight does not publish universal hardware minimums because they are not universally applicable.
Can IntraSage run without internet access?
The core document retrieval and question-answering capabilities can run without an active internet connection when local models are configured. Connectivity may still be required for: model updates, selected optional integrations, and monitoring or alerting tooling you choose to enable. The deployment documentation for each installation specifies which components require connectivity and which do not.
How are document permissions handled?
IntraSage is designed to return information according to the user's role, department, group memberships, document permissions, and configured access policies. Connecting a source does not automatically make all of its content visible to every user — source permissions and local access policies must be preserved and enforced during retrieval. Permission behavior is validated as part of the pilot stage before full implementation proceeds.
Does IntraSage train on our data?
No. IntraSage uses retrieval-augmented generation: it indexes your documents and retrieves relevant passages to inform answers. It does not update or retrain the underlying AI model on your organization's data. Improvements in answer quality come from better retrieval configuration, improved source documents, and prompt tuning — not from model training.
What AI models does IntraSage use?
IntraSage supports multiple approved AI models, including local, customer-hosted, private-cloud, and optional external providers. Organizations control which models may process each type of information and use case. Fully local deployments use customer-hosted models running on the customer's own infrastructure, without sending document content to an external model provider. Hybrid deployments may use approved external models for selected, non-sensitive requests — this must be explicitly configured and approved. The readiness assessment includes a model selection discussion based on answer quality, hardware requirements, and data sensitivity.
What is the difference between the Readiness Assessment, Pilot, and Full Implementation?
The Readiness Assessment evaluates use cases, data sources, permissions, infrastructure, security requirements, model options, and deployment approach — it produces a written recommendation before any deployment begins. The Pilot deploys IntraSage against a limited document set for a defined group of users, validating answer quality, permissions, and operational behavior before committing to full scale. Full Implementation deploys IntraSage for the approved use cases across the target departments or user base, with full integration, access controls, and operational documentation.
What is included in Ongoing Support?
Ongoing Support covers model updates, connector maintenance when source systems change, backup verification, usage reviews, administrative support, and periodic health checks. It does not include unlimited software development, new feature builds, or custom integrations beyond those defined at implementation. Scope is agreed at engagement time.
Not sure if IntraSage fits your situation?
The Readiness Assessment is what answers that. It covers use cases, data sources, permissions, infrastructure, model options, and deployment approach — no obligation to move past it.