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 risk2= controlled but incomplete3= material risk requiring remediation before broad deployment4= high risk that limits deployment to tightly bounded pilots5= 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
1or2if 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 risk100= 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
5on 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.