Don’t Let an LLM Run Your Pay Transparency Reporting

“You can save €25,000 in expensive consultancy by using my EU Pay Transparency framework! I built it in half a day. Comment ‘framework’ and I’ll send you a copy.”

I’ve seen a few LinkedIn posts like this. And I love the enthusiasm for innovation and the willingness to build something and help others. And from the large number of comments, I see people are tempted to explore these free frameworks.

While it sounds tempting, this is the kind of offer that should make you very nervous. Because the coders built them on LLMs, like OpenAI or Claude. So, let’s explore why you should think carefully before letting an LLM handle your pay transparency reporting.

But isn’t this a good thing?

Sure, in theory. But here’s the problem: the EU Pay Transparency Directive isn’t a technical exercise, it’s a legal compliance framework with real consequences. When consultants charge €25,000, you’re not paying for automation. You’re paying for deep expertise in employment law across EU member states, professional liability insurance, and defensible methodologies.

And I am sure an LLM framework can generate an impressive regression model or dashboard. But does it understand the definition of “work of equal value” in your company? Can it defend its methodology to an inspector? And when something goes wrong, who do you think is liable: the creator and the LLM? Or you?

Why can’t I use an LLM?

It’s all about the data. Pay transparency analysis requires some of your most sensitive personal data: names, salaries, job titles, performance ratings, and protected characteristics like gender and age. You should not upload that to an LLM.

If you’re using AI tools, even with a paid subscription, your employee data might be:

• Used to train AI models. As of late 2025, major AI providers updated their terms so data from consumer accounts (including paid ones) can be used for training unless you opt out. And the opt-out might only apply going forward.
• Retained for months or years. AI providers may keep your data for 30 days to 5 years depending on settings. There’s no right to be forgotten.
• Processed without proper agreements. These accounts don’t include Data Processing Addendums with Standard Contractual Clauses that are required for GDPR compliance.
• Processed outside the EU. Most providers process data in the US or other jurisdictions, creating additional GDPR obligations.

To handle sensitive employee data properly, you need enterprise agreements with commercial terms that prohibit training on your data and include proper DPAs. Maybe you could use API access or enterprise plans, but certainly not the consumer tools most people use.

But what if I anonymize the data first?

Here’s the thing: removing employee names probably isn’t enough protection under GDPR. Pay transparency analysis requires a rich dataset to be meaningful: date of birth, hire date, promotion history, job title, department, location, performance ratings, and of course all compensation details.

This combination of data points can easily identify individuals, even without names attached. Think about it: “45-year-old Senior Software Engineer in the Amsterdam office, hired in March 2018, with a base salary of €95,000 plus 15% bonus.” How many people in your company fit that description? Probably one. Under GDPR, this is still personal data because the individual is identifiable.

True anonymization (where re-identification is impossible) would require stripping out so much detail that your pay transparency analysis becomes meaningless. You could e.g. remove names and replace date of birth with an age range (45-50). You’d lose the granularity needed for proper pay equity assessment, and you could not explain individual pay gaps anymore. And pseudonymization (e.g. replacing names with numeric values) doesn’t change your GDPR obligations, it’s still considered processing personal data.

So no, removing names before uploading files to an AI service doesn’t solve the data protection problem. You still need proper enterprise agreements, DPAs, and all the safeguards that come with them. Always check with your legal advisor first!

How will you explain the results to employees if an LLM generated them?

This is the explainability problem I’ve written about before, and it’s huge. Under the EU Pay Transparency Directive, you need to explain to employees “why you pay what you pay” and why they do or don’t have a pay gap. “Because the AI framework said so” isn’t going to cut it. Not with your employees, not with works councils, and definitely not with regulators.

LLMs are black boxes. Can you articulate exactly which factors the model considered? How it weighted them? Why it classified certain requirements as comparable? What assumptions it made about your data? If an employee challenges their pay determination, can you walk them through the methodology step by step?

A proper pay equity analysis has a clear, documented process: define comparable work, identify legitimate factors that explain pay differences (experience, performance, location), run statistical analysis with explicit controls, document any unexplained gaps. Every step is explainable to a non-technical audience. Every step is repeatable, regardless of the moment in time.

With LLM-generated analysis, you’re left trying to reverse-engineer decisions you didn’t make. That’s not transparency, that’s opacity with extra steps. Your employees deserve better, and the Directive requires more.

So, AI has no place in pay transparency work?

I didn’t say that. Many trusted pay equity vendors use AI and machine learning in their solutions. The difference:

• Their AI is purpose-built and extensively tested for this purpose
• Human experts review and validate all outputs
• They can explain and defend their methodology in legal proceedings
• They have proper data processing agreements and security controls
• And if something goes wrong, they carry professional liability insurance

Using AI as a tool within a professional framework is very different from asking a general-purpose LLM to build your entire compliance system.

What should we be doing instead?

Start with expertise. Engage qualified professionals, like internal analysts with proper training, external consultants, or specialized vendors.

Protect your data. Never upload employee pay data to an LLM. If you use AI tools, get enterprise agreements with proper data protection clauses. Better yet, work with vendors who handle processing under proper DPAs.

Build in review. Whatever tools you use, have qualified people review the methodology, assumptions, and results before submission. Make sure the outcomes are the same every time you repeat the review.

Document everything. You need to explain and defend every choice. Clear documentation of methodology, data sources, exclusions, and assumptions, readily available to your employees.

Plan for challenges. Assume your analysis will be questioned. Build your process to withstand scrutiny from day one.

What’s the bottom line?

The framework coders are right about one thing: the technical work isn’t impossibly complex. What makes it expensive is ensuring it’s done correctly, legally, and defensibly. That requires human expertise, professional accountability, and proper data protection. And it sometimes means paying an external consultant for expertise you don’t have.

I am all for using AI to assist you. Use LLMs to draft explanations, FAQs, and other documents that experts review. Use AI to find patterns that humans validate. Use it to document processes that professionals audit. But don’t use it as a substitute for expertise and accountability or as a quick cost saving exercise. Because that will come back to bite you. The stakes are too high, the legal requirements too precise, and the data too sensitive to trust to a tool that doesn’t understand the weight of what it’s producing.

In pay transparency reporting, the constraints aren’t technical. They’re legal, ethical, and reputational. Be very deliberate and yes, transparent, about when and how you use AI.