This document is for IT teams, security reviewers, procurement stakeholders, and technical decision-makers evaluating a Strateia AI deployment built on a third-party Deployment Platform. The Deployment Platform includes SOC 2 Type II compliance, SAML 2.0 SSO, encryption in transit and at rest, AWS-based infrastructure, and bot-level data isolation.
Strateia builds the intelligence and control layer of the deployment.
That includes:
In practical terms, Strateia defines how the system behaves, what knowledge it is allowed to use, how it answers, where it routes users, and what it must refuse or escalate.
No.
Strateia does not train the foundation model from scratch. The deployment runs on third-party model infrastructure. Strateia’s work is the deployment design, control logic, business structure, and operating behavior built around that model layer. The Deployment Platform can use external model-provider paths depending on deployment configuration.
The proprietary part is Strateia’s intelligence design methodology and business system structure.
That includes:
The base hosting and model stack may be third-party. The business intelligence layer applied to that stack is Strateia’s work.
The deployment is best understood in three layers.
Infrastructure layer
The hosted environment, storage layer, model access layer, and supporting cloud environment.
Deployment data is stored on AWS-based infrastructure, and vector storage is handled through Pinecone.
Intelligence layer
The Strateia-designed layer, including persona, routing, knowledge structure, constraints, business logic, escalation rules, and answer behavior.
Client layer
The approved content, files, policies, workflows, governance boundaries, escalation paths, and retention or review requirements defined for that deployment.
This is a shared-responsibility system.
Strateia is responsible for the deployment design: knowledge structure, behavior rules, routing logic, escalation logic, guardrails, use-case shaping, and refinement.
The Deployment Platform is responsible for the hosted environment, storage operation, model access layer, and the platform-level controls available in that environment.
The Deployment Platform includes SAML 2.0 authenticated access, private-by-default bots, encryption, and role controls.
The client is responsible for approving what content is allowed, what use cases are in scope, who may access the deployment, and what governance rules apply for retention, review, escalation, and operational use.
It uses only the content and rules approved for that deployment.
That can include approved website content, uploaded files, structured knowledge packs, policies, processes, routing rules, and escalation paths.
It does not need unrestricted public knowledge to operate.
No.
Not in a controlled Strateia deployment unless that capability is intentionally included.
That means internet access is not assumed. A controlled deployment can be restricted to approved knowledge, approved tools, and defined operating boundaries.
When Strateia uses the phrase Closed Network, Private AI, we do not mean that Strateia owns every server, model, or cloud primitive.
We mean the deployment is configured so that, for its intended business use case, the AI operates inside a controlled knowledge and operating boundary.
That means:
The Deployment Platform aligns with that model: bots are private by default, customer data is not used for model training, and data is isolated between builds.
So the correct meaning is:
a controlled AI deployment operating within approved content, approved access, approved behavior, and approved governance boundaries, rather than an unrestricted public AI experience.
No.
It is a configured business system for defined use cases. It is built to answer from connected business content and controlled instructions. Strateia adds the business operating layer on top so the deployment behaves like a governed system rather than a generic assistant.
Behavior is controlled through the Strateia-designed intelligence layer.
That includes:
On the Deployment Platform side, persona setup, visibility settings, access controls, and role controls support that structure.
That depends on the approved use case, but it may include:
Deployment data is processed in the United States. The environment uses AWS US East infrastructure, and vector storage is handled through Pinecone. The Deployment Platform maintains an authorized subprocessor list for customers under its DPA.
Yes.
Data is encrypted in transit with TLS 1.2+ and encrypted at rest with AES-256.
No.
Client data is not used to train public models.
No.
Data is isolated between builds. That supports a client-specific deployment model rather than a shared cross-client knowledge pool.
Yes.
The Deployment Platform offers a delete immediately after processing option for uploaded files. Files are not stored unless configured to remain available for response viewing.
Yes.
Retention depends on deployment configuration and governance choices. It should be defined explicitly for the use case and contract rather than assumed. The DPA states data is retained only as long as necessary for the purpose collected or as required by law.
Yes.
The DPA provides for deletion or anonymization when data is no longer needed, and deletion handling should be defined in the deployment governance model, including backup and retention-window handling.
Yes, depending on configuration and access rights.
This should not be assumed either way. It depends on who is granted workspace access, admin rights, and conversation-management permissions. The Deployment Platform includes Owner, Administrator, Member, Chat-only, and custom role structures.
Yes.
The Deployment Platform supports SAML 2.0 SSO and authenticated end-user access through an identity provider. It includes documented setup paths for providers such as Okta, Microsoft Entra ID, Google Workspace, and PingOne.
Yes.
The Deployment Platform includes team roles, custom roles, agent-specific custom roles, and role mapping for IdP-based access.
Logging and access controls exist, but full enterprise-grade end-user access audit coverage should not be assumed across every deployment path unless it is confirmed for the exact setup being sold. For one IdP-based access flow, the platform states detailed access audit logs are not yet available.
Yes.
That is one of the main design points of the deployment.
The client can govern:
Yes.
The deployment can be restricted to approved files, approved content sources, approved knowledge packs, and defined workflows.
Yes, to a meaningful degree.
That is handled through knowledge restriction, behavior rules, routing logic, escalation rules, refusal boundaries, and source limitation.
It is still an AI system, so it should be treated as a governed probabilistic system, not a mathematically perfect rules engine.
No.
Security here is a combination of platform controls and deployment governance.
At platform level, the environment includes SOC 2 Type II compliance, encryption, AWS-based infrastructure, private-by-default builds, identity and access controls, and data isolation. At deployment level, Strateia defines knowledge boundaries, behavior boundaries, escalation boundaries, access scope, and retention or review rules.
Strateia is not claiming that:
A Strateia deployment on the Deployment Platform can be described as Closed Network, Private AI when it is configured to operate within approved knowledge sources, approved access boundaries, approved behavior rules, and approved governance controls, with no assumption of open internet use and no use of client data for public model training. That position is supported by the Deployment Platform’s private-by-default build model, build isolation, AWS-based infrastructure, encryption, SSO support, role controls, and no-training-on-customer-data posture.
We use cookies to analyze website traffic and optimize your website experience. By accepting our use of cookies, your data will be aggregated with all other user data.