Like many people reading this, I spend my working week moving between the two areas that increasingly shape a privacy professional’s day: the familiar routine of data protection and the newer, faster-moving field of AI governance. The more I do both, the more I notice how much they have in common; less on the surface than in how we approach the work. This overlap matters most for organisations in the early stages of adoption who are using only a handful of AI tools and acting as deployers rather than providers. For them, the privacy function that they already have in place is enough to build a credible starting point for AI governance. It will not remain sufficient and as the risks grow and the use cases multiply, the baseline will need to mature but it is the right place to begin. The clearest illustration of that shared foundation is something privacy teams already do well.
Two assessments, one method
Take the gap assessment which sits at the heart of most privacy programmes. A privacy gap assessment sets out to understand how mature an organisation’s data protection really is: assessing the current state, measuring it against what the law and good practice require, seeing where the gaps lie, and turning that into a prioritised roadmap. An AI gap assessment does the same for an organisation’s use of AI, weighing governance, oversight, documentation and risk practices against the expectations now forming in the field.
What links the two so closely is not simply that they have a similar format, but that they both measure against an external legal benchmark. The privacy assessment can fall back on the GDPR; the AI assessment can fall back on the EU AI Act, together with the standards and guidance growing up around it.
From assessment to everyday practice
The same similarities run through the everyday work of putting a general-purpose AI tool to use. Through our privacy and data protection practice we are already familiar with many of the checks and balances required when assessing a new AI tool:
- The provider’s role: In most cases, an AI provider would be considered a processor. Therefore, per Article 28 of the GDPR, the team would perform an assessment to confirm whether the contracts and Data Protection Addendums are compliant, and are your inputs used to train the models.
- Input discipline: Prompts that are put into an AI tool is at heart a data minimisation question. We all understand that personal or special-category data should not go into a general tool without a lawful basis and a clear view of the confidentiality and IP risk.
- International transfers: Where the provider sits outside the EEA, the Chapter V analysis and transfer impact assessment are the same checks you would run for any other non-EEA processor.
Shared disciplines
The European Commission’s Digital Omnibus, proposed in late 2025, points in the same direction. It is, at its core, a simplification package, and the thinking behind it is encouraging. As the digital rulebook has grown into a tangle of overlapping obligations, the sensible response is to read the GDPR and the EU AI Act together rather than as separate silos. This helps cut some of the duplicated paperwork and clarify how personal data is handled when AI systems are trained and built. The detail remains provisional, but the direction is clear and it points back to where I began: for an organisation finding its feet with AI, the smartest first move is to build on the privacy function it already has.
So before creating a whole new governance structure for AI, it is worth asking what the privacy function would already do with the problem in front of you. For an organisation early in its journey this practice can easily become a baseline to begin from, on the understanding that it must grow as the risks and use cases do. Seen that way, this new chapter feels less like unknown territory and more like work we already know how to do well.