Data Handling

Beta Program | Last updated: April 2026

This document is intended to give prospective beta customers a clear, plain-language explanation of how InPolicy AI handles data. For full contractual details, our Data Processing Agreement (DPA) is available at https://inpolicy.ai/legal/dpa. This document is provided for informational purposes only and does not create any contractual obligations beyond those set forth in InPolicy’s Terms of Service, Privacy Policy, Data Processing Agreement, Security Addendum, Acceptable Use Policy, and Cookie Policy (collectively, the “Legal Documents”). In the event of any inconsistency between this document and any Legal Document, the applicable Legal Document shall control. All Legal Documents are available at https://inpolicy.ai/legal.

1. What Data InPolicy Collects and Stores

Account and Organization Data

When a user creates an account, InPolicy stores basic account information (name, email address, role) and creates an organizational profile. This data is used solely to manage access and deliver the service. InPolicy does not use this data for any purpose other than operating the Service, communicating with you about the Service, and complying with legal obligations. This data is encrypted at rest and in transit, and access is limited to authorized personnel on a need-to-know basis.

Policy Documents

Organizations configure InPolicy by uploading policy documents (PDFs, URLs, or other files) that define their compliance requirements. These documents are stored securely on Google Cloud Platform (GCP) infrastructure located in the United States. Policy documents are owned by the customer organization and are treated as confidential.

InPolicy staff will not access your policy documents unless you explicitly request it (for example, as part of a supported onboarding or customer service engagement). Any such access is logged and traceable. Policy documents are encrypted at rest using AES-256 encryption and in transit using TLS 1.2 or higher. Access to policy documents is controlled through role-based access controls, and all access events are logged with timestamps, user identity, and the nature of the access. Logs are retained for audit and compliance purposes. InPolicy does not share your policy documents with any third party, except as necessary to provide the Service through its subprocessors as described in Section 5.

2. What Data InPolicy Does NOT Store

User Content

InPolicy is designed so that the content your employees are working on — emails, documents, messages — is never stored by InPolicy. This is a core architectural principle, not just a policy commitment.

All user content is processed transiently: it is received, analyzed, and a response is returned. Nothing is written to persistent storage. To be specific: user content exists only in volatile memory (RAM) during the processing cycle. It is not written to disk, not cached, not logged, and not retained in any database or file system. Once the analysis is complete and the response is returned, the content is released from memory. InPolicy’s LLM subprocessor (Google Vertex AI) operates under a data processing agreement that contractually prohibits the retention, logging, or use of content for model training or any purpose other than returning the inference result.

Policy state summaries — system-generated records of which policies are active and applicable to a given conversation, containing no message text or personal information — do not constitute Content and may be retained for the duration of an active enforcement session, subject to a maximum of 30 days.

Violation Logs

When a policy violation is detected, InPolicy logs anonymous metadata only: timestamp, the policy rule triggered, severity level, and engagement signals (e.g. whether the user accepted, dismissed, or resolved the suggested change). This metadata is not linked to any individual user identity — it cannot be used to identify who was working on a document or what they were writing. It is retained for aggregate analytics purposes only and is not used for individual monitoring or follow-up. To be clear: violation metadata does not contain any text from the document being reviewed, any identifier of the individual user, or any information that could be used to reconstruct the content of the communication. InPolicy applies technical safeguards to ensure that violation metadata cannot be re-linked to individual users or specific content. This metadata is used exclusively to generate aggregate reports for customer organizations (e.g., total violations by policy category, resolution rates) and to improve the accuracy of InPolicy’s detection capabilities.

3. How Data Flows Through InPolicy

Browser Extension

• The extension extracts text from the document or email the user is actively working on.
• That text is transmitted to the InPolicy policy violation endpoint over an encrypted connection (TLS).
• InPolicy's backend selects the relevant policy context for that organization and constructs a prompt.
• The prompt is sent to our LLM provider (Google, via Vertex AI) over an encrypted connection.
• The LLM response (violation analysis and suggestions) is returned to the user's browser.

No user content is stored at any point in this flow. All data transmitted between the browser extension and InPolicy’s servers is encrypted using TLS 1.2 or higher. All data transmitted between InPolicy’s servers and the LLM provider is similarly encrypted in transit. InPolicy’s backend infrastructure runs on Google Cloud Platform with network-level isolation, and all inter-service communication within InPolicy’s backend is encrypted.

Policy Bot (Google Docs Agent)

• The user shares a Google Doc with the InPolicy Policy Bot's dedicated account for their organization.
• The Policy Bot opens the document and extracts its text.
• The text is processed through the same policy violation endpoint described above.
• The Policy Bot uses document automation to leave comments and suggestions directly in the Google Doc.
• The Policy Bot removes the document from its Google Drive immediately after processing.

A note on Google Docs sharing: When a document is shared with the Policy Bot account and subsequently removed from the bot's Drive, the sharing permission technically persists in Google's system until the document owner revokes it. InPolicy has no mechanism to enumerate or discover documents accessible to that account — exploitation would require an attacker to independently know a specific document ID. We recommend users revoke sharing access after processing is complete, and we are evaluating additional controls to automate this step. InPolicy recommends that organizations establish an internal process for revoking sharing permissions after each processing cycle. The Policy Bot account is secured with multi-factor authentication, and is monitored for unauthorized access attempts. InPolicy will notify customers promptly if any unauthorized access to the Policy Bot account is detected.

4. How InPolicy Understands Context

Accurate policy enforcement requires more than checking a message against a rule. Many violations — an unsupported product claim, a reference to a competitor that violates policy, a statement that conflicts with a regulatory requirement — are only detectable if the system understands the facts necessary to apply the relevant policies. InPolicy maintains a Tenant Knowledge Base for each customer organization to provide this grounding.

Tenant Knowledge Base

The Tenant Knowledge Base is a structured set of facts assembled specifically to fill the gaps needed for effective policy enforcement. It contains only information that is directly relevant to applying your organization's policies — for example, who your competitors are, what your products claim to do, and what regulatory standards apply to your business.

This knowledge base is assembled and maintained by InPolicy, primarily from publicly available sources such as product documentation, public filings, and regulatory registers. It is specific to your organization, is never shared with or accessible to other InPolicy customers, and contains no employee communications or personal data.

Your organization can review and correct the Tenant Knowledge Base at any time by contacting security@inpolicy.ai.

Why this matters: A policy prohibiting unsupported product claims cannot be enforced without knowing what your products actually claim. A policy prohibiting competitor disparagement cannot be enforced without knowing who your competitors are. The Tenant Knowledge Base exists solely to close these gaps — it contains only what is necessary to make enforcement decisions, nothing more.

5. Subprocessors and Third-Party Data Handling

InPolicy does not share customer data with any other third parties. InPolicy has executed a Cloud Data Processing Agreement with Google Cloud covering both infrastructure (GCP) and LLM inference (Vertex AI). InPolicy will provide at least 30 days' notice before adding or replacing any subprocessor. The Google Cloud Data Processing Agreement includes contractual commitments that Google will not use customer data for advertising, will not train its AI models on customer data, and will process data only in accordance with InPolicy’s instructions. Google’s Vertex AI service operates under a zero-data-retention policy for inference requests, meaning that prompts and responses are not stored or logged by Google after processing is complete. InPolicy conducts periodic reviews of its subprocessors’ data protection practices and security certifications. Any new subprocessor will be subject to the same level of due diligence and contractual data protection requirements before engagement.

6. Data Residency

All data processed and stored by InPolicy is hosted on Google Cloud Platform infrastructure located in the United States. We do not transfer customer data outside the United States.

7. No Training on Customer Data

InPolicy does not use customer data — including policy documents, user content, or violation metadata — to train, fine-tune, or improve any AI model. This applies to both InPolicy's own systems and any LLM subprocessors. To be explicit: InPolicy does not use customer data for fine-tuning, reinforcement learning from human feedback (RLHF), embeddings generation, transfer learning, or any other form of machine learning model development. This prohibition applies regardless of whether the data has been anonymized or aggregated. InPolicy’s subprocessor agreements contractually prohibit Google from using any customer data to train or improve Google’s own AI models. InPolicy may use aggregated, anonymized usage data (which does not include any customer content or personally identifiable information) to improve the Service’s general performance, as described in the Terms of Service.

8. Access Controls

• Customer data is accessible only to a small engineering team on a need-to-access basis.
• Access to customer policy documents requires an explicit, logged support request from the customer.
• All internal access to production systems is authenticated and logged.

InPolicy is in active preparation for SOC 2 Type I certification. A security posture report is available upon request. In addition to the measures described above, InPolicy maintains the following access controls: role-based access with the principle of least privilege; multi-factor authentication for all employees with access to production systems; automated monitoring and alerting for anomalous access patterns; regular access reviews to ensure that permissions remain appropriate; and documented onboarding and offboarding procedures that include immediate revocation of access for departing employees.

9. No Guarantee of Compliance or Complete Detection

InPolicy does not guarantee the detection of all policy violations. The Service may not identify every instance of non-compliant content, and the absence of a violation flag does not constitute a representation that any communication, document, or other content reviewed by the Service is compliant with any applicable law, regulation, internal policy, or other requirement.

Use of the Service does not transfer compliance responsibility to InPolicy. Customers remain solely responsible for their own compliance programs and for ensuring that their communications and activities comply with all applicable laws and regulations. InPolicy is a detection assistance tool; it is not a compliance officer, legal advisor, or guarantor of regulatory compliance. InPolicy strongly recommends that all Output be reviewed by a qualified compliance or legal professional before any action is taken. The Service is designed to assist human decision-makers, not to replace them. InPolicy’s AI technology is inherently probabilistic and may produce false positives (flagging compliant content as a violation) or false negatives (failing to flag non-compliant content). Neither outcome creates liability for InPolicy, as set forth in the Terms of Service.

10. Data Retention and Deletion

11. Customer Rights

Customers may request at any time:

• A copy of their stored data
• Deletion of their policy documents and account data
• Review or correction of their Tenant Knowledge Base
• A copy of our Data Processing Agreement (DPA) at https://inpolicy.ai/legal/dpa
• Our current SOC 2 readiness report

Requests can be directed to: security@inpolicy.ai InPolicy will acknowledge receipt of all customer data requests within five (5) business days and will use commercially reasonable efforts to fulfill requests within thirty (30) days. Data exports will be provided in a commonly used, machine-readable format (such as JSON or CSV). Deletion requests will be confirmed in writing upon completion. Customers may also exercise their rights under applicable privacy laws (including the CCPA, GDPR, and other applicable data protection laws) by contacting privacy@inpolicy.ai.

12. Incident Response

InPolicy maintains a documented incident response plan that covers the identification, containment, eradication, and recovery from security incidents. In the event of a confirmed security breach affecting customer data, InPolicy will notify affected customers within seventy-two (72) hours, as required by applicable law and our Data Processing Agreement. Notifications will include: a description of the nature of the breach; the categories and approximate number of data records affected; the likely consequences of the breach; and the measures taken or proposed to address the breach and mitigate its effects. InPolicy conducts periodic tabletop exercises to test its incident response procedures and incorporates lessons learned into its security program.

13. Prohibited Data Types

The Service is not designed to process, and customers should not submit, the following types of data: Protected Health Information (PHI) as defined under HIPAA; payment card data subject to PCI DSS; data classified under ITAR or EAR; government classified or controlled unclassified information (CUI); personal data of children under eighteen (18); or any data whose processing through a cloud-based AI service would violate applicable law or regulation. InPolicy does not offer Business Associate Agreements and is not HIPAA-compliant. Submitting prohibited data types constitutes a material breach of the Terms of Service.

14. Geographic Restrictions

The Service is currently not available to organizations or users based in the United Kingdom. All data is stored and processed in the United States. InPolicy does not transfer customer data outside the United States. For customers subject to the GDPR who transfer personal data from the European Economic Area, InPolicy offers Standard Contractual Clauses (Module 2, Controller to Processor) as part of its Data Processing Agreement.

This document reflects InPolicy AI's data handling practices as of the beta program launch. It will be updated as our infrastructure and certification status evolves. For questions, contact us at security@inpolicy.ai.