Locara

26 — Compliance

How Locara — and apps built on Locara — handle data-protection regulations and regulated industries. The framework’s local-first architecture simplifies compliance dramatically, but does not eliminate it.

This is guidance + framework-level commitments, not legal advice. App developers building for regulated industries are responsible for their own compliance.

The local-first compliance dividend

Most data-protection regulations apply to data controllers and processors. They regulate what organizations do with personal data: how they collect it, store it, share it, retain it.

Locara apps that are “fully local” don’t collect, store, share, or retain user data at the Locara level — the data lives on the user’s device, processed by code running on the user’s device, in the user’s own SQLite file. Locara is not in the data flow.

This means:

  • Locara (the org) is not a data processor for app data. Apps process their users’ data on the user’s hardware. Locara doesn’t see it.
  • Most user-facing compliance burden falls on the app developer, not Locara.
  • Apps that use net: false (the “fully local” badge) have a much simpler regulatory story than equivalent SaaS apps.
  • Apps that use net: true (allowed but flagged) are subject to the same compliance burden as equivalent SaaS apps, scoped to whatever they send over the wire.

Regulations covered here

We give explicit guidance for:

  • GDPR (EU General Data Protection Regulation) — applies broadly to EU users.
  • CCPA / CPRA (California Consumer Privacy Act) — applies to California users.
  • HIPAA (US Health Insurance Portability and Accountability Act) — applies to healthcare data.
  • COPPA (Children’s Online Privacy Protection Act) — applies to apps targeting children under 13.
  • AI-specific regulation — emerging EU AI Act and similar.

What Locara (the project) is responsible for

The Locara registry, website, and operations have a small but real footprint:

Data collected by Locara (the registry / website)

  • Publisher accounts. GitHub OAuth identity, email, optional DNS-verified domain.
  • Publisher activity. Submission events, version uploads.
  • App ratings and reviews. Optionally tied to Locara-client-authenticated users (TBD).
  • Aggregate install counts. Computed from anonymized update-check pings; no per-user tracking.
  • Public manifest content. Apps’ declared metadata, capabilities, models — public.
  • Server logs. Cloudflare access logs (IPs, user agents) retained per Cloudflare’s policy; minimized.

Data Locara does NOT collect

  • App content (transcripts, documents, prompts, embeddings, generations).
  • User identifiers tied to install activity.
  • Cross-app correlation.
  • Browsing patterns within the catalog (no analytics).
  • Telemetry from the runtime / client / CLI.

Locara’s commitments under GDPR

  • Lawful basis: legitimate interest for publisher data (running the registry); consent for any user-visible features that touch identity (e.g., reviews).
  • Transparency: publisher data, what it’s used for, retention, are documented in the privacy policy.
  • Access / portability: publishers can export their account data anytime via API.
  • Erasure: publishers can delete their accounts; published apps can be unpublished. Public artifacts may remain in transparency logs (Sigstore) but are clearly marked as superseded.
  • Data residency: registry runs on Cloudflare R2 (multi-region) + Neon Postgres (selectable region; default US). EU residents can request EU-region accounts where possible.
  • Breach notification: within 72 hours per GDPR.
  • DPO: for the project lead’s contact info; updated as the team grows.

CCPA / CPRA

Same principles. California-specific commitments:

  • “Do Not Sell” — N/A; we don’t sell data.
  • Right to know — disclosed in privacy policy.
  • Right to delete — deletion mechanism for publisher accounts.

What app developers are responsible for

Apps that handle personal data — even fully-local apps — have responsibilities to their users:

Disclosing what the app does with data

Even a fully-local app that processes a user’s voice should tell the user:

  • “This app records audio; transcripts are stored on your Mac; nothing is uploaded.”
  • “If you export a transcript, you control where it goes.”
  • “Deleting the app removes all transcripts.”

Locara’s app-page format provides structured fields for this; developers must fill them honestly.

Deletion / portability

Apps should provide:

  • Export. User can extract their data in a portable format (JSON, markdown, CSV, etc.).
  • Deletion. User can delete app data from within the app, or by removing the app + its container directory from ~/Library/Containers/<bundle-id>/.

Locara provides infrastructure for both via the SDK (db.export.{json|csv|markdown}) and via the client’s uninstall flow.

App-specific compliance

  • Apps that collect health information (even locally) must consider HIPAA if used by US healthcare providers.
  • Apps targeting EU users must comply with GDPR.
  • Apps handling children’s data must comply with COPPA.
  • Etc.

Locara doesn’t enforce these — the framework gives developers the tools to be compliant; the choice and responsibility are theirs.

HIPAA-adjacent apps

Apps that store or process Protected Health Information (PHI) in a US healthcare context:

  • Fully-local processing dramatically reduces HIPAA exposure for the app developer + their users (covered entities and business associates).
  • A fully-local app where data never leaves the user’s device may not even be in HIPAA scope (HIPAA covers transmission and storage by covered entities; if the user is the data subject and the developer never sees the data, the analysis differs).
  • Apps that DO transmit data (net: true) are subject to HIPAA in the standard way; the developer needs a Business Associate Agreement with whatever cloud they use.

Locara does not sign BAAs as a covered entity or business associate. Locara is software; HIPAA covers usage, not authorship.

Apps targeting healthcare professionals should:

  • Use the “Healthcare” category tag.
  • Include the “not medical advice” disclaimer (per 22-content-policy.md).
  • Document their PHI handling in the app’s README.
  • Likely require net: false to claim HIPAA-friendly status; allow user-controlled export for clinical documentation workflows.

COPPA — apps for children

Apps targeting users under 13:

  • Must declare in manifest: target_age: "under_13" or similar.
  • Trigger stricter capability defaults (no net, no device.camera unless essential, no analytics-style storage).
  • Cannot collect contact info from kids.
  • Cannot use third-party SDKs (we don’t have any anyway, but reaffirm).
  • Must include a clear, accessible kid-friendly privacy disclosure.

Locara’s review pipeline has additional checks for COPPA-tagged apps.

EU AI Act and emerging AI regulation

The EU AI Act (in force 2026) categorizes AI systems by risk and imposes obligations on high-risk and general-purpose AI systems. Locara’s relevant points:

  • Locara as a framework is not itself a “high-risk AI system.”
  • Apps built on Locara may be — depending on what they do (e.g., apps for hiring, credit scoring, education, law enforcement). The app developer is the provider under the Act.
  • Locara provides infrastructure that helps with transparency requirements: capability badges, model cards, provenance attestations are all aligned with the Act’s spirit.
  • Apps using foundation models (which all Locara apps using LLMs do) inherit the foundation model provider’s GPAI obligations downstream.

We track the regulatory landscape and update guidance as it evolves. Apps in regulated categories (hiring, lending, healthcare, law enforcement) should consult their own legal counsel.

App developer compliance checklist

For apps published to the Locara registry, developers should self-check:

  • Does my app handle personal data? If yes, is it disclosed in the app’s manifest + README?
  • Does my app process special-category data (health, biometrics, kids)? If yes, am I in compliance with the relevant law?
  • Is my app’s data export honest (everything user-generated is exportable)?
  • Is my app’s data deletion complete (uninstall removes everything)?
  • If I use net: true, am I documenting what’s transmitted and to whom?
  • If I’m in a regulated industry, do I have a BAA / DPA / etc. where required?
  • Have I included the appropriate disclaimers?

The Locara CLI’s locara verify will eventually include a “compliance checklist reminder” that prompts publishers in regulated categories.

Localization & accessibility as compliance-adjacent

  • EU Accessibility Act (EAA). Effective 2025; requires accessible digital products for EU users. Locara’s accessibility commitments (see 20-accessibility.md) align with this.
  • Localization. Not legally required for compliance, but practically required for many EU markets. v1 is English-only; localization deferred.

What happens if Locara becomes the data processor

For paid services (e.g., enterprise registry hosting, verified-privacy certification), Locara may become a data processor in a more traditional sense. When/if those launch:

  • We’ll execute appropriate data-processing agreements (DPAs) with customers.
  • We’ll comply with the standard GDPR data processor obligations.
  • Pricing will reflect the operational cost of compliance.

This is a phase 4+ concern; not relevant for the OSS-first launch.

Right to repair / right to fork

Locara’s OSS posture (Apache-2.0) means:

  • If Locara the org disappears, the framework continues.
  • If Locara takes a direction users disagree with, they can fork.
  • The data formats are open; apps can be migrated by users to a fork’s runtime if needed.

This is a compliance benefit that closed-source SaaS competitors can’t offer.

Open questions

  • (open) Should we publish a “Locara compliance brief” template that publishers can adapt for their own apps? Probably yes; useful for sales conversations.
  • (open) When does it make sense to pursue formal certifications (SOC 2, ISO 27001) for the Locara registry? Phase 4+ if enterprise adoption justifies.
  • (open) Should we offer DPA-as-a-service for publishers (a template they can use with their customers)? Maybe; depends on demand.
  • (open) EU AI Act compliance is evolving; we’ll need to revisit this doc.

Cross-references