What we tell people who ask whether AI belongs in compliance work

It comes up in almost every conversation now, usually in the first ten minutes, and usually phrased as a slightly nervous question. Are you putting AI in this. The person asking is rarely excited. They have been sold something before.

So here is the answer we give, plainly, because it has not changed in a year of building.

AI belongs in the reading. It does not belong anywhere near the deciding. Everything else is detail.

Why the reading is the right job for it

Think about what compliance work actually consists of on a Tuesday. Somebody opens a framework document that runs to a few hundred pages. Somebody else opens a shared drive full of evidence that a colleague uploaded in a hurry eight months ago, with file names that made sense at the time. A third person tries to work out whether the thing in the second folder answers the question in the first document.

That is reading. Slow, careful, repetitive reading, done by people who are good at it and would rather be doing almost anything else.

A machine is genuinely good at this. Give it the requirement text and the evidence and it will come back with a shortlist. This probably belongs here. This one does not look like it answers what it is filed against. This date is older than your own policy says it should be. None of that is a decision. All of it saves a person an afternoon.

That is a real gain, and we are happy to claim it.

Why the deciding is not

Now think about what happens when the machine is allowed one step further, and it marks the control satisfied.

Nine times out of ten it will be right, and that is exactly the problem. The tenth case is the one you find out about eighteen months later, in a room, with somebody asking who accepted this. If the honest answer is that nothing accepted it, a process did, you have not got a compliance position. You have a record of confidence that nobody can account for.

A control accepted by a model is a control nobody can be asked to explain. That is the opposite of what the whole exercise is for.

Accountability is not a nice property of compliance. It is the entire mechanism. A regulator is not really asking whether a control works. They are asking whether somebody competent looked at it, understood it, and was willing to put their name against it. Remove the name and the rest of the structure has nothing to stand on.

So in everything we build, the acceptance stays with a person. It carries their name and the date, and it stays attached to the record long after they have moved on.

What that looks like in practice

The rule we hold ourselves to is simple enough to test. If a step ends in an opinion that somebody might later have to defend, a person takes it. If a step ends in a shortlist, a summary or a draft, the machine can take it.

None of this is a technical constraint. It is a design position, and it is one we are comfortable defending, including to the people who would prefer the more impressive answer.

The part nobody mentions in the demo

There is a second question hiding underneath the first, and it matters more than most buyers realise. Where does the data go.

A compliance platform holds the most sensitive map an organisation has. Not the data itself, but the far more useful thing, which is the list of where the organisation is weak and who has not fixed it yet. Feeding that to a third party service without knowing the retention terms is a decision, and it should be taken deliberately rather than discovered later.

If you are evaluating anything in this space, make the vendor answer four questions in writing. Do my inputs train the model. How long are they retained. Which regions process them. Who at your company can read them. Vague answers are an answer.

The NIST AI Risk Management Framework is a reasonable starting point for structuring that conversation, and the OWASP Top 10 for Large Language Model Applications is the most practical list we have found for the failure modes that actually show up. If you want the adversarial side of it, MITRE ATLAS does for AI systems roughly what ATT&CK did for everything else.

Where we landed

Both CyberNexus and ControlGraph use AI, and both use it in the same narrow way. It reads, it suggests, it flags. A person confirms, and that confirmation is what the record keeps.

We could have built the other version. It would demo better. It would also quietly transfer the accountability from a named professional to a piece of software, and the first time that mattered, it would matter a great deal.

If somebody is selling you the other version, ask them who signs.

Common questions

Can AI be used for compliance work

Yes, in the reading. It is genuinely good at working through framework text and uploaded evidence and returning a shortlist of where things probably belong and what looks missing. The line worth holding is that it should not accept a control, because acceptance is an opinion somebody may later have to defend.

Is it safe to put compliance data into an AI tool

Only once you know the answers to four questions. Do your inputs train the model, how long are they retained, which regions process them, and who at the vendor can read them. A compliance platform holds the map of where an organisation is weak, so vague answers should be treated as a no.

What should AI never do in a compliance process

Sign anything. Every acceptance needs to carry a named person and a date, because the question that eventually gets asked is not whether a control was satisfied but who decided that it was, and a model cannot be asked to explain itself.

How do we evaluate an AI compliance vendor

Ask them who signs. If the product accepts controls on its own, it has quietly moved accountability from a named professional to software. Then ask the four data questions in writing, and treat unclear answers as the answer.