How to Define a Job Description for an AI Employee: Scope, Authority, and Review

Start with the Work Product, Not the Job Title

A finance team pilots an AI employee to help with invoice exceptions. The initial brief says: 'Act as a helpful accounts payable assistant.' Six weeks later the pilot is stuck because nobody agrees which documents it may open, whether it can email suppliers, who checks the coding decision, or what 'done' looks like. The model is not the bottleneck. The missing artifact is a job description.

Write the role around a recurring work product: an exception summary, an onboarding checklist, a contract review memo, a collections draft, or a service ticket triage decision. For each work product, name the trigger, the consumer, the required inputs, the acceptance criteria, and the failure mode. This forces the business to describe the job in operational language rather than in model language.

• Work product — the artifact or decision the role owns, not a general capability.
• Trigger — the event that starts the work: new invoice, signed contract, employee start date, or customer complaint.
• Consumer — the person or system that receives the output and the format they need.
• Acceptance criteria — what makes the output usable without rework.
• Failure mode — the most expensive way this role could be wrong and who must catch it.

Write the Role in Five Blocks

A practical job description for an AI employee fits on one page and uses five blocks: purpose, scope, inputs, actions, and boundaries. Purpose states why the role exists and which business outcome it supports. Scope says what is included and explicitly excluded. Inputs list the documents, systems, and data classifications the role may read. Actions define what it may draft, recommend, or execute. Boundaries set the escalation and refusal rules.

The test is simple: a new human hire should be able to start from the description, and a systems integrator should be able to configure from it. If the description says 'handle HR onboarding' but does not say whether the role can send offer letters, book equipment, or update the HRIS, it is not a job description yet. It is a wish list that will produce hidden assumptions during implementation.

• Purpose — reduce invoice exception resolution time while keeping coding decisions auditable.
• Scope — includes reading invoices, purchase orders, and vendor records; excludes supplier negotiation and payment release.
• Inputs — finance shared drive, ERP read-only vendor master, policy PDFs tagged finance-policy-v3.
• Actions — summarize exception, propose coding, draft supplier question, route to AP owner.
• Boundaries — no payment execution, no bank-detail changes, escalate any mismatch above policy threshold.

Separate Authority from Capability

Most AI failures in enterprise settings are not failures of language generation; they are failures of authority. A role description must distinguish what the AI employee can read, what it can draft, and what it can execute in connected systems. A retrieval system may summarize a supplier contract, but that does not mean the same role should be allowed to change a vendor bank account. The job description should map each action to a permission level and a human approver.

Use least privilege and explicit escalation. If the role can read invoices but not post journal entries, say so. If it can draft a customer reply but not send it, say so. If it can create a ticket but not close it, say so. These distinctions change integration design, audit logging, and the cost of the role. They also protect the business from a confident but unauthorized action.

• Read-only — best for research, summarization, and exception detection where a human keeps execution authority.
• Draft-and-route — best for communications, coding proposals, and onboarding packs that need review before sending.
• Execute-with-limit — best for low-risk system updates with thresholds, audit trails, and rollback paths.
• Human-only — best for payments, legal commitments, employment decisions, and any action with irreversible external impact.

Define Review Metrics and Escalation Rules

A job description should say how the role will be reviewed, not only what it will do. Choose a small set of metrics tied to the work product: first-pass acceptance rate, rework rate, exception rate, cycle time, escalation precision, and audit completeness. Avoid vague success criteria such as 'user satisfaction' unless the role is actually a support role and the survey is tied to specific outputs.

Escalation rules must name the human owner and the trigger. Typical triggers include a confidence threshold, a monetary threshold, a policy gap, a missing document, a request to change master data, or any output that touches a sensitive category. Review cadence should be explicit: daily checks during the first weeks of a new role, then weekly or monthly as the role stabilizes. The review should also examine whether the job description itself needs to change, because scope creep often appears first as a series of small exceptions.

• Quality metric — measures whether the output is usable without rework.
• Risk metric — catches unauthorized actions, missing approvals, or unsupported claims.
• Volume metric — shows whether the role is being used for the intended work or drifting into adjacent tasks.
• Escalation metric — tests whether the role routes the right cases to the right human owner.

Make It Operable: Data, Residency, and Change Management

An AI employee job description has deployment clauses. List the data sources, retention expectations, residency requirements, and integration owner. A role that reads HR records may need stricter access controls and regional hosting than a role that summarizes public product documentation. Integration cost often exceeds model cost in enterprise deployments, so the description should identify which systems are read-only, which need write access, and which are out of scope for the first release.

Change management belongs in the description too. Name who can change the role's scope, who approves new data sources, and how often the description is reviewed. Version the document and keep it next to the configuration. When a policy changes, the role description should change before the workflow does. Pilardin's workspace is built around scoped roles that combine document chat, live system connections, and Matrix modules; if you are mapping a role to modules, start with /matrix, and use /pricing to scope deployment options.

• Data inventory — sources, classifications, retention, and residency.
• System access — read, draft, execute, and the named owner for each connection.
• Human owner — the person accountable for outputs and escalations.
• Review date — the next scheduled check of scope, permissions, and performance.
• Change log — who changed what and why.

A Practical Template and Sign-Off Checklist

Use a one-page role charter before writing prompts or configuring agents. The charter should contain the five blocks from the earlier section plus deployment clauses, review metrics, and approval names. It should be signed by the business owner, the system owner, and a security or compliance reviewer. If the role touches regulated data, add legal or privacy review. This is not bureaucracy; it is the difference between a demo and an operable role.

After sign-off, convert the charter into configuration: retrieval scope, action permissions, escalation routes, and logging. Run dry runs with historical cases before giving the role live access. Track the first exceptions as design feedback, not as model failures. The job description is a living control document, and the quality of the role depends on how honestly the business defines the work.

• Name the work product and the business owner.
• List included and excluded tasks.
• Classify data and specify residency and retention.
• Map every action to read, draft, execute, or human-only authority.
• Define escalation triggers and named approvers.
• Choose two to four review metrics and a review cadence.
• Schedule a scope review before connecting additional systems.

FAQ

How is an AI employee job description different from a prompt?

A prompt tells a model how to respond in a specific interaction. A job description defines the role: the work product, data inputs, authority level, escalation rules, review metrics, and named human owners. Prompts can change per task; the job description is the control document that keeps the role consistent as tools and models change.

Should the job description include system permissions?

Yes. It should state which systems the role can read, where it can draft, what it can execute, and which actions require human approval. Without that mapping, implementation teams guess, audit logs become incomplete, and the business cannot tell whether the role is operating inside its intended scope.

Who should approve an AI employee job description?

At minimum, the business owner accountable for the output and the system or IT owner responsible for integration. Add security or privacy review for sensitive data, and legal review for regulated decisions. If the role affects employment, finance, or customer commitments, the relevant functional owner should sign off before live access is granted.

How often should the role be reviewed?

Review frequently during launch and then on a scheduled cadence. Daily or weekly checks are reasonable while the role is new; afterward, review when policies change, systems change, or exception patterns shift. The important rule is to review the job description itself, not only the model output, because scope creep usually appears as small undocumented exceptions.

Can we reuse one job description across different AI tools?

Keep the role charter tool-neutral, but expect tool-specific configuration. One platform may support read-only retrieval while another supports write actions and approval workflows. Reuse the purpose, scope, and boundaries, then map permissions, data connections, and audit logs separately for each tool so the role remains governable in practice.