What each control function actually needs from you

Delivery teams tend to treat governance as a single mass called "the approvals". It is not one thing. It is several functions, each trying to answer a different question, each with a different definition of a satisfactory answer.

Almost all of the time lost to governance in the organisations I have seen goes to one failure: bringing the wrong evidence, being asked for the right evidence, and coming back three weeks later. Knowing the question in advance fixes most of that, and it costs nothing.

What follows is generic. Every organisation names and splits these differently, and some combine them. The questions are consistent.

Risk

The question: if this goes wrong, how wrong, how often, and who absorbs it?

Risk is not trying to establish that nothing can fail. It is trying to establish that the failure modes are understood, bounded and owned. A team that arrives asserting reliability is answering a question nobody asked. A team that arrives with the failure modes enumerated, with impact and likelihood characterised and a named owner, is answering the real one.

The most useful thing to bring is the list of ways this can be wrong, written by you, before anyone asks for it. It reads as competence rather than as weakness, which is counterintuitive the first time.

Privacy

The question: what personal information is involved, on what basis, and can the individual's rights still be exercised?

Privacy needs specificity about data, not reassurance. Which fields. Where they came from. What the original collection purpose was and whether this is compatible with it. What leaves the environment. What is retained and for how long. Whether an individual could still be told what happened to their data and have it corrected or removed.

The recurring stumble is treating "the model does not output personal data" as sufficient. What went in matters as much as what comes out.

Security

The question: what is the attack surface, and what is the blast radius?

Security wants the boundaries. What can reach this, what can this reach, how is access granted and revoked, where do secrets live, what is logged, and what happens if a component is compromised. For machine learning specifically, add: where did the training data come from, and what would happen if it had been tampered with.

Security conversations go badly when a team presents a design as finished. They go well when the boundaries are drawn explicitly and the team can say which ones they are unsure about.

Data governance

The question: is this data being used by the right people for the right purpose, and can you prove where it came from?

Lineage, ownership, classification, and whether the use is consistent with what the data was stewarded for. This function is frequently the one that surfaces the awkward finding that a dataset in wide informal use has no actual owner.

Bring the lineage. If you cannot describe how the data got to you, that is the finding, and discovering it in a review is much more expensive than discovering it in a design session.

Architecture

The question: does this fit, and what does it commit us to?

Architecture is thinking about the estate, not your system. Whether this duplicates something that exists, whether it introduces a dependency the organisation does not want, whether it can be operated by the teams that operate everything else, and what it will cost to change or remove later.

The most productive way to arrive is with the alternatives you rejected and why. Architecture reviews that feel adversarial are usually reviews where only one option was presented.

Model risk

The question: is this model appropriate for its purpose, and will you know when it stops being appropriate?

Distinct from technical performance. Model risk is concerned with whether the problem was framed correctly, whether the data supports the inference being drawn, what the model's limits are, what happens at those limits, and how degradation would be detected after deployment.

The evidence that matters most is the monitoring and revalidation plan, because it is the part that says what happens after the day everyone is looking.

The pattern underneath

Read them together and something becomes clear. Every one of these functions is asking a version of the same question: do you understand this well enough to be trusted with it, and will you still understand it in a year?

Which means the most reliable way to get through governance quickly is not to prepare persuasive material. It is to genuinely understand the failure modes of your own work and be able to say them out loud, including the ones you have not solved.

Teams that do that move quickly. Teams that arrive with a confident narrative and no stated limitations move slowly, and reasonably so.

The practical move

Write down, for each applicable function, the question it is asking and the specific artefacts that answer it. Do this once, for your organisation, and reuse it.

That document is worth more than any amount of process improvement, because it converts governance from an unknown into a checklist you can prepare against. It is also the thing that, in most organisations, nobody owns, which is why it does not exist.