Every AI Needs a Manager

By now, our AI employee has come a long way. We handed it a job, found it a department to call home, figured out what it should and shouldn’t see, and made sure it didn’t end up as a digital intern with the keys to the kingdom. (That’s tech-speak for not letting the new guy have admin rights.)

So far, things are humming along nicely. Our AI hasn't tried to take over the world or accidentally order 500 pizzas to the office, so I’d call that a win.

Which brings us to the awkward question nobody wants to answer: Who’s actually in charge of this thing?

This is where AI governance gets about as clear as a cup of day-old coffee. Organizations are great at making lists of everyone involved in an AI project: business sponsors, app teams, infrastructure folks, cybersecurity, legal, privacy, procurement, compliance, data owners, and that ever-enthusiastic vendor success manager who loves to start emails with 'Just checking in!'

That’s a lot of cooks in the AI kitchen, and if you’ve ever seen a group project in action, you know the soup can end up a little salty.

But just because everyone’s invited to the party doesn’t mean anyone’s actually sticking around to clean up the mess. In tech, that usually means a lot of finger-pointing and a suspiciously empty conference room when things go sideways.

When AI is treated purely as technology, responsibility tends to follow whatever piece of the platform someone manages. IT owns the application. Security owns the controls. Procurement owns the contract. Legal owns the risk review. The business owns the process. Everyone owns a piece, which works reasonably well until the AI does something unexpected.

Suddenly, figuring out who’s responsible becomes the classic group-project scenario: lots of awkward silences, everyone avoiding eye contact, and someone quietly hoping the problem goes away.

Who approved that connector? Who gave the AI access to those documents? Who changed the prompt? Who decided it could take that action automatically? Who reviewed the output? Who has the authority to shut it down?

Take it from someone who’s been in more than a few incident war rooms: you don't want to start asking those questions when alarms are blaring, and everyone’s already sweating through their shirts.

If AI is going to operate like a worker inside the organization, then every AI needs a manager.

Now, I’m not suggesting we start scheduling monthly performance reviews with Copilot and ask it about its five-year plan. Although, given how fast AI is evolving, its answer might be 'replacing you.'

What I mean is someone needs to step up and own the AI’s job description, what it’s allowed to do, how it behaves, and what comes out the other end. Someone should be able to say, without scanning the room for a scapegoat, 'This AI is ours. We’re on the hook for what it does.'

That ownership begins with the job.

If Finance deploys an AI to analyze invoices, Finance should own the business outcome. If Security deploys an AI to triage alerts, Security should own that process. If Human Resources uses an AI assistant to answer employee-policy questions, HR should own the service being delivered.

IT may operate the platform. Cybersecurity may establish controls. Legal may evaluate contractual and regulatory concerns. Privacy may define data requirements. But none of those groups can decide whether an AI is successfully performing a Finance, HR, Legal, or Customer Support function.

The business owns the job.

The technology teams help make that job safe.

That difference really matters, because if we’re not careful, IT ends up owning every AI just because they know where the admin console is hiding. That’s like saying the infrastructure team owns payroll just because the payroll system happens to live on their servers. Trust me, nobody in IT wants to be responsible for your paycheck.

Nobody wants that.

Especially the infrastructure team.

Things get even trickier when you look at what actually tells the AI what to do. Enter prompts. In plain English, prompts are the instructions, rules, and settings that guide the AI’s behavior. Think of them as the AI’s job description, only instead of being buried in HR paperwork, they’re written in sentences the AI can understand. These aren’t just technical toggles anymore—they’re quickly becoming real business policies, written in everyday language instead of code.

Suppose a security AI is instructed to escalate any alert involving a privileged account automatically. Somebody made that decision. If the prompt is later changed so the AI can automatically close certain alerts, somebody has expanded its authority. If a customer-service AI is told never to approve a refund above a certain amount, somebody established that threshold.

Those are not just prompt-engineering decisions.

They are governance decisions.

Someone needs to own them.

This matters because prompts are sneaky-easy to change. With traditional software, you have to jump through all sorts of hoops: development, testing, change management, reviews, and enough paperwork to make your eyes glaze over. With AI, someone can rewrite a couple of sentences, and suddenly the AI is acting like it’s got a whole new job description.

That is powerful.

Before you know it, 'Who changed the prompt?' will be the new 'Who messed with the firewall rule?' If you’ve ever been in IT, you know that’s never a fun question to answer.

Organizations should be able to answer both.

The same issue applies to connectors. In the previous article, I argued that a connector is really another form of permission. Connecting AI to SharePoint, Salesforce, ServiceNow, GitHub, email, or a database gives it access to something it didn't have before.

Every one of those connections should therefore have an owner and a reason.

If the AI can access SharePoint, who approved which sites? If it can query customer information, who decided which customer data is appropriate? If it can access ServiceNow, can it only read tickets, or can it update them? If someone wants to connect it to HR records, financial data, or source code, who decides whether that is justified?

The answer can’t just be 'the admin had the button and pressed it.' That’s like saying, 'the door was unlocked, so I walked in.' Not exactly a solid business process.

Technical ability isn't the same as business authorization.

Somebody has to be the grown-up in the room who says yes, and actually means it.

And just as importantly, someone has to be brave enough to say no, even when everyone else is excited about the shiny new AI toy.

That may be the harder job.

There’s always a ton of pressure to make AI do more, and do it faster. People see something shiny and immediately start dreaming up what it could do if we just fed it a little more data. It’s like giving a toddler sugar and then wondering why they’re bouncing off the walls.

“What if we connected email?”

“What if it could see Teams?”

“What if it could update the ticket itself?”

“What if it could make the change instead of just recommending it?”

Those questions are perfectly reasonable. They are also requests for additional authority.

Good governance shouldn’t be the place where fun ideas go to die. The goal isn’t to have someone whose only job is to rain on the AI parade. But someone should be able to ask, 'Why does the AI need this?' and get a better answer than 'because it would be really cool.'

'Cool' is not a security model. I checked. It’s not in any of the frameworks.

Ownership also matters when AI output leaves the platform and becomes part of the business. One phrase I expect organizations to hear increasingly often is, “The AI wrote it.”

That sentence should never eliminate accountability.

If an AI drafts a customer communication and the company sends it, the company owns the communication. If AI generates code that goes into production, the organization owns the code. If it creates a risk assessment, financial analysis, legal summary, or security recommendation that influences a business decision, somebody still owns the decision.

AI can’t be the new 'blame the intern' when things go sideways. Trust me, the intern already has enough on their plate.

We can’t blame the AI model every time something goes wrong, any more than a manager can blame Microsoft Word for a terrible memo.

The technology contributed.

A human or a business process still decided to trust the result.

This matters even more because modern AI is fantastic at sounding confident. It can take a wild guess and make it sound like it came from a grizzled expert who’s mildly annoyed you even asked. If you’ve ever met a consultant, you know the type.

Polish creates confidence.

Confidence creates trust.

That trust needs an owner.

Someone has to decide when AI’s work needs a human double-check and when it’s safe just to hit 'send.' The answer depends on the risk. If the AI is suggesting a snazzier title for your PowerPoint, that’s probably fine. If it’s recommending firing someone, moving money, shutting down a service, or tinkering with safety systems, that’s a whole different ballgame—and one you don’t want to play without a referee.

Not every AI decision needs a committee, a task force, and three PowerPoint decks.

But just because the answer pops up fast and looks pretty doesn’t mean we should let the AI make big decisions on its own. Sometimes, speed means you get to the wrong answer faster.

Mistakes are another ownership headache. Every worker messes up sometimes, and AI will too. The real question isn’t if errors happen, but what we do when they do.

If an AI gives a customer incorrect information, who investigates? If it retrieves information that should not have been exposed, who owns the incident? If it makes the wrong recommendation during security triage, who determines why? If it performs an unauthorized action, who has the authority to stop it immediately?

The answer cannot simply be “the AI team.”

That’s the same problem as saying 'the cloud team' or 'the app team.' It points to a group, but doesn’t actually pin down who’s responsible.

The AI should have a business owner. The underlying platform should have a technical owner. Security controls should have control owners. Data should have data owners. The responsibilities can be distributed across the organization, but accountability cannot be invisible.

This will really come into play during audits. If you’ve never been through one, imagine a dentist appointment, but with more spreadsheets.

Eventually, auditors will ask uncomfortable questions about AI.

Auditors have a special talent for asking the questions that make everyone squirm. It’s practically their superpower.

They will want to know who approved the AI, what information it can access, how those permissions are reviewed, who monitors its activity, who approves changes, how results are validated, and what happens when the AI’s responsibilities change.

'Bob set it up during the pilot' is not going to cut it. Sorry, Bob.

Neither is 'We think Marketing owns it.'

Good AI governance should make ownership easy to demonstrate. Someone should be able to explain what the AI does, why it exists, who approved it, what systems it can access, who authorized those permissions, how changes are controlled, and who is responsible for the outcome.

That doesn’t mean every chatbot needs a 37-page governance binder, three committees, and a ceremonial handshake from Enterprise Architecture. Let’s keep things reasonable.

The controls should match the risk.

An AI helping someone rewrite a meeting agenda probably does not need the same governance structure as an agent capable of changing production systems.

But when AI has meaningful access to organizational data or meaningful authority to act, ownership should not be optional.

A manager also decides when a worker is ready for more responsibility.

That idea maps surprisingly well to AI.

An AI might begin by reading information and making recommendations. After it demonstrates reliable performance, someone may want it to create tickets, modify records, send communications, or execute certain actions automatically.

That is a promotion.

The AI is receiving more authority.

Someone should approve it.

Before expanding that authority, the owner should be able to explain why the change is necessary, what evidence shows the AI is ready, what additional risk it introduces, and what happens if the new capability fails.

This is important because AI privilege can grow gradually enough that nobody notices how far it has expanded.

One connector gets added.

Then another.

One action becomes automated.

Then another.

None of the individual changes feel particularly dramatic. Six months later, someone discovers that the AI created to summarize help-desk tickets can now reset accounts, update production records, send external email, and access three departments.

Congratulations. You’ve just promoted your AI intern to Chief Operating Officer, and nobody noticed until it started making executive decisions.

Privilege creep does not stop being privilege creep because the identity happens to be artificial.

Someone needs to watch it.

Good managers also know when to reduce responsibility. If AI performance declines, reduce its authority. If a model update causes unexpected behavior, autonomous actions may need to return to human approval. If a connector creates unexpected risk, remove it. If the system starts producing poor decisions, move it from acting back to recommending while the problem is investigated.

And once an AI has a manager, there is another uncomfortable part of being an employee that it probably hoped to avoid.

Performance reviews.

If AI is going to join the workforce, we should ask whether it is any good at its job.

That is where we go next.