Privacy engineering mid-year temperature check

In the immortal words of the indie pop band Future Islands, "seasons change." The onset of summer has folks in the Northern Hemisphere watching temperatures rise while cold-weather lovers Down Under eagerly break out their jackets and jumpers. This time of transition offers a fitting moment to check the temperature of privacy engineering in 2026. What's hot? What challenges are cooling things off? And what does the future hold? There is much more to discuss than there is room here, so we will focus on three high-level areas of work: managing AI privacy risk, using large language models to manage privacy risk and traditional privacy engineering work.

Managing AI privacy risk

We hear anecdotally, and unsurprisingly, that privacy engineers are devoting more time than ever to managing artificial intelligence privacy risks. As they battle for solutions to address these new risks, the operational workhorse remains the privacy risk assessment. The new additions to this space in the AI era are the requirements for transparency and accountability of AI models and their outputs. The emerging practice of including model cards for the AI itself and provenance standards like C2PA, or Coalition for Content Provenance and Authenticity, for outputs are helping to simplify the AI privacy risk assessment process.

Cutting-edge, privacy-enhancing technologies continue to mature from research to practice, supporting this hot area of work. Differential privacy is leading the charge on addressing AI training risks and is being used during training to limit the influence any specific data point can have on the final model. This helps meet data minimization requirements, as sensitivity during fine tuning can be controlled at the data level.

We're also seeing growth in the use of secure compute environments for inference and even product improvement. In these scenarios, purpose-built hardware and end-to-end encryption are used to limit how and why data will be processed. This covers both on-device and on-cloud data flows to ensure sensitive data can only be read in a protected space and used with a precise set of instructions. These limits may help make organizations comfortable with sharing sensitive data by offering additional controls to prevent it being reused or accessed without authorization.

Challenges

When it comes to AI privacy risk assessments, a big chunk of historical privacy engineering relied on knowing where data came from and how it would be processed. AI adds significant complexity, as agents collect data autonomously and process it non-deterministically. Data provenance offers help on this front, but privacy engineers should be cautious. Over-zealous provenance may generate its own privacy risks, such as cross-context linkage or personally identifiable information leakage. The second head of this hydra is the challenge of sourcing and handling of data used for AI training. In addition to data quality requirements, the requirements for privacy rights and intellectual property may be unclear when collating the training data — for example, whether the data must be licensed or whether user consent is sufficient.

Challenges in deploying PETs have persisted for some time and continue in the context of AI privacy risks. High-dimensional data poses difficulty when using differentially private synthetic data methods. These approaches can also be limited when the data is highly complex, as there is a risk that outliers will be underrepresented and common patterns exaggerated. Finally, while secure computation for execution encrypts data in use and offers secure attestation, it is not a silver bullet; side-channel attacks, prompt injections and a reliance on trusted third parties remain in play. In general, most PETs still require a significant amount of know-how to deploy correctly, many lack mature implementations and the privacy vs. utility trade-offs are not always clear. These are important considerations in any build vs. buy discussion. 

Looking ahead 

The IAPP is tracking progress on standardization efforts as well as conducting further research into PETs, such as using differential privacy tools to generate insights on LLM chatbot interactions. LLMs are also opening new doors for collaboration between specialties, such as legal and product teams, where privacy-by-design reviews can be made self-service through careful prompt creation and the ingestion of privacy resources. Now is a great time for non-engineers to leverage these new tools to explore adjacent areas.

Using LLMs to manage privacy risk

Privacy engineers are at various stages of exploring, testing and implementing AI solutions to support privacy risk management tasks. Some are finding LLMs to be useful to surface and document risks. In this context, AI serves as a "gut check" or gap filler — helping to identify risks the human may have missed or to simply save time with creating risk descriptions. 

More complex agentic workflows are showing promise to interpret privacy requirements and translate them into verifiable controls. At the PEPR '26 conference, participants offered insights into design solutions, such as orchestration loops and intelligence layers, to address the challenge of translating requirements that arrive as text with numerous exceptions. While agentic software development is outstripping any human capacity for classifying new data correctly and identifying privacy risks in the code, there is still hope. There is a positive trend towards teams using AI agents to classify data at scale, to scan code bases for vulnerabilities and to perform privacy red-teaming at scale. 

Challenges

Numerous challenges turn the temperature down on these active areas of privacy engineering work. It is often expensive and time-consuming for organizations to make their legacy systems and databases AI-ready. As noted, LLMs can be helpful to expedite this process, but specialized talent is needed regardless of whether these processes are automated. There are also risks of over-reliance on AI outputs, including automated decisions at high-risk boundaries. The incorrect integration of these tools may see code bases and internal secrets exposed to the world. Care should be taken to ensure the right controls are in place, both contractual and technical.

Looking ahead

As automated solutions continue to be desired and explored, a promising emerging practice is to build model context protocols on core privacy infrastructure to allow a more direct integration with agents. However, the need for high-quality access control and audit records increases in this space when you're no longer dealing with deterministic systems or directly with humans. The use of LLMs to manage privacy risk gives privacy engineers another potential hat to wear: tech tutor. This is an opportunity to help nontechnical privacy folks leverage AI to improve their work. This isn't exclusive to AI, of course — show the lawyers how to use developer tools in a browser. Finally, as AI technologies improve, and so with it trust in their capabilities, there are increased incentives to give them more responsibility for privacy risk management. We will be tracking the prevalence of this AI overreliance risk, as it intersects with the work of privacy teams. 

Traditional privacy engineering

AI may remain the hottest topic, but traditional privacy engineering work is as active as ever. Ultimately, successful privacy compliance and risk management require good data hygiene and data management. Privacy engineers are busy locating data, identifying and mapping relevant data flows and keeping accurate and up-to-date data — no small task.

Challenges

Tracking data, including legacy versions, updated records and proliferating copies, is keeping plenty of technical privacy pros awake at night as they try to tackle retention and deletion requirements. Consent management — data subject access and its sibling, data portability — are also keeping privacy engineers busy. Problems can compound when agentic workflows are in the mix that reduce user stickiness. Some fantastic work at PEPR '26 highlighted the need for greater standardization in data portability — alongside increased usability and trust — and underscored, with some sobering statistics, how few companies are providing proper portability. While privacy engineers chase the shiny new AI risks popping up all over the place, it is important that "bread-and-butter" privacy rights issues are not neglected.

Looking ahead

There is no shortage of legal and policy activity in the privacy and AI space, and privacy engineers are on the front lines of technical implementation. A key example is age verification, which sits at a tricky intersection of technical controls, front-end design challenges and policy requirements. 

There is a great opportunity for privacy engineering to step up and provide new solutions and standardized patterns to help ensure existing privacy infrastructure is fit for purpose when handling the data of young people. More broadly, it is always a good time for technical folks to share what is working and engage with the broader community to drive new standards. Similarly, there is an opportunity for less-technical privacy pros to get into the weeds as AI lowers the bar for entry and helps with discovery. Be on the lookout for future resources from the IAPP Engineering Network to support this ongoing work and collaboration.

Here are a few other things we're following:

• NIST differential privacy deployment registry
• Carnegie Mellon University research on user (non-)compliance with age verification prompts
• IAB Transparency and Consent Framework public comment period