Organizational charts are a curious mix of helpful facts and a bit of corporate fossil hunting. They show us who reports to whom, which departments are still alive and kicking, where the bosses sit, and sometimes even uncover that one poor soul who’s still reporting to someone who left the company half a year ago. (It happens more often than you’d think.)
Take a look at most org charts today and you’ll spot a familiar pattern: they’re packed with actual people. You know, the kind who need coffee to function and occasionally forget their passwords. No robots in sight—at least, not yet.
But give it a little time, and that could change. The robots are probably just waiting for their onboarding paperwork.
If AI keeps moving up from being just a handy gadget to actually taking on real, ongoing business responsibilities, companies might have to start giving AI its own spot on the org chart—right next to the humans. Not because the AI needs an impressive title, a corner office, or a plate at the holiday party buffet (though I’d love to see an AI try to eat shrimp cocktail).
But because, as always, when things go wrong, someone—or something—has to take the blame. That’s just how it works.
Imagine looking at an organizational chart ten years from now. Finance includes the controller, financial analysts, a Budget Forecasting AI, and an Audit Preparation AI. Engineering includes developers, architects, a Coding Assistant, a Test Automation AI, and a Documentation AI. Security has analysts, engineers, a Threat Hunting AI, a Malware Analysis AI, and a Compliance Evidence Assistant.
Marketing has a Creative AI. Legal has a Contract Review AI. HR has an Employee Policy Assistant.
And of course, somewhere deep in the digital basement, there’s an AI that was spun up during a pilot project three years ago. Now, nobody wants to admit they’re responsible for it. It’s the office plant of the tech world—everyone waters it, but nobody claims it.
Some things about corporate life never change. There will always be mystery projects, forgotten passwords, and that one AI nobody wants to make eye contact with.
That future may sound slightly theatrical, but pieces of it already exist. Organizations are deploying specialized AI systems that triage alerts, summarize contracts, produce reports, review source code, answer internal questions, create tickets, enrich incidents, and coordinate workflows.
The important change is not simply that AI can perform those tasks. Automation has been doing pieces of business work for decades.
The real change is that organizations are beginning to give AI persistent responsibilities.
Once responsibility becomes persistent, organizational structure matters.
Earlier in this series, I argued that AI should have many of the same governance attributes we associate with an employee or service identity. It should have a defined job description, an owner, a unique identity, appropriate access, performance expectations, and a person responsible for supervising what it does.
Put all of those things together, and we have something that starts looking curiously like a position.
That does not mean an AI should become a legal employee, receive a salary, get benefits, accrue vacation time, or appear in the HR system as a person. It means organizations may need an equivalent governance structure for systems that perform persistent business functions.
If an AI performs the same business function every day, several questions immediately appear. Who owns that function? Which department does the AI belong to? Who funds it? Who approves changes? Who reviews its performance? Who decides whether its responsibilities expand? Who shuts it down when it is no longer needed?
Those are organizational questions, not just technology questions.
The org chart is one way companies communicate those relationships.
Today, many AI systems live outside traditional organizational structures. They are categorized as projects, applications, pilots, platform features, or experiments. That model works reasonably well as long as AI remains primarily assistive.
Things get a little more awkward when the AI stops just helping and starts actually doing the work.
Imagine an AI that automatically reviews low-risk cybersecurity alerts, enriches them with additional information, evaluates them against recognized criteria, and closes those that meet predetermined conditions. That system is now doing work previously handled by a security analyst.
Where does it belong?
The answer probably isn’t, ‘Just stick it under IT because they run the server.’
The work belongs to Security.
The underlying technology may be hosted, maintained, or supported elsewhere, but the business function remains part of the security organization.
That distinction will matter more as AI crosses traditional technology boundaries.
Consider a contract-review AI. It may operate the infrastructure. Procurement may own the vendor relationship. Legal may govern the documents being reviewed. Security may establish access controls. Privacy may dictate how information can be processed.
But the job belongs to Legal.
An AI’s organizational home should be based primarily on the work it performs, not where the compute runs.
That all sounds perfectly logical, right up until someone raises the budget.
Suddenly, the conversation turns into a nighttime college dorm debate, complete with crazy theories and maybe a pizza box or two.
If Finance owns the AI worker but IT pays for the platform, whose budget gets charged? If twelve departments use the same foundation model but create their own specialized agents, how should costs be allocated? If an AI reduces the need for outside consulting, which department gets to claim the savings?
Eventually, some poor soul will be tasked with inventing an AI chargeback model.
And to that person, I offer my deepest sympathy—and maybe a hot cup of coffee. You’re going to need it.
The future org chart may also change how managers think about teams. Managers could eventually supervise mixed workforces composed of humans and AI agents. The management responsibilities will not be identical, obviously, but parts of the operating model will look surprisingly familiar.
The manager still determines what work needs to be done.
What’s changing isn’t the work itself, but who (or what) actually does each part. Spoiler: sometimes it’s not a person anymore.
A security analyst may investigate unusual events while an AI handles repetitive enrichment and evidence collection. A lawyer may negotiate a contract while an AI compares the language against approved standards. A developer may design an application architecture while AI generates test cases, boilerplate code, and documentation.
That moves the conversation past the tired old question, “Will AI replace employees?” (Short answer: not exactly.)
That framing misses the real story, which is much more interesting—and a lot less like a sci-fi flick.
The better question is: how will work be divided between people and AI?
Some tasks will remain entirely human. Some will become completely automated. Many will become shared processes where people and AI perform different parts of the same job.
That changes job design.
A security analyst in an AI-enabled SOC may spend less time manually collecting context and more time making decisions. A financial analyst may spend less time assembling reports and more time interpreting results. A developer may spend less time producing repetitive code and more time reviewing architecture, validating design choices, and verifying generated output.
AI can change the shape of a role without eliminating the role.
That part is not new. Technology has been changing jobs for centuries. The difference is that AI is increasingly capable of participating in cognitive work that previously required a person.
That divides responsibility much more subtly.
Organizations will have to decide which decisions remain inherently human and which they can delegate.
Some lines should be relatively obvious. High-impact employment decisions, major financial actions, legal judgments, safety decisions, and other consequential activities may still require clear human accountability, even when AI provides analysis or recommendations.
Other lines will move over time.
A security AI might initially draft an incident summary. Later, after enough evidence demonstrates reliable performance, it might recommend containment actions. Eventually, it might be authorized to automatically contain a narrowly defined class of well-understood, low-risk events.
The org chart alone cannot show all of those distinctions, but the operating model behind it must.
Human responsibilities and AI responsibilities need to be explicit.
Otherwise, work will eventually fall into the gap between them.
The human assumes the AI handled it.
The AI was never authorized to handle it.
The incident report begins with the phrase, “There appears to have been a misunderstanding.”
Hearing that phrase has never made anyone’s day better. Trust me, it’s right up there with ‘We need to talk’ in the list of things you don’t want to hear at work.
Mixed human and AI teams also create interesting escalation questions. If an AI faces a situation outside its assigned role, what happens next? Does it escalate to a person? Another specialized AI? A queue? A manager? Does it stop completely?
The right answer depends on the use case, but the escalation path should be designed intentionally.
If a customer-support AI cannot answer a question, the request might move to a human support representative. If a security triage AI identifies a potentially serious incident, it may escalate directly into the incident-response process. If a financial AI encounters a transaction above its authority threshold, it might halt the workflow and request human approval.
Escalation should be part of the AI’s job design.
The agent should not simply fail open, guess, improvise, or wander into another department looking for answers.
Humans do this too, but at least we usually send a ‘heads up’ email before wandering into someone else’s territory.
The future org chart may also include relationships among AI workers.
An orchestration AI may coordinate several specialized agents. A general assistant might delegate research to one agent, analysis to another, and execution to a third. A security agent might request threat intelligence from one system, query asset information from another, and then invoke an incident-response workflow.
At that point, congratulations—you’ve just built a machine management hierarchy. Somewhere, a robot is probably updating its LinkedIn profile.
Before anyone gets too excited, this does not mean the Research AI gets promoted to Vice President.
What it really means is that even when we allow machines hand off tasks to other machines, we still need to keep track of who did what and who is responsible—otherwise, things get messy fast.
If Agent A tells Agent B to do something, the organization still needs to know who started things off, who did each part, who owns which agent, what permissions were used, and who gets the credit—or the blame—when it’s all over.
Otherwise, we end up in a world in which machines are handing off work to other machines, and the humans are left scratching their heads, wondering who actually said yes to any of it.
At that point, it starts to feel less like progress and more like we’ve just created a new layer of middle management, except this time it moves at the speed of light and never takes a coffee break.
And as if that wasn’t enough, we’re about to have an inventory headache too.
Organizations already try to keep track of employees, contractors, laptops, servers, cloud stuff, service accounts, vendors, databases, certificates, and about seventeen other things—usually with mixed results and a few spreadsheets that nobody wants to update.
Now, AI workers are about to join the party.
Organizations will need to know how many active AI agents exist, what jobs they perform, who owns them, which models they use, what information they can access, what actions they can take, which applications they connect to, when they were last reviewed, whether they are still needed, and who is paying for them.
Congratulations, you now have an AI workforce inventory—just what every IT department always wanted.
Without some kind of list, shadow AI could start popping up everywhere, and good luck trying to keep tabs on it all.
A department creates an agent for a temporary project. Another group independently builds something similar. A third purchases a SaaS product with embedded AI functionality. An employee creates an automation using an API key. Someone enables a new Copilot feature because it was included in the license.
Fast forward six months, and suddenly you’ve got fifty AI workers running around, but only a dozen of them made it onto the official AI roadmap.
This, my friends, is how enterprise architecture develops what we politely call ‘character’—which is really just a fancy word for headaches.
Thankfully, nobody expects the org chart to show every single AI agent. Nobody wants to open a diagram with 14,000 boxes and realize half of them are chatbots arguing about lunch orders.
But high-impact AI roles should exist somewhere in the governance structure.
If an AI has meaningful authority, performs an important business function, accesses sensitive data, or can take consequential action, the organization should know where it belongs and who is responsible for it.
The org chart of the future might also make us rethink what we mean by headcount.
Organizations traditionally measure workforce capacity partly in terms of people. How many employees do we have? How many positions are open? How many contractors support this function? How many additional people would we need to increase capacity?
AI, of course, makes all those questions a lot more interesting—and complicated.
One AI agent might do the work of part of a traditional job. Another may support fifty employees without replacing any. A third might operate continuously and process a volume of repetitive transactions that would require an entire human team to match.
Just counting up the number of AI ‘employees’ probably won’t tell you much—unless you’re playing AI bingo, in which case, good luck.
It’s probably more useful to count what AI can actually do, rather than how many digital workers you have.
Instead of asking how many AI workers a department has, organizations may eventually ask what percentage of a business process is automated, how much human review is required, how much decision authority AI possesses, what percentage of output depends on automated platforms, and where human accountability still exists.
Those kinds of measures tell you a lot more about how things really work than just counting boxes on a chart.
And let’s keep in mind the culture side of things.
People need to know what role AI actually plays on their team.
Is it a tool, an assistant, an automated process, a decision helper, or just another digital coworker?
The answer will probably be different every time, and that’s perfectly fine. The important thing is that everyone’s clear on it.
How you describe a system changes how people act around it.
If people think AI always gets it right, they might stop double-checking. If they think it’s just a science experiment, they might ignore good advice. And if nobody knows whether the AI can actually do anything, everyone assumes someone else is watching it.
That’s why organizations need to spell out what each AI is supposed to do, what it can’t do, how much power it has, and how people should work with it.
The future workforce will need more than AI governance.
It will also need AI literacy.
People should know when to trust AI, when to verify, when to call for backup, and when to just ignore it and move on.
That last one is a life skill, by the way.
Let’s be honest, every organization already has at least one automated alert that everyone pretends doesn’t exist.
Let’s try not to add AI to that continuously expanding list.
Ultimately, the future org chart will not be interesting because somebody put robots in boxes.
It’ll be interesting because it shows how work is really divided up between people and machines.
People will remain accountable for the organization. AI will do more and more work inside it. Managers will decide how responsibilities are divided. Security will protect both human plus machine identities. Business owners will define the anticipated results. Governance teams will determine where autonomy is appropriate and where human approval is still necessary.
And somewhere in the building, there will always be someone struggling with the conference-room projector, wondering why it hates them personally.
Some things are simply beyond the reach of artificial intelligence.
But if AI begins appearing on the organizational chart—even conceptually—then it needs more than a job title, an identity, and a manager.
It needs rules.
Human employees receive policies and handbooks that explain expected behavior, acceptable use, security responsibilities, escalation requirements, conflicts of interest, and what occurs when things go wrong.
AI needs the same clarity.
Not necessarily in a three-ring binder.
But definitely in policy.
And that, dear reader, is exactly where we’re headed next.