Most compliance problems are design problems

If you are building software in the EU, compliance rarely shows up at the beginning. It becomes relevant when the system starts to matter. You have users, possibly customers, and the architecture has grown beyond something you can fully reason about in your head. That is usually when the first real questions appear. Not abstract ones, but very concrete ones. Can a user’s data actually be deleted across the system? Where does that data end up once it leaves your application? What exactly happens when a third-party service processes it? At first, these questions look like legal or administrative concerns. In practice, they are not. They are questions about system behavior. If you cannot answer them, it is usually not because the regulation is unclear. It is because the system itself is.

Where things actually go wrong

Logging is a good place to start because almost every system relies on it. In the early stages, logging is added to make debugging easier. You log request IDs, then user IDs, then maybe email addresses because they make support cases easier to trace. Later, you include parts of request payloads because they help reproduce edge cases. Each step is useful, and none of them feels problematic. Now consider what happens when a user asks for their data to be deleted: You remove their account from your main database. That part is straightforward. But their email address still exists in logs that were written months ago. Those logs might be stored in a central logging system, replicated across regions, and retained for operational reasons. They may also have been forwarded to an external service for analysis. Even if you wanted to delete that data, you quickly run into practical constraints. Logs are often append-only. Backups are immutable. External tools maintain their own storage and retention. At that point, the issue is not whether deletion is required. The issue is that deletion was never part of the system’s design. The system was optimized for observability and reliability, not for controlled removal of data.

When your system stops being just your system

A similar pattern appears with third-party integrations. Take a common setup. You use a payment provider to handle transactions, an analytics tool to understand user behavior, and a support platform to manage customer requests. Each of these tools requires some form of user data to function. When a user signs up, their data flows through multiple paths: it is stored in your database, sent to the payment provider for billing, passed to analytics for tracking, and possibly included in support tickets if they contact you. Now imagine you are asked a simple question. What happens to this user’s data if they close their account? To answer that properly, you need to trace every path that data has taken. It is not enough to delete it from your own database. You need to know whether it exists in analytics systems, whether it is referenced in support tools, and whether it is retained by external providers. Most teams discover at this point that they do not have a clear map of these flows. Not because they ignored the problem, but because each integration was added independently, without a full picture of how data moves through the system as a whole.

Why regulation exposes this

Regulation does not introduce these problems. It forces you to confront them. Frameworks like GDPR or the AI Act require you to explain what your system does with data. What is collected, how it is used, where it is stored, and who has access to it. These are not abstract requirements. They correspond directly to real system behaviour. If your system sends user data to three different services, then your explanation needs to account for all three. If your system cannot remove data from certain components, that limitation becomes visible. This is why compliance often feels difficult. Not because the rules are inherently complex, but because the system was never designed to provide clear answers.

How systems become hard to reason about

The underlying issue is rarely a single bad decision. It is an accumulation: You keep logs longer than necessary because they might help with future debugging. You store additional user attributes because they might be useful for features later. You add tools because they solve immediate problems. Over time, data ends up in multiple places, often with different retention periods and access controls. Some of it is actively used, some of it is not, and some of it is simply forgotten. For example, a user’s email might exist in your primary database, in historical logs, in exported analytics datasets, and in archived support conversations. Each of these locations is valid on its own. Together, they make it difficult to answer a simple question like “where is this user’s data stored?” Without a clear model of how data is distributed and managed, any requirement that depends on control becomes hard to implement.

What changes if you treat it as a design problem

The alternative is not to introduce heavy compliance processes. It is to make certain decisions explicitly earlier. When designing logging, you decide what kind of data belongs there. For example, you might choose to log internal identifiers instead of directly logging personal data, and keep the mapping in a controlled location. That way, logs remain useful for debugging, but are less sensitive and easier to manage. When integrating external services, you define what data is shared and for what purpose. Instead of forwarding entire user objects to analytics, you might only send event-level data that is sufficient for analysis but does not expose unnecessary detail. When storing data, you define how long it should remain relevant. For instance, detailed operational logs might only be needed for a limited period, after which aggregated data is sufficient. Making that distinction early prevents the system from accumulating data indefinitely. These decisions do not eliminate complexity, but they keep it bounded. More importantly, they ensure that the system behaves in predictable ways.

A more useful framing

Compliance is often treated as a checklist or a milestone. In practice, it behaves more like a property of the system. If the system’s behavior is unclear, compliance will always require effort. Each question will trigger an investigation. Each requirement will require adjustments across multiple components. If the system’s behavior is defined through design, compliance becomes a matter of describing those behaviors. The same system that is easier to operate and debug is also easier to explain.

The relevance of this in design

For teams building in the EU, these questions will surface sooner or later. When they do, the cost of change depends on how the system was designed: If data flows are implicit and widely distributed, changing them is difficult. If they are explicit and controlled, changes are more manageable. Most compliance issues originate in ordinary decisions. What is logged, what is stored, what is shared, and how long it persists. These decisions define the system long before they are evaluated from a compliance perspective. Understanding that is the starting point.