Security & Compliance
Last updated: March 15, 2026
AI4Docs.AI is built with healthcare-grade security from the ground up. This page describes our security architecture, compliance measures, and the safeguards we implement to protect your data and your patients' information.
1. Infrastructure Overview
🛡 Our entire backend runs on Google Cloud Platform under a signed HIPAA Business Associate Agreement (BAA), ensuring all infrastructure services meet healthcare compliance requirements.
| Component |
Technology |
Security Features |
| Backend API |
Google Cloud Run |
HIPAA-eligible, auto-scaling, containerised, TLS enforced |
| AI Processing |
Google Vertex AI (Gemini) |
HIPAA-eligible, stateless (no data retention), no model training on your data |
| Temporary Audio Storage |
Google Cloud Storage |
AES-256 encryption at rest, 24-hour auto-deletion, signed URLs with 15-minute expiry |
| CDA Frontend |
Firebase Hosting |
Global CDN with TLS, security headers (HSTS, X-Frame-Options, CSP) |
| Authentication |
Supabase Auth |
bcrypt password hashing, OAuth 2.0, row-level security |
| Payments |
Stripe |
PCI DSS Level 1, no card data touches our servers |
| Smart EMR Data |
Google Sheets (doctor's own Drive) |
Doctor-controlled access, Google Workspace encryption |
2. Zero-Storage Architecture
The core principle of our security design is data minimisation. We process patient health information transiently and never maintain a database of patient records.
2.1 Data Lifecycle
- Capture: Your browser records audio or accepts text/file input. Data stays in browser memory.
- Transit: Data is transmitted to our backend over TLS 1.2+ encrypted connections.
- Processing: Our backend forwards the data to Google Vertex AI for note generation. Vertex AI processes the data statelessly — it does not store inputs, outputs, or use them for model training.
- Response: The generated clinical note is returned to your browser. No copy is retained on our servers.
- Cleanup: All temporary data (in-memory session state, GCS temp files) is automatically purged. Large audio files in Cloud Storage are deleted within 24 hours via lifecycle policy.
2.2 What This Means
- If our servers were ever compromised, there would be no patient records to exfiltrate
- There are no databases to breach, no patient files to expose
- The attack surface for patient data is limited to the brief processing window
3. Encryption
3.1 In Transit
- All connections use TLS 1.2 or higher (HTTPS enforced)
- HTTP Strict Transport Security (HSTS) headers prevent downgrade attacks
- Browser-to-backend, backend-to-Vertex AI, backend-to-Supabase — all encrypted
3.2 At Rest
- Google Cloud Storage uses AES-256 encryption for all stored objects (temporary audio files)
- Supabase encrypts database contents at rest
- Stripe encrypts all payment data in compliance with PCI DSS Level 1
4. Access Controls
- Least-privilege service accounts: Backend service accounts have only the minimum permissions required for their function
- API key validation: Smart EMR endpoints require a unique per-user API key for every request
- Row-level security (RLS): Supabase database enforces that users can only access their own profile data
- Signed URLs: Temporary audio upload URLs expire after 15 minutes and are write-only (cannot be used to read other files)
- CORS restrictions: Cloud Storage accepts uploads only from authorised domains
- Webhook signature verification: All Stripe webhooks are cryptographically verified before processing
5. Audit Logging
We maintain comprehensive audit logs for security monitoring and compliance:
- Cloud Audit Logs for Cloud Run, Vertex AI, Cloud Storage, and Secret Manager (both data access and admin activity)
- 6-year retention in Google Cloud Storage archive bucket (meeting regulatory requirements)
- PHI exclusion filter: An automated log filter ensures that patient health information (patient names, diagnoses, medications, prescription details) is excluded from stored audit logs
6. HIPAA Compliance
6.1 Business Associate Agreement
AI4Docs.AI operates under a signed HIPAA Business Associate Agreement (BAA) with Google Cloud, covering:
- Google Cloud Run (backend hosting)
- Google Vertex AI (AI processing)
- Google Cloud Storage (temporary file storage)
- Google Secret Manager (credentials management)
6.2 Technical Safeguards
| HIPAA Requirement |
Our Implementation |
| Access Controls |
Unique user authentication, role-based service accounts, row-level database security |
| Encryption |
TLS 1.2+ in transit, AES-256 at rest for all stored data |
| Audit Controls |
Cloud audit logs with 6-year retention, PHI exclusion filter, automated log archival |
| Integrity Controls |
Webhook signature verification, atomic database operations, idempotency safeguards |
| Transmission Security |
HTTPS enforced on all endpoints, HSTS headers, CORS restrictions |
| Data Minimisation |
Zero-storage architecture: no persistent PHI, 24-hour auto-delete for temp files |
6.3 Shared Responsibility
HIPAA compliance is a shared responsibility. AI4Docs.AI provides the technical infrastructure and safeguards. As the healthcare provider (covered entity), you are responsible for:
- Patient consent and authorisation for recording and AI processing
- Secure use of your own devices, browsers, and networks
- Your own Google Workspace security settings (for Smart EMR users)
- Compliance with all applicable regulations in your jurisdiction
7. GDPR Compliance
- Data Protection Officer: Prof. Dr. Alaa Meshref (support@ai4docs.ai)
- ICO Registration: AI4DOCS.AI LTD is registered with the UK Information Commissioner's Office (Reference: C1891752)
- Data Processing Agreement: Available for all healthcare providers. See our DPA.
- Lawful basis: We process data based on contractual necessity (providing the Service) and your instructions as Data Controller.
- Data minimisation: We collect only what is necessary and retain nothing beyond operational requirements.
- Right to erasure: Patient data is not stored, so there is nothing to erase. Account data is deleted within 30 days of a deletion request.
- Data portability: Profile data can be exported upon request.
- Google Cloud Data Processing Addendum: Accepted (March 5, 2026), providing GDPR-compliant standard contractual clauses for international data transfers.
8. MENA-Ready Architecture
AI4Docs.AI's zero-storage architecture and HIPAA/GDPR-compliant infrastructure are designed to align with data protection requirements across the Middle East and North Africa (MENA) region:
- Saudi Arabia (NDMO / PDPL): The Personal Data Protection Law requires data residency or adequate protection for Saudi residents' data. Our zero-storage architecture means no patient data is stored on any server — eliminating data residency obligations entirely. Audio is processed transiently and immediately discarded.
- UAE (Federal Data Protection Law / DHA): The UAE's Federal Decree-Law No. 45 of 2021 on Personal Data Protection is modeled on GDPR. Our full GDPR compliance covers all requirements under the UAE framework. Dubai Health Authority (DHA) security requirements are met through our encrypted, stateless processing pipeline.
- Egypt (EDPA): Egypt's Personal Data Protection Act follows GDPR principles. Our GDPR compliance and zero-storage architecture satisfy EDPA requirements for health data processing.
- Qatar (PDPPL) / Bahrain / Kuwait / Oman / Jordan: All GCC and MENA data protection laws are influenced by or aligned with GDPR. Our GDPR-compliant infrastructure with zero patient data storage is designed to align with the core requirements of these frameworks.
- Data Sovereignty: Since no patient data is stored on our servers, there are no cross-border data transfer concerns. The doctor's clinical notes exist only in their browser and any systems they choose to export to.
Note: AI4Docs.AI is built on Google Cloud infrastructure with a signed HIPAA BAA — the strictest healthcare compliance standard globally. MENA data protection frameworks are derived from or aligned with GDPR, which our platform fully complies with. Our zero-storage architecture provides an additional layer of alignment with regional requirements by design.
9. Risk Assessment Summary
We conduct regular risk assessments of our data handling practices. Key risks and mitigations:
| Risk |
Likelihood |
Mitigation |
| Unauthorised access to patient data in transit |
Low |
TLS 1.2+ encryption on all connections; HSTS prevents downgrade attacks |
| Patient data breach from database compromise |
Very Low |
No patient database exists; zero-storage architecture eliminates this attack vector |
| Temporary audio file exposure |
Low |
24-hour auto-deletion; write-only signed URLs with 15-minute expiry; AES-256 encryption at rest |
| AI model data leakage |
Very Low |
Vertex AI operates statelessly; no data retention, no model training on customer data |
| Authentication compromise |
Low |
bcrypt password hashing; OAuth 2.0; session token management by Supabase Auth |
| Payment data theft |
Very Low |
Card data never touches our servers; processed entirely by Stripe (PCI DSS Level 1) |
| Smart EMR data exposure |
Low |
Data stored on doctor's own Google Drive; doctor controls sharing; service account access is opt-in and revocable |
| PHI in system logs |
Low |
Automated PHI exclusion filter blocks patient/diagnosis/medication keywords from stored logs |
10. Breach Notification Plan
In the unlikely event of a security incident involving personal data, we follow a structured response process:
10.1 Detection and Containment
- Cloud audit logs and Google Cloud monitoring alerts are reviewed for anomalies
- Upon detection of a potential breach, the affected systems or access credentials are immediately isolated
- The incident is logged with timestamp, scope, and initial assessment
10.2 Assessment
- We assess the nature and scope of the incident: what data was involved, how many users affected, and whether patient health information was at risk
- Due to our zero-storage architecture, the risk of PHI exposure is inherently limited to data in transit during the brief processing window
10.3 Notification Timelines
| Obligation |
Timeline |
Recipient |
| GDPR (EU/UK) |
Within 72 hours of becoming aware |
Information Commissioner's Office (ICO) and affected individuals (if high risk) |
| HIPAA (US) |
Within 60 days of discovery |
Affected individuals, HHS, and (if >500 individuals) prominent media |
| Subscriber doctors |
Within 48 hours of confirmation |
All affected users via email |
10.4 Notification Content
Breach notifications will include:
- Nature of the breach and type of data involved
- Date and duration of the incident
- Measures taken to contain and remediate the breach
- Steps affected users should take
- Contact information for questions
10.5 Post-Incident Review
- Root cause analysis conducted within 30 days
- Security controls updated to prevent recurrence
- Incident report documented and retained for regulatory purposes
11. Sub-processor List
The following third-party services process data on our behalf. We maintain agreements with each sub-processor to ensure appropriate data protection:
| Sub-processor |
Purpose |
Data Processed |
PHI? |
Compliance |
| Google Cloud Platform |
Backend hosting (Cloud Run, us-central1), AI processing (Vertex AI), temporary storage (Cloud Storage) |
Audio, text (transiently); account metadata |
Transient only |
HIPAA BAA signed, SOC 2, ISO 27001 |
| Firebase Hosting (Google) |
CDA application frontend (clinic.ai4docs.ai) |
None (static content; all data handled by backend) |
No |
Google Cloud SOC 2, ISO 27001 |
| Supabase |
Authentication, doctor profiles, usage tracking |
Email, professional profile, subscription data |
No |
SOC 2 Type II (Frankfurt, Germany — EU) |
| Stripe |
Payment processing, subscription management |
Email, payment card details |
No |
PCI DSS Level 1, SOC 2 (United Kingdom) |
| Resend |
Transactional email delivery |
Email address, subscription status |
No |
SOC 2 |
| Netlify |
Marketing website hosting (ai4docs.ai) |
None (static content) |
No |
SOC 2 |
We will notify subscribers of any changes to this sub-processor list at least 30 days in advance.
12. Smart EMR Security Model
Smart EMR uses a unique architecture where patient data remains entirely under the doctor's control:
- Data Sovereignty: All patient records are stored in the doctor's own Google Sheet, on their own Google Drive. AI4Docs.AI does not host, own, or have default access to this data.
- Opt-in Access: To enable CDA integration, the doctor explicitly shares their Google Sheet with our service account. This can be revoked at any time by removing the sharing.
- Cloned Template: Smart EMR is cloned from a template to the doctor's own Google Workspace. Each doctor's instance is fully independent.
- Google Workspace Security: Data is protected by Google Workspace's enterprise-grade security, including encryption at rest and in transit, access controls, and audit logging.
- AppSheet Security: Require Sign-In is enabled. Users can only see their own data (enforced by USEREMAIL() throughout the app).
13. Application Security
- Security Headers: X-Content-Type-Options, X-Frame-Options, X-XSS-Protection, Referrer-Policy, and Content-Security-Policy headers on all responses
- No Tracking: The CDA application does not use third-party analytics, advertising pixels, or tracking cookies
- Service Worker: Caches only static assets (HTML, CSS, JS). API responses and clinical data are never cached by the service worker
- Session Management: Authentication tokens managed by Supabase Auth with automatic refresh. Sessions are invalidated on logout.
- Input Validation: All API endpoints validate input parameters before processing
14. Responsible Disclosure
If you discover a security vulnerability in our service, we encourage responsible disclosure. Please report it to support@ai4docs.ai. We commit to:
- Acknowledging your report within 48 hours
- Providing an initial assessment within 7 days
- Keeping you informed of remediation progress
- Not pursuing legal action against good-faith security researchers
15. Contact
For security questions, compliance inquiries, or to request our Data Processing Agreement:
Email: support@ai4docs.ai
HIPAA Security Officer / DPO: Prof. Dr. Alaa Meshref
Company: AI4DOCS.AI LTD
Address: 167-169 Great Portland Street, 5th Floor, London W1W 5PF, United Kingdom
Company No. 16893518
ICO Registration: C1891752
