Risk and compliance has always had a headcount problem because there is a systemic problem. Every step is handled as a fresh task across siloed systems. Prerequisite admin swallows the time that should go to judgement. Teams scale by adding people rather than building systems. The Compliance Engineer is a new kind of professional who designs that repetitive work away, combining regulatory expertise with systems thinking.
Key Takeaways:
What is a Compliance Engineer? A compliance professional who designs how regulatory change moves from obligation to policy to control, and owns that whole thread rather than one task in it.
Who can become one? Domain experts, not developers. AI has democratised the technical skills, so the edge is applying compliance knowledge to building systems and workflows.
How does AI enable Compliance Engineers? Agents take on the repetitive, prerequisite work under human oversight, freeing experts to spend their time on the judgement calls that need it.
The state of risk and compliance
Most compliance functions are organised around documents, not decisions. A regulator publishes an update; someone reads it, summarises it, and circulates the summary. Then the next, and the one after. What rarely happens is the part that matters: tracing each change to the obligations it creates, the policies they require, and the controls that prove the firm has met them.
Without a systemic approach to compliance the tracing is redone from scratch on every change. Each review rebuilds the same links by hand, and that repetitive groundwork. Compliance teams spend more time assembling the picture than on applying expert judgement only they can provide.
Audits become high-risk events rather than routine confirmations. Edge cases slip through while attention goes to organising information. Scarce expert time is spent on reactive preparation rather than proactive compliance decisions, and managing more strategic risks.
Increasing regulatory burden makes this approach unsustainable
Consider a Tier 1 bank running across dozens of legal entities and jurisdictions. In the past two years alone it has worked through DORA, the EU AI Act, Basel 3.1, an expanding sanctions map, and the FCA's Consumer Duty and its ongoing supervision. Each carries its own obligations, timelines, and evidence expectations, and each has to be interpreted separately for every entity and every regime it touches.
Picture how a single change moves through that bank today. An analyst reads the update and writes a summary. The summary is circulated. Someone then maps it by hand to the obligations it affects, then to the policies that must change, then to the controls that evidence them, and then repeats the entire exercise for each entity and jurisdiction it applies to. Every step is a fresh task in a different system: a spreadsheet here, a GRC platform there, an email thread, a shared drive. Nothing carries forward, so the next change starts from scratch.
The default response is to scale the only way this model allows, by adding people. Another analyst for the new regulation, a contractor for the policy refresh, a consultant when the backlog reaches the board. The regulatory burden builds steadily, rule after rule, across every entity and jurisdiction, and each new hire reflects a linear increase in cost with regulatory obligations. Each time the answer is more headcount, it is a decision not to build the system that would let compliance scale without increasing headcount.
Experts can now use AI to design and build the workflows that manage the repetitive, prerequisite work, the reading, tracing, and routing that used to drain resources. As that workload moves to agents under human oversight, a greater share of expert time returns to what only they can do: the judgement calls, the edge cases, the grey areas.
Who is the Compliance Engineer?
Compliance engineers are not coders or software engineers. They are compliance practitioners with three traits: deep domain expertise, systems thinking, and practical AI skills. Compliance engineers know where to apply AI safely and where not to. They know how to score confidence in a model's output, how to evaluate what it produces, and where human judgement still has to sit.
Crucially, this is a skillset that can be learnt through experimenting and iteration rather than years of technical training. AI has democratised learning the technical layer. What has been missing in early enterprise AI adoption is the framework and the permission to step into the role. At our recent workshop with the ICA, over 250 compliance professionals worked through a defined compliance workflow using agents. The session focused on where to apply AI safely, how to score confidence in outputs, how to evaluate outputs, and where judgement must stay human.
.png)
For an ambitious compliance or risk professional, this is a natural progression. Step by step, the reactive checker forwarding alerts becomes the architect of the system everyone else relies on. The expertise is not automated away; it is concentrated where it counts, on the decisions the business actually feels.
Governing where AI can be trusted
AI is already entering compliance, but mostly ad hoc: a pilot here, a tool there, adopted without a clear view of where it can be trusted. The defining skill of the Compliance Engineer is governance: knowing which parts of the work AI can safely take, being able to prove it, and judging the risk of the AI itself, not only the compliance risk it is pointed at.
Our research on the future of AI governance in financial services finds the gap already opening. AI adoption is most mature in the first line, while the oversight functions meant to challenge these systems follow from a much lower base, often without the technical literacy to do it well.
How a Compliance Engineer designs gap analysis for controls
Take control gap analysis, the work of proving every obligation is backed by a control that actually works. It breaks into five steps: extract the obligations from the regulation, identify which of them need a control, map those to the controls that exist, find the gaps, and decide the remediation. Done by hand, an expert grinds through all five for every obligation, and because there is never enough time, only a sample, often around 5%, is ever looked at. The judgement that matters explicitly competes with the admin that comes before it.
The Compliance Engineer designs the same five steps differently. Each is scored on three things: how confident the model is, how material an error would be, and how easily a mistake would be caught. That score decides how much human judgement the step needs. Extracting obligations and mapping them to controls are high-confidence, lower-stakes steps, so an agent runs them and a second model checks. Identifying control gaps is more interpretive, so a human reviews the exceptions. Deciding remediation is nuanced and consequential, so the human decides, with the AI assembling the evidence.
The effect is to remove the prerequisite admin. The expert no longer works through extraction and mapping to earn the right to think; the system does that, consistently, every time. Their judgement goes straight to the steps that genuinely need it, the ambiguous gap and the finely balanced remediation call. The complex, nuanced problems get more expert attention.
It changes what a review can cover, too. Sampling was only a workaround for limited human capacity. When every item is scored and confidence decides what escalates, the whole population can be reviewed rather than just 5% of it. Consistency stops depending on who happened to pick up the file on a given day, and the blind spot on 95% of the controls is removed.
How we hire for Compliance Engineers at Zango
Read our job description and it outlines the key experience, mindset and skills required for the role. The new skill is knowing where AI can be trusted and where it cannot. This is what turns a Compliance Engineer's regulatory judgement into logic that AI scales, so their expertise is spent where it counts. In practice, it comes down to three things.
- Compliance domain expertise. Three to six years in compliance within non-financial risk, ideally in regulatory compliance or a related role in financial services.
- Systems thinking. Turn regulation into structured obligations, map them to policies and controls, and encode that logic into the models. Run the obligation extraction, compliance assessments, risk reviews and gap analyses, then shape how AI performs them at scale.
- AI skills. Embed regulatory logic into AI models, and validate agent outputs as the human in the loop, keeping them accurate and aligned to the regulation.
Our first Compliance Engineer, Ashi Bajwa joined us from KPMG with a background in assurance and law: deep domain expertise rather than a technical background. She learned the systems and AI skills, and now designs how compliance work runs at scale rather than repeating processes by hand. She also leads our workshops with the ICA, teaching other professionals to make the same move.
.png)
