How to Build a Security Team in the AI World

Everyone's a Builder Now (Yes, Even GRC)

A while back someone asked me a deceptively simple question: how do you build a security team with AI in mind? I lead security for a living, so this isn't a thought experiment for me, it's the actual hiring-and-design problem sitting on my desk. I pulled my answer together from a mix of research and hard-won experience, put it in front of a few peers, and it kicked off enough debate that I figured it was worth writing up properly.

So I'm splitting it into a short three-part series, broken down the boring-but-useful way: People (this one), Technology, and Process. The thread running through all three is an idea I keep coming back to: AI is a magnifying glass. It amplifies your people, your data, and your process discipline, for better and for worse. Let's start with the people.

I keep hearing two lazy takes about AI and security careers: "AI is going to replace the analysts" and "nothing really changes, it's just another tool."

Both miss it.

Here's the take that actually matters: the bar for every security role is quietly becoming like the DevSecOps builder. Not just the red-teamers and cloud engineers. Everyone. And yes, that includes the traditionally "non-technical" corners like GRC.

The DevSecOps profile is the new floor

The candidate you want looks a lot like a strong DevSecOps or SRE engineer does today. Someone who can move laterally across wildly different environments and technologies, and vertically up and down the stack, comfortable with both observability and security.

In a word: builders.

This isn't a fringe opinion anymore, it's where the discipline is heading. Platform engineering, basically "DevOps evolved", is already folding observability, security and data into one builder craft. Gartner reckons around 80% of software-engineering organisations will have platform teams by 2026. The corner you could once keep "non-technical" is shrinking fast.

From buying tools to building them

The bigger shift is from people who operate a tool to solve a problem, towards people who build the tool that solves it.

For example, instead of buying a generic vulnerability scanner off the shelf and ticking a box, you build one wired to your actual business context, that tests the things you genuinely need tested. Not a checkbox. A real answer.

And the economics now support it: Gartner expects by 2030 AI-augmented teams will reshape 80% of organisations’ large software engineering teams into smaller, more nimble teams augmented by AI.

The bit that surprises people: curiosity is the moat

Here's the counterintuitive part. If AI is doing more of the building, why do humans matter more, not less?

Because of what AI is good at, and what it quietly isn't.

AI is brilliant at the obvious. By design, it optimises for the most probable path. The research is uncomfortably clear on this: a 2024 study in Science Advances found generative AI boosts individual creativity while reducing the collective diversity of ideas, and a 2026 review in Trends in Cognitive Sciences describes how large language models favour the frequent, easily-generalisable pattern and smooth over the unusual one.

Translation: AI will reliably hand you the answer everyone else is also getting.

So the edge belongs to the person who asks the non-obvious question, reframes the problem, and goes looking down the path the model would never suggest. This is the magnifying glass again: AI amplifies whatever you bring it. Point it at a curious, self-directed mind and it's rocket fuel. Point it at the absence of one and that shows up just as loudly.

The World Economic Forum's Future of Jobs 2025 makes the same point with data: analytical thinking is the single most-valued core skill (7 in 10 employers call it essential), and creative thinking, curiosity and lifelong learning are among the fastest-rising. The skills that survive contact with AI are precisely the ones it can't fake.

So why even GRC?

Because the floor moved for everyone. When the routine analysis, the first-draft policy, the control mapping can all be drafted by a machine, the value of a GRC professional shifts to asking the sharper question and building the thing that checks the answer. The job doesn't disappear. It levels up.

Practical takeaway: hire for the slope, not the snapshot

1. Hire builders and learners, not operators. Range and curiosity beat a static checklist of certs.
2. Actually test for curiosity. Give candidates an ambiguous problem and watch whether they reach for the obvious answer or the interesting one.
3. Reward building over running. The person who automated the toil should out-earn the person who endured it.
4. Raise build-literacy across the whole team, GRC included. Everyone should be able to shape the tool, not just consume its output.

"AI is a magnifying glass. It doesn't replace your people, it amplifies them, which is exactly why curiosity is the thing you hire for now."

Next up, Part 2 → "Give Your AI a Clean Room", on why your platform choices now matter more than your model choices.