Enterprise engineering teams are under pressure to put AI into every workflow that touches data. Privacy and security teams are under equal pressure to keep production context from leaving the network. Those two mandates collide hardest in one quiet but consequential place: PII classification — deciding which columns, free-text fields, and nested JSON keys are sensitive before anyone masks, subsets, or copies them into lower environments.
The usual debate frames this as "AI versus no AI." That framing is wrong. The durable question is narrower and more architectural:
Where should the model sit?
If inference runs in a vendor cloud, classification can get faster — and you invent a new egress path for the exact context you were trying to protect. If inference never runs at all, teams fall back to brittle rules and tribal knowledge that rot the moment the schema changes. The middle path is becoming the serious one: assistive AI that stays inside the trust boundary, with humans still owning ambiguous and high-risk decisions.
This article explains why classic classification broke down under modern data architectures, why cloud LLM assist is a false comfort for regulated environments, and what a durable in-network pattern looks like in practice.
Why Classification Quietly Broke Down
For years, "find the PII" meant scanning column names and running a short list of regex patterns: email, ssn, phone, national_id. That worked when schemas were small, naming was honest, and sensitive values lived neatly in typed columns.
Modern database architectures do not cooperate.
1. Column Names Lie and Evolve
A field called user_ref can hold an email address. meta can store a national ID. payload can contain a payment token or OAuth secret. Heuristics tuned to yesterday's schema naming conventions miss tomorrow's developer abbreviations or microservice migrations.
2. PII Hides in Free-Text Prose
Support notes, chat transcripts, delivery instructions, and error logs routinely contain names, phone numbers, and addresses embedded in free text. A regex configured to match +1-555-0100 will fail on string fragments like "Call Jane on her mobile after 6 PM".
3. Nested JSON Multiplies the Surface Area
Consider a standard JSONB audit column in PostgreSQL or a document collection in MongoDB:
{
"event": "checkout_completed",
"actor": {
"id": "usr_948102",
"contact": { "primary_email": "jane@example.com" }
},
"metadata": { "billing_country": "US", "tax_id": "12-3456789" }
}
Masking the entire JSONB column as a binary blob destroys data utility for local development. Ignoring the nested structure leaves residual identifiers in every lower environment that receives a copy.
4. Schema Drift Invalidates Static Audits
Microservices introduce schema migrations continuously. A static classification spreadsheet or quarterly security review is obsolete by the time the ticket is closed. Teams that rely on shared staging and infrequent refreshes discover the same failure mode: the map of sensitive data is always behind production reality.
The False Choice: Slow, Leaky, or Brittle
When teams feel that pressure, they tend to pick one of three default engineering tradeoffs.
| Pattern | Throughput & Latency | Network Egress Vector | Drift & Context Adaptability |
|---|---|---|---|
| Manual Review & Spreadsheets | ❌ Low (Backlog build) | ✅ Zero Egress | ❌ Low (Lagging indicator) |
| Cloud LLM API Inference | ⚠️ API Latency & Cost | ❌ High Egress Vector | ✅ High Context Awareness |
| Static Regex & Dictionaries | ✅ High Speed (Sub-ms) | ✅ Zero Egress | ❌ Brittle Under Drift |
| In-Network Tiered Local AI | ✅ High (Sub-sec SLA) | ✅ Zero Egress | ✅ High Context & Adaptive |
1. Manual Review Everywhere
Security operators inspect sample rows, approve labels, and update rules manually. This works for small schemas, but it fails to scale across hundreds of microservices. The review backlog becomes the primary security risk: unclassified columns ship into test environments as "unknown," which in practice means unmasked.
2. Sending Context to a Cloud LLM
Pasting schema fragments, sample rows, or free-text excerpts into a hosted model API improves classification accuracy. However, it creates a new processing location and network egress vector for sensitive context — complete with vendor terms, data residency questions, and prompt-logging risks.
[!WARNING] The Egress Paradox: Shipping unclassified raw data across the public internet to an external inference API to determine whether that data is sensitive creates a circular compliance risk under SOC 2, GDPR, and HIPAA.
3. Doubling Down on Regex and Dictionaries
Pattern libraries remain valuable for high-precision formats (e.g., Credit Card numbers or SSNs). However, they are insufficient for free-text prose, multilingual fields, and nested document payloads. Teams relying solely on regex report high compliance coverage in dashboards while leaking sensitive attributes in practice.
The In-Network Architecture: Tiered Intelligence Inside the Trust Boundary
A durable architecture separates classification into execution tiers based on cost, latency, and context depth:
┌─────────────────────────────────────────┐
│ Database / Schema Drift │
└────────────────────┬────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ Tier 1: Fast Heuristics & Pattern Match │ (80% of routine fields)
└────────────────────┬────────────────────┘
│ (Ambiguous fields / Free-text)
▼
┌─────────────────────────────────────────┐
│ Tier 2: In-Network Local AI (SLM) │ (Customer VPC / Local Ollama)
└────────────────────┬────────────────────┘
│ (Low confidence edge-cases)
▼
┌─────────────────────────────────────────┐
│ Tier 3: Human Operator Governance Loop │ (Policy approval)
└────────────────────┬────────────────────┘
│
▼
┌─────────────────────────────────────────┐
│ Downstream Action: Mask / Subset / Dev │
└─────────────────────────────────────────┘
Key Architectural Principles
- Keep Raw Context In-Network: Inference models run close to the data source — inside the customer VPC or private network — eliminating outbound API calls containing customer data.
- Tiered Execution: Micro-heuristics handle 80% of routine typed columns instantly at zero token cost. Small Local Language Models (SLMs, such as Llama-3 8B or Phi-3 running via Ollama/vLLM) evaluate ambiguous column names and free-text excerpts inside the boundary.
- Assistive AI with Governance: The model proposes classifications and confidence scores. Human security operators review edge-cases rather than manually auditing every boolean column.
- Closed-Loop Downstream Delivery: Classification outputs directly feed downstream data masking, referential subsetting, and environment generation.
- Auditable Decision Lineage: Every label records which rule or local model executed, the confidence score, and operator approval history.
Practical Implementation with Ark
Ark (Subsetra Ark) implements this architectural pattern using an outbound-only VPC agent.
The control plane orchestrates jobs and security policies, while the agent executes classification, masking, and subsetting directly inside the customer data boundary. The agent does not require inbound firewall ports; it establishes outbound TLS connections to pull job definitions and report status.
┌───────────────────────────┐ ┌───────────────────────────────────────────┐
│ Ark Control Plane │ ◄─── Outbound ───│ Customer VPC Agent │
│ (Policy & Governance) │ TLS Only │ ┌──────────────┐ ┌───────────────┐ │
└───────────────────────────┘ │ │ Local Engine │ ────►│ Local SLM │ │
│ │ (Mask/Subset)│ │ (Inference) │ │
│ └──────┬───────┘ └───────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ │
│ │ Source DB │ │
│ └──────────────┘ │
└───────────────────────────────────────────┘
For contextual classification, Ark leverages local model inference (e.g., via Ollama or local ONNX runtimes). The pipeline operates in a closed loop:
$$\text{Classify (Local AI)} \longrightarrow \text{Review (Governance)} \longrightarrow \text{Mask (Policy)} \longrightarrow \text{Subset & Deliver (Dev/CI DB)}$$
Approved classifications immediately feed downstream masking policies and environment creation — including referentially intact database subsets and ephemeral, production-like databases for CI/CD pipelines and local development.
Without automated in-network classification upstream, teams default to full production replicas. Understanding why full replicas remain the wrong default begins with classification: safe subsets are impossible if sensitive fields remain unmapped.
Operational Benchmarks for In-Network Classification
Engineering teams evaluating in-network classification systems should measure five key metrics:
- Zero Outbound Data Egress: 100% of raw data samples, column values, and free-text excerpts remain within the internal network perimeter.
- Schema Drift Detection SLA: Automatic identification and classification of new columns and document keys within seconds of schema migration runs.
- Review Backlog Reduction: Operator review effort limited to low-confidence ambiguity, reducing manual classification workloads by over 90%.
- End-to-End Pipeline Latency: Classification to masked environment delivery completing within minutes, meeting automated CI/CD pipeline requirements.
- Masking Fidelity & Residual Check: Automated scanning of masked output data to verify zero residual PII leakage before delivery to lower environments.
Summary
Treating privacy controls as an obstacle to developer velocity is an outdated assumption. Cloud LLM APIs offered speed at the expense of network perimeter security.
Local, in-network AI assist eliminates this compromise. By running inference adjacent to raw data, organizations achieve continuous classification under schema drift while maintaining strict zero-egress security boundaries.
To explore how Ark executes in-network classification and test data orchestration inside your infrastructure:
Get started · Docs · Blog