The hardest problem in standing up a second-line AI function is not identifying risks. The risk taxonomy is by now reasonably well understood:hallucination, bias, drift, leakage, access violations, adversarial manipulation, excessive agency, third-party dependency. Any competent practitioner can produce that list.
The hard problem is decision rights. Who assigns the risk tier, and who can override it. Who signs off at each level. Who may accept risk, and for how long. Who is merely consulted, and who genuinely decides. Programs that leave these questions implicit discover the answers during their first serious disagreement, which is the worst possible time to be negotiating them.
This article covers the three components of an operating model that make authority explicit:
The ownership split across the three lines
The decision-rights matrix
The governance forums that carry the decisions
Ownership: What Each Line Owns, and What It Explicitly Does Not
Most three-lines diagrams state what each line owns. Fewer state what each line explicitly does not own, and the second half is where the model earns its keep, because role creep is quiet and almost always well-intentioned.
The first line
Owns: design and build; intended-use and limitations documentation; evaluation evidence; production monitoring; self-identified issues; remediation delivery; and day-to-day operation of its controls.
Does not own: sign-off on its own risk tier, or independent challenge of its own evaluation results. Both are structurally impossible from inside the first line: not because builders are unreliable, but because proximity to the work makes independent judgment about it unavailable.
The second line
Owns: the framework and policy; the tiering standard; independent challenge; control expectations by tier; the risk acceptance process; aggregate reporting; and the escalation path.
Does not own: building models, fixing defects, or product outcomes, and importantly, it does not own being the approval bottleneck for every use case.A second line that reviews everything has misunderstood proportionality and will be routed around within two quarters.
The third line
Owns:independent assurance over both the first line's execution and the second line's effectiveness.
Does not own: designing the framework it will later audit. This is worth stating explicitly in the operating model, because a new second-line function will reasonably ask internal audit for help, and internal audit will reasonably want to give it.
Negotiating the Seams
In most organizations, the second-line AI function is not the only group with a claim on AI governance. There is often a responsible AI or AI ethics lead, an AI engineering lead who owns platform standards, an AI strategy function, and established privacy and security functions with their own mandates.
These roles overlap genuinely rather than accidentally, and the overlaps must be negotiated in the first weeks rather than litigated in the first crisis. Three seams recur:
Responsible AI versus AI risk.Responsible AI typically owns principles, fairness, and the ethical frame; AI risk owns the control framework, tiering, and challenge. The workable division is that responsible AI defines what good looks like in principle and AI risk makes it operational and testable. Both must sit in the same forums.
Engineering platform standards versus risk control standards.Engineering owns how systems are built; risk owns what must be true before they ship. When engineering standards are strong, the risk function should adopt them by reference rather than duplicating them under a different name.
Privacy and security versus AI risk. Privacy owns the data protection assessment; security owns the security assessment; AI risk owns the AI-specific risk assessment and the tiering of the use case. The failure mode is a system cleared by privacy and security with nobody having asked whether the model is fit for the purpose it will serve.
The practical instrument for all three is a written statement of who owns what, agreed with the named counterparts and circulated, before the framework is published. An operating model that has not been agreed with its neighbors is a proposal, not a model.
The Decision-Rights Matrix
For each significant decision, three roles must be named: who recommends, who decides, and who is consulted. The following set covers the decisions that actually arise.
1. Risk tier assignment
Recommends: the first line, through the intake questionnaire.
Decides: the second line.
Consulted: product and legal where the classification is contested.
Tier assignment must sit with the second line, because a self-assigned tier determines the intensity of the review the assignor will subsequently face.
2. Deployment approval
This should differ by tier, and the differentiation is the whole point of tiering.
Standard tier: first-line self-attestation, sampled by the second line. The second line does not review each one; it samples to confirm the attestation means something.
Elevated tier:second-line review and sign-off, consulting privacy and security where triggered.
Critical tier: the risk committee decides, on a joint recommendation from the first line and the AI risk function, with legal, compliance, security, privacy, and responsible AI consulted.
3. Risk acceptance
Recommends: the accountable business executive.
Decides: the chief risk officer or the risk committee, with a mandatory expiry date.
Consulted:AI risk and legal.
The second line owns the process for risk acceptance but should not be the body that grants it: accepting risk on the organization's behalf is an executive act, not a control's function.
4. Third-party model or vendor onboarding
Recommends:procurement with the first line.
Decides: AI risk, security, and privacy jointly.
Consulted: legal and the business owner.
Joint decision rights are appropriate here precisely because the three assessments test different things and none is sufficient alone.
5. Definition of material change requiring re-review
Recommends and decides:the second line, consulting the engineering lead.
This is a quietly critical decision right. If the first line defines what counts as a material change, the definition will narrow over time under delivery pressure, and systems will drift away from their approved profile without ever formally changing.
6. Escalation of an open critical issue
Recommends: the second line.
Decides: the risk committee, and then the enterprise risk committee if unresolved.
Informed:internal audit.
The right to escalate must be unobstructed and must not require the agreement of the party being escalated about.
Governance Forums
Decision rights need bodies to exercise them. Three forums, at different cadences, cover the work, and the design principle that matters most is that they should attach to existing governance rather than replacing it.
1. The working group: monthly, working level
Membership is working-level leads from AI engineering, product, data, legal, compliance, security, privacy, and responsible AI. Its mandate is tier disputes, framework changes, emerging issues, and pre-reads for the committee.
This is where the real work happens. Most tier disagreements are resolved here on the technical merits, without executive involvement. Afunction whose disputes routinely reach the committee has a working group that is not functioning, and it will burn executive attention on questions that should never have travelled that far.
2. The risk committee: quarterly, executive
Membership is executive sponsors from technology, product, legal, and compliance, chaired by or reporting to the chief risk officer. Its mandate is critical-tier approvals, risk acceptances, aggregate risk posture, resourcing, and escalation.
The committee's value depends almost entirely on the quality of the working group beneath it. Items should arrive with the technical disagreement already resolved and a clear recommendation attached, so that the committee decides rather than deliberates.
3. The existing enterprise risk committee, as scheduled
AI risk should appear as a standing agenda item on the governance structure the organization already has, rather than as a parallel tree. This point deserves more weight than it usually receives.
A separate AI governance hierarchy looks like seriousness and behaves like isolation.It competes for the same executive attention, produces a second set of reporting nobody reconciles, and, most damaging, signals that AI risk is a specialist concern rather than an enterprise one. The objective is for AI risk to become an ordinary category of risk reported through ordinary channels. Building a shadow governance tree makes that harder, not easier.
Design Principles for the Operating Model
Name a person, not a function, for every decision. Functions do not decide; people do. A matrix that assigns a decision to a department has deferred the question.
Separate who recommends from who decides. Collapsing them is how self-approval enters a framework without anyone intending it.
Make the escalation path unobstructed. If escalation requires the agreement of the party being escalated about, there is no escalation path.
Write down what each line does not own. Role creep is quiet, well-intentioned, and only visible against an explicit boundary.
Attach to existing governance. A standing item on a functioning committee beats a new committee with perfect membership.
Agree the seams with named counterparts before publishing. An operating model circulated without agreement is a territorial claim.
Revisit decision rights after two quarters. The first version will be wrong in ways only operation reveals: usually a decision assigned too high, creating a bottleneck, or too low, creating a self-approval.
Conclusion
With ownership, decision rights, and forums established, the remaining question is how to build the thing in practice: how to turn a framework on paper into a functioning program, in what order, and on what timeline. That is the subject of the final article in this series.
Explore more: Start Here · Topics · Archive · About