How to Map Data Flows in a Local-First AI Assistant

TL;DR: Learn how to map data flows in a local-first AI assistant to meet GDPR Article 30 and EU AI Act requirements with a 10-boundary framework.

If you are a CTO, platform engineering lead, or AI transformation lead at a European scale-up adopting a local-first AI assistant, here is the verdict: your data-flow map is the only artefact that both GDPR Article 30 (S2) and the EU AI Act Article 16 (S1) will accept as auditable evidence. Why this matters: by 2 August 2026, the first EU AI Act regulatory sandbox milestone (S1), all AI systems in scope must demonstrate mapped data flows. For privacy leads, security leads, and operations leaders, the map reveals egress points that marketing materials hide. This article covers 10 boundary classes, a 30-day workflow, and the compliance mapping your team needs. Procurement-aware engineering managers and finance teams will also find the risk table essential for vendor evaluation. Founder-led companies with growing software teams should pay attention: the map is your cheapest insurance against regulatory delay.

The short version

• A local-first AI assistant has more egress points than advertised; a data-flow map is the only audit trail regulators accept.
• The minimum map covers 10 boundary classes: user prompt, local files, connectors, model call path, local vs remote inference, vector store, logs, plugins, secrets, human approval.
• For European scale-ups, the map directly feeds GDPR Article 30 (S2) records of processing and EU AI Act Article 16 (S1) technical documentation.
• On-device processing is controller responsibility per EDPB (S3) and CNIL (S4); the vendor is not exempt.
• Common failures include prompt injection (S8), sensitive info disclosure (S9), and connector overscope (S13, S14).

Why this matters for European scale-ups

European scale-ups operate under a stricter privacy regime than US or Asian competitors. GDPR Article 30 (S2) requires every controller to maintain a record of processing activities, and the EU AI Act (S1) extends this to technical documentation for high-risk AI systems. A local-first AI assistant does not exempt you: the European Data Protection Board (S3) and CNIL (S4) have made clear that on-device processing remains a controller-side responsibility. The ENISA AI threat landscape (S5) identifies on-device AI as a vector for novel attacks, while the NIST AI RMF (S6) provides a structured way to surface trade-offs. For privacy leads and operations leaders, failing to map flows means exposing the company to fines and audit failures. For security leads, the map is the starting point for threat modelling.

The audit-facing version of this argument is sharper. EU AI Act Article 16 obligations and DORA-style third-party risk processes are not satisfied by a vendor questionnaire response that says "our assistant runs locally so most data stays on the device". They are satisfied by repeatable evidence: a versioned data-flow map, a categorisation per boundary class, a per-boundary retention window, and a tested reversibility runbook. For a 30-person engineering scale-up, the difference between a half-day audit response and a two-week audit response is whether the 10 boundary classes below were structured up front. Finance teams who sign off the compliance budget should treat the map as the cheapest single compliance investment available: the same artefact serves GDPR Article 30 (S2) records of processing, EU AI Act Article 16 (S1) technical documentation, the procurement-aware engineering manager's third-party register, and the security lead's incident-response runbook.

What "data flow" actually means for a local-first AI assistant

A data-flow map for a local-first AI assistant is not the same as a network diagram. It traces every path that personally identifiable information (PII), proprietary code, or credentials can travel from the moment a user types a prompt to the moment the model returns an output. This includes local processes (IPC, socket calls), file system reads, extensions to browser or email APIs, and any remote inference fallback. The map must distinguish between encrypted tunnels and clear-text paths, between ephemeral state and persistent storage. The key difference from a cloud-only assistant is that many flows terminate on your device but leak through logging, telemetry, or connectors to external services like MCP servers (S13, S14).

OWASP LLM Top 10 v2.0 (S7) frames the broader threat-model context for this kind of map. Three risks dominate at the local boundary: LLM01 prompt injection (S8) targets the user-prompt boundary and the file-read boundary; LLM02 sensitive information disclosure (S9) targets the telemetry, log, and vector-store boundaries; LLM08 excessive agency targets the connector and human-approval boundaries. Engineering leaders sometimes treat the data-flow map as a privacy artefact only; it is also the cheapest threat-model artefact available, because every boundary you record is also a place where one of those three risk classes can land. Pair the map with OpenSSF Scorecard (S10) signals for the assistant's binary, SLSA build provenance (S11) for the model and runtime, and the CISA SBOM minimum elements (S12) for the assistant's supply chain, and you have one consolidated evidence package that satisfies the privacy lead, the security lead, and the procurement-aware engineering manager simultaneously.

The minimum data-flow map (10 boundary classes)

1. User prompt: The input string entered by the user. Capture length, encoding, and whether it includes file attachments or system context. Flag plaintext transmission to local processes.
2. Local files (project, repo, working directory): The assistant often accesses files to provide context. Map which directories are read, which symlinks are followed, and whether write-back occurs.
3. Clipboard, browser, email, calendar, ticketing connectors: Every integration that pushes or pulls data across application boundaries. Each connector is a potential egress point for PII or confidential data.
4. Model call path (HTTP, IPC, websocket, local socket): The exact mechanism by which the prompt reaches the model. For local models, this is typically IPC; for remote fallback, it is HTTPS. Both must be recorded with endpoint addresses and TLS versions.
5. Local model vs remote model selection: How the system decides to use a local model or a cloud API. The decision logic may itself leak data through timing or error messages.
6. Vector store / memory: Persistent or session-based storage of embeddings, chat history, or retrieved documents. Map where vectors are stored, whether they are encrypted, and how they are evicted.
7. Logs and telemetry: Every log line and telemetry event that includes prompt content, model output, or metadata. This is the most common source of accidental PII disclosure (S9).
8. Plugins, MCP servers, or connectors: Third-party extensions that extend assistant capabilities. Each MCP server (S13, S14) introduces a separate data flow that must be audited for scope and data handling.
9. Secrets and credentials: API keys, OAuth tokens, and other secrets stored for the assistant to use. Map where they are stored, how they are transmitted, and whether they are logged.
10. Human approval boundary: Points where a human must approve an action (e.g., sending an email, executing code). The map should show which actions bypass human review and under what conditions.

A practical 30-day mapping workflow

Phase 1: Days 1 to 7 - Egress capture and inventory

Owner: Platform engineering lead. Artefact: Raw flow inventory (a list of all observed egress events). Success criterion: At least 90% of unique destinations recorded by instrumenting network calls, file access, and IPC.

Phase 2: Days 8 to 21 - Categorisation and policy draft

Owner: AI transformation lead with privacy lead and security lead. Artefact: Categorised flow map with risk labels (high, medium, low) and draft data-handling policies. Success criterion: Every flow class is annotated with its data sensitivity and applicable regulation (GDPR Article 30, EU AI Act).

Phase 3: Days 22 to 30 - Audit-trail wiring and reversibility drill

Owner: CTO with operations leader and procurement-aware engineering manager. Artefact: Automated audit trail and a signed reversal procedure for each high-risk flow. Success criterion: A full reversal drill is executed for at least two high-risk flows without data loss or service interruption. Finance team reviews cost implications.

What you can automate safely

• Egress capture: Use network proxies or seccomp profiles to log all outbound connections from the assistant process.
• Flow inventory: Automatically generate a first-pass list of unique hosts, file paths, and IPC channels.
• Change detection: Alert when a new egress destination appears or a known flow changes its TLS version.
• Policy enforcement: Block flows that match a deny list (e.g., unknown MCP servers) or that exceed a data size threshold.
• Regression testing: Re-run the capture on CI to ensure new features do not introduce unmapped flows.

What must remain human-reviewed

Anti-patterns that require manual oversight:

1. Do not rely solely on automated egress capture; it may miss short-lived or low-frequency flows that only appear under specific conditions.
2. Do not treat a single scan as final; data flows change with every update to the assistant or its connectors.
3. Do not ignore flows that originate from local system processes (e.g., a telemetry daemon embedded by the vendor).
4. Do not assume that local model inference is safe from data leakage; side-channel attacks and model exfiltration via model weights are real.
5. Do not let a green data-flow map become a substitute for a documented purpose-limitation per data class, a tested reversibility drill, or a published incident response runbook.
6. Do not skip the human approval boundary review; every flow that bypasses human consent is a potential risk.

A risk table for European scale-ups

How the data-flow map maps to GDPR Article 30 and the EU AI Act

(a) GDPR Article 30 (S2): The data-flow map directly serves as the technical basis for your records of processing activities (ROPA). Each boundary class corresponds to a processing purpose: user prompt (request processing), local files (context enrichment), connectors (data sharing), logs (compliance monitoring). For each flow, document the categories of data subjects, the nature of data, the retention period, and the technical safeguards. The map proves that you have identified all processing operations, which is the core requirement of Article 30.

(b) EU AI Act Article 16 (S1): For high-risk AI systems, the technical documentation must include a detailed description of the system's data flows, including the sources of training data, the methods for ensuring data quality, and the mechanisms for human oversight. Your data-flow map provides this description. It shows where data enters and exits the system, how it is transformed, and where human approval is required. As of 2 August 2026, sandbox participants (S1) must have this map in place.

For both regulations, the map is not a one-time artefact. It must be kept current and version-controlled. We recommend tying flow changes to your CI/CD pipeline.

A concrete walk-through for a 30-person engineering scale-up. The platform engineering lead exports the boundary table as JSON: 10 rows, each with the boundary class, the data category, the retention window, the encryption-in-transit setting, and the most recent egress-capture timestamp. The privacy lead pairs each row with the GDPR Article 30 (S2) processing-activity entry it backs. The security lead pairs each row with the OWASP risk class (S7, S8, S9) it most plausibly fails under. The procurement-aware engineering manager attaches the SBOM (S12) for the assistant binary and the OpenSSF Scorecard (S10) snapshot for the assistant's source repository. The CTO signs off the consolidated package. Total elapsed engineering time for the first article-30-style readback: roughly half a day on the first boundary cohort, then under two hours per quarterly refresh thereafter. The same artefact answers an EU AI Act conformity assessor, a CNIL (S4) inspector, and an internal DORA-style third-party-risk review with zero rework.

To assess your current compliance posture, start with our AI Readiness Assessment. For strategic guidance, explore our AI Consulting services.

Limits and failure modes

A data-flow map is only as good as its coverage. Common failure modes include: missing flows that only occur during error recovery or degraded-mode operation; assuming that all flows are captured by a single monitoring tool (network proxy will miss local socket connections); treating the map as a static document instead of a living model; failing to include third-party dependencies (OS libraries, kernel modules). Also, the map may give a false sense of control if it is not paired with enforcement mechanisms (e.g., egress policies, trigger-action rules). Finally, the map itself is sensitive data: if it falls into the wrong hands, it reveals attack surface.

A second class of failure deserves explicit naming because European scale-ups hit it harder than US peers. Boundary-class drift: the assistant ships a new feature (a calendar connector, a browser extension, a remote-inference fallback) and the data-flow map remains anchored to last quarter's boundary list. The CI-side mitigation is a boundary-class diff check on every release: re-run the egress capture from Phase 1, compare to the approved baseline, and fail the deploy if a new boundary appeared without a documented owner. A platform engineering lead can ship the check inside a one-day spike using the same egress-monitoring proxy from Phase 1.

A third class is human. Engineers under shipping pressure will mark a boundary as low-risk to avoid the categorisation step. Mitigations: require a written exception with a documented retention window for any boundary that is downgraded; surface downgrade frequency as a process metric in the CTO's monthly review; track the bypass rate as part of the Publishing Control Tower equivalent platform analyst lane. If the downgrade rate exceeds 15 percent of new boundaries per quarter, the categorisation workflow itself needs revision, not the bypass policy. ENISA (S5) explicitly frames human-process gaps as the dominant failure mode in European AI deployments, which is why the metric belongs on a recurring review and not in a one-time audit.

Frequently Asked Questions

Q: What egress point do European teams miss most often?

A: Telemetry and analytics. Many local-first assistants collect usage metrics that include prompt summaries or model output snippets. These telemetry endpoints often bypass the main network proxy and are sent directly to the vendor's cloud. European teams frequently forget to include these in their data-flow map, leading to GDPR non-compliance.

Q: Should the data-flow map cover GDPR Article 30 explicitly?

A: Yes. The map should be structured so that each flow can be mapped to a specific processing activity in your ROPA. Include columns for legal basis, data category, and retention period. This makes the map directly usable by privacy leads and auditors.

Q: How often does the map need to be refreshed?

A: At a minimum, after each major release of the assistant or any of its connectors. For teams with continuous deployment, we recommend automated regression checks that flag new egress points. In a scale-up environment where features ship weekly, a manual refresh every quarter is the practical baseline.

Q: What is the smallest acceptable data-flow map for a 30-person scale-up?

A: A table with 10 rows (one per boundary class) and columns for data type, destination, storage, and access control. It should be accompanied by a one-page diagram showing the main flows. This is sufficient for early-stage compliance, but you must commit to expanding it as the assistant's capabilities grow.

Q: How does the map interact with MCP servers and connectors?

A: Each MCP server (S13, S14) is a separate data flow that must be audited individually. The map should list the MCP server's identity, its declared capabilities, the data it accesses, and the authentication method. Treat MCP servers as untrusted until you verify their claims with the MCP specification (S14).

Further Reading

• Local-First AI Stack Privacy Trade-Offs (2026)
• How to Evaluate MCP Servers for Enterprise Workflows (2026)
• Skills, Memory, and Agent Harnesses: The Next AI Layer (2026)
• Local-First AI Assistants for Enterprise Privacy (2026)
• Open-Source AI Tool Security Checklist for European Scale-Ups (2026)
• How to Run a 30-Day Pilot for an Open-Source AI Coding Agent (2026)
• Should Your Maintainer Health Rubric Change by Dependency Tier? (2026)