I’ve seen this conversation happen at company after company, across industries and company sizes.
Engineering has built an AI feature and wants to ship it. Legal says it needs more review. Product is trying to hit a roadmap deadline that both of them seem to be ignoring.
Nobody is wrong. Everyone is frustrated. The AI sits in limbo while the business opportunity the team was trying to capture moves on.
This dysfunction is one of the most consistent reasons AI governance fails in practice, and it has almost nothing to do with policies or frameworks.
Why These Three Teams Keep Talking Past Each Other
Engineering, legal, and product are each trying to do their jobs well. The problem is their jobs are defined around different success measures that don’t naturally include each other.
Engineering measures success by whether the system works as intended. If the AI performs correctly and the code is clean, the job is done from an engineering perspective. Compliance considerations feel like someone else’s problem, and legal review feels like an obstacle to shipping work that’s technically complete.
Legal measures success by whether the company is protected from liability. Legal teams see risk that engineering doesn’t because they’re thinking about regulatory requirements, litigation exposure, and what happens when things go wrong. From their perspective, shipping before those risks are addressed isn’t progress, it’s recklessness.
Product measures success by whether features ship on schedule and users adopt them. Product managers are accountable to roadmaps and business metrics that legal review timelines don’t account for. They’re stuck trying to satisfy stakeholders with completely different definitions of ready.
None of these definitions of success are wrong. But when teams are optimizing for different outcomes without a shared framework for making decisions together, the result is conflict, delay, and AI governance that exists on paper while shipping decisions happen around it.
How the Dysfunction Plays Out
The most common pattern is legal getting involved too late.
Engineering builds an AI feature. Product schedules it for launch. Legal reviews it before release and identifies compliance issues that require significant changes. Engineering has to go back and rebuild parts of what they thought was finished. The launch is delayed. Everyone is frustrated at legal for slowing things down, even though the problems legal identified were real.
The frustration is misdirected. The problem isn’t that legal raised issues. The problem is that legal raised them after the build was complete, when fixing them required rework instead of incorporating them into the original design.
The second pattern is legal saying no without explaining the actual risk in terms the other teams understand.
Legal identifies a compliance concern and recommends against shipping. Engineering and product don’t understand why, so they push back. Legal digs in. The conversation becomes adversarial rather than collaborative. Either the AI doesn’t ship, and nobody understands why, or it ships over legal’s objection and creates the exact exposure legal was trying to prevent.
Both patterns have the same root cause: teams making decisions without a shared framework for weighing competing priorities.
What Actually Fixes It
After working with companies across telecom, compliance, and now AI governance for nearly 30 years, the fix is consistently the same. Teams that work well together on AI governance have built structures for making decisions together, not structures that route decisions through each team sequentially.
The practical version of this is getting legal involved before the build rather than before the launch. When compliance requirements are part of the design conversation, engineers can build systems that satisfy those requirements from the start. The compliance work happens in parallel with the engineering work instead of after it.
This requires legal teams to show up differently. Instead of reviewing finished work and listing problems, they need to translate compliance requirements into specific design constraints that engineers can actually work with. “This AI system can’t make employment decisions without documented human review” is actionable. “This raises employment law concerns” is not.
It also requires products to build governance checkpoints into the development process rather than treating compliance as a final gate before launch. When governance is part of the process, it doesn’t delay launches. When governance is a separate gate, it always does.
The Decision Rights Problem
Most cross-functional AI conflicts aren’t really about compliance disagreements. They’re about unclear decision rights.
When it’s ambiguous who has final say on whether an AI system is ready to ship, every team with a stake in the decision tries to veto it, which creates gridlock, or the team with the most organizational leverage wins, which doesn’t produce good decisions.
Companies that handle AI governance well have explicit frameworks for how decisions get made when teams disagree. Legal doesn’t have unlimited veto power over shipping decisions. Product doesn’t have unlimited authority to ship over compliance objections. There’s a defined process for escalating disagreements and a defined person with authority to make the call.
Building that structure before a high-stakes disagreement forces the issue produces much better outcomes than building it in the middle of a conflict when everyone’s position is already entrenched.
The Bottom Line
AI governance doesn’t fail because companies lack policies. It fails because the people responsible for building and shipping AI aren’t operating from a shared understanding of what governance requires and who decides when it’s satisfied.
The solution isn’t more documentation. It’s clearer decision-making structures, earlier cross-functional involvement, and legal teams that translate compliance requirements into language engineers can build to.
Companies that get this right ship AI faster, not slower, because they stop spending time on conflicts that a better process would have prevented.
Brian Alexander
Founding Partner, VisionAI+ Consulting Group
Former General Counsel, AI Engineering Firm
Certified ISO 42001 Lead Auditor