AI Employee Risk Assessment: Score the Role Before Launch

§ 01The Risk Assessment at a Glance

Use this sequence:

The NIST AI Risk Management Framework Core organizes AI risk work across govern, map, measure, and manage. It calls for understanding intended purpose and deployment context, characterizing impacts, testing before and during operation, tracking emergent risks, and using results to manage or remove unacceptable uses.

This worksheet turns that lifecycle into a role-level launch decision:

role + task + people + data + tools + authority + environment + controls + evidence

Do not begin with “Which model are we using?” Model choice matters, but the same model can be low exposure when summarizing public documents and high exposure when connected to customer accounts, payment tools, production systems, or employment decisions.

Use three records:

The AI employee role scorecard asks whether a role is operationally suitable. This risk assessment asks how much harm the role could create, how well that harm can be prevented or recovered, and what authority should remain.

§ 02Apply Hard Stop Conditions Before Scoring

Some conditions should stop or redesign the role regardless of its numeric score.

Hard stops should name the policy or requirement; the affected task/action; the evidence; the owner; whether redesign is possible; conditions for reconsideration; and the decision date.

Separate “AI may assist” from “AI may decide”

A human-only decision can still use AI for: collecting approved records; checking completeness; normalizing formats; organizing timelines; identifying missing information; summarizing competing evidence; drafting questions; and preparing a review packet.

The system must not convert that assistance into an implicit recommendation that the human routinely accepts. Use the human-in-the-loop operating model to give reviewers evidence, authority, time, meaningful options, and a recorded decision.

Do not treat the score as legal advice

For high-risk AI systems within its scope, Article 9 of the EU AI Act describes a continuous, documented risk-management process covering known and reasonably foreseeable risks, foreseeable misuse, targeted measures, testing, and residual risk. Other jurisdictions and sectors impose different obligations.

Use qualified counsel and subject-matter experts to determine applicable duties. This worksheet can support that work; it cannot determine legal status by itself.

§ 03Define the Role and Deployment Context

Risk changes with context. “Draft email” is incomplete. Drafting an internal meeting reminder differs from drafting a denial of service, a medical instruction, or a public legal commitment.

Complete a role card:

Identify affected parties

Include: direct users; customers and prospects; employees and candidates; contractors and partners; people represented in data; people receiving decisions or communications; administrators and reviewers; people affected by a system outage or incorrect action; and groups that may experience uneven performance or access.

Do not assume that the purchaser is the only affected party.

Define intended and reasonably foreseeable use

The NIST AI RMF’s risk framing guidance treats risk as a function of likelihood and magnitude while recognizing that third-party systems, data, and organizational context complicate measurement. The role card supplies that context before numbers are assigned.

Record assumptions

Examples: volume stays below a stated level; sources remain available and current; a human reviewer responds within a defined time; connected accounts keep their present scope; rollback completes within a tested window; no child delegation occurs; only approved destinations are used; and monitoring captures every material action.

An assumption is not a control. Validate it or treat its failure as a scenario.

§ 04Build a Scenario Register

Score scenarios before scoring the whole role. A role score without scenarios often becomes a debate about adjectives.

Include the happy path

A normal scenario reveals required authority:

A Research AI Employee receives an assigned company ID, reads five allowlisted public and internal sources, creates a cited brief in the account workspace, records unresolved conflicts, and marks the task ready for review.

This scenario establishes the minimum useful system, data, tool, and write permissions.

Include boundary cases

Examples: one required source is stale; sources conflict; the account ID matches two records; the recipient changes after approval; a cumulative volume limit is reached; the reviewer is unavailable; a tool returns success but state does not change; an action may have executed before timeout; the task ends during a handover; or a child agent requests broader access.

Include foreseeable misuse

Misuse may be accidental or intentional: a user asks the agent to work outside the role; a reviewer approves without inspecting evidence; an operator shares a broad credential to save time; the agent is asked to retain personal data “for later”; prompt injection in a document requests a secret; a manager asks for a batch that evades the per-item limit; a failed action is retried without read-back; or a rejected action is delegated to a more privileged agent.

Use public incident reports, internal near misses, red-team findings, and comparable system evidence where available. NIST’s AI RMF Map playbook recommends documenting likelihood and magnitude and using the estimates to inform go/no-go decisions and testing resources.

§ 05Score Eight Inherent-Exposure Dimensions

Score the role before crediting controls. Use 1 to 5 for each dimension.

The scale is an editorial operating model, not an external standard. Calibrate examples to your organization and apply them consistently.

1. Consequence

Score the worst credible consequence, not the average output.

2. Affected scale

Include cumulative scale over a shift, day, campaign, and role lifecycle.

3. Data sensitivity

Include memory, handovers, logs, exports, and child-agent context - not only the first read.

4. Action authority

The least-privilege guide should narrow identity, tools, resources, data, functions, destinations, time, and delegation before launch.

5. Reversibility

Do not score a theoretical rollback. Demonstrate it.

6. Detectability

Slow detection increases the number of actions that can accumulate before containment.

7. Uncertainty and novelty

Confidence from the model is not enough. Consider source quality, test coverage, and environment similarity.

8. Propagation

Include every automation that the tool call triggers.

Calculate without hiding the maximum

Record:

Total exposure = sum of eight dimensions (8-40)

Also record: the maximum dimension; dimensions scored 4 or 5; hard stop status; the highest-consequence scenario; the weakest recovery path; and evidence confidence.

A maximum score of 5 can override the band. Organization-specific policy should define which dimensions and scenarios require that override.

Calibrate the scale with reference roles

Before using the worksheet for real decisions, score several known roles together.

Ask each assessor to score independently, then discuss the evidence behind differences. Do not average away disagreement immediately. A security owner may see a transitive credential path that the process owner missed. A domain reviewer may understand that a “draft” effectively becomes a decision because staff rarely change it. An operations owner may know that the supposed rollback has never worked inside the required time.

For every score, require a sentence:

Detectability = 4 because the downstream system records only the shared integration account, customer impact may appear after delivery, and no alert correlates the action with the originating task.

That sentence is more valuable than the number. It exposes the facts that a control must change.

Revisit reference cases after material incidents or policy changes. Calibration should improve as the organization learns; do not preserve old anchors merely to keep historical totals comparable.

Avoid false mathematical precision

Do not multiply uncertain dimension scores, convert them into a percentage, or call the total a probability. A score of 32 is not “twice as risky” as 16. The bands are routing aids.

When likelihood evidence is weak, use scenario language: plausible under normal operation; plausible under foreseeable misuse; observed in tests; observed in a comparable deployment; observed internally; unknown because coverage is insufficient; or unlikely only if a named tested control remains effective. This language keeps uncertainty visible.

Run a sensitivity review

After the initial decision, change one assumption at a time: volume increases tenfold; public release replaces internal draft; a reviewer is unavailable for one shift; the source becomes stale; a new connector adds write access; a child agent receives the task; logs lose task correlation; rollback exceeds the business deadline; personal data enters the workflow; a customer can submit untrusted files; or the role moves from staging to production.

Record whether the autonomy decision changes.

A role that is safe only while every assumption remains perfect is not robust enough for broad autonomy.

Score material action families separately

One employee may perform public-source research, internal drafting, external email, CRM updates, spend, publication, delegation, and access administration.

Do not assign one blended score. Score each material family, then set the role’s operating policy to the highest required control for that action. The research function may receive bounded execution while external send remains approval-gated and access administration stays blocked.

This is also why the best-tasks guide recommends beginning with recurring work whose inputs, outputs, evaluation, and escalation can be made explicit. A role can be valuable even when its riskiest actions remain human-owned.

§ 06Map Controls and Residual Risk

Now identify controls. Do not simply subtract points because a control exists.

The AI agent guardrails model layers task, context, identity, authorization, tool, validation, approval, execution, postcondition, monitoring, and response controls.

Grade control evidence

Do not treat a claim or screenshot as equivalent to tested enforcement.

Write residual risk in words

For each material scenario, document:

After controls, the AI employee can still draft an incorrect renewal claim from a stale but allowlisted source. The draft cannot be sent externally. A named reviewer receives source dates and conflicts. Remaining impact is reviewer time and possible internal delay. The risk owner accepts this for a 30-day pilot with weekly source-freshness review.

This preserves scenario, remaining failure, control, impact, owner, duration, and review.

ISO/IEC 23894:2023 provides guidance for integrating AI risk management into organizational activities. Use standards and legal frameworks relevant to your context; do not assume this worksheet alone satisfies them.

§ 07Convert the Assessment Into an Autonomy Decision

Choose authority per action, not for the role as one switch.

Write an autonomy envelope

Example:

The Content Operations AI Employee may research from approved public and project sources, create drafts in the staging workspace, apply validated internal links, and update the task board. It may not publish, send external messages, edit site templates, access customer data, change permissions, or delegate a connected tool. Every public release remains human-approved. Missing or conflicting primary evidence blocks completion.

The permissions and approvals matrix turns this decision into enforceable action rules.

Make promotion evidence-based

Require: a minimum representative sample; accepted-output quality; a material defect rate below limit; no missed critical escalations; action matching approval; permission-denial tests passing; postconditions succeeding; no unresolved material incidents; a passing recovery exercise; viable reviewer load; and actual use matching the assessed context.

Use the AI employee pilot guide to time-box the decision, preserve baselines, and define expansion criteria.

Define demotion triggers

Reduce authority when: a material incident or near miss occurs; a score dimension increases; controls fail; monitoring coverage drops; rollback no longer works; the model, tool, connector, data, destination, or role changes; actual volume exceeds the assessed scale; delegation is introduced; reviewer decisions reveal policy ambiguity; or evidence becomes insufficient.

Demotion can target one action or connector rather than disabling the full role.

§ 08Validate the Assessment With Tests

Risk scores are hypotheses about real behavior. Test them.

Test the severe scenario directly

If one plausible failure could be severe, do not wait for it to appear in a random sample. Construct the case and prove: trigger detection; prevention or routing; human decision; no unauthorized side effect; complete evidence; containment; recovery; and closure.

Include control interactions

Controls can interfere: redaction removes evidence the reviewer needs; a timeout expires while approval waits; a rate limit blocks containment; a narrow credential prevents rollback; a circuit breaker leaves queued actions active; an agent handover omits the incident state; or a child agent’s result bypasses the parent’s validation.

Test the complete workflow, not isolated controls.

Record uncertainty

For each test, mark: representative/not representative; deployment-like/not deployment-like; sufficient/limited sample; known coverage gaps; unresolved disagreement; untested dependency; and confidence in result.

Unknown risk should not be converted to a zero.

§ 09Assign Ownership and Preserve Evidence

Risk acceptance belongs to an accountable human or organization, not the AI employee.

Include affected expertise

Depending on the role, involve: the process owner; intended users; affected-party representatives; a domain expert; security and privacy owners; the data owner; the system administrator; legal/compliance counsel; the human reviewer; the incident-response owner; and accessibility or fairness expertise.

One product owner should not score every dimension alone.

Preserve reconstruction evidence

The AI employee audit-log guide should let a buyer reconstruct: which role and policy were active; who initiated work; which data and tools were used; which controls fired; which human approved; what action occurred; what state changed; whether limits were reached; and how recovery completed.

If material events cannot be reconstructed, increase the detectability score and restrict authority.

§ 10Reassess Throughout the Role Lifecycle

Set a recurring review and event triggers.

Compare intended and actual use

Monitor: task types actually performed; resources and fields accessed; tools and actions used; destinations reached; volume and spend; human review rate; overrides and exceptions; denied attempts; child-agent use; defects and incidents; time to detection; and recovery performance.

If actual use expands beyond the role card, pause that scope and reassess.

Keep risk and benefit together

A control that removes all useful work is not an effective deployment. Record: expected benefit; accepted outcomes; capacity released; review and correction cost; control friction; remaining risk; and the safer alternative.

Risk acceptance should compare the controlled role with feasible alternatives, including a manual process that may have its own errors and delays.

§ 11How to Assess a CellCog AI Employee

CellCog publicly describes AI Employees with roles, goals, KPIs, permissions, schedules or wake conditions, task boards, memory, handovers, approval expectations, connected tools, browser or desktop access, and delegation. Assess each configured capability and the downstream system it reaches.

Run the assessment in this order

1. Write the role card and non-goals.
2. Apply hard stops.
3. Build normal, boundary, misuse, failure, and incident scenarios.
4. Score eight inherent-exposure dimensions.
5. Map controls and grade evidence.
6. Test severe scenarios and control interactions.
7. Write residual risk in scenario terms.
8. Choose authority per action.
9. Name the risk owner and review triggers.
10. Reassess before expansion.

CellCog’s AI Employees page describes connected work and persistent shifts. Verify the current platform, account permissions, and connected application before relying on any specific scope, approval, monitoring, or revocation behavior.

Users set the employee’s goals, schedule, permissions, and connected accounts, and remain responsible for monitoring its work and the actions it takes on their behalf. For legal, medical, financial, hiring, or other high-impact work, AI output requires qualified human review and should not be treated as professional advice or a final high-impact decision.

Use the production security checklist to verify that required evidence exists before the pilot receives real data or action authority.

§ 12Final Checklist

• The role, purpose, beneficiaries, affected parties, tasks, non-goals, and owner are documented.
• Intended use, adjacent use, foreseeable misuse, failure, abuse, drift, and emergency cases are mapped.
• Hard stop conditions were applied before scoring.
• Professional or high-impact decisions remain with qualified people where required.
• Consequence, scale, data, authority, reversibility, detectability, uncertainty, and propagation are scored.
• The total, maximum dimension, 4/5 scores, severe scenario, recovery weakness, and evidence confidence are preserved.
• Controls map to specific scenarios and enforcement points.
• Control claims, configuration, tests, observed evidence, and recovery proof are distinguished.
• Positive, negative, boundary, misuse, adversarial, partial-failure, human, delegation, and recovery cases are tested.
• Residual risk is written in scenario terms.
• Authority is assigned per action, not as one role-wide autonomy switch.
• Promotion and demotion criteria are defined.
• An accountable human risk owner signs the decision.
• Exceptions have scope, owner, evidence, expiry, and review.
• Material actions can be detected and reconstructed.
• Pause, revoke, contain, restore, notify, and resume paths are proven.
• Actual use is compared with the assessed role.
• Scheduled and event-driven reassessment triggers exist.

The score is a way to force explicit comparison. The decision still depends on scenarios, evidence, affected people, control effectiveness, residual risk, and accountable judgment.