Marcus Delacroix manages a nine-person customer support team at a regional insurance company. He had found an AI tool that could read incoming support tickets and write a clean two-line summary at the top of each one, the kind of thing that would save each agent a few minutes per ticket. He was ready to roll it out on a Monday. Then a colleague asked him a simple question that stopped him cold: "Did Security clear it? What about the customer data in those tickets?" Marcus did not know. He had no idea who owned that decision, what the approval process looked like, or how long it would take. He shelved the launch, and over the next three weeks he learned how to move a new AI use case through his company's governance process without either breaking the rules or stalling out. This lesson is what he learned.

What This Lesson Covers

Governance is the set of policies, approval steps, and oversight that an organization puts in place to make sure AI is used safely and responsibly. Think of it as the guardrails on a mountain road. They are not there to slow you down for its own sake. They are there so you can drive the road at all.

This lesson is written for a manager operating inside a governance framework, not for the executive who sets it. You are not writing company-wide AI policy. You are the person who has a real use case, a real tool, and a real team, and who needs to get a yes from the right people without becoming the cautionary tale in next quarter's compliance review. You will learn how to read your organization's governance maturity, who owns which decision, how to take a use case through an approval workflow, how to work across functions, how to contribute to the policy itself rather than only obeying it, when to escalate, and how to stay compliant while still moving.

What a Governance Framework Is Actually Made Of

Before Marcus could navigate anything, he had to know what he was navigating. Every AI governance framework, however formal or informal, is built from the same six parts, and being able to name them is what turns a vague sense of "there are rules somewhere" into a map you can act on.

• Policy. The rules about AI use itself: which tools are approved, what you may and may not put into them, what counts as acceptable use.
• Approval processes. The steps required to get permission for something new, usually a request, a review, and a decision.
• Standards. The bar the work has to clear: quality, fairness, compliance, and disclosure.
• Oversight. How compliance is monitored and enforced once something is approved, rather than only at the moment of approval.
• Escalation. The path by which issues get raised and addressed when something falls outside the rules or the rules do not cover it.
• Governance bodies. The people who actually decide. Sometimes a standing committee, sometimes a single senior technology or security leader, sometimes both depending on the size of the request.

When Marcus wrote these six headings on a page and filled in what he could find for each, he discovered that his gaps were not in policy, which was published and clear, but in escalation and oversight, where he genuinely did not know who to call. That gap, not the tool, was his real risk.

Why Working With Governance Pays

Managers often experience governance as a tax on their time, which is why so many quietly route around it. The managers who invest in understanding it get a set of advantages that compound. They get approvals faster, because they know the criteria and can present a case that answers the criteria. They shape better policy, because they are in the conversation rather than complaining about its output. They maintain their innovation pace, because knowing the constraints tells you exactly how much room you have to move inside them. They reduce their own exposure to risk and compliance problems, because governance thinking is built into how they design the work rather than bolted on afterward. And they build organizational credibility, becoming known as a responsible steward rather than a rogue operator.

The alternative is not neutral. Managers who resist governance or work around it create real damage: security exposure, compliance violations, and a lack of coordination that leaves three teams solving the same problem three incompatible ways. Managers who navigate it well accelerate adoption while keeping the organization safe, which is the only version of speed that lasts.

Reading Your Organization's Governance Maturity

Before you can navigate governance, you have to know what kind of governance you are dealing with. Organizations sit at very different points on a maturity scale, and the right move at one level is the wrong move at another. Here is a simple five-level model.

• Level 1, No governance. There is no policy and no approval process. People adopt tools on their own. This feels fast, but it is the riskiest state, because nobody is checking for data leaks, compliance gaps, or unfair outputs.
• Level 2, Emerging governance. Basic rules are forming. There may be a short approved-tools list and a rough process for clearing something new. Monitoring is light.
• Level 3, Defined governance. There are clear policies, a structured intake-and-review process, named owners for security and privacy decisions, and regular oversight. Most mid-size organizations that take AI seriously land here.
• Level 4, Managed governance. Governance is tied to business strategy. There is proactive risk classification, periodic audits, an incident-response plan, and a standing review body.
• Level 5, Optimized governance. The framework continuously improves itself based on what the organization learns. Policy evolves on a schedule, not just after an incident.

Each level is appropriate for a different stage of adoption, and that is the part managers miss. Having no formal governance is defensible only while an organization is doing early-stage experimentation with nothing sensitive at stake. Emerging governance, with tool evaluation and approval before purchase plus some monitoring of use, is what an organization needs as it moves from pilot to broader adoption. The defined and managed levels, with structured approval, regular oversight, a community of practice, and explicit risk assessment and mitigation, are what an organization with significant AI use requires. Continuous policy evolution, regular audits, and incident-response plans belong to enterprises running AI extensively. If your organization's maturity is a level behind its actual usage, that gap is itself a governance risk worth naming out loud.

Marcus spent an afternoon figuring out where his company sat. He found a published AI policy, an approved-tools list, and an intake form for new requests, but no audit schedule and no incident-response plan. That put his organization solidly at Level 3. Knowing that mattered: at Level 3, the path is to use the formal intake process, not to improvise a workaround and not to wait for a process that does not yet exist.

The single most useful thing a manager can do in their first month is build a one-page map of their own organization's AI governance: who owns what, what the process is, and what gets monitored. Most managers never do this, which is why most approval requests stall.

Who Owns What

When a new AI use case touches the organization, several functions have a legitimate stake. A manager who knows which function cares about which question can prepare answers in advance instead of getting ambushed in a review meeting.

• Legal cares about contracts, liability, intellectual property, and disclosure. Do we have the right to feed this data into this vendor's tool? Do we need to tell customers AI was involved?
• Security cares about where data goes and who can reach it. Is the connection encrypted? Is access controlled? Is there an audit trail? Does the vendor meet our security bar?
• Data and Privacy cares about personal information. Whose data is this? Is processing it allowed under our privacy commitments and applicable regulation? How long is it retained?
• An AI review board or committee is the body that weighs the whole picture, risk versus benefit, and grants or denies approval. At Level 3 and above, this group usually makes the final call for anything above the lowest risk tier.
• You, the manager, own the business case, the day-to-day use, and the accountability for how your team uses the tool once it is approved.

Understanding the Constraints, Then Working Inside Them

Navigating governance is a loop of four moves, and skipping any one of them is where managers get into trouble.

The first move is to understand the constraints. Which tools are already approved, so you may not need a request at all? What approval process applies to what you want to do? What standards must the work meet once it is running? What is monitored, and how? Marcus answered all four before he wrote a single word of his request, and two of the answers changed his plan.

The second move is to work inside those constraints rather than around them. Use the approved tools where an approved tool will do the job. Follow the approval process as it is written, not as you wish it were. Meet the standards that apply to your output. Participate in monitoring rather than treating it as surveillance, because the monitoring data is also your evidence that the thing is working.

The third move is to contribute, which we will come back to in its own right, because it is the move managers most often skip.

The fourth move is to know when to escalate: a novel use case the policy does not address, a potential fairness or compliance issue, a request for an exception, or a governance concern that genuinely needs attention above your level. Everything else you resolve locally.

Risk Classification: The Move That Sets Everything Else

Most governance processes route a request based on its risk tier, so classifying your use case correctly is the first real decision. A rough three-tier model works for most managers.

• Low risk: internal-only, no personal or sensitive data, a human reviews every output, and a mistake is easy to catch and cheap to fix. Example: brainstorming internal meeting agendas. These often need only a logged notification, not a full review.
• Medium risk: touches customer data or feeds work that customers eventually see, but a human still reviews before anything goes out. Example: summarizing support tickets that contain customer names and policy details. These need a real review, usually by Security and Privacy at minimum.
• High risk: automated decisions that affect people, sensitive or regulated data, or output that reaches customers without a human check. Example: AI that decides which claims get flagged for denial. These get the full review board treatment and the most scrutiny.

Marcus classified his ticket-summary tool as medium risk. It read real customer data, which ruled out low risk, but every summary sat inside a ticket that an agent read anyway, so no AI output reached a customer unreviewed. Naming the tier honestly is what kept his request credible. Managers who undersell risk to move faster get caught, and then every future request from them is treated with suspicion.

The Approval Workflow, Step by Step

Once you know your maturity level, your stakeholders, and your risk tier, the workflow itself is fairly mechanical. Here is the path Marcus followed.

1. Understand the criteria. He pulled the intake form and read what the review board actually evaluates: security posture, data handling, cost, capability, and compliance. Knowing the rubric in advance let him write to it.
2. Build the business case. Problem, solution, and impact in plain numbers. Agents spent about four minutes per ticket orienting themselves; the tool would cut that to roughly one minute; at 1,200 tickets a week that is an estimated 60 hours of agent time returned monthly.
3. Document risk and mitigation. For each thing that could go wrong, he named the control. Data exposure was mitigated by the vendor's enterprise plan with a signed data-processing agreement. A wrong summary was mitigated by the agent reading the full ticket before acting.
4. Map data handling. Where does the data go, is it encrypted in transit and at rest, who can reach it, how long is it kept. He answered these before anyone asked.
5. Submit and route. He filed the intake request and, because it was medium risk, it routed to Security and Privacy for review before the board's sign-off.
6. Respond to feedback fast. Security asked one question about retention. He answered the same day. Speed here signals that you are a serious, responsive partner, which makes the next request easier.
7. Execute as approved and report back. He rolled out exactly what he proposed and sent the board a short results note at 30 days. That report is what builds the credibility that gets future requests approved faster.

Anticipating the Questions Before They Are Asked

A request that survives contact with a review board is one where the reviewers' questions have already been answered on the page. There are five that come up almost every time, and Marcus wrote a short paragraph on each before submitting.

• Security. Is the data encrypted? Is access controlled? Is there an audit trail of who used what?
• Compliance. Does this meet our own standards and the external requirements we operate under?
• Cost. Is it inside an existing budget, and is the return clear enough to justify the spend?
• Risk. What is the genuine worst case, and what specifically stops it from happening?
• Scale. If this works and we want it in three more teams, does the tool, the licence, and the process hold up?

A complete request also covers two things managers routinely forget. The first is team readiness: is the team actually prepared to use this well, and what training and support will they get? A board that hears "four hours of hands-on training plus a named person to ask" is far more comfortable than one that hears nothing about people at all. The second is the implementation plan and the metrics that go with it. Marcus proposed a phased rollout, setup and training in the first two weeks, a monitored pilot with three agents in weeks three and four, then full team adoption from week five, and he committed to reporting four numbers: handling time against the four-minute baseline, adoption across the team, quality holding steady, and spend against budget. Proposing your own monitoring is one of the strongest signals of good faith a manager can send.

When feedback comes back, answer it in the reviewer's own terms. A security concern is answered with the security plan, a cost concern with the return, a risk concern with the specific controls, and a request for clarification with a prompt, plain reply. Then, once approved, do exactly what you said you would do, report the metrics you promised, and escalate anything that emerges. That follow-through is not administrative housekeeping; it is how you build the credibility that makes your next request easy.

Worked Example: A RACI for the Ticket-Summary Approval

The piece managers most often get wrong is involving the right people in the right way. Too few stakeholders and the request gets blocked late; too many and it drowns in meetings. A RACI chart fixes this. RACI assigns four roles to every task: Responsible (does the work), Accountable (owns the outcome and makes the final call, exactly one person per row), Consulted (gives input before the decision), and Informed (told after the decision).

Here is how Marcus mapped his approval across its main steps.

• Write the business case and intake request. Responsible: Marcus. Accountable: Marcus. Consulted: his team lead. Informed: his director.
• Security review of the vendor and data flow. Responsible: the Security analyst. Accountable: the Security manager. Consulted: Marcus and the vendor contact. Informed: the review board.
• Privacy and data-handling sign-off. Responsible: the Privacy officer. Accountable: the Privacy officer. Consulted: Marcus and Legal. Informed: the review board.
• Final approval decision. Responsible: the AI review board chair. Accountable: the AI review board chair. Consulted: Security, Privacy, Marcus. Informed: Marcus's director and the IT procurement team.
• Rollout and 30-day results report. Responsible: Marcus. Accountable: Marcus. Consulted: his team lead. Informed: the review board.

Notice that every row has exactly one Accountable owner. That is the discipline that makes RACI work. When Marcus walked into the review meeting, he could say "Security and Privacy have signed off; the only open decision is yours," which turned a vague discussion into a clean yes. The timeline ran 18 calendar days from intake to approval: 5 days for Security, 6 for Privacy running partly in parallel, and the rest for scheduling the board. The documentation he produced, a one-page business case, a risk-and-mitigation table, a data-flow description, and the RACI, became a reusable template for the next two requests his team filed.

A Second Request: Coaching a Peer Through the Same Process

Two months later a sales manager down the hall asked Marcus for help with a request of her own, and walking her through it is a good way to see the shape of a strong submission in a different context.

Her business case was tight. The problem was that writing a proposal took four to six hours per deal and was bottlenecking the sales cycle. The solution was an AI-assisted drafting step to bring that down to two or three hours. The impact was roughly forty percent faster proposals, returning that time to customer strategy work. The return paid back the cost within about three months on time savings alone.

Her tool evaluation ran the candidate against the organization's own published criteria rather than against a vendor brochure: capability, where the writing quality and the ability to customize were strong; security, where an enterprise plan with proper data-privacy terms was available; cost, at roughly three hundred dollars a month for the whole sales team; integration, since it connected to the CRM the team already lived in; and compliance, where the vendor could supply the data agreement and certifications the policy required.

Her risk assessment named three risks and paired each with a control. AI might generate inappropriate content, mitigated by the rep reviewing every output before it is sent. Customers might be uneasy about AI-generated proposals, mitigated by disclosing honestly if asked and by the quality bar not moving. The output might contain outdated information, mitigated by the rep remaining responsible for accuracy, backed by spot checks.

Her implementation ran in three phases, setup and training, then a pilot with three reps under monitoring, then full adoption. Her success metrics were concrete: proposal time from about four and a half hours to a target of two and a half, full team adoption by week four, no decline in win rates, and spend tracked against budget. She closed the request by stating plainly how it met the governance requirements: the tool meets the security bar, the data handling complies with policy, the quality standards are met, and the implementation includes its own monitoring. She got a yes.

Working Across Functions Without Friction

Approval is a cross-functional act, and the manager is the connective tissue. A few habits make it smoother. Speak each function's language: lead with data handling and audit trails for Security, with consent and retention for Privacy, with liability and disclosure for Legal. Bring answers, not just questions; a reviewer who receives a complete data-flow diagram moves faster than one who has to drag it out of you. And involve governance early rather than presenting a finished decision, because a review board that helped shape your safeguards is far more likely to approve them.

Contributing to Governance, Not Just Complying With It

Sooner or later someone will ask for your perspective on a draft policy or standard. Most managers treat that invitation as an administrative chore. It is the single highest-leverage moment you get, because policy written without frontline input becomes policy that frontline people quietly ignore.

Start by understanding what the drafters are trying to accomplish. Which risks are they trying to mitigate? What compliance obligation are they trying to satisfy? What consistency across teams are they trying to achieve? Feedback that ignores their actual goal reads as resistance, however reasonable it is.

Then give grounded feedback rather than opinion. What has genuinely worked in your team's experience? Which parts of the draft are practical and which are bureaucratic? What would actually prevent the problem they are worried about, and what would be so restrictive that people route around it? Share what you have learned: here is what we found out about quality standards, here is how we are monitoring for fairness, here is where our team needed more support than we expected. Suggest improvements concretely, naming the standard that is good and the one that is too tight and why. And advocate for the team perspective explicitly, because you are the only person in the conversation who can say what compliance will actually cost the people doing the work.

When Marcus was asked to comment on a proposed standard reading "all customer-facing AI output is reviewed for accuracy before use," he responded with something more useful than approval. He agreed with the intent and said so. Then he raised four honest questions. Should the same standard apply to internal AI use, or should internal and customer-facing work have different bars? Who performs the review, and how much reviewer time is reasonable? How does the standard survive genuinely high-volume work? And what happens when a reviewer is unsure?

Each question came with a suggestion. Set different standards for customer-facing and internal use. Adopt risk-based review, where high-risk output is fully reviewed and low-risk output is sampled. Build in an efficiency mechanism for routine cases so the standard does not collapse under volume. Add an explicit escalation path when the reviewer is uncertain. He even proposed replacement wording: customer-facing AI output is reviewed for accuracy, with the level of review depending on risk, high-risk items fully reviewed and routine items spot-checked, and reviewers escalating to a supervisor when unsure. His rationale was one sentence: this keeps the quality bar while staying practical at volume. The standard shipped close to his wording, which meant the policy was now informed by what actually happens on a support floor.

Escalation: Knowing When to Raise Your Hand

Escalation is for genuine governance issues, not for everything and not for nothing. Raise it up the chain when you hit a novel use case the policy does not cover, a possible fairness or compliance problem, a request for an exception to policy, or a real risk that needs attention beyond your authority. Do not escalate routine questions you can resolve locally; a review body that gets flooded with small things starts ignoring escalations, and then the one that matters gets missed too.

Midway through his rollout, Marcus noticed the summaries were flagging tickets from one customer segment as "complex" far more often than the historical baseline, around 70 percent versus a long-run 40 percent. That is exactly the kind of thing to escalate: a possible fairness issue with real evidence. He wrote a short report, the pattern, the data, his initial read on whether it was real bias or a legitimate signal, and a recommendation, and sent it to the review board. They investigated, traced it to a quirk in how the tool weighted certain policy codes, and adjusted. The process worked because he surfaced the issue instead of hiding it.

The report itself followed a shape worth copying. First, understand the issue before you raise it: what exactly is the pattern, is it real and verified rather than a one-week anomaly, and how serious is it, meaning does it harm anyone or breach policy? Second, work out the escalation path: who needs to know, the review board, compliance, or risk, and whether the route is a formal report or a conversation. Third, write the report in five parts: the issue stated plainly, the evidence behind it, why it matters, your initial assessment of the cause including the honest possibility that the pattern is legitimate rather than biased, and your recommended next step. Fourth, escalate to the right person with the evidence attached and the recommendation stated rather than implied.

Fifth, and most neglected, follow up. What is actually being done? When will it be resolved? How will we prevent this class of issue from recurring, for example by monitoring categorization across all customer segments from now on and running a periodic fairness check rather than waiting for the next complaint? And what is the communication plan for the people affected? An escalation that you never follow up on teaches the organization that escalations do not matter.

Holding Governance and Innovation Together

There is a genuine tension here and pretending otherwise helps nobody. Governance exists to reduce risk and ensure compliance. Innovation requires moving fast and trying things that have not been tried. Both are necessary. Governance without innovation is safe and stagnant. Innovation without governance is fast and dangerous. Your job is not to pick a side but to hold both.

Five moves make that possible in practice. Start with a pilot rather than a full rollout, because a small, bounded trial is lower risk and demonstrates the concept with real evidence instead of argument. Involve the governance body early, so they understand what you are trying to do while the design is still soft enough to shape. Propose clear safeguards yourself, quality checks, monitoring, an escalation route, rather than waiting to have them imposed. Show explicitly how you will manage the risk, not just that you have noticed it. And be transparent about the challenges, including the ones that make your case weaker, because a manager who volunteers the hard parts is believed about the good parts.

Four Ways Managers Undermine Themselves

Four failure patterns account for most of the trouble managers get into with governance, and all four are avoidable.

Working around governance. You skip the approval process, use an unapproved tool quietly, or find a technical workaround. It fails for the obvious reason, risk and compliance exposure, and for a less obvious one: when it is discovered, and it is always eventually discovered, your credibility is gone and every future request you file starts from suspicion. If the process is genuinely too restrictive, argue for changing it. Do not evade it.

Complying but never contributing. You follow every rule and never tell anyone whether the rules are working. Governance then drifts away from reality, policies never improve, and the people writing them have no idea what they are costing. Compliance and contribution belong together.

Waiting for a perfect approval process. The governance process is not defined yet, so you do nothing. Opportunities pass and your team's adoption stalls while you wait for a form that may never arrive. The right move at low maturity is an interim approach: proceed carefully, escalate the decisions that genuinely need a decision-maker, document what you did and why, and help build toward the formal process.

Escalating everything. You send every question to the governance body, which overwhelms them and trains them to treat your name as noise. The escalation channel then fails at exactly the moment you need it. Escalate real issues; solve routine ones locally.

Human Judgment Checkpoints

Governance work rewards a pause before action. Five checkpoints are worth running through whenever you are about to move.

Do you actually understand the framework, meaning do you know what approval and oversight this specific action requires, or are you assuming? Are you proposing thoughtfully, having done the work to build a real case, or are you asking the governance body to do your thinking for you? Are you being patient with process, having built realistic approval time into your project timeline rather than treating the review as an unexpected delay? Is this a real governance issue, or are you escalating because you disagree with a decision that went against you? And are you building credibility, so that over time this organization sees you as a responsible steward rather than a risk to be managed?

Responsible AI Considerations

Three considerations sit underneath everything in this lesson.

The first is that governance protects fairness and safety, and that is precisely why circumventing it is not a clever shortcut but a genuine harm. The checks that feel most bureaucratic are often the ones standing between an AI system and a group of people it would quietly disadvantage. Embrace the parts of governance that address those concerns rather than negotiating them down.

The second is to escalate real risks rather than hiding them. If you see a fairness or safety problem, surface it, and build a team culture where your people surface them to you. Issues that are raised early are cheap; issues that surface through a complaint are not.

The third is that governance itself should improve as the organization learns. Provide feedback, suggest improvements, and take part in the evolution when you are invited. A framework that never changes is a framework that has stopped matching reality.

Staying Compliant While Still Moving

The deepest skill here is holding two things at once: the discipline to respect the guardrails and the momentum to keep delivering. Managers who treat governance as the enemy work around it, and when that is discovered, their credibility is gone for good. Managers who treat governance as a partner build a track record, and a track record is what gets the next yes faster. Marcus's first approval took 18 days. His second, using the same template and the trust he had banked, took 6. That acceleration is the real payoff of navigating governance well rather than fighting it.

Practice and Reflection

Five exercises will turn this lesson into something your organization can feel. Work through them with your own context in front of you.

Map your governance framework. Document, in one page, what your organization's AI governance actually is: the structure and who decides, which tools are approved, what approval process a new tool requires, which standards must be met across quality, security, compliance, and fairness, what is monitored and how, and what the escalation path is. If you cannot fill in a box, that gap is your first task.

Prepare a real approval request. Take a tool you genuinely want and write the full submission: the business case with problem, solution, and impact; the tool evaluated against your organization's criteria; a risk assessment naming what could go wrong; the mitigation for each risk; an implementation plan with phases; and the success metrics you will report on. Write it as if you were submitting it tomorrow.

Draft governance feedback. Pick a policy or standard you operate under. Name what works about it, what is problematic in practice, what would improve it, and what you would recommend. Write it as feedback you would actually send, with proposed wording rather than complaints.

Build an escalation plan for your team. Decide in advance what would trigger an escalation, whether a fairness issue, a security issue, or a policy violation. Name who you would escalate to, how you would do it, and what information you would bring. Document it while you are calm, so you are not designing it during an incident.

Assess your maturity honestly. Place your organization on the maturity scale, from no formal governance through emerging, defined, managed, and optimized. Then answer two harder questions: where should you be given how much AI you are actually running, and what specifically would it take to get there?

Related Lessons

Two lessons sit immediately alongside this one and are worth reading in sequence with it.

Coordinating AI Use Across Teams covers the horizontal problem that governance solves vertically. Where this lesson is about getting a decision from the people who own approval, that one is about keeping several teams' AI work coherent with each other, which is exactly the coordination that weak governance fails to provide.

Stakeholder Communication About AI is the skill that makes everything here land. A strong approval request, a piece of policy feedback, and an escalation report are all acts of tailored communication with a specific audience and a specific concern, and the framing techniques in that lesson are what turn a technically correct submission into one that gets a yes.

Key Takeaways

• Map your governance before you need it. Build a one-page picture of your organization's maturity level, who owns security, privacy, and legal decisions, the intake process, and what gets monitored. This map turns a stalled request into a routed one.
• Classify risk honestly. The risk tier, low, medium, or high, determines the path. Underselling risk to move faster destroys the trust that makes every future request easier.
• Use a RACI to involve the right people the right way. One Accountable owner per step, the right Consulted parties before each decision, and the rest Informed after. Walking into a review with the prerequisites already signed off turns a debate into a clean approval.
• Prepare a strong case rather than a request. Answer the security, compliance, cost, risk, and scale questions in advance, cover team readiness and your own monitoring plan, and governance will respond to the work you have already done.
• Speak each function's language and bring answers. Lead with data handling for Security, consent and retention for Privacy, liability and disclosure for Legal, and arrive with complete documentation, not open questions.
• Comply and contribute. Feedback grounded in what your team has actually experienced is what keeps policy practical, and shaping the standard is far more effective than resisting it later.
• Escalate real issues, not noise. Raise novel use cases, fairness or compliance concerns, and exception requests with evidence and a recommendation, then follow up until they are resolved. Solve routine questions locally so the escalation channel stays credible.
• Treat governance as a partner, not a roadblock. Following through on commitments and reporting results builds the track record that gets later requests approved in days instead of weeks.