Privacy-Preserving AI Architectures

Four privacy architecture patterns

Each pattern trades off privacy, cost, capability, and operational complexity differently.

Pattern 1: Fully Local (Maximum Privacy)

User Device
├── Local model (browser or native app)
├── Local embeddings and vector index
├── Local data storage
└── No network connections for AI workloads

• Privacy level: Maximum. Data never leaves the device.
• Threats mitigated: All six. No external attack surface.
• Capability: Limited to what runs on the device (2-12B models typically).
• Use cases: Personal knowledge bases, field workers, classified environments, individual professional tools.
• Limitations: No cross-user capabilities, limited model size, user is responsible for their own device security.

Pattern 2: On-Premises Centralised (High Privacy)

Enterprise Network
├── vLLM cluster (GPU servers)
├── Vector database (on-prem)
├── Document ingestion pipeline
├── Internal API gateway with auth
└── No external AI API calls

• Privacy level: High. Data stays within the enterprise network.
• Threats mitigated: 1, 2, 5 fully. 3, 4, 6 partially (depends on internal controls).
• Capability: 27-70B models, full RAG pipelines, high throughput.
• Use cases: Enterprise-wide AI service, regulated industries, organisations with existing data centre infrastructure.
• Limitations: Capital expense for GPU hardware, requires infrastructure team to maintain.

Pattern 3: VPC-Isolated Cloud (Moderate Privacy)

Cloud VPC (your tenant, your network)
├── GPU instances (cloud provider)
├── Model served within your VPC
├── Data encrypted at rest and in transit
├── No data leaves your VPC
└── Cloud provider has physical access to hardware

• Privacy level: Moderate. Data stays in your cloud tenant but exists on shared physical infrastructure.
• Threats mitigated: 1, 2 mostly. 3, 4 partially. 5 depends on regulatory interpretation.
• Capability: Equivalent to on-premises, with cloud scalability.
• Use cases: Organisations without data centres, moderate regulatory requirements, need for elastic scaling.
• Limitations: Cloud provider has theoretical physical access. Regulatory interpretation varies on whether VPC isolation satisfies data residency requirements.

Pattern 4: Hybrid with Sanitisation (Pragmatic Privacy)

On-Premises / Edge
├── Local model handles most queries
├── PII gateway sanitises queries that need cloud escalation
└── Sanitised queries → Cloud API
    └── Cloud response → PII restoration → User

• Privacy level: Proportional. PII stays local. Non-sensitive context may reach cloud.
• Threats mitigated: 1 partially (PII protected, some context sent). 2-6 partially.
• Capability: Edge quality for most queries, frontier quality for complex ones.
• Use cases: Organisations that need cloud quality for some tasks but must protect PII.
• Limitations: PII detection is imperfect. Sanitisation may remove context needed for the best answer. Regulatory acceptance varies.

Building a PII detection layer

PII detection is the technical foundation of privacy-preserving AI architectures. It is also where most implementations are weaker than they think.

What counts as PII:

Under GDPR, personal data is any information relating to an identified or identifiable natural person. This includes the obvious (name, email, phone, address, date of birth, national ID numbers) and the less obvious:

• IP addresses
• Cookie identifiers
• Location data
• Biometric data
• Genetic data
• Political opinions, religious beliefs (special category data)
• Health information
• Trade union membership
• Data that could identify someone in combination with other data

Building effective detection:

Layer 1: Pattern matching (deterministic)

import re

PATTERNS = {
    "EMAIL": r'\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,}\b',
    "PHONE_UK": r'\b(?:0|\+44)\s?\d{4}\s?\d{6}\b',
    "PHONE_US": r'\b(?:\+1\s?)?\(?\d{3}\)?[\s.-]?\d{3}[\s.-]?\d{4}\b',
    "SSN": r'\b\d{3}-\d{2}-\d{4}\b',
    "CREDIT_CARD": r'\b\d{4}[\s-]?\d{4}[\s-]?\d{4}[\s-]?\d{4}\b',
    "NHS_NUMBER": r'\b\d{3}\s?\d{3}\s?\d{4}\b',
    "NINO": r'\b[A-CEGHJ-PR-TW-Z]{2}\s?\d{2}\s?\d{2}\s?\d{2}\s?[A-D]\b',
    "DATE_OF_BIRTH": r'\b(?:DOB|Date of Birth|born on)[:\s]+\d{1,2}[/.-]\d{1,2}[/.-]\d{2,4}\b',
    "POSTCODE_UK": r'\b[A-Z]{1,2}\d[A-Z\d]?\s?\d[A-Z]{2}\b',
    "IP_ADDRESS": r'\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b',
}

Layer 2: NER model (probabilistic)

# Using Microsoft Presidio (open source PII detection)
from presidio_analyzer import AnalyzerEngine
from presidio_anonymizer import AnonymizerEngine

analyzer = AnalyzerEngine()
anonymizer = AnonymizerEngine()

text = "Dr. Sarah Thompson reviewed the case at St Mary's Hospital on 15 March."

results = analyzer.analyze(text=text, language='en')
# Detects: PERSON (Sarah Thompson), LOCATION (St Mary's Hospital), DATE_TIME (15 March)

anonymized = anonymizer.anonymize(text=text, analyzer_results=results)
# Output: "<PERSON> reviewed the case at <LOCATION> on <DATE_TIME>."

Presidio combines rule-based detection with spaCy NER models. It is production-ready, supports multiple languages, and is extensible with custom recognisers.

Layer 3: Context-aware detection (LLM-based)

For the highest quality PII detection, use your local LLM:

async def detect_contextual_pii(text: str, local_model) -> list:
    response = await local_model.generate(f"""
Identify all personally identifiable information in the following text.
Include: names, addresses, phone numbers, emails, dates that could identify someone,
organisation names that reveal confidential business relationships,
and any other information that could directly or indirectly identify a person.

Format each finding as: [TYPE]: "exact text"

Text: {text}

Findings:""", temperature=0, max_tokens=500)

    return parse_findings(response)

This catches contextual PII that neither regex nor standard NER detects: nicknames, indirect references ("my manager" in a small team), organisation names that reveal relationships, and combinations of innocuous data that together identify someone.

The cost of false negatives vs false positives:

• False negative (missed PII): A privacy violation. Sensitive data reaches the cloud API. Depending on the data and regulation, this could be a reportable breach.
• False positive (over-redaction): The sanitised query loses context, and the cloud model's answer quality degrades. Annoying but not a compliance violation.

For privacy-critical deployments, bias toward false positives. It is better to over-redact and get a slightly worse answer from the cloud model than to miss PII and create a compliance exposure.

Logging inference without logging content

Enterprise AI deployments need audit trails for compliance, security, and operational monitoring. But logging the content of AI queries and responses creates its own privacy risk -- you are now storing potentially sensitive data in log files.

The solution: metadata logging.

Log everything about the inference except the content:

{
  "timestamp": "2026-03-15T14:32:01Z",
  "request_id": "req_a7f3b2c1",
  "user_id": "user_12345",
  "department": "legal",
  "model": "gemma-4-27b-it-awq",
  "deployment": "on-prem-cluster-1",
  "routing_decision": "edge",
  "input_tokens": 847,
  "output_tokens": 312,
  "latency_ms": 2340,
  "pii_detected": true,
  "pii_types": ["PERSON", "EMAIL", "ADDRESS"],
  "pii_action": "redacted_for_cloud_escalation",
  "data_classification": "CONFIDENTIAL",
  "compliance_flags": ["HIPAA_PHI"],
  "session_id": "sess_x9k2m",
  "client_type": "browser",
  "gpu_utilisation": 0.73,
  "error": null
}

This log entry tells you: who used AI, when, which model, how many tokens, whether PII was detected, what classification the data had, and how the query was routed. It does not contain any of the actual query text or response text.

When you must log content:

Some compliance frameworks (FDA 21 CFR Part 11, certain financial regulations) require that the actual inputs and outputs of AI systems be logged for audit purposes. In this case:

1. Log content to an encrypted, access-controlled audit store -- separate from operational logs
2. Apply the same retention and access policies as the underlying data classification
3. Ensure the audit store itself is within your compliance boundary (on-premises for ITAR, EU-resident for GDPR)
4. Implement tamper-evident logging (append-only, cryptographic hash chains) to satisfy integrity requirements

Which architecture satisfies which regulation

This is the practical reference table. For each major regulation, which of the four privacy architecture patterns satisfies its requirements.

Key takeaways:

• ITAR and FedRAMP High effectively require Pattern 1 or Pattern 2. Cloud options are extremely limited.
• GDPR is satisfiable with any pattern if implemented correctly, but Pattern 4 adds complexity around cross-border transfers and right to erasure.
• HIPAA requires Pattern 2 or higher for PHI. Pattern 4 works only if the PII gateway guarantees PHI never reaches the cloud -- which is hard to guarantee with imperfect PII detection.
• SOC 2 is the most flexible -- it cares about controls being in place and operating effectively, not about where the data physically resides.