Security is foundational to RAi. Our customers handle sensitive regulatory documentation for medical device companies, and we take our responsibility to protect that data seriously. This page describes our security posture, infrastructure, access controls, and data handling.
RAi is built on established, enterprise-grade cloud infrastructure providers and does not run its own data centers. You benefit from the security investments those providers have already made. Each provider is named, with its role and certifications, in our Data Processing Agreement, which is provided to customers and prospects under NDA.
Our API runs on a globally distributed edge compute platform providing DDoS protection, a web application firewall, and TLS termination, operated under ISO 27001, PCI DSS Level 1, and other independent security frameworks. All traffic to RAi is served exclusively over HTTPS, and HTTP requests are permanently redirected.
Customer Data (documents, metadata, audit logs, organization records) is stored in the United States on a managed Postgres platform running on a major cloud provider. It provides encryption at rest (AES-256), encryption in transit (TLS 1.2+), automated daily backups with point-in-time recovery, and row-level isolation enforced at the database layer. The provider maintains independent third-party security certifications.
Uploaded document files are stored in the United States on managed object storage with encryption at rest (AES-256) and are accessed only via time-limited signed URLs generated by our API after verifying the requesting user's organization membership and permissions. Documents imported from a connected Microsoft 365 tenant are read on demand via the Microsoft Graph API using OAuth tokens you authorize.
RAi runs on infrastructure operated by established cloud providers that maintain independent third-party security certifications available through their trust portals. Our application-layer controls, covering access management, audit logging, secret handling, and incident response, are designed and operated to recognized security best practices.
For security reviews, vendor assessments, or specific compliance documentation, contact [email protected] and our team will work directly with your security organization.
Our Data Processing Agreement (DPA), including the sub-processor list, technical and organizational measures, and Standard Contractual Clauses, is available for enterprise customers.
RAi is a regulatory affairs and QMS platform. Its intended use is to store and manage QMS documentation, device technical files, 510(k) preparation materials, project records, and similar non-patient-specific content. Medical device regulatory documentation such as DHFs, risk management files and design records generally does not constitute PHI under HIPAA as long as it does not contain patient-identifiable information.
Some customers may wish to upload clinical study protocols or post-market surveillance data that could contain patient identifiers. If this applies to you:
Our key sub-processors and their HIPAA status are:
Note: our AI sub-processor does not train models on API inputs by default. If your organization requires a formal BAA covering AI processing, contact us and we will identify the provider and route the request.
RAi enforces role-based access control (RBAC) within every Organization. The available roles and their capabilities are:
| Role | Description |
|---|---|
| Owner | Full access; manage billing, members, and all data |
| Admin | Manage members and all content; cannot change billing |
| Member | Create, edit, and sign documents; manage projects |
| Consultant | Read access plus predicate search; cannot sign documents |
| Viewer | Read-only access to documents and projects |
Platform-level administrative access is granted by explicit invitation only and recorded in a controlled roster. It is never conferred by an email address or its domain. Sessions end automatically after a configurable period of inactivity, with a warning before logoff.
All role checks are enforced server-side at the API layer. The front-end UI is for display purposes only and cannot bypass server-side authorization. Organization isolation is enforced at the database layer by row-level security policies that filter every query by org_id.
RAi includes an electronic signature feature aligned with the principles of 21 CFR Part 11 (FDA's rule on electronic records and signatures). Our implementation provides:
RAi treats AI output as something that has to be accountable, not only accurate. Four controls apply to every workspace.
AI reads, and proposes. It cannot create, change, approve or sign a controlled record. A proposal is a separate object that a person reviews field by field, edits, and authorizes with a recorded reason; the record is then created under that person's identity, not the AI's. Rejecting a proposal is recorded too. This is enforced in the API, so no interface path or configuration bypasses it.
For each generation RAi records the model and its exact version, an identifier and cryptographic hash of the prompt used, the sources retrieved to ground it, hashes of the input and output, and what the reviewing person then did: accepted as written, accepted after edits with the fields they changed, or rejected. Prompt text itself is never stored; the hash proves which prompt version ran without disclosing its contents. Failed generations are recorded as well.
Records can be marked as containing PHI, which blocks them from AI drafting, AI analysis and any connected AI client. Submitted content is separately screened for patient identifiers, so the control does not depend on someone remembering to mark the record. RAi does not transmit PHI to its AI sub-processor. A de-identification tool replaces detectable identifiers before processing; it reduces risk and is not a de-identification determination under 45 CFR 164.514(b).
RAi runs an automated control verification against the live system after every release. It exercises the controls described on this page rather than inspecting the code that implements them: it confirms that patient identifiers are detected and that ordinary regulatory text and supplier contact details are not, that de-identification removes what it found, that editing signed content changes the hash its signature is bound to, that storage access is refused outside your own tenant, and that the audit log and PHI access log accept and return events. Organization Owners and Administrators can run it themselves from the Diagnostics page and export a dated record of the result for their validation file.
Every significant action in RAi is written to an immutable audit log. Recorded events include: user login and logout, document upload, download, edit, and deletion, e-signature events, project creation and modification, team member role changes, and AI chat interactions. Audit logs include a timestamp, user ID, user email, action type, target object ID, and relevant metadata.
Access to records marked as containing PHI is additionally written to a separate, append-only PHI access log, so a privacy officer can review those events without filtering the general trail. Administrative access into a customer workspace is flagged as elevated in that log.
Audit log entries are retained for a minimum of 7 years to support regulatory and quality management requirements, including 21 CFR Part 820 and ISO 13485 records retention requirements.
Audit logs can be exported by Organization Owners and Administrators from the Audit Log page within the RAi application.
Every query to our database includes an org_id filter enforced by Row-Level Security (RLS). It is architecturally impossible for a query from one organization's authenticated session to return data belonging to a different organization.
Our database platform provides automated daily backups with point-in-time recovery. Our Recovery Time Objective (RTO) and Recovery Point Objective (RPO) depend on our infrastructure provider's SLAs, which are provided under NDA.
No secrets, API keys, or tokens are embedded in client-side JavaScript. All sensitive values are stored as encrypted server-side environment secrets and accessed only server-side at runtime.
In the event of a confirmed security incident involving Customer Data, we will:
To report a security incident or potential vulnerability, email us immediately at [email protected].
We welcome reports of security vulnerabilities from security researchers and customers. If you discover a potential security issue in RAi, please:
We do not currently operate a paid bug bounty program, but we deeply appreciate responsible disclosure and will acknowledge valid reports.
If you are located in the European Economic Area (EEA), United Kingdom, or Switzerland, you have certain rights under the General Data Protection Regulation (GDPR) or equivalent laws, including the right to access, correct, delete, or export your personal data.
Our primary data processing occurs in the United States. Data transfers from the EEA to the US rely on Standard Contractual Clauses (SCCs) as provided in our sub-processors' data processing agreements. We are not an established business in the EEA and do not designate an EU representative at this time; if you have GDPR concerns, contact us at [email protected].
For a full description of data we collect and how we use it, see our Privacy Policy.
We use the following sub-processors to deliver the Service:
We do not sell your data to third parties. Sub-processors are only permitted to process your data as needed to provide the Service.