Enterprise AI Role SystemOrganise six families around the service, not the label

Outcome and workflow roles own the business service, decision population, adoption, difficult exceptions, affected-party experience and benefit capture. Human-AI operating roles frame work, use or supervise AI, verify evidence, make bounded decisions, escalate and retain professional accountability. These families keep business purpose and daily judgment visible.

Product, data and engineering roles own product direction, data meaning, system design, model and tool integration, reliability, security, monitoring and change. Assurance and challenge roles independently evaluate risk, fairness, privacy, security, control, compliance, evidence and audit without owning delivery. Separation is defined at the event and right, not necessarily by a large department.

Shared capability roles provide platforms, evaluation services, procurement support, incident coordination, learning, standards, portfolio insight and specialist pools. Transition and ecosystem roles embed expertise, manage vendors, represent workers and affected groups, transfer capability, redesign work and retire obsolete duties or services. Some transition work should end by design.

One person can wear several compatible hats in a small organisation. The system still names each hat, the event at which it applies and any rights that must be separated. A product and data owner may be the same person for a low-consequence service, while high-consequence challenge comes from an external assessor. A vendor can supply evidence and expertise but cannot accept the buyer's risk or approve remedies for affected people.

Role ContractWrite the event, authority and evidence before changing the title

A Role Contract is this article's synthesis. It begins with an outcome, recurring decision and consequence, then names the role holder and population served. It separates the AI contribution from human authority and non-delegable judgment. The contract identifies inputs, evidence owed, records created, upstream requests and downstream acceptance.

Rights use precise verbs. A role may propose a change, specify a constraint, approve deployment, challenge evidence, veto a condition or assure a control. The right belongs to a decision object and event. “Risk approval” is too broad. “Veto release when the severe-harm evaluation lacks the declared population evidence, with a two-day response and executive escalation” is operable.

Workload belongs in the contract. State arrival rate, volume, review duration, queue ceiling, peak demand, service time, availability and fallback. A reviewer with formal authority but insufficient time cannot change the outcome. An accountable operator without access to model, policy or data evidence holds liability without control.

The contract closes with prohibited combinations, incidents, recourse, proficiency, support, change triggers, transfer and expiry. A delivery role cannot independently assure its own work. A vendor cannot approve internal risk acceptance. A temporary translator should not become a permanent relay. Role grade and reward should recognise consequential judgment, emotional load, learning and added accountability rather than celebrating output volume alone.

Role Mutation MatrixEnrich, separate, time-limit, institutionalise or remove

The Role Mutation Matrix is this article's synthesis. Enrich adds bounded AI duties to an existing role while preserving coherent accountability. A customer adviser can verify suggestions and escalate new failure patterns without becoming responsible for model policy. Split separates delivery from independent challenge, approval from execution, or high from low consequence when one contract contains incompatible rights.

Create temporarily establishes migration, translation or embedded-expertise work with an artefact-transfer and sunset mandate. Create persistently establishes a specialist or shared service when repeated demand, independence, scarce expertise or economies of scale justify it. Dissolve removes a role or duty when work disappears, is absorbed by a better workflow or survives only as an information relay.

A new title is justified only after the event and load are measured. Several recurring cells may support a persistent evaluation service. One deployment may need a temporary forward-deployed engineer. An old committee that forwards papers between product and executives can disappear once proposal, evidence, escalation and decision rights are placed directly. Dissolution is design work, not an afterthought.

Mutation also affects grade, reward and transition. Enriched roles may carry greater decision consequence or emotional load. Split duties need career paths in both delivery and challenge. Temporary roles need a credible destination after sunset. Dissolved work requires fair consultation, redeployment and knowledge preservation. The system should remove obsolete reporting before adding new control tasks.

Decision Accountability SpineKeep one outcome owner while expertise and vetoes remain distributed

The Decision Accountability Spine is this article's synthesis. It links enterprise outcome, workflow decision, AI behaviour, human action, evidence, challenge and final authority. Every material event has one accountable outcome owner even when several roles propose, specify, constrain, challenge or assure parts of it.

The spine prevents two errors. First, a technical owner is not made accountable for adoption or benefit without business authority. Second, distributed vetoes do not become duplicated accountability. Security may block release on a declared condition. Legal may constrain purpose. Risk may challenge evidence. The outcome owner still decides within those constraints, escalates unresolved conflict and owns the service consequence.

Trace a real event from outcome to evidence and back. Which AI behaviour influenced the recommendation? Which human accepted, modified or refused it? Which version and source support the decision? Who challenges population effects? Who can suspend operation? Where does recourse arrive? A chart that cannot answer these questions does not prove accountability.

Knowledge and rights should meet without collapsing control. Organisational research argues for locating decision rights near specific knowledge while connecting them to evaluation and control systems.18 In AI work, that means domain experts can exercise bounded judgment while product, policy, assurance and executive rights remain explicit along the same event.

Role Interface ContractsRepair the handoff before calling it a talent shortage

A Role Interface Contract is this article's synthesis. For every handoff, state the request, expected response, evidence artefact, version, service time, acceptance criteria, exception and escalation. Many apparent staffing gaps are broken interfaces. Risk receives a persuasive narrative rather than testable evidence. Product receives contradictory domain requests with no priority. Operators cannot reach the owner authorised to resolve an exception.

The request should name the decision it supports. The response should be usable without private translation. The artefact should expose assumptions, configuration and evidence. Service time should reflect consequence and delivery cadence. Acceptance records whether the receiving role can act, rejects the package or opens an exception. Escalation should reach a decision owner, not another relay.

Risk challenge illustrates the point. A universal approval right without a declared evidence contract and response time can freeze delivery while adding little control. Conversely, a two-day review target is fictional when the team receives incomplete evidence and has one reviewer for ten launches. Repairing artefact quality, demand priority and capacity can solve the problem without another role.

Affected workers and users also participate in interfaces. Consultation is not a late presentation. Worker representatives need a route to influence task design, workload, monitoring, grade and transition. Affected people need complaint and recourse routes that reach someone with authority. ILO material reinforces the role of social dialogue in shaping purpose, control and job quality.10

Role Load and Conflict TestMake human review and independent challenge operationally true

The Role Load and Conflict Test is this article's synthesis. Ask whether the role can perform assigned review volume within the decision time; whether it owns an outcome and independently challenges its own evidence; whether it approves work it built or sold; whether it carries accountability without access, authority or capacity; whether several roles claim the same outcome; whether the role only relays information; and whether temporary expertise has transfer and exit.

Load begins with arrival rate and variation, not an average. Multiply review duration by expected cases, then include complex tails, rework, incidents, leave, training and peaks. Compare demand with qualified availability and queue limits. When capacity fails, contract scope, add support, change the interface or stop automation volume. A human review box in a process map cannot absorb work.

Conflict tests rights at the event. Delivery and independent challenge require separation. Build and final approval may need another reviewer. A supplier can attest to its controls but not accept buyer risk. An outcome owner can receive challenge while retaining accountable authority. In a small firm, separation may come through different times, explicit hats, peer review or external assurance rather than extra permanent departments.

Field and human-factors research cautions that AI can redistribute expertise and tasks while different automation stages place humans in different acquisition, analysis, selection and action roles.1316 Role design should therefore follow the actual division of work and failure, not the system's marketing category.

Ten role-system casesChange the contract, interface and load before changing the title

Each case identifies the Role Contract, six-family placement, mutation, accountability spine, interfaces, load and conflict, worker or affected-party implications and accountable owner. The smallest useful mutation is preferred.

Enterprise AI Role-System DesignerResolve the recurring work event into one of five mutations

The Enterprise AI Role-System Designer is this article's synthesis. It returns exactly five outcomes: enrich an existing role; split conflicting duties; create a temporary transfer role; establish a persistent specialist or shared service; or remove a role because its work should disappear. It does not create a universal organisation score or recommend a new title when interface repair is sufficient.

Strong rival and failure boundaryMinimum viable separation without organisational churn

The strongest rival is right that continuous role redesign can produce title inflation, anxiety, grade disputes and churn. Formal contracts can lag emergent work. Small organisations cannot fund every specialist or independent department. People often span several families effectively, and rigid interfaces can turn collaboration into bureaucracy.

The answer is minimum viable separation and explicit hats. Create a new role only when durable demand, scarce capability, independence or a distinct service justifies it. Let existing roles absorb coherent bounded duties. In small teams, separate incompatible rights by event, reviewer, time or external assurance. Pilot contracts on real workflows and revise them from observed load, incidents and worker evidence.

Do not publish a list of fashionable titles or rename roles without changing work. Do not make an AI owner responsible for an outcome they cannot control, or make data science own adoption, benefits and every incident. Do not let product assure itself, give risk an unbounded approval right, add review without capacity, or ask operators to carry choices they cannot change.

Role design must subtract. Temporary migration work needs transfer and sunset. Committees that only relay information should dissolve. Old reporting and approval layers should not survive after direct evidence and decision interfaces replace them. Affected workers need genuine participation in workload, monitoring, grade, reward, transition and learning decisions, not a presentation after the chart is approved.

Sources have limits. NIST informs lifecycle roles and risk responsibility, while EU and UK materials apply within their legal and institutional contexts. ILO and OECD evidence describes task and worker change across studied settings. Team and human-factors studies illuminate mechanisms, not universal role blueprints.141517 The named role-system constructs are this paper's synthesis.

The final test is operational: can the role act within authority, produce or receive usable evidence, meet demand, escalate exceptions, preserve challenge, support affected people and adapt or expire when work changes? If not, the organisation chart is a promise its queues and rights cannot keep.

Evidence spineSources checked 3 September 2026

1. NIST, Artificial Intelligence Risk Management Framework.
2. NIST AIRC, AI RMF Core.
3. NIST AIRC, Descriptions of AI Actor Tasks.
4. NIST AIRC, AI Risk Management and Human-AI Interaction.
5. NIST, AI RMF Playbook.
6. European Union, Regulation (EU) 2024/1689, Artificial Intelligence Act.
7. UK Government, AI Skills Tools Package.
8. UK Government, Artificial Intelligence Playbook for the UK Government.
9. International Labour Organization, Artificial Intelligence Adoption and Its Impact on Jobs.
10. International Labour Organization, Social Dialogue Critical to Ensure Positive Outcomes of AI in the Workplace.
11. OECD, The Impact of AI on the Workplace.
12. OECD, Artificial Intelligence and the Changing Demand for Skills in the Labour Market.
13. Dell'Acqua et al., The Cybernetic Teammate.
14. Brynjolfsson, Li and Raymond, Generative AI at Work.
15. Amershi et al., Guidelines for Human-AI Interaction.
16. Parasuraman, Sheridan and Wickens, A Model for Types and Levels of Human Interaction with Automation.
17. Edmondson, Psychological Safety and Learning Behavior in Work Teams.
18. Jensen and Meckling, Specific and General Knowledge, and Organizational Structure.