Security and data handling
Good security starts with knowing where data goes, who can use it, and who is responsible for it. Navaura works directly with customers to define those requirements during discovery and document the agreed controls in the scope of work.
Last updated September 24, 2026Customer projects and this website
Customer implementations have their own architecture, configuration, providers, and contractual terms. The topics below are part of evaluating and scoping an engagement; they are not a claim that every project includes the same controls.
This public website is hosted on AWS. Nia uses Anthropic to generate responses through a server-side integration; the model API key is not sent to your browser. Nia and our public forms are intended for general business inquiries, not confidential documents, patient or policyholder records, or credentials.
Deployment and responsibility
We can evaluate a deployment in a customer-controlled cloud environment or a Navaura-managed environment as part of the proposed architecture. The choice depends on your existing systems, approved services, operational requirements, and the scope we agree.
Before implementation, the design should identify the hosting account owner, regions, connected systems, data flows, and responsibilities for deployment, monitoring, maintenance, and incident response. On-premises, private-network, or residency requirements need an explicit feasibility review.
Access controls
We review who needs access to the application, source data, administration tools, and cloud resources. The implementation scope should specify roles, service accounts, credential storage, and how access is granted and removed.
Requirements such as single sign-on, multifactor authentication, audit logs, and restricting AI retrieval to each user’s authorized data are agreed for the selected systems. Their availability depends on the providers and configuration chosen for the project.
Retention, deletion, and backups
Customer data, logs, model requests, and backups can have different retention periods. We work through those categories during design so the agreement can state what is retained, where it is stored, who can access it, and how deletion and project handover are handled.
A provider’s default retention period is not a substitute for an agreed project policy. Backup expiry, legal retention requirements, and deletion limitations need to be considered before production data is introduced.
AI and model providers
For an AI implementation, the design should name the model provider and describe what information is sent to it. Provider terms, training use, retention, hosting regions, and any additional services need to be reviewed for that particular integration.
We do not make a blanket promise of zero retention or no model training across all providers and services. Any such requirement must be supported by the chosen service, its configuration, and the applicable agreement. Human review and approval steps are scoped around the decisions and actions the system can take.
Contracts and regulated information
Engagements begin with a written agreement and a defined scope of work. Raise confidentiality, data-processing, security-review, and service-level requirements during discovery so we can determine the terms and supporting services required.
If your organization requires an NDA, data-processing agreement, BAA, or a particular certification, confirm that requirement with us before sharing sensitive information. Availability and suitability must be established for the engagement; this page does not represent a certification or promise that a regulated workload is approved.
Discuss your requirements
Tell us which workflow you want to improve, which systems are involved, and any required data locations or review process. We can use discovery to identify the questions that need answers before a pilot begins. For a website security concern, email a general description without including credentials or sensitive data.
Schedule a conversation or email sales@navauratech.com.