Build the Core, Localise the Delta

Keep three layers separate

1. Binding rule. What the law or another applicable legal source requires.
2. Operational implication. What must change in a workflow, responsibility or decision.
3. Design hypothesis. One way a team might implement that requirement through product behaviour, architecture and controls.

A law may require a company to honour a right, assess a risk or restrict a transfer. It may not prescribe the database structure, API, ticket route or release process. Those implementation choices still depend on the product and its role.

Map the processing operation before the jurisdiction

A product does not become subject to every privacy law simply because it calls itself global. Applicability cannot usually be resolved only by asking where the company is incorporated or where its main servers sit.

For each material processing operation, map the people affected, their location, the relevant entities, the company's role, the purpose, data sensitivity, systems, recipients, transfers and sector conditions.

The first market-entry artefact should therefore not be a revised privacy notice. It should be an applicability and role map connected to concrete processing operations.

Let the role change the workflow

The same SaaS company may process tenant content on a customer's instructions and process account, billing or security data for its own purposes.

One deletion request may therefore become several routes. For tenant-controlled data, the product may forward the request, provide tenant-scoped tools or execute a documented instruction. For data the company controls itself, it may need a separate decision and exception analysis.

Role-aware does not mean manual approval for every technical action. It means the architecture does not quietly replace the responsible party's legal decision with one universal workflow.

Build a common privacy control plane

The reusable layer can provide capabilities through which different rules are implemented:

• data discovery and lineage beyond the customer database;
• records of role, purpose, processing condition, vendor and location;
• rights and preference orchestration;
• retention and deletion across copies, logs, embeddings and backups;
• vendor, subprocessor, transfer and residency records;
• risk and impact-assessment workflows;
• incident management and evidence generation;
• dataset, model and version provenance for AI-enabled features.

The control plane does not decide what the law requires. It gives the company mechanisms through which the correct decision can be executed and evidenced.

Use the feature as the implementation unit

Legal comparisons are organised around doctrines. Product teams build features.

Take an AI summarisation feature. A release review can connect role, provider terms, prompt retention, training use, location, sensitive inputs, rights handling, deletion, model provenance, human review and evidence to one concrete implementation object.

That feature becomes the meeting place for Legal, Privacy, Product, Engineering, Security, Data and Procurement. The output is not only a legal memorandum. It is a regulatory delta backlog with owners and release consequences.

Finish the traceability chain

Requirement -> role and context -> product behaviour -> control -> evidence -> owner

If a requirement has no defined product behaviour, it has not been operationalised. If the control has no reliable evidence, its operation cannot be demonstrated. If no one owns the outcome, the workflow is unlikely to survive a real request, incident or launch.

The portable formula is therefore:

Build the operational core. Map the role. Localise the legal rule and deployment constraint. Test the product behaviour. Preserve the evidence.