Trust Center

1. Trust Center Overview

PIA is built for organizations that need to apply AI to sensitive documents while maintaining strict control over confidentiality, regulatory obligations, and internal security policies.

Our security and privacy posture is guided by four core principles:

• Privacy-first design. The system is architected so that document processing happens in the user's browser whenever technically feasible. Features are designed to avoid centralizing customer documents on our servers by default.
• Security by default. Secure defaults are prioritized over convenience. All network communication uses modern encryption, and infrastructure access is strongly controlled and audited.
• Minimal data retention. We do not maintain a persistent document database. While a session is open, document text is held in browser memory (including parsed sections and retrieval chunks) so analysis can run. That working copy is not encrypted at rest in the client. It is discarded when the page is refreshed, the tab is closed, idle timeout fires, or the session expires.
• Transparency with customers. We clearly describe how data flows through the system, what is and is not stored, which subprocessors are involved, and which controls are in place. We also share our roadmap toward formal certifications so that security, legal, and procurement teams can evaluate our posture.

The platform is intended to allow secure AI-assisted document analysis while substantially reducing exposure to unnecessary data storage, centralized repositories, and third-party model training pipelines.

2. Security Architecture

The platform's security architecture assumes that documents may contain highly sensitive or regulated information such as contracts, financial statements, personal data, or confidential intellectual property. The primary design objective is to keep document content on the user's device when possible and to avoid persistent backend storage.

• Client-side document processing. The application is delivered as a web client over HTTPS. Document ingestion (file selection or paste) is handled in the browser. Parsing, text extraction, and most pre-processing are executed locally using client-side JavaScript and, where applicable, WebAssembly. When supported by the user's device, certain AI models may run directly in the browser, avoiding the need to send document content over the network.
• Secure communication channels. Communication between the browser and backend APIs is performed exclusively over HTTPS with TLS (TLS 1.2+). API endpoints are authenticated where applicable and are rate-limited to reduce abuse. Hosting providers may also apply transport security such as HSTS.
• AI model interaction. When in-browser models are available, inference occurs locally and document content does not leave the user's device. When Deep Analysis (hosted AI) is used, the browser encrypts the request to our API; we decrypt it in memory only, forward the minimal necessary text over TLS to a privacy-constrained AI gateway (OpenRouter) or our optional self-hosted pods (RunPod), stream the result back, and discard transient data when the request completes. We do not store documents, prompts, or chat queries in our database. We configure OpenRouter with a provider allowlist and privacy routing flags (including data_collection: deny and Zero Data Retention where available) and do not build internal training datasets from customer documents. See AI subprocessors for named providers and their retention policies.
• Ephemeral session design. Both the web client and backend services are designed to treat analysis sessions as short-lived. Document content and derived context, such as extracted text or segmented chunks, are stored in browser memory in plaintext for the current session so run, chat, and retrieval stay synchronous. They are not encrypted in the client store. Backend components are stateless with respect to document content; any transient data needed for processing is held in memory and is discarded after completion of the request.

By combining client-side processing, encrypted communication, limited AI payloads, and ephemeral session design, we reduce the amount of sensitive data available to any single system component and minimize the impact of potential compromise.

3. Data Flow and Document Lifecycle

This section describes how a typical document flows through PIA and clarifies where data is—and is not—stored.

3.1 High-level lifecycle

1. User opens the application. The user accesses the web application over HTTPS, and the browser downloads the application assets (HTML, CSS, JavaScript).
2. User provides a document. The user selects a local file or pastes text into the interface. The file or text is loaded directly into the browser's memory. By default, the full document is not uploaded to our servers.
3. Local parsing and pre-processing. The browser extracts readable text and structure from the document, such as from PDF or DOCX formats. Pre-processing such as normalization, segmentation, or tokenization occurs client-side.
4. AI interaction. If local or in-browser models are used, the model runs entirely within the browser context and the document content remains on the device. For Deep Analysis, the browser encrypts payloads to our backend (application-layer session keys); we decrypt in memory, forward the relevant text over TLS to the configured AI provider, and return the streamed result. We do not store original document content, prompts, or chat queries in our database. Inference providers process plaintext for the duration of the request under their published policies (see AI subprocessors).
5. Results presented to the user. The browser receives AI outputs and displays them to the user. The analysis context, such as question-answer history, is maintained in the browser's memory for as long as the session is active.
6. Session termination. When the user refreshes the page, closes the tab, or navigates away, the in-memory session state is discarded by the browser. Backend services treat each request as independent and discard any transient processing data after the request completes or after a short time-to-live.

3.2 Storage and retention

• Document content and prompts. There is no persistent document or prompt database. We do not store uploaded documents, analysis prompts, or chat queries in application storage. While you work, the open browser tab holds document text in memory; that copy is discarded on idle timeout, refresh, or close. Usage metering, when enabled, records only aggregate token estimates—not document or prompt text. Backend in-memory data used for a Deep Analysis request is discarded when the request completes.
• Application logs and telemetry. Logs focus on technical metadata such as timestamps, status codes, error messages, and request identifiers. Logging is configured to avoid capturing document content or other sensitive payload data. Log retention periods are defined to balance operational needs and data minimization.
• User accounts and configuration. If the platform uses accounts, limited account information such as email address, organization name, and settings may be stored in encrypted databases. This account data is logically separated from ephemeral analysis sessions and does not include document content unless a future feature explicitly requires and clearly discloses such storage.

In summary, documents are processed in memory, not stored persistently, and are discarded when analysis completes or the user ends the session.

4. Encryption and Data Protection

Encryption is a core control for PIA, particularly because documents may include confidential and regulated information.

• HTTPS / TLS for all traffic. All communication between client and server uses HTTPS with TLS (TLS 1.2+). We use certificates from trusted Certificate Authorities and follow modern TLS configurations and cipher suites. Our cloud host may apply HTTP Strict Transport Security (HSTS); we do not currently set HSTS in application config.
• Secure client-server communication. Authentication tokens, session cookies, and API keys are transmitted only over TLS. Session cookies are configured with secure attributes such as Secure, HttpOnly, and, where appropriate, SameSite. APIs are designed with authentication and authorization checks aligned to user roles.
• Encrypted AI requests. Requests from the browser to our API use application-layer session encryption (ECDH + AES-256-GCM). This protects payloads from TLS-terminating proxies; PIA servers hold the session key and decrypt in memory. After decrypt, requests to hosted AI models (OpenRouter or optional self-hosted pods) are transmitted as plaintext over TLS-protected channels. Separate credentials are used for AI providers and are stored in dedicated secrets management systems. We avoid sending unnecessary identifiers in AI payloads and keep payloads scoped to the requested task.
• Data in transit protection. Network-level protections are layered on top of encryption, including restrictive firewall rules and, where applicable, private networking between services. Encryption in transit helps ensure that, even if traffic is intercepted, document content and credentials remain confidential.
• Data at rest (non-document data). Because we do not persist documents, at-rest encryption primarily protects user account and configuration data, operational logs and metrics (without document content), and credentials and keys in secrets management systems. These storage systems are encrypted at rest using the cloud provider's native mechanisms.

Encryption safeguards both the document analysis workflow and the supporting operational data, significantly reducing the risk of unauthorized disclosure.

5. Infrastructure Security

The platform is hosted on a modern cloud provider that holds widely recognized security certifications such as SOC 2 and ISO 27001. While PIA itself has not yet undergone those audits, we inherit and build upon the provider's strong baseline.

• Secure cloud hosting. Production workloads run in dedicated cloud accounts or projects with strict separation from development and test environments. Network segmentation and security groups limit inbound and outbound traffic to necessary ports and services. Administrative access paths, such as bastion hosts or VPNs, are tightly restricted and monitored.
• Restricted infrastructure access. Identity and Access Management (IAM) policies enforce least-privilege access to cloud resources. Only a small set of authorized engineers have access to production environments. Access rights are reviewed periodically and revoked when no longer needed.
• Multi-factor authentication (MFA). MFA is required for access to cloud consoles, CI/CD systems, and other critical administrative tools. Where possible, we favor phishing-resistant authentication mechanisms.
• Monitoring and logging. Centralized logging and monitoring provide visibility into system health and security events, including failed logins, unusual resource changes, and elevated error rates. Alerts are configured for security-relevant conditions so incidents can be detected and investigated promptly. Infrastructure changes are tracked through version control and CI/CD pipelines, providing an audit trail.
• Patch and vulnerability management. Base images, container images, and dependencies are regularly updated to incorporate security patches. Automated dependency scanning and vulnerability reporting tools are used to identify known issues, and high-severity findings are prioritized for remediation.
• Secrets management. Sensitive credentials such as API keys, database passwords, and AI provider keys are stored in managed secrets services. Access to secrets is limited to specific services via IAM roles and is auditable.

6. Access Control and Operational Security

Human access to systems is treated as a critical risk factor, and controls are in place to limit, monitor, and audit access.

• Production access restrictions. Direct access to production systems is limited to a small group of engineers who require it to operate the service. Operational tasks such as deployments and configuration updates are performed primarily through automated CI/CD pipelines rather than manual changes. Access is reviewed on a regular cadence and adjusted based on role changes.
• Role-based access control (RBAC). Internal tools and administrative interfaces use RBAC to restrict actions based on functional responsibilities. Support and operations personnel are granted only the permissions required to fulfill their duties. Because documents are not centrally stored, routine access to customer document content by staff is structurally limited.
• Multi-factor authentication (MFA). MFA is enforced for administrative systems, including cloud accounts, code repositories, CI/CD platforms, and internal dashboards. Password policies and the use of password managers are encouraged and, where possible, enforced.
• Employee security practices. Employees receive guidance on secure handling of credentials, devices, and potentially sensitive information. Company-managed devices are expected to use full disk encryption and regular operating system and browser updates. Access to production data and systems is logged and auditable.
• Logging and monitoring of access. Administrative actions such as configuration changes and deployments are logged. IAM events and privilege changes are monitored for anomalies. On detection of suspicious activity, incident response procedures define escalation, containment, and remediation steps.

7. Privacy Principles

Privacy is built into the architecture and design decisions of PIA, rather than considered only at the policy layer.

• Privacy-by-design and by default. New features are evaluated for privacy impact during design and implementation. Default settings favor minimal data collection and local processing where feasible. We avoid building unnecessary data collection paths or broad logging of payloads.
• Minimal data collection. We collect only what is needed to operate and secure the service, such as account details, high-level usage metrics, and diagnostic information. Document content is not collected into centralized databases or used to build user profiles.
• No persistent document storage. By default, we do not store user documents or their full contents in application databases or long-term storage. Temporary processing data is scoped to single requests or short-lived sessions. If future features require optional document persistence, such as shared team workspaces or saved analyses, they will be clearly opt-in and documented with associated data handling.
• User control of their data. Users can end analysis sessions at any time by closing or refreshing the browser, which clears in-browser state. For account-related data such as name and email, we aim to support access, correction, and deletion requests in line with applicable regulations.
• Limited and governed third-party sharing. Sharing of data with subprocessors is limited to what is strictly necessary, such as infrastructure hosting or AI APIs. We publish the AI providers we use below and configure privacy routing (provider allowlist, no training / deny data collection, and Zero Data Retention where the endpoint supports it). Our zero persistence on PIA systems is distinct from short legal or abuse retention that a downstream provider may apply under its own policy.

These principles ensure that confidential information is protected both through technical mechanisms and through organizational rules about how data is handled.

8. AI Subprocessors

Deep Analysis may involve the following AI-related parties. PIA does not store your documents or prompts. Downstream providers process request content only to return an inference result; their published retention and training policies apply for the duration (and any short legal hold) described on their sites.

Analytics tools, when enabled, are consent-gated via our cookie banner and do not receive document or prompt content. For the latest provider list or a vendor questionnaire, contact stefan.sajkovski@yups.tech.

9. AI Safety and Responsible AI

Applying AI to documents introduces both opportunities and risks. Our approach to responsible AI focuses on safeguarding data, clarifying how models are used, and avoiding unnecessary reuse of customer content.

• Responsible use of AI models. Models are used to assist users in understanding and analyzing documents, not to make unilateral decisions that affect rights or obligations without human oversight. We encourage customers to treat AI outputs as support for, not replacements of, professional judgment.
• Data protection during AI processing. Document content is processed only to fulfill user-initiated analysis requests. For remote AI models, payloads are limited to the minimal text and context needed to respond to the query. Where available, AI provider settings are configured to prevent the use of customer submissions for training or unrelated analytics.
• Transparency of AI interactions. We aim to clearly indicate where AI is involved in generating results and, at a high level, what types of models are used, such as local or hosted. Named AI subprocessors and retention notes are published in this Trust Center.
• No reuse of documents for training by default. We do not build internal training datasets from user documents without explicit, informed consent. We configure OpenRouter privacy routing so providers that may store or train on prompts are denied where those controls are available.
• Monitoring and improvement. The platform is monitored for misuse patterns, such as attempts to use the system for clearly abusive purposes, and we may take action aligned with terms of use. Feedback mechanisms allow users to report problematic outputs, which can be used to adjust prompts, configurations, or safeguards.

10. Compliance Approach

Although PIA is an early-stage platform and has not yet completed formal audits such as SOC 2 or ISO 27001, its controls and processes are designed to align with recognized security and privacy principles.

• Alignment with GDPR principles. We align with key GDPR concepts, including lawfulness, fairness, and transparency by clearly stating what data we collect, how it is used, and which subprocessors are involved. Purpose limitation ensures that data, including any document content processed, is used only to deliver and secure the service as requested by the user. Data minimization is achieved by avoiding persistent storage of document content and collecting only limited account and operational data. Storage limitation ensures operational data is retained only as long as necessary for security, support, and legal obligations. Integrity and confidentiality are supported through encryption, access control, and infrastructure security measures.
• General data protection best practices. PIA follows data protection best practices, including documented procedures for access control, incident handling, change management, and backup of critical configuration data. Secure development practices such as code review and dependency scanning are used, and vendor and subprocessor assessments focus on security certifications, data protection, and contractual safeguards.
• Effect of data minimization on compliance risk. By not maintaining a persistent store of user documents, we reduce the scope and impact of potential data breaches. Reduced data holdings simplify compliance with some regulatory requirements and limit long-term obligations associated with stored content.

Our goal is to ensure that operational practices support regulatory compliance and can be readily mapped to formal frameworks as we progress to audited certifications.

11. Compliance Roadmap

As the platform and customer base grow, we intend to obtain formal attestations and certifications that validate our security and privacy controls.

• Short term. Formalize and document internal security and privacy policies, including access control and least-privilege standards, incident response and escalation procedures, and change management processes for infrastructure and application code. Maintain an up-to-date data inventory and data flow diagrams with emphasis on document analysis paths and third-party dependencies. Strengthen GDPR-aligned practices for account-level personal data, including subject access and deletion requests.
• Medium term. Engage an independent auditor to perform a SOC 2 Type I assessment focusing on security, availability, and confidentiality controls. Conduct regular independent penetration tests and security assessments and define processes for remediation of findings. Expand and document a vendor risk management program, including periodic review of subprocessors' certifications and security practices.
• Long term. Achieve SOC 2 Type II attestation, demonstrating the operation of key controls over a defined observation period. Implement and certify an ISO 27001 information security management system covering core services and supporting infrastructure. Evaluate additional frameworks, such as AI-specific standards including ISO 42001, as they mature and become relevant to customer requirements.

12. Vulnerability Disclosure

We operate a responsible vulnerability disclosure program and welcome contributions from security researchers and customers.

• Responsible disclosure expectations. Researchers are asked to investigate and report vulnerabilities in a way that avoids privacy violations, service disruption, or data destruction. They should not attempt to access data that does not belong to them and should give us reasonable time to investigate and remediate before public disclosure.
• How to report a vulnerability. Security issues can be reported to stefan.sajkovski@yups.tech with a detailed report including a clear description of the issue and potential impact, step-by-step reproduction instructions, affected components or endpoints, and contact details for coordinated follow-up.
• Handling of security reports. Reports are triaged and assigned a severity rating based on impact and exploitability. We acknowledge receipt of reports, investigate confirmed issues, prioritize remediation based on severity, and provide status updates where appropriate, particularly for high-impact issues. Once remediation is complete, we may update this Trust Center or other security documentation to reflect new controls or lessons learned.

13. Security Contact

Organizations evaluating or using PIA can contact our security and privacy team for due diligence, risk assessments, and compliance questions.

• Security and technical due diligence. For security questionnaires, vendor risk assessments, and detailed architecture or control descriptions, contact stefan.sajkovski@yups.tech.
• Privacy and data protection inquiries. For Data Protection Agreements, GDPR-related questions, and data subject requests concerning account-level data, contact stefan.sajkovski@yups.tech.

We encourage prospective and current customers to engage with us. Security and privacy are shared responsibilities, and we aim to provide the clarity needed for informed risk decisions and secure adoption of PIA.