How to Understand Privacy Engineering

Google has published a whitepaper on privacy in AI, proposing a practical framework for integrating Privacy Enhancing Technologies (PETs) across the entire AI lifecycle — from data collection to training, personalization, and deployment. The paper reframes privacy from “regulatory obligation” to “product design.” PETs shouldn’t be bolted on at the end just to manage compliance risk; they should be part of the system architecture from the start. The approach is: map where personal data enters the model at each stage, identify the specific privacy risks in each of those stages, and then apply targeted protections in data handling, training, and production. The framework is built around a three-way decision: privacy, utility, and cost. Teams are expected to intentionally choose the combination of PETs that offers protection without breaking product value or user experience. The whitepaper also categorizes PETs by phase: 📃Data layer: PII removal, deduplication, anonymization, synthetic data with differential privacy. ⚙️Training: differential privacy during optimization, federated learning, MPC, trusted execution environments to reduce memorization and internal exposure. 🚀Deployment: input/output filtering, secure runtime environments, on-device processing, and computation over encrypted data to protect prompts and responses in production. Finally, the document introduces the idea of creating “well-lit paths”: reusable engineering and governance patterns that make privacy part of the core infrastructure instead of something manually reinvented by each team. It’s a useful read for anyone looking to understand, in practical terms, how to apply PETs when assessing and deploying AI models.

Humans are terrible at maintaining secrets at scale. Look at the history of public sector data breaches that could have been avoided with a de identification pipeline. Unlocking data value without compromising privacy is technical architecture. At Mayfair IT, we have built data platforms handling sensitive information where the stakes are absolute. Citizens trust government with their data.  Breaching that trust destroys the entire relationship. But locking data away completely prevents the analysis that improves services. The challenge is sharing insights without sharing secrets. This requires privacy preserving pipelines built into the architecture, not added after the fact. How de identification pipelines actually work: Data enters the system with full identifying details.  Name, address, date of birth. Everything needed to link records to real people. The de identification pipeline processes this before analysts ever see it. Personal identifiers get replaced with pseudonyms. Granular location data gets aggregated to broader areas.  Rare combinations of attributes that could identify individuals get suppressed. What emerges is data rich enough for meaningful analysis but stripped of the ability to identify specific people. The technical complexity most organisations underestimate: → De identification is not a one time transformation, it is a continuous process as new data arrives. → Different analysis types require different privacy levels, so pipelines must support multiple outputs. → Re identification risk changes as external datasets become available, requiring constant threat modelling. → Audit trails must prove no analyst accessed identifying data without legitimate need. We have implemented these systems for programmes analysing geospatial patterns, health outcomes, and economic trends across millions of records. The platforms enable insights that improve public services whilst maintaining privacy standards that survive regulatory scrutiny. Engineering systems to treat data utility and privacy protection as non negotiable requirements solves the conflict entirely. The organisations that get this right unlock data value others leave trapped because they cannot guarantee privacy. What prevents your organisation from sharing data that could improve services? #DataPrivacy #PrivacyPreserving #DeIdentification #DataGovernance

🌊 The Privacy Professional Iceberg 🌊 Most people assume privacy professionals spend their time doing things like reviewing contracts, policy writing or managing data subject requests (DSRs). While those tasks are certainly part of the role, there’s a whole other layer of skills that often go unseen. These are the skills that truly make a difference and allow us to navigate today’s fast-evolving landscape of privacy and AI. What We Actually Do: ⚙️ Operations: Turning legal requirements into practical, scalable processes. Rolling those out and monitoring whether they work, if not, adapt! 🤖 AI & Emerging Technologies: Understanding new and popular tools and technologies and their impact on privacy. Getting ahead of this, so you have done some thinking prior to having to review them during your day-to-day. 📈 Program & Project Management: Building privacy programs that run across teams and jurisdictions. Ensuring projects are planned, executed and properly evaluated with metrics and KPIs is key. 👥 Team Building & Management: Attracting the right team and doing your best to coach and develop them. We’re not just solo experts, if a program is in good shape, chances are there is a group of brilliant people behind that. It’s about creating a privacy function that’s robust and sustainable. 📚 Continuous Learning: Staying ahead of new laws and technologies and what is happening in the real world. Trying new technolgies yourself so you understand what may come across your desk. 🤝 Stakeholder Alignment: Finding the how together with your stakeholders. Influencing across departments to ensure privacy is embedded while ensuring cross-functional alignment and achieving business goals. 🌐 External Relationship Building: Staying connected with industry groups, policy makers and peers. 💼 Business Acumen & Strategy: Business skills are so helpful and will make you more successful, especially for privacy pros in commercial settings. You should understand the business and your colleagues who are driving that business forward. Business skills come in handy while actually running your program too: from user experience design to organisational strategy, learning about this has all been helpful to me. 💻 Tech-Driven Compliance Solutions: Staying up-to-date with tech solutions to improve, automate and manage compliance. 🎨 Creativity in Compliance: Try and have fun along the way. For example, your training can be fun and entertaining and done in ways beyond just recording a video or buying one off the shelf. This was an impossible list, I could have added so many more. Pitching skills is another one! 💖What else belongs on here?

Privacy isn’t a policy layer in AI. It’s a design constraint. The new EDPB guidance on LLMs doesn’t just outline risks. It gives builders, buyers, and decision-makers a usable blueprint for engineering privacy - not just documenting it. The key shift? → Yesterday: Protect inputs → Today: Audit the entire pipeline → Tomorrow: Design for privacy observability at runtime The real risk isn’t malicious intent. It’s silent propagation through opaque systems. In most LLM systems, sensitive data leaks not because someone intended harm but because no one mapped the flows, tested outputs, or scoped where memory could resurface prior inputs. This guidance helps close that gap. And here’s how to apply it: For Developers: • Map how personal data enters, transforms, and persists • Identify points of memorization, retention, or leakage • Use the framework to embed mitigation into each phase: pretraining, fine-tuning, inference, RAG, feedback For Users & Deployers: • Don’t treat LLMs as black boxes. Ask if data is stored, recalled, or used to retrain • Evaluate vendor claims with structured questions from the report • Build internal governance that tracks model behaviors over time For Decision-Makers & Risk Owners: • Use this to complement your DPIAs with LLM-specific threat modeling • Shift privacy thinking from legal compliance to architectural accountability • Set organizational standards for “commercial-safe” LLM usage This isn’t about slowing innovation. It’s about future-proofing it. Because the next phase of AI scale won’t just be powered by better models. It will be constrained and enabled by how seriously we engineer for trust. Thanks European Data Protection Board, Isabel Barberá H/T Peter Slattery, PhD

Too many enterprise programs still treat privacy as a policy checkbox. But privacy - done right - isn't simply about compliance. It’s about enabling confident, ethical, revenue-generating use of data. And that requires infrastructure. Most programs fail before they begin because they’re built on the wrong foundations: • Checklists, not systems. • Manual processes, not orchestration. • Role-based controls, not purpose-based permissions. The reality? If your data infrastructure can’t answer “What do I have, what can I do with it, and who’s allowed to do it?” - you’re not ready for AI. At Ethyca, we’ve spent years building the foundational control plane enterprises need to operationalize trust in AI workflows. That means: A regulatory-aware data catalog Because an “inventory” that just maps tables isn’t enough. You need context: “This field contains sensitive data regulated under GDPR Article 9,” not “email address, probably.” Automated orchestration Because when users exercise rights or data flows need to be redacted, human-in-the-loop processes implode. You need scalable, precise execution across environments - from cloud warehouses to SaaS APIs. Purpose-based access control Because role-based permissions are too blunt for the era of automated inference. What matters is: Is this dataset allowed to be used for this purpose, in this system, right now? This is what powers Fides - and it’s why we’re not just solving for privacy. We’re enabling trusted data use for growth. Without a control layer: ➡️ Your catalog is just a spreadsheet. ➡️ Your orchestration is incomplete. ➡️ Your access controls are theater. The best teams aren’t building checkbox compliance. They’re engineering for scale. Because privacy isn’t a legal problem - it’s a distributed systems engineering problem. And systems need infrastructure. We’re building that infrastructure. Is your org engineering for trusted data use - or stuck in checklist mode? Let’s talk.

As a new joiner, a privacy professional might face several privacy challenges within a company. Here are some of the key challenges: 1. Understanding the Existing Privacy Landscape • Learning Existing Policies and Procedures: Quickly getting up to speed with the company’s current privacy policies, procedures, and compliance frameworks. • Data Inventory: Identifying what personal data the company collects, processes, stores, and shares, and understanding the data flows. 2. Ensuring Compliance with Regulations • Navigating Multiple Regulations: Understanding and ensuring compliance with various data protection laws (e.g., GDPR, CCPA, PDPL) that may apply to the company’s operations. • Keeping Updated: Staying current with evolving privacy laws and ensuring that the company’s practices and policies are continuously updated. 3. Implementing Privacy by Design • Integrating Privacy Practices: Ensuring that privacy considerations are integrated into the design of new products and services from the outset. • Collaboration with IT and Development Teams: Working closely with technical teams to implement privacy features and security measures. 4. Managing Data Breaches • Incident Response Planning: Developing and implementing an effective incident response plan for data breaches. • Training and Awareness: Educating employees about recognizing and responding to data breaches and other privacy incidents. 5. Ensuring Data Subject Rights • Handling Requests: Implementing processes to handle data subject access requests (DSARs), such as requests for data access, rectification, erasure, and portability. • Maintaining Documentation: Keeping detailed records of how data subject requests are handled to demonstrate compliance. 6. Establishing a Privacy Culture • Training and Awareness: Developing and delivering privacy training programs to ensure all employees understand their privacy responsibilities. • Building Trust: Creating a culture of privacy where employees feel responsible for protecting personal data and understand the importance of privacy compliance. 7. Conducting PIAs • Risk Assessment: Identifying and assessing privacy risks associated with new projects or data processing activities. • Mitigation Strategies: Developing and implementing strategies to mitigate identified privacy risks. 8. Vendor Management • 3rd Party Compliance: Ensuring that third-party vendors comply with the company’s privacy policies and data protection regulations. • Contractual Agreements: Reviewing and negotiating data protection clauses in vendor contracts. 9. Data Governance • Data Quality and Accuracy: Ensuring the accuracy and quality of the data collected and maintained. • Data Retention and Disposal: Implementing data retention policies and ensuring that data is disposed of securely when no longer needed. Addressing these challenges requires a proactive approach and a commitment to fostering a culture of privacy within the organization.

Your privacy notice became wrong 24 hours after you published it. Product launched a feature that collects location data. Nobody told you. This is why perfect compliance is impossible. You spend 40 hours updating your privacy notice to match new regulations. The day after you publish it, product ships something that collects completely different data. → Customer service has different data than sales. Sales has different data than marketing. → Nobody talks to each other. → That integration from three years ago is still running. → You don't remember what data it accesses. → Your company pivoted six months ago. Your privacy program is still optimized for the old business model. Here's the truth: Your job isn't perfect compliance. Your job is managing risk while building toward better outcomes over time. Most privacy programs get stuck at Level 1: Meeting legal requirements. Responding to regulators. Documenting decisions for audits. This is table stakes. But if it's all you're doing, you're just playing defense. Level 2 is operational work: Building systems that actually work. Training people on realistic scenarios. Fixing processes that create privacy problems. This is where you start preventing fires instead of just putting them out. Level 3 is strategic work: Influencing product decisions before they're made. Shaping business practices at the source. Building privacy into company culture. This is where privacy becomes invisible because it's built into how decisions get made. Don’t chase perfect compliance. Build systems that get better over time. Accept  that privacy work is imprecise and plan accordingly. Focus on progress, not perfection. What if you shifted your time allocation? 20% on compliance work. 30% on operational improvements. 50% on strategic initiatives that prevent problems before they happen. Your privacy notice might still get out of sync sometimes. But you'll have processes that catch it quickly and systems that prevent the biggest risks. That's not perfect compliance. That's smart privacy work. Which level resonates most with where you want to focus your energy? Sometimes just naming it helps clarify what to prioritize.

Engineers love to build for scale, but ignore privacy until legal comes knocking. This costs MILLIONS. When engineers design data systems, privacy is often an afterthought. I don’t blame them. We aren’t taught privacy in engineering schools. We learn about performance, scalability, and reliability - but rarely about handling consent, compliance, or privacy by design. This creates a fundamental problem: We build data systems as horizontal solutions meant to store and process any data without considering the special requirements of CUSTOMER data. As a result, privacy becomes a bolt-on feature. This approach simply DOES NOT WORK for customer data. With customer data, privacy needs to be a first-class citizen in your architecture. You need to: 1. Track consent alongside every piece of customer data throughout the entire lifecycle 2. Build identity resolution with privacy in mind 3. Design data retention policies from day one 4. Implement access controls at a granular level When privacy is an afterthought, you'll always have leaks. And in today's regulatory environment, those leaks can cost millions. The solution isn't complicated, but it requires a shift in mindset. Start by recognizing that customer data isn't like other data. It has unique requirements that must be addressed in your core architecture. Then, design your systems with privacy, consent, and compliance as fundamental requirements, not nice-to-haves.

I keep seeing the term “Privacy-by-Design” everywhere. Webinars. Frameworks. ISO guides. Posts. Articles. Finally, after reading countless resources, attending classes, and engaging with domain experts, I decoded a pattern which is now a trending topic in the privacy and AI compliance world. I realized the market isn’t confused about privacy. It’s confused about how to design it. We follow policy, but what we truly need is a system which is a hidden geometry that quietly powers every mature privacy program. 1️⃣ The Compliance Triangle GDPR × ISO 27001 × NIST CSF This is the foundation of Privacy-by-Design where law defines what’s right, controls define how it’s done, and resilience ensures it lasts. ↳ GDPR defines why data must be protected. ↳ ISO 27001 structures how it’s secured. ↳ NIST CSF measures how well it’s sustained. Together, they turn compliance from paperwork into proof.   2️⃣ The Engineering Triangle Minimization × Encryption × Access Control This is the core of Privacy-by-Design ,where principles become protocols. ↳ Minimization limits what you collect. ↳ Encryption shields what you store. ↳ Access Control governs who touches what. When these align, privacy becomes a default setting, not a feature. 3️⃣ The Governance Triangle Policy × People × Proof This is the continuum that keeps privacy alive after launch. ↳ Policy defines intent. ↳ People uphold accountability. ↳ Proof (audits, DPIAs, reports) converts trust into evidence. Governance makes privacy sustainable not seasonal. Together, they create a privacy engine a continuous loop of law → design → assurance. #PrivacyByDesign #GDPR #ISO27001 #NISTCSF #AIGovernance #DataPrivacy #PrivacyEngineering #DigitalTrust #ResponsibleAI Privacy-by-Design isn’t one triangle, it’s a triad of triads. Because It isn’t a policy. It’s an architecture.

The Privacy Role That Pays $150K+ But Gets Fewer Than 10 Applicants Yes, you read that right. There’s a role that desperately needs privacy + legal talent, pays senior-level tech salaries, and still struggles to fill vacancies. It’s called a Privacy Engineer. Before you scroll away thinking “that sounds too technical for me”, let me show you why you may already be closer to qualified than you think. What job postings actually ask for I’ve reviewed dozens of privacy engineer listings. The patterns repeat: Translate privacy requirements into technical safeguards.  Work with developers to embed “privacy by design.”  Assess risks in data flows, AI models, and apps.  Build or review tools for consent, access controls, retention, etc.  Notice something? None of these say “you must be a software wizard.” Data mapping/records of processing → translates into system data flow diagrams. DPIAs & risk assessments → align directly with technical threat modeling. Interpreting GDPR, HIPAA, AI Act → becomes requirements gathering for engineers. Policy drafting → evolves into control design & documentation. In other words: if you’ve done privacy ops, impact assessments, or compliance frameworks → you already speak half the language. The pathway to transition: Learn to “read” system diagrams (lots of free resources on basic data architecture). Pick up lightweight tech tools (SQL basics, data visualization, or even privacy tech platforms like OneTrust/BigID). Shadow/partner with IT colleagues - your legal brain + their tech brain = privacy engineering in practice. Start calling yourself what you are → a legal/privacy professional with engineering alignment. Why this matters These roles are being posted with $150K+ salaries, hybrid work, and long-term demand. Yet many go half-empty because privacy pros self-select out before even applying. If you’re already bridging law, compliance, and data, you’re halfway to being a privacy engineer. So let me leave you with this challenge:    Next time you see “Privacy Engineer” in a job post, don’t scroll past.    Click. Read. Map your skills. Apply. Because the companies need you more than you realize. --- #PrivacyEngineer #PrivacyJobs #DataPrivacy