Privacy Architecture for Immigration Intake: Why Shared Tenants Are a Liability

Immigration intake data includes alienage, family relationships, employment history, country of origin, arrival dates, and — often — criminal and enforcement history. For a subset of clients, that data combined in the wrong hands is existentially dangerous.

Most SaaS intake tools treat this data the way they'd treat any other CRM record: stored in a shared multi-tenant database, logically separated, encrypted at rest with a platform-wide key. That's fine for dentist offices. It is not fine for an immigration firm whose clients include mixed-status families and asylum seekers.

Why 'logical separation' isn't enough

Shared multi-tenant architecture means every firm's data sits in the same database, separated by a tenant ID on every row. A bug in an access control check, a misconfigured query, a compromised service account — any of these can expose data across tenants. It has happened publicly to major SaaS platforms in the past three years, multiple times.

For most industries, the risk math is: this is unlikely, and the blast radius is some embarrassment and a notification letter. For an immigration firm, the blast radius can include a client's physical safety.

What dedicated infrastructure looks like

Per-firm private VPS. Isolated database schemas with firm-specific encryption keys. TLS everywhere. AES-256 at rest. Audit logs that never cross tenant boundaries. No admin account that can query across firms. When Firm A's environment is compromised, Firm B's environment is not on the same physical host, not using the same credentials, not reachable via a privilege escalation.

This costs more to operate. It is worth it. The firms we work with ask this question first, before pricing.

The AI-specific risks

Any AI intake layer has to answer two additional questions that traditional intake tools don't. First: does the model train on client data? (The correct answer is no, with contractual guarantees to back it up.) Second: what are the model's hard boundaries — specifically, will it give legal advice, or will it recognize compliance-adjacent signals and escalate to a human?

A model that will improvise an answer to 'do I qualify for asylum?' is a liability. A model that recognizes the question, flags it, and routes it to a licensed attorney is an asset. The difference lives in system prompts, tool-use constraints, and supervised evaluation — not in model choice.