I keep running into the same question with most of the clients we work with: who owns AI?
Sometimes the answer is someone in IT. Sometimes it's a committee that has met twice. Sometimes it's a director of AI.
More often, it's the person who got good at ChatGPT and became the in-house expert.
Most of the time, the real answer is that nobody knows.
That used to be fine. It isn't anymore.
This is now a real management issue, bigger than which model is best or which vendor to sign. It comes down to who owns AI.
And the two most common answers are both wrong.
The first wrong answer is to put a central AI team in charge of everything. Every use case routes through them. Every workflow waits in their queue.
It feels responsible. In practice, it becomes a chokepoint.
The people who understand the work sit and wait: the BD team chasing a pitch, the account team buried in client reporting, the associate who knows the matter. A small central group tries to build for departments it doesn't live in. The queue gets longer every week.
The second wrong answer is the opposite. Let everyone build on their own.
The marketing team buys one tool, BD buys another, three people are pasting confidential client material into consumer apps, and nobody can say what's running or where the data goes.
That's sprawl.
You need both. And you need to be clear about who does what.
A central AI team should set the standards and own the security and vendor decisions. It should maintain the shared infrastructure everyone builds on. And it should help build the first few examples, so teams have a working model to copy instead of a blank page.
But the business teams need to own the workflows themselves.
The marketing team should own the marketing workflows. BD should own the BD workflows.
They know where the work is slow. They know what "good" looks like and what a finished output is supposed to be.
A central team can't know that for them and shouldn't try.
If the central team owns every use case, it becomes the chokepoint. If everyone builds alone, you get the sprawl.
You hold both at once: shared standards underneath, business ownership on top.
Now it gets harder.
AI attacks the boundaries on your org chart. A single workflow draws in people from three or four departments at once, over and over.
The work was never as neatly separated as the chart made it look. We drew boxes for marketing, BD, IT, and knowledge management because boxes are easy to manage.
The real work always spilled over the lines. AI just makes that obvious.
A content workflow pulls in marketing, the subject-matter expert, and the compliance reviewer. A pitch workflow runs through BD and whoever owns the CRM. Automate either one and you're standing on three people's turf, which is exactly where the work tends to stall.
So I don't settle that by arguing about who reports to whom. For each workflow, I define four roles instead:
That's a much clearer conversation than trying to redraw the org chart first. You don't need a reorg. Four named people per workflow will do it.
I train marketing and business development teams at a lot of firms. But two of them were different, because I got to speak with the person in charge of AI for the whole firm before the workshop.
At Reed Smith LLP , that was Richard Robbins. At Womble Bond Dickinson (US) LLP, it was Joshua Freeman .
I didn't want to walk into a room and teach a marketing team a stack of workflows that had nothing to do with the tools and guardrails the firm had already put in place. I wanted what I taught to line up with what Rich and Joshua had already built for the entire firm.
When I ran the workshop at Reed Smith, Rich was in the room.
As the team surfaced specific use cases, Rich was right there as an ally. He told them what was already possible inside the firm, which tools they had access to, how his team could help them build the workflows, and what was coming next.
The marketing team wasn't guessing. The person who owned the infrastructure was sitting with them while they figured out what to build on top of it.
At Womble, Joshua wasn't in the room. But the conversation I'd had with him beforehand changed how I ran the session anyway.
I told that team, with full confidence, that if they needed help building a workflow, using a specific tool, or wiring it into their CRM, Joshua would be glad to help. He'd already told me as much.
In both cases, the lesson was identical. The business team owned the workflows.
The central owner, Rich in one case and Joshua in the other, owned the standards and the infrastructure and made himself available as a partner. Neither side was waiting on the other.
And it's exactly as true inside an agency as it's inside a firm. Swap "managing partner" for "agency owner" and "practice group" for "account team." The picture doesn't change.
So say you're a 500-person agency or law firm that wants to get past the policy memo and build AI into how the work happens. This is where I'd start.
First, start with leadership. The executives, the managing partner, and the agency owners need enough hands-on time to see what's possible with these tools.
A vendor demo watched from the back of the room won't do it. They need real time in the tools themselves.
If leadership can't picture what's possible, they can't make good calls about vendors, budgets, or where to begin.
Second, pick two or three teams with painful, repetitive, high-value work. Start narrow. Pick the teams where the pain is obvious and the payoff is concrete.
Third, map one workflow, build one useful skill or agent, and prove it works. Then use that as your internal example, the thing you point to when the rest of the firm asks what an AI workflow looks like.
The usual mistake is rolling AI out broadly before anyone can point to a single concrete workflow that changed.
You announce a platform. You run firm-wide training. Six months later nothing is different, because nobody ever proved the thing worked on real work.
One workflow that visibly changed beats a hundred licenses nobody uses.
So do executives know where the biggest automation wins are?
Usually not.
They know the business pain cold. That part they've got.
Their blind spot is what's easy or hard to do with AI tools.
What they assume is impossible is often a Tuesday. What they expect to be simple needs judgment the tools can't supply.
So instead of asking leaders what to automate, I start with the company's goals. Then I ask where the work is slow, expensive, and either highly repetitive or held up by scarce expertise.
The best AI opportunities share a profile: a clear output, a lot of context-gathering up front, and human judgment at the end.
Think client alerts, competitive intelligence, first-draft pitches, editorial calendars, media tracking. They all fit. The expert still owns the call; the tool does the context-gathering that used to eat the hours.
There's one more boundary to get right: IT.
A marketing or BD team, or honestly any team at an agency, wants to start automating. How do you do that without making IT feel like you bypassed it?
You make IT a design partner rather than the office that says no.
The business team owns the workflow and the definition of success: what it does, what "good" looks like. IT owns access controls, system architecture, and the security review.
Some tools need far more scrutiny than others.
An AI assistant that helps someone write a draft is a completely different proposition from a system that can reach into your databases and client files. Treating every use case as equally risky just makes it harder to approve any of them.
Using AI well is about weighing the upside against the downside. IT is already the resource you have for exactly that.
It's an evolving conversation. You explain the business outcome you're after.
They name the real risks, and together you decide which protocols make sense for your firm.
When that conversation works, IT stops being the brake and becomes part of the build.
Nobody owns it alone.
The central group owns the standards, the security, the vendors, and the shared infrastructure. It also builds the first few examples.
The business teams own the workflows. Every workflow gets a business owner, a technical owner, a risk owner, and an approver.
IT works as a partner throughout.
Forget the reorg. It starts with one workflow that changes how the work gets done. Then the next one.