Here's a question worth sitting with for a moment: is your technical recruitment team using any AI tools right now? An applicant tracking system that filters CVs? A platform that scores candidates? A note-taking bot that summarises interviews? If the answer to any of those is yes, and you have candidates or employees in the EU, you are already operating in territory the EU AI Act cares about.

There's a conversation I find myself having surprisingly often with founders and CTOs at growing tech companies. It goes something like this: "We know we probably need to look at privacy, but we're not processing that much personal data yet" or "we're not ready to take on something that big." And so the program gets shelved. Indefinitely.

The irony is that waiting until you feel "ready" is one of the riskier positions you can take.

Let me paint you a picture that I see far too often in growing tech companies. You've got multiple products, multiple development teams, and they all have access to production data. DevOps has keys to everything. Support can see client information whenever they need it. Dev teams can pull production databases for debugging. Everyone's happy because they can move fast and fix things quickly.

Your privacy officer, however, is having a quiet panic attack in the corner.

One of the issues I see repeatedly when working with development teams and their CTOs is the way companies treat email. Most organizations have their email configured as a permanent archive, keeping messages for the duration of someone's employment and then indefinitely thereafter "just in case we need it later."

This approach seems prudent on the surface, but from a privacy perspective, it's a ticking time bomb.

Companies are increasingly relying on security evidence collection platforms for their SOC 2, ISO 27001, or GDPR compliance programs, assuming that if the tool says they're compliant, they must be covered. The reality is quite different, particularly for privacy.

These platforms are excellent at what they do: collecting digital evidence, tracking policies, monitoring systems, and creating audit trails. They'll plug into your cloud infrastructure, pull logs from your applications, and generate reports that auditors love to see. But here's the catch: they only see what's digital.

As a fractional privacy engineer working with development teams, I often get called in after the fact. A feature has been built, it's ready to ship, and suddenly someone realizes there might be a privacy problem. The scramble that follows is never fun for anyone involved.

The good news is that there are clear red flags that should signal to your team that it's time to loop in privacy expertise. If you catch these early, you can save yourself from costly redesigns, delayed releases, or worse: regulatory complaints and fines.

A few days ago I attended the OWASP Toronto chapter, where agentic AI took centre stage from a security perspective. It confirmed something I'd been sitting with for weeks, and honestly, it wasn't comfortable.

Every relationship has a moment where someone needs to say it out loud. The dev team and the privacy office have been growing apart for a while now, and agentic AI just accelerated things considerably. The privacy office is still setting ground rules for the first date, and the development team has already moved in together, redecorated, bought a hot-tub, and is halfway through building an extension.

I spend a lot of time talking to development teams about implementing privacy requirements. It's necessary work, but here's what I've learned: by the time privacy lands on a developer's desk, you've already missed half the opportunities to get it right.

Privacy isn't a coding problem. It's a product problem.

If you're leading product management, design, or research teams, privacy is just as much your responsibility as it is your developers'. The difference is that when you get it right early, you save your team from the nightmare of retrofitting privacy into a product that was never designed for it.

I talk to a lot of founders and early-stage CTOs who just flake out when they hear about privacy compliance. They've read about GDPR fines, watched competitors scramble with incident response, and now they're convinced they either need a bulletproof privacy program before they can even ship their MVP, or nothing at all. The result in both cases? Paralysis.

Here's what I wish all founders were told: you don't need to implement every privacy requirement under the sun on day one. Privacy compliance isn't an all-or-nothing game.

When I'm working with development teams on privacy compliance, there's a persistent assumption that seems to pop up : "We've got a Master Services Agreement with our supplier, so we're covered for data protection."

Not quite.

As much as I love a hub-and-spokes model, I've walked into many organizations and found their privacy champions sitting through the same training as the compliance team. It's well-intentioned, sure, but it's also a recipe for glazed eyes and forgotten lessons by the time everyone gets back to their desks.

There's an old saying in IT circles that has caused more headaches than it has solved: "If it ain't broke, don't fix it." On the surface, this seems like sound advice. Why tinker with systems that are humming along nicely? Why risk introducing new issues when everything is stable?

The problem is that this philosophy, while comfortable, can quietly transform from prudent caution into outright negligence.