Unseen AI Operational Risk Framework (AIORF v1.0)

The Unseen AI Operational Risk Framework (AIORF) is the standard method for assessing whether a Salesforce environment can support AI agents without introducing uncontrolled operational risk.

Framework AIORF v1.0

Series AI Readiness

Published May 2026

Purpose

The Unseen AI Operational Risk Framework (AIORF) is the standard method for assessing whether a Salesforce environment can support AI agents without introducing uncontrolled operational risk.

The framework is designed for enterprise buyers evaluating Agentforce, copilots, workflow agents, retrieval-backed assistants, or custom AI automations that read from or write into Salesforce. It translates opaque CRM conditions into a defensible risk posture leadership can act on.

AIORF should be used after, or alongside, the Unseen Operational Intelligence Audit so the AI conversation starts from evidence rather than enthusiasm.

Core Principle

AI does not create most Salesforce risk. It amplifies the risk already embedded in the environment:

poor data becomes faster bad decisions
conflicting automation becomes harder-to-debug system behavior
weak permission design becomes unauthorized agent reach
undocumented process logic becomes non-repeatable agent judgment
unmanaged model behavior becomes operational inconsistency at scale

Assessment Scope

AIORF covers five risk categories:

Data Quality Risk
Automation Conflict Risk
Permission Boundary Risk
Logic Opacity Risk
Model Drift Risk

Each category is scored on a 1-5 scale where:

1 = low operational risk
2 = controlled but incomplete
3 = material risk requiring remediation before broad deployment
4 = high risk that limits deployment to tightly bounded pilots
5 = critical risk; deployment should not proceed without structural intervention

Evidence Rules

Scores must be tied to named artifacts, observed behaviors, metadata inspection, and stakeholder interviews.
No category can score 1 or 2 if critical workflows rely on undocumented exceptions, unknown owners, or untraceable changes.
A score may be improved only by evidence of control, not by confidence statements from stakeholders.
For production deployment decisions, sample-based review is insufficient on revenue-critical objects, automations, and permissions.

Risk Categories And Weights

Category	Weight	What it measures	Evidence to review
Data Quality Risk	20%	Whether the records, fields, and historical patterns an agent relies on are complete, consistent, and trustworthy enough for action.	Critical field population, duplicate fields, validation coverage, historical data anomalies, exception handling, ownership of key data definitions
Automation Conflict Risk	25%	Whether the agent will operate inside an already-crowded automation surface where flows, Apex, routing logic, or approvals can produce collisions or unintended side effects.	Flow inventory, trigger overlap, legacy automation, recursion controls, fault handling, sequencing rationale
Permission Boundary Risk	20%	Whether the org can define and enforce what the agent may read, suggest, update, approve, or trigger.	Profiles, permission sets, service accounts, delegated admin, field-level security, approval authority, segregation of duties
Logic Opacity Risk	20%	Whether the business logic the agent is expected to follow is documented, explainable, and institutionally owned.	SOPs, decision trees, exception rules, process maps, metadata descriptions, knowledge-holder concentration
Model Drift Risk	15%	Whether the organization can detect and govern performance degradation, prompt drift, context drift, or business-policy drift after deployment.	Versioning, evaluation cadence, prompt governance, feedback loops, rollback paths, KPI monitoring

Scoring Anchors By Category

Category	`1` Low Risk	`3` Material Risk	`5` Critical Risk
Data Quality Risk	Critical fields are defined, owned, and reliably populated; historical records are usable for agent context; duplicate semantic fields are controlled.	Several critical fields are inconsistently populated or ambiguously defined; some decisions still depend on admin interpretation or cleanup.	Agents would rely on records or fields that are widely incomplete, contradictory, duplicated, or historically untrustworthy.
Automation Conflict Risk	Critical objects have a mapped automation surface with known order-of-execution and low collision risk.	Agent actions would enter objects with partial automation mapping, unresolved overlap, or insufficient fault-path visibility.	Agent behavior would run through an org with frequent collisions, legacy automation sediment, or unknown side effects on critical objects.
Permission Boundary Risk	Agent scope is explicitly bounded by action class, object, field, and approval rule; privileged actions are separated.	Some agent permissions are defined, but service-account access, field-level controls, or escalation ownership remain ambiguous.	The org cannot clearly state what the agent can and cannot do, or privileged access is already too broad to govern safely.
Logic Opacity Risk	Core process logic, exception paths, and business intent are documented and owned by the institution.	Happy-path logic is mostly documented, but exception handling, local workarounds, or cross-team dependencies remain partly oral.	Business logic exists primarily in memory, ticket history, or legacy admin habits; the institution cannot explain why the org behaves as it does.
Model Drift Risk	Agent outputs are versioned, monitored, and evaluated against known business-quality thresholds with rollback in place.	Monitoring exists for some workflows, but evaluations are irregular and policy changes are not consistently reflected in prompts or instructions.	There is no practical mechanism to detect degraded output quality, business-policy drift, or harmful behavior before impact reaches operations.

Composite Risk Calculation

Step 1: Score each category

Assign an integer score from 1 to 5 for each category.

Step 2: Calculate weighted average risk

Weighted Risk Score = sum(category score x category weight)

Example:

Category	Score	Weight	Weighted contribution
Data Quality Risk	4	0.20	0.80
Automation Conflict Risk	5	0.25	1.25
Permission Boundary Risk	3	0.20	0.60
Logic Opacity Risk	4	0.20	0.80
Model Drift Risk	2	0.15	0.30
Total			3.75

Step 3: Convert to normalized risk index

AI Risk Index = ((Weighted Risk Score - 1) / 4) x 100

This converts the 1-5 weighted score into a 0-100 risk index where:

0 = minimum observed risk
100 = maximum observed risk

In the example above:

((3.75 - 1) / 4) x 100 = 68.75

Rounded result: 69

Risk Profiles

Profile	AI Risk Index	Practical meaning	Recommended intervention
Low	`0-24`	The org has the structural controls needed for bounded production use. Risk is not absent, but it is legible and governable.	Proceed with a tightly scoped pilot or production use case under active governance and monitoring.
Moderate	`25-49`	The org is directionally ready, but specific control gaps would make broad deployment irresponsible.	Remediate named gaps before expanding beyond recommendation-only or human-approved use cases.
High	`50-74`	The org can support only narrow, highly supervised AI use. Broad execution authority would amplify existing operational weakness.	Pause broad deployment. Run targeted remediation across documentation, automation, permissions, and monitoring before pilot scale-up.
Critical	`75-100`	The environment is not structurally ready for operational AI. AI would multiply ambiguity faster than the organization can contain it.	Do not deploy autonomous or write-enabled agents. Start with Unseen recovery, documentation, governance, and control work.

Hard-Stop Conditions

Regardless of the normalized score, the profile must be set to High or Critical if any of the following are true:

Permission Boundary Risk scores 5
Logic Opacity Risk scores 5
Automation Conflict Risk scores 5 on revenue-critical objects the agent would touch
there is no human escalation path when the agent encounters an undocumented rule, exception, or failed write
the proposed agent can approve, reassign ownership, modify lifecycle stage, or trigger downstream systems without explicit approval boundaries

Recommended Intervention By Profile

Profile	What Unseen does	Exit criteria before next level
Low	Validate the target use case, define action boundaries, establish evaluation metrics, and implement operating guardrails.	Pilot KPIs defined, logging live, business owner assigned, rollback tested.
Moderate	Run focused remediation on the affected surfaces: data definitions, automation mapping, field ownership, permissions, or prompt governance.	All blocking controls documented and evidence-backed; unresolved gaps are explicitly accepted by leadership.
High	Conduct a formal AI readiness engagement using audit outputs, living documentation, automation collision analysis, and governance design before deployment.	Critical workflows documented, permission model bounded, unresolved collisions reduced, human review inserted into risky paths.
Critical	Start with knowledge recovery and control reconstruction. The goal is to make the org explainable before any agent is allowed to act inside it.	Revenue-critical logic is mapped, asset ownership is assigned, and baseline governance exists for change, monitoring, and escalation.

Remediation Pathways Mapped To Unseen's 6-Stage Model

Risk profile	Required stages	What the pathway looks like
Low	Stage `4` Governance, Stage `5` AI Readiness, Stage `6` Operational Intelligence Platform	The org is already understandable enough to move directly into AI guardrails, instrumentation, and operating metrics.
Moderate	Stage `1` Audit, Stage `2` Living Documentation, Stage `4` Governance, Stage `5` AI Readiness	The environment needs targeted evidence recovery before AI policies can be trusted.
High	Stage `1` Audit, Stage `2` Living Documentation, Stage `3` Monitoring, Stage `4` Governance, Stage `5` AI Readiness	The org requires structural visibility and active control before AI use can expand beyond constrained pilots.
Critical	Stage `1` Audit, Stage `2` Living Documentation, Stage `3` Monitoring, Stage `4` Governance, then reassess for Stage `5`	AI work should not proceed until the institution can explain how the environment currently behaves and who owns it.

Standard Output

Every AIORF engagement should produce:

category scores with written rationale
normalized AI Risk Index
final risk profile and any hard-stop overrides
named deployment blockers
use-case specific guardrails
a remediation roadmap tied to Unseen's six-stage model

Executive Reading Of The Score

Leadership should interpret AIORF as a control-readiness score, not as a statement about AI ambition.

A low score means the organization can govern AI.
A high score means the organization would be asking AI to operate inside a system it does not sufficiently understand.
The value of the framework is not the number alone. It is the conversion of hidden Salesforce ambiguity into a visible, governable decision.

Ready to assess your Salesforce org?

Email hello@unseen.so to request an AI Readiness Audit.