A founder I advised last month handed me two documents. The first was the job description for her new operations coordinator: title, reporting line, the specific invoices and vendor emails the role owned, a 90-day review built into the calendar. The second was the "job description" for the AI system now doing a third of that operations work. It was a Slack message from four months earlier. It read: "handles invoices now."
That gap is not unusual. It is close to universal. Organizations that would never let a human start work without a defined scope routinely let AI systems start work with none at all. And then, six months later, they are confused about why the AI drifted into tasks no one assigned it, or got blamed for a failure that was never actually its job, or got so tightly micromanaged after one mistake that it stopped being useful at all.
None of that is an AI problem. It is a management problem wearing an AI costume. We already know how to structure a role. We simply have not been applying that discipline to the roles we are handing to software.
The fix is not a governance framework or a committee. It is the same document you would write for a human hire, adapted to six specifics an AI role needs that a human role usually gets by default. I call it a role charter. Five minutes, one page, before the system's first day of real work.
1. Title and scope
Name the role the way you would name a human job title, not the way you would name a piece of software. "AI assistant for customer support" is not a scope. "Drafts first-response replies to billing inquiries under $200; does not send without approval; does not touch refund disputes" is a scope. If you cannot write the boundary in one sentence, the role is not defined yet, no matter how good the tool is.
2. Reporting line
One named human owns this AI's output. Not a team, not "IT," not "whoever set it up." A single person whose job includes explaining what this system did and why, the same way a single manager owns a direct report's output. Shared ownership is the fastest route to no ownership.
3. Escalation trigger
"Escalate when uncertain" is not a trigger, because uncertainty is not measurable and every system is confident about the wrong things sometimes. A real trigger is specific: a dollar threshold, a keyword, a customer tier, a request type. "Any invoice reconciliation flagging a variance over $500 goes to the finance lead before it posts" is a trigger. You can audit that. You cannot audit a feeling.
4. Review cadence
Put it on the calendar, the same way you would schedule a new hire's 30/60/90-day check-in. Not "we'll look at it if something goes wrong." A scheduled review catches the failures that never generate a complaint: the ones that are quietly wrong in a way nobody happens to notice until the pattern is expensive. If the review only happens reactively, you are not managing the role. You are waiting to be told it failed.
5. Performance metric
Pick a measure that would catch quiet underperformance, not just visible errors. Visible errors get reported on their own. What does not get reported is scope creep, where the system is technically still "working" but has drifted into judgment calls it was never charged to make, or has quietly narrowed its own effort to avoid the hard cases. A good metric surfaces drift before a client does.
6. Renewal clause
Set a fixed date to revisit the role: expand it, narrow it, or retire it. AI roles should not be permanent by default any more than a project-based hire should be. The work an AI system was right for six months ago may not be the work it should still be doing today, and the only way to catch that is to have already scheduled the conversation.
None of these six items require new infrastructure. They require the same document you already know how to write, applied to a role you have been treating as a purchase instead of a hire. The organizations getting real, durable value out of AI right now are not the ones with the most advanced systems. They are the ones who wrote the job description first.
