AI Needs an HR Department

In the last post, I argued that your next employee may not have a pulse. It may have an API token instead of a username, connectors instead of application access, prompts instead of training manuals, and guardrails instead of corporate policies. The terminology is different, but once AI starts performing actual work inside an organization, the similarities between managing AI and managing employees become difficult to ignore.

So let’s take that idea one step further. If AI is becoming part of the workforce, maybe it needs an HR department.

Not literally. I am not suggesting we enroll Copilot in the dental plan, invite ChatGPT to the company picnic, or schedule a difficult conversation with an agent because it has been showing up late to the morning stand-up. What I am suggesting is that organizations already have a well-established way of thinking about workers. We define jobs, assign people to departments, establish responsibilities, create reporting relationships, train new hires, evaluate performance, expand responsibilities when someone proves capable, and eventually offboard them when the relationship ends.

For some reason, when AI arrives, we often forget all of that and follow a very different process. Someone sees a demo. The demo is impressive. A license is purchased. A few integrations are enabled. People begin experimenting. Someone creates an agent. Someone else creates three more agents. Six months later, nobody is entirely sure which one is the official one, but at least two of them are connected to SharePoint.

Then we start asking what exactly these systems are supposed to do.

That order may need some work.

The way we describe AI influences the way we manage it. If someone says, “We are deploying an AI platform,” the discussion immediately becomes technical. Which model are we using? Where is it hosted? Does it integrate with Microsoft 365? Can it access ServiceNow? What is the licensing model? How many tokens can it process? Does it support single sign-on?

Those are all legitimate questions, but they are not the first questions.

Change the sentence slightly. Instead of saying, “We are deploying an AI platform,” say, “We are hiring a research assistant.”

Suddenly the conversation changes. What will the research assistant research? Who will use its work? What information does it need? What information should it not see? Who reviews its conclusions? What happens when it gets something wrong? How do we know whether it is actually helping anyone?

Those sound much more like governance questions because that is exactly what they are.

The technology still matters. The model matters. The architecture matters. Security controls matter. But those decisions should support the job. The job should not exist simply because we bought the technology.

Before an organization deploys an AI agent, it should be able to explain in plain English what that agent is supposed to do. Preferably without phrases like “leverage transformative artificial intelligence capabilities to unlock enterprise synergies.” That is not a job description. That is what happens when an executive presentation is left unattended near a thesaurus.

A useful job description should be simple enough that someone outside the AI project can understand it. Maybe the organization wants a Security Alert Triage Assistant. Its job is to review lower-severity alerts, gather context from approved systems, summarize what happened, and recommend whether the issue should be escalated to an analyst. Maybe the company wants a Contract Review Assistant that compares specific contractual language against approved standards and flags differences for legal review. Perhaps it needs a Customer Support Assistant that answers routine questions using approved documentation and hands anything unusual to a person.

Those are jobs.

“Use AI to improve productivity” is not a job. Neither is “implement generative AI across the enterprise.” Those are goals, strategies, or perhaps sentences designed specifically for steering committee meetings. They do not tell us what the AI is expected to do on Tuesday morning.

The job description matters because nearly every governance decision that comes afterward depends on it. If we do not know what the AI’s job is, we cannot reasonably decide what data it needs, what actions it should be allowed to perform, how its performance should be measured, or who should own the results.

Humans get hired into jobs. AI should be assigned one.

That also means AI should belong somewhere in the organization. Employees generally have departments, managers, cost centers, responsibilities, and some identifiable place on the organizational chart. Yes, modern corporate reporting structures sometimes resemble a subway map designed by someone experiencing a personal crisis, but at least there is usually an attempt to establish who works for whom.

AI should have the same organizational context.

A Finance AI should belong to Finance. A Security AI should belong to Security. A Customer Support AI should belong to Customer Support. An HR AI should belong to HR. That does not necessarily mean those departments operate the underlying technology. IT may manage the platform. Cybersecurity may define the controls. Legal and privacy may establish requirements around sensitive information. Procurement may manage the vendor relationship.

But somebody on the business side should be able to say, “That AI works for us.”

This is important because AI systems can easily become everybody’s project and nobody’s responsibility. During deployment, everyone wants to participate. There are working groups, pilot teams, innovation committees, architecture reviews, and presentations with impressive diagrams showing arrows flowing between things.

Then something goes wrong.

At that point, organizational ownership can become strangely difficult to locate.

IT says it only manages the platform. Security says it established the controls. The business says it thought IT owned the AI. The vendor says the system operated as configured. Legal asks who approved the configuration. Everyone suddenly becomes deeply interested in finding the original project charter.

A worker needs a home.

AI does too.

Once we have defined the job and established where the AI belongs, the next mistake to avoid is giving it too much authority too quickly. Most organizations do not hire an employee on Monday and give them unlimited decision-making authority by Tuesday. New hires spend time learning the environment. Their work is reviewed. Someone watches how they perform. They demonstrate competence before receiving more responsibility.

AI should follow the same pattern.

A new AI system might begin in an observation role. It can review approved information, analyze it, and produce a recommendation. Nothing happens automatically. A person decides whether the recommendation makes sense.

If the AI consistently performs well, perhaps the organization allows it to prepare work. It might create the draft ticket, write the response, prepare the change request, or assemble the information someone needs to make a decision. A human still approves the action.

Over time, after the organization understands how the system behaves, the AI might be allowed to perform a limited set of low-risk actions independently.

That progression looks a lot like a probationary period.

The AI proves it can perform the job before we expand its authority.

This may sound overly cautious to people excited about autonomous agents. Autonomy is, after all, where the exciting demos live. Nobody schedules an executive presentation to demonstrate an AI carefully recommending that a human review something. The room becomes much more interested when the AI clicks the button itself.

Unfortunately, autonomous action is also where the exciting incident reports live.

There is nothing wrong with giving AI authority. In many cases, that is where much of the value will eventually come from. But authority should follow evidence rather than enthusiasm. We should understand how the AI performs, where it fails, how often it is wrong, how it behaves when information is incomplete, and what happens when something unexpected occurs.

Trust should be earned.

That principle is familiar because we already apply it to people.

The same idea applies to performance expectations. One of the stranger parts of AI adoption is how often organizations implement AI without clearly defining what good performance looks like. People use the system. Everyone is impressed that it can summarize documents. Someone produces a presentation explaining that the organization is now “AI-enabled.” Eventually, someone should probably ask whether any of this is actually helping.

Employees have performance expectations. AI should too.

If we hire a security triage assistant, success might mean reducing analyst review time while maintaining a defined level of accuracy. If we hire a customer support assistant, perhaps we expect shorter response times without increasing incorrect answers or unnecessary escalations. If we deploy a research assistant, maybe we care about the accuracy of its sources, the completeness of its summaries, and how much time it saves employees.

Different AI workers should have different expectations because they have different jobs.

That is another reason why defining the job first matters so much. We cannot measure whether the AI is performing well if we never established what it was supposed to accomplish.

The metrics also need to include the negative side of performance. Did the AI save employees three hours each week, or did employees spend three hours correcting its output? Did it reduce ticket volume, or merely change the type of tickets being created? Did it improve customer response times while quietly increasing inaccurate responses? Did it reduce security analyst workload but create so many false escalations that the SOC developed a new and exciting relationship with caffeine?

The question should not be whether the AI is impressive.

The question should be whether the AI is useful.

A beautifully written wrong answer is still wrong. A fast process that produces poor outcomes is still a poor process. An AI that appears productive while creating significant cleanup work should not receive a good performance review simply because its summaries contain excellent formatting.

This is especially important because generative AI can be extremely confident. Confidence and competence are not always traveling together. Most organizations already have at least one employee who has demonstrated this phenomenon. AI simply gives us the opportunity to automate it.

If performance is good, the AI may earn additional responsibilities. That is essentially a promotion. An assistant that initially only recommends actions might later be allowed to prepare them. After additional testing, it may be allowed to perform certain low-risk tasks automatically. Maybe its approved knowledge sources expand. Perhaps it receives access to an additional application required for a new responsibility.

That expansion should be deliberate.

An AI should not get promoted because someone found another connector in the administration console and thought it looked useful.

Every increase in authority should have a reason. The organization should be able to explain what changed, why additional capability is necessary, what evidence supports the decision, and what controls are in place if the AI behaves unexpectedly.

Promotions should be earned.

And, like humans, AI should also be capable of being demoted.

This part is important because AI governance should not assume that autonomy only moves in one direction. Models change. Prompts change. Data changes. Applications change. Integrations change. Something that performed reliably six months ago may behave differently after a major update.

If the AI begins producing more errors, the organization should be able to reduce its authority. Move it from acting back to recommending. Require additional human approval. Restrict a connector. Limit the data available to it. Return it to observation mode while someone figures out what changed.

That should not be viewed as failure.

It is simply management.

Trust is not a certificate we issue once and assume remains valid forever. It should be continuously supported by evidence.

Eventually, of course, the AI employee will leave.

A project will end. A vendor will be replaced. A better model will become available. A business process will change. A proof of concept will quietly stop being used after everyone involved changes jobs. The AI itself may disappear from daily use, but its service account, API token, and application permissions may remain behind like the digital equivalent of someone leaving the company but keeping their building badge.

We are already very good at creating orphaned technology.

AI gives us the opportunity to create orphaned technology that can also send email.

That means offboarding has to be part of the lifecycle from the beginning. When an AI role ends, its identity should be disabled. Credentials and tokens should be revoked. Connectors should be removed. Automated workflows should be stopped. Retained data should be reviewed. Required logs should be preserved. Someone should verify that the AI can no longer interact with organizational systems.

The principle should be exactly the same as employee offboarding: when the job ends, the access ends.

None of this means HR should suddenly become responsible for managing AI infrastructure. I suspect most HR departments have enough to do without receiving tickets because a chatbot wants access to Salesforce. The point is that HR has spent decades developing a lifecycle for workers, and that lifecycle gives IT, cybersecurity, and business leaders a useful model for AI governance.

Define the job before the worker arrives. Decide where the worker belongs. Establish expectations. Start with supervision. Expand responsibilities as trust is earned. Measure performance. Reduce authority when necessary. Remove access when the job ends.

That is not particularly revolutionary.

In fact, that is exactly why it is useful.

Artificial intelligence can feel like an entirely new governance problem that requires completely new controls, committees, frameworks, and terminology. Some of that will certainly be necessary. AI creates risks and capabilities we have not encountered in exactly this form before.

But not everything is new.

Organizations already understand how to manage identities that perform work. We already understand roles, accountability, supervision, lifecycle management, and access control.

The worker has changed.

Many of the management principles have not.

Perhaps the biggest shift organizations can make is therefore surprisingly simple. Stop beginning every AI conversation with, “What technology should we deploy?” Start with, “What job are we trying to fill?”

Once that question is answered, many of the other questions become easier. The job defines the responsibilities. The responsibilities help define the information required. The information begins to define the access. The risk helps determine the level of supervision. Performance determines whether the AI deserves additional authority. And eventually, the lifecycle tells us when that authority should end.

Maybe AI does not literally need an HR department.

But it absolutely needs an HR mindset.

Because if we are going to treat AI as part of the workforce, we should manage it like part of the workforce.

And once we have written the AI’s job description, placed it in a department, and decided what it is supposed to accomplish, we arrive at the next question.

How much access does that job actually require?

That is where we go next.

Because AI may be new, but the Principle of Least Privilege definitely is not.