The deployment decision needs to connect company requirements to the actual path of the application and data. Start with the work to be performed and only then compare environments, integrations, and operational responsibilities.
Describe what needs to work
List the people, agents, channels, sources, and systems that participate in the operation. For each component, record its role and dependencies. An internal chat that queries documents, an outbound communication, and a flow that changes the financial system may have different requirements even when they use the same platform.
Ask which restrictions the company has already defined and who can clarify them. Separate firm requirements from preferences and points under investigation. “We want our own infrastructure” may be a decision or an initial way of expressing concerns about access, availability, or data location. Understanding the need avoids choosing an option before knowing what it must meet.
Trace storage and processing
Map the path of a piece of information from entry through its use and records. Identify where the file is stored, who extracts its content, which model receives the query, and where results, indexes, copies, and logs are kept. The application may be in the company's environment and still query an external service.
For each outbound transfer, note the content sent, the purpose, the destination, and the person responsible for configuration. Consider supporting services, such as search, transcription, or monitoring, when they are part of the design. Do not conclude that data remains within a perimeter solely because of a database's location. The path needs to be checked with the technical team for the specific deployment.
Assign operational work
Define who provisions the environment, administers access, maintains integrations, updates components, and monitors availability. Include how incidents are communicated and who can intervene. Having an application on the customer's infrastructure does not, by itself, define who will be responsible for each of these activities.
Also consider future changes. Who approves a new data source or a new model? Who reviews the flow when a system changes its API? How will testing and returning to an earlier version be handled? Record business and technology responsibilities, because continuity depends both on technical operation and on the team that uses the result.
Compare designs against the same requirements
SaaS means using a provider's application on cloud infrastructure: the customer uses the service and its available settings, while the underlying infrastructure is operated by the provider. Location, data access, and service responsibilities still need to be checked in the design and the terms of the offering.
Assisted deployment, in this guide, means deployment on the customer's infrastructure with support from Starya. Provisioning, updates, support, and operation need agreed owners. The term does not imply a standalone installation package or operation without an external connection.
Use the same list of needs to compare SaaS and assisted deployment in the company's environment. For each option, record what is supported, what requires configuration, what depends on development, and what has not yet been confirmed. A reference diagram helps the discussion but does not demonstrate that all components are available in that option.
Choose a representative scenario to validate the design before expansion. Check access, information movement, integration behavior, and the support path. Also note what was not tested. A useful conclusion is a decision with explicit conditions, not the designation of an environment as universally safer, cheaper, or simpler.
Illustrative example · no customer data
The document is at the company; the query uses an external service
Illustrative example: a team wants an assistant to look up internal procedures. The files remain on the company's infrastructure, but the proposed solution sends excerpts to an external model. The map identifies document storage and question processing separately.
The matrix below fills in this hypothetical design. Locations and assignments are proposals for discussion, not a description of an available deployment. Retention periods still need to be defined: keeping “to be confirmed” visible makes it possible to identify who needs to answer before the choice is made.
The responsible team checks which content may follow this path. If the condition is not met, the design needs to change or the scope must be limited. Changing only the chat's location does not resolve the dependency.
| Component | Data | Processing | Records | Retention | Proposed owner |
|---|---|---|---|---|---|
| Source repository | Internal procedures and their versions. | Storage in the customer's environment. | File, version, and read permissions. | Retention period to be defined; include copies and old versions. | Document owner and customer IT. |
| Extraction and search | Extracted excerpts and search index. | Extraction and querying in the customer's environment. | Source, version, and indexing result. | To be defined; plan for deletion from the index when the source is removed. | Customer IT, with configuration support from Starya. |
| Chat and orchestration | Question, selected excerpts, and response. | Application in the customer's environment; sends excerpts to the external model. | Conversation and query reference, according to configuration. | History retention period and content to be confirmed. | Person responsible for the application and user access. |
| External model | Question and authorized excerpts sent to the API. | Provider infrastructure; region to be confirmed. | Provider records to be checked for the contracted service option. | Retention, deletion, and usage conditions to be confirmed with the provider. | Person responsible for contracting and integration administrator. |
| Logs and support | Execution identification and failures; content to be minimized. | Collection in the customer's environment; support access to be agreed. | Technical events and support access, according to the design. | Retention period, backups, and deletion to be defined. | Operational owner; Starya access according to the agreement. |
The question for the decision is concrete: which excerpts may leave, to which destination, and under which conditions? While region, retention, or support access remain open, those conditions are not confirmed. The matrix helps test the design; keeping the files at the company does not, by itself, demonstrate sovereignty over the entire data path.
When the approach needs to change
If the company already has a data platform or an approved provider, include that as a starting point. If a component does not yet exist in the desired option, record the dependency and assess a feasible scope. When there are connectivity restrictions, also validate updates, support, and operation; do not assume offline operation because company-owned infrastructure is used.
A point to watch: Assuming that company-owned infrastructure prevents any data from leaving it.
The worksheet is ready to move forward when…
- Components and data movement are described, including external services.
- Requirements and responsibilities have people assigned to confirm them.
- The chosen option records conditions, dependencies, and checks still pending.
Bring the map and questions to a technical discussion. Use the environment comparison as a visual aid and confirm the capabilities available for your context before defining the deployment.
Your worksheet
Complete it with your team.
Record what you know and what still needs confirmation. Answers stay in memory and are not submitted.
References for further reading
- NIST SP 800-145 · definition of SaaS ↗
Defines SaaS as the use of a provider's applications on cloud infrastructure whose underlying infrastructure is not managed by the customer. The definition does not determine where a specific deployment processes or retains data.