AI Compliance — HIPAA, PCI-DSS & SOC2
Compliance guide for AI in regulated Indian enterprises
Every Indian enterprise exploring AI faces the same tension: move fast with AI adoption or move carefully to maintain compliance. In regulated industries — healthcare, financial services, insurance, legal — this tension is not theoretical. A single compliance violation can result in penalties running into crores, loss of certifications, and reputational damage that takes years to recover from.
This guide breaks down the compliance landscape for AI in Indian enterprises, covering the major frameworks that apply and practical strategies for using AI without violating them.
What You'll Learn
- HIPAA requirements for healthcare AI systems
- PCI-DSS constraints on fintech AI applications
- SOC2 audit requirements for AI-powered SaaS
- India DPDP Act 2023 implications for all AI systems
- Practical strategies to use AI compliantly in regulated industries
- A compliance checklist for enterprise AI adoption
HIPAA for Healthcare AI
The Health Insurance Portability and Accountability Act applies to any organization handling Protected Health Information (PHI) — and this includes Indian companies serving US healthcare clients, which is a significant portion of Indian IT services revenue.
What HIPAA Requires for AI Systems
Business Associate Agreement (BAA): Before any PHI touches an LLM API, the AI provider must sign a BAA. This makes them legally responsible for protecting the data.
| Provider | BAA Available | PHI-Safe Channel | |----------|:------------:|------------------| | AWS Bedrock | Yes | Claude, Titan via Bedrock API | | Azure OpenAI | Yes | GPT models via Azure endpoints | | Google VertexAI | Yes | Gemini via VertexAI API | | OpenAI Direct (api.openai.com) | Limited | Enterprise plan only | | Anthropic Direct (api.anthropic.com) | Limited | Enterprise plan only |
Minimum Necessary Rule: Only the minimum amount of PHI needed for the AI task should be sent. If you are summarizing a patient record, strip out data fields not relevant to the summary.
Audit Controls: Every interaction between your system and an LLM must be logged — what data was sent, what was returned, who initiated the request, and when. These logs must be retained and auditable.
Safe Patterns for Healthcare AI
Patient Record → PII Redaction Layer → De-identified Data → LLM API → Response → Re-identification Layer → Final Output
De-identification before API call: Replace patient names with tokens (Patient_A), remove dates of birth, mask medical record numbers. The LLM processes de-identified data. Your application re-maps tokens to real identities in the response.
On-premise models for sensitive tasks: For use cases where de-identification is impractical (radiology report analysis, clinical decision support), consider self-hosted models using Ollama or vLLM. Data never leaves your infrastructure.
PCI-DSS for Fintech AI
The Payment Card Industry Data Security Standard applies to any organization that stores, processes, or transmits cardholder data. Indian fintech companies, payment gateways, and banks building AI features must comply.
What Cannot Go to LLM APIs
PCI-DSS is unambiguous about cardholder data:
- Primary Account Number (PAN): Never send to external APIs
- CVV/CVC: Must not be stored anywhere, let alone sent to LLMs
- Expiry dates: Restricted when combined with PAN
- Cardholder name + PAN combination: Restricted
Safe AI Patterns for Fintech
Transaction analysis with tokenization:
# WRONG — PCI-DSS violation
prompt = f"Analyze this transaction: Card {card_number}, Amount ₹{amount}"
# CORRECT — tokenized reference only
prompt = f"Analyze this transaction: Token {transaction_token}, Amount ₹{amount}, Merchant category: {mcc_code}"
Fraud detection can use AI effectively by sending behavioral patterns (transaction velocity, geolocation anomalies, merchant category patterns) without any cardholder data. The LLM analyzes patterns, not card numbers.
Customer support AI for banking chatbots must be configured with guardrails that prevent the model from echoing back any card data, even if a customer types their card number into the chat.
SOC2 for SaaS AI
SOC2 Type II certification is essential for Indian SaaS companies selling to US and European enterprises. Adding AI features to a SOC2-certified product requires extending your controls to cover AI-specific risks.
SOC2 Trust Service Criteria Applied to AI
Security: Access controls on who can configure AI models, API key management, network segmentation for AI services.
Availability: SLA monitoring for LLM API providers. If your product depends on Claude API, what happens when Anthropic has an outage? Failover strategies are required.
Processing Integrity: AI outputs must be accurate and complete. This means:
- Output validation before presenting to users
- Hallucination detection for factual claims
- Version tracking of prompts and models (a prompt change can change outputs for all users)
Confidentiality: Customer data sent to LLM APIs must be handled according to your data handling policy. Most enterprise LLM APIs do not use customer data for training — but this must be verified and documented.
Privacy: Consent management for personal data processed by AI. Users must know when AI is processing their data and what data is involved.
AI-Specific SOC2 Controls
| Control | Implementation | |---------|---------------| | Audit logging | Log all LLM API calls with input hash, output hash, user ID, timestamp | | Access control | Role-based access to AI configuration and prompt management | | Change management | Version control for system prompts, review process for prompt changes | | Incident response | Playbook for AI-specific incidents (data leak via LLM, prompt injection) | | Vendor assessment | Annual review of LLM provider security posture and certifications |
India DPDP Act 2023
The Digital Personal Data Protection Act 2023 is India's comprehensive data protection law. It applies to all AI systems processing personal data of Indian citizens.
Key Requirements for AI Systems
Consent: Before processing personal data through AI, you need clear, informed consent. Generic terms of service are not sufficient — the consent must specifically mention AI processing.
Data Localization: Critical personal data must be processed within India. This affects cloud provider and region selection:
- AWS:
ap-south-1(Mumbai) - GCP:
asia-south1(Mumbai) - Azure:
Central India(Pune),South India(Chennai)
Right to Erasure: Data principals can request deletion of their data. If their data was used to fine-tune a model, this creates challenges. Enterprise AI architectures should prefer RAG over fine-tuning to make data deletion feasible.
Data Protection Officer: Significant Data Fiduciaries must appoint a DPO who oversees AI data processing practices.
DPDP Act Compliance Checklist for AI
- [ ] Consent mechanism specifically mentions AI processing
- [ ] Personal data processed in Indian cloud regions
- [ ] Data retention policies cover AI interaction logs
- [ ] Right to erasure process includes AI-processed data
- [ ] Data Protection Impact Assessment for AI use cases
- [ ] DPO appointed (if Significant Data Fiduciary)
- [ ] Cross-border data transfer mechanisms documented
Practical Strategies for Compliant AI
Strategy 1: Data Classification First
Before any AI implementation, classify your data:
| Classification | Example | LLM API Allowed | Requirement | |---------------|---------|:---------------:|-------------| | Public | Product descriptions | Yes | None | | Internal | Meeting summaries | Yes | Audit logging | | Confidential | Customer PII | Conditional | Redaction + BAA | | Restricted | PHI, card data | No (external) | On-premise only |
Strategy 2: Build a Redaction Pipeline
Every enterprise AI system should have a data redaction layer between your application and the LLM API:
- Input scanning: Detect PII, PHI, PAN data in user inputs
- Token replacement: Replace sensitive data with tokens
- API call: Send redacted data to LLM
- Response processing: Re-map tokens to real data if needed
- Audit log: Record the complete flow
Strategy 3: Use Enterprise AI Platforms
Cloud provider AI platforms (VertexAI, Bedrock, Azure AI) offer compliance features that direct API access does not — VPC isolation, CMEK encryption, audit logging, and BAA coverage.
Strategy 4: Prompt Security
Secure prompting practices prevent prompt injection attacks that could cause AI systems to leak sensitive data. System prompts must include explicit instructions to never reveal confidential information, even if a user requests it.
Compliance Audit Checklist for Enterprise AI
Use this checklist before deploying any AI system in a regulated environment:
- [ ] Data classification completed for all AI inputs
- [ ] LLM provider BAA signed (if handling PHI)
- [ ] PII/PHI redaction pipeline implemented and tested
- [ ] Audit logging for all LLM interactions enabled
- [ ] Access controls on AI system configuration verified
- [ ] Incident response plan for AI failures documented
- [ ] SOC2 controls extended to cover AI systems
- [ ] DPDP Act consent mechanism implemented
- [ ] Data residency requirements verified (Indian cloud regions)
- [ ] Prompt injection testing completed
Official Resources
- India DPDP Act 2023 — MeitY — Official text and guidelines
- HIPAA Security Rule — HHS.gov — US Department of Health and Human Services
- PCI-DSS v4.0 Standards — Payment Card Industry Security Standards Council
- SOC2 Trust Service Criteria — AICPA — American Institute of CPAs
- RBI Guidelines on AI/ML — Reserve Bank of India circulars on AI in banking
Next Steps
- Learn the V.A.U.L.T. framework for structured AI transformation that builds compliance from day one
- Implement AI security guardrails — monitoring, content filtering, and data redaction
- Practice secure AI prompting for regulated industries
- Compare enterprise AI platforms — VertexAI vs. Bedrock vs. Azure compliance features
Community Questions
0No questions yet. Be the first to ask!