The Question Everyone’s Actually Asking
I’ve seen this story play out dozens of times. A company builds an AI system. It works beautifully in the demo. Then it goes to production, and suddenly there’s confusion about who owns what.
The data scientists built the model. The platform engineers built the infrastructure. The ops team monitors it. And when something breaks at 2 a.m., nobody quite knows who’s responsible for fixing it.
So the natural question comes up: do we need a dedicated MLOps team to bridge this gap?
The honest answer is more complicated than yes or no. What actually matters is accountability. And I’ve learned that accountability doesn’t come from creating more teams. It comes from making sure one team owns the entire journey from architecture through production.
Why Separate MLOps Teams Create Problems
I’ve watched teams spend months building beautiful data pipelines, then discover the data changed. I’ve seen vector databases deployed without any thought to data freshness, permissions, or accuracy. I’ve watched RAG systems generate confident answers from retrieved documents that were incomplete or outdated.
Here’s what usually happens: the data science team builds something. They hand it off to the MLOps team. The MLOps team deploys it. The ops team monitors it. And when the model starts degrading in production, it’s not clear who should have caught it first.
Was it a data quality problem? That’s the data team’s job. Was it a deployment issue? That’s MLOps. Was it infrastructure? That’s ops. By the time you’ve figured out whose responsibility it is, the problem has already cost you money.
The real issue isn’t that you need more specialists. It’s that you need someone accountable for the entire pipeline working together. Separate teams create handoff points. Handoff points create blind spots.
What Actually Works: Unified Accountability
Here’s what I’ve seen work. One team, not a handoff chain. They own the business outcome from the moment you ask the question “what do we want to achieve?” all the way through to “is it still working in production?”
This doesn’t mean everyone on the team does everything. It means everyone on the team understands the full picture. The person who deployed the model knows why the data pipeline was built that way. The person who monitors it knows what the model is supposed to do. The person who maintains the data knows how it’s being used.
When something breaks, they don’t need to schedule a meeting to figure out whose problem it is. They already know, because they’ve been working together the whole time.
I’ve seen teams where one person understands the entire system, and that’s a disaster waiting to happen. But I’ve also seen teams where nobody understands the whole picture, and that’s worse.
In my experience, teams usually end up with a tiered approach, and it’s the right one. You have people who specialize in different areas. But they’re all part of the same team, all accountable for the same outcome, all working from the same roadmap.
The Architecture Question
This starts before you write any code. Before you choose your vector database or your model serving framework or your monitoring stack.
You need to know what you’re actually trying to achieve. Not the technology goal. The business goal. Are you trying to speed up a decision process? Are you trying to unlock a new revenue stream?
Then you work backwards. What does the system need to do to achieve that? What data does it need? How fresh does that data need to be? What happens if it gives the wrong answer? What’s the cost of that?
Once you’ve answered those questions, you can design the infrastructure. And the person designing it needs to understand that they’re not just building something that works. They’re building something that the team can operate, monitor, and improve together.
Where I’ve Seen the Most Creative Chaos
Access control. Seriously.
I’ve seen teams where anyone with database access could retrain the model, which meant that a data analyst could accidentally (or intentionally) change the model’s behaviour without anyone knowing. I’ve seen other teams where only one person could deploy models, which meant that a single person leaving the company could paralyse the entire operation. I’ve seen teams paralysed by the complexity of access control itself, where every change requires five approvals and takes three weeks.
This is where unified accountability actually matters most. You need to decide: who can do what, and why? And that decision needs to be made by people who understand the full picture. Not just the security team. Not just the data team. The whole team together.
Because the wrong access control doesn’t just create security problems. It creates operational problems. It slows down deployments. It prevents people from doing their jobs. It creates single points of failure.
Monitoring and Observability
This sounds obvious, but I’ve seen teams with sophisticated monitoring systems where nobody actually knows what the alerts mean.
You can have perfect metrics. But if the person on call doesn’t understand what they’re looking at, those metrics are just noise.
Here’s what actually works: the team that built the system defines what matters. Not just technical metrics like latency and error rate. Business metrics. Is the model still achieving what it was supposed to achieve? Is the data still fresh enough? Are we still making money?
Then you build monitoring around those metrics. And you make sure everyone on the team understands what each alert means and what to do about it.
The Data Freshness Problem
I’ve seen retrieval systems where the documents were weeks out of date, and nobody noticed until a customer asked why the system was giving them outdated information. I’ve seen vector databases where nobody could explain how documents got into them. I’ve seen systems that worked fine with 100 requests a day completely collapse at 1,000.
These aren’t technical problems. Well, they are. But they’re really accountability problems.
When one team owns the entire pipeline, they can’t ignore data freshness because it’s “not their job.” They can’t deploy without thinking about scale because they’re the ones who’ll get paged when it breaks. They can’t build a vector database without thinking about permissions because they’re the ones who’ll have to explain to compliance why they can’t audit it.
How to Know If You Need to Reorganize
Ask yourself these questions.
Can you trace where the data came from? Do you know how often it gets updated? Do you know if it’s accurate?
Can you explain why the model gives the answer it gives? Can you point to the data that led to that answer? Can you reproduce it?
When something breaks in production, do you know who to call? Do they know what to do? Do they have the access they need to fix it?
If you’re answering “I don’t know” or “it depends” or “we’d have to ask someone else,” then you probably have an accountability problem. Not necessarily a team structure problem. An accountability problem.
Sometimes that means reorganizing. Sometimes it means better communication. Sometimes it means clearer documentation. But it always means making sure someone owns the whole thing.
When to Bring in Help
If you’re not sure what your current structure is doing well and where it’s breaking down, that’s worth understanding before you make changes.
We can audit what you have, identify the gaps between what you’re measuring and what actually matters, and build a roadmap to fix it. We talk to the people who built the system, the people who maintain it, the people who depend on it, and the people who own the business outcome.
Or if you want to move faster, we offer a Diagnostic Sprint. Two weeks to a clear picture of what you have, what you need, and what the business case looks like.
FAQ
Do we need a separate MLOps team or not?
What you actually need is clear accountability. That might look like a separate MLOps team in a large organization. It might look like one person wearing multiple hats in a smaller one. What matters is that someone owns the whole pipeline and has the authority to make decisions about it.
What if we already have separate teams?
That’s fine. The question is whether they’re working together as one team with shared accountability, or whether they’re operating in silos. The structure matters less than the alignment.
How do we know if our current structure is working?
Ask the questions I mentioned above. If you can’t answer them, you have a problem. If you can answer them but it takes a week to get the answer, you have a problem. If different people give you different answers, you definitely have a problem.
What’s the biggest mistake teams make?
Treating MLOps as a separate concern instead of a core part of how the team works. You can’t hand off a model to an ops team and expect them to maintain it if they didn’t help build it. You can’t deploy something to production without thinking about how it’ll be operated. These things need to be part of the same conversation.
Let’s Talk About Your Situation
Every organization is different. What works for a 10-person startup doesn’t work for a 1,000-person enterprise. What works for a team building internal tools doesn’t work for a team building customer-facing products.
But the principle is the same: someone needs to own the whole thing. And that someone needs to have the visibility, the authority, and the accountability to make it work.
If you’re not sure whether your current structure is serving you well, let’s talk about it. Email us at hello@aartian.com and we’ll get back to you within a day. We can help you figure out what’s working, what’s not, and what to do about it.