Desert Ant Labs' Redact Doesn't Just Detect PII On-Device — It Deletes the GDPR Transfer Question

On 2026-09-08, a small outfit called Desert Ant Labs launched on Hacker News with 18 free on-device AI models — audio, vision, and text, shipped as a single SDK for Swift, Kotlin, and JavaScript, running fully offline via Core ML, LiteRT, and WebAssembly. The launch thread has pulled nearly 500 points and over 100 comments, which is a big reception for a company most of this audience had never heard of a week ago.

The model worth stopping on if you build in the EU is Redact: on-device PII detection and redaction across 27 languages — every official EU language plus Norwegian and Icelandic — with a deterministic validation layer sitting on top of the neural detector. Luhn checks for card numbers, ISO 13616 validation for IBANs, checksummed national ID formats for all 24 EU countries, all 27 EU VAT number formats, IMEI checks, and per-country driving-license validation. The point of the deterministic layer is precision: a random 16-digit string doesn't get flagged as a card number just because it has the right shape.

Desert Ant Labs' own marketing calls this "sovereignty-by-architecture" — "Desert Ant is building this in Europe, where on-device is the sovereign default," per their site. That's a good line, but it skips past the actual legal mechanism, and the mechanism is more interesting — and more useful to you — than the slogan.

Why this isn't an Article 9 story

If you've been following our AWS Comprehend or AWS Macie coverage, your instinct might be to file "PII detection" under GDPR Article 9 — special categories of personal data: racial or ethnic origin, health data, biometric data, and so on. That instinct is wrong here, and it's worth being precise about why.

Redact's default categories — names, addresses, emails, phone numbers, card numbers, IBANs, passport and driving-license numbers, tax IDs and national IDs — are ordinary personal data under Article 4(1), not special-category data under Article 9. That's a real distinction: AWS Comprehend Medical, which we covered separately, processes clinical text and genuinely does touch Article 9 health data. Redact's shipped configuration doesn't. If you point it at free text that happens to contain health or religious information, Article 9's stricter lawful-basis requirements (Article 9(2)) still apply regardless of where the processing happens — on-device architecture doesn't change what triggers Article 9, only where the trigger occurs.

The actual story is a different, arguably bigger one: Article 44 — the general principle governing international transfers of personal data.

What "on-device" actually removes

Every cloud-based PII detection service — AWS Comprehend, AWS Macie, Google Cloud DLP, Azure AI Language's PII detection — has to answer the same question once you're a controller processing EU personal data: where does the data go, and does that constitute a "transfer" under GDPR Chapter V? Even with an EU region selected, the parent company (Amazon, Google, Microsoft) remains a US legal entity subject to the CLOUD Act, which means you're typically still building a paper trail of Standard Contractual Clauses and a post-Schrems II Transfer Impact Assessment to justify the arrangement. We walked through six specific exposure points for exactly this reason in the Comprehend and Macie posts linked above.

Redact sidesteps that analysis entirely, and it does so structurally rather than contractually. If the text never leaves the device — no API call, no server round-trip, no logging endpoint — there's no controller-to-processor relationship for the redaction step at all, and therefore nothing that meets GDPR's definition of a transfer. You're not relying on a vendor's promise to keep data in an EU region, or on SCCs surviving the next adequacy challenge. There's simply no wire for the data to travel on. That's a stronger compliance posture than any "EU region" flag a cloud vendor can offer, because it removes the question rather than answering it favorably.

This is also the correct way to read Article 25 — data protection by design and by default — and Article 5(1)(c), the data minimization principle. Redact is a concrete instance of both: instead of collecting the raw payload and then relying on downstream controls (encryption, access policies, retention schedules) to protect it, the identifiable data is stripped before it's ever transmitted or persisted. Minimization by construction, not by policy.

What on-device processing does not remove

None of this makes the rest of your pipeline exempt. A few things stay squarely your responsibility:

• What happens to the pre-redaction payload. If your app logs the raw input anywhere — crash reporting, debug logs, an analytics SDK sitting upstream of the redaction call — you've recreated the exact transfer problem Redact was supposed to eliminate. On-device redaction only helps the data path that actually runs through it.
• Article 32 security of processing still applies to whatever data does get transmitted after redaction, plus the device itself. A stolen or compromised device with cached, unredacted text is a security incident regardless of where the redaction model runs.
• Accuracy is not compliance. The deterministic checksum layer gives you very low false-positive rates on structured data — a valid IBAN checksum is a valid IBAN checksum — but free-text detection of names and addresses across 27 languages, several scripts (Latin, Greek, Cyrillic), will have a real false-negative rate. Benchmark it against your own data before treating "PII redacted" as a fact rather than a probability. High-risk pipelines (health intake forms, legal document processing) still warrant human review downstream, not blind trust in the redaction layer.
• A DPIA under Article 35 may still be required for the encompassing processing operation, independent of where the PII detection step sits. On-device processing changes the risk profile a DPIA describes; it doesn't exempt you from writing one if your overall processing is otherwise high-risk (large scale, systematic monitoring, etc.).

The license is not what "free on-device model" usually implies

Before you design a product around Redact, read the actual terms — Desert Ant Labs Source-Available License v1.0, not MIT, Apache, or AGPL. It is not OSI-approved open source; GitHub itself flags the desert-ant-core repository as carrying a non-standard license. The concrete terms:

• Free below 100,000 monthly active devices per platform, per model. iOS and Android are counted separately, and the threshold applies independently to each model — so a multi-platform app tracking Redact usage needs to watch each platform's count on its own.
• Embedding in commercial products is explicitly allowed under the free tier — you can ship Redact inside a paid app without a commercial license, as long as you're under the device threshold.
• You cannot redistribute the model or SDK itself — selling, sublicensing, or distributing it as a standalone product, model, SDK, or hosted service is off-limits, including a "substantially unmodified derivative."
• You cannot use its outputs to train a competing on-device model — the license specifically prohibits using "the Models, their Outputs, or anything you log from them" to build competing systems, and separately bars reverse engineering, model extraction, and weight recovery.
• Free use requires attribution — a "Powered by Desert Ant Labs" credit linking back to desertant.com.
• Cross the 100K-monthly-active-devices line on any platform/model combination, and you need a commercial license from licensing@desertant.com.

None of this makes Redact a bad choice — the terms are generous for most apps below the threshold, and "source-available with a usage ceiling" is a completely normal shape for a company monetizing infrastructure. But it's a different due-diligence exercise than evaluating an AGPL or Apache-2.0 project, and it's worth doing before, not after, a launch that suddenly clears 100K monthly devices on one platform.

Where this actually fits

If you're building anything that pipes user input — support tickets, form submissions, chat messages — toward a cloud LLM API or an analytics backend, on-device redaction is the cleanest way to make sure PII never enters that pipeline in the first place, rather than trying to filter it out at the cloud edge after the fact. That's a materially different design than routing everything to a US-headquartered classification service and hoping the EU-region flag and an SCC hold up under the next transfer-mechanism challenge. It doesn't replace the need for an EU-hosted backend for whatever does get transmitted — it just shrinks what that backend, and its own Chapter V exposure, ever has to deal with.