Both matter, but the workflow often creates the real risk. The model may be the engine, yet data sources, prompts, access paths, and handoffs determine whether the system stays within policy. Governance has to cover the full operating context, not just the model artifact in isolation.
Why the workflow often matters more than the model artifact
The model is only one component of an AI system. In practice, the operating workflow is where policy violations, data exposure, overreach, and unsafe outputs usually become possible, because it determines what the model can see, what it can call, and how its outputs are consumed. That is why governance has to assess the full path from input to action, not just the base model.
Data sourcing, prompt construction, retrieval, tool calls, and human handoffs all shape the real security boundary. A well-known model can still be governed poorly if it is embedded in a workflow that pulls in unapproved data, accepts untrusted instructions, or allows outputs to trigger downstream actions without review.
What belongs in scope when you govern the surrounding workflow
Workflow governance should cover the data inputs, prompt handling, access paths, and decision points that sit around the model. That includes who can submit prompts, which systems the model can reach, what context is injected, how outputs are filtered, and whether a human or automated step can act on those outputs.
This is also where policy gaps usually show up. If the model is approved but the connected retrieval layer, integration layer, or handoff process is not governed with the same rigor, the overall system can drift outside intended use even though the core model remains unchanged.
Good governance treats the workflow as the control surface. NIST AI 600-1 GenAI Profile is useful here because it focuses attention on lifecycle controls, testing, provenance, and incident handling around the deployed system, not only the model artifact.
How to decide whether model risk or workflow risk is the binding issue
Ask where the unsafe behavior actually emerges. If the concern is capability limits, robustness, bias, or hallucination intrinsic to the model, model-centric controls matter most. If the concern is unauthorized data access, unsafe prompt pathways, uncontrolled tool use, or unreviewed downstream action, the workflow is usually the binding risk.
That distinction matters because the right control is different. Model-only review may satisfy a procurement checklist, but it will miss the operational conditions that turn a compliant model into an unsafe system. Conversely, over-focusing on the workflow while ignoring model behavior can leave a system vulnerable to systematic output failures that no amount of routing logic can fix.
For governance programs, the practical test is whether you can explain the system’s trust boundary end to end. NIST AI Risk Management Framework helps structure that question, while ISO/IEC 42001:2023 AI Management System Standard reinforces that governance should cover the organization’s AI operating context, accountability, and risk treatment.
Risk and Threat Considerations
When governance stops at the model, the surrounding workflow becomes the easiest place for exposure to accumulate. Untrusted prompts, weak access controls, permissive connectors, and poorly governed human handoffs can let a system leak sensitive information or take actions that were never intended by policy.
Failure mechanism: The workflow expands the effective attack surface by combining model output with retrieval, APIs, files, identities, and human approvals. An attacker does not need to break the model if they can influence the context, abuse a connected tool, or exploit an over-permissive handoff.
Impact: The result can be data exposure, unauthorized action, policy bypass, or business harm that appears to originate from the model but is actually caused by the surrounding system design. That is why workflow control is often the difference between a contained AI feature and an operational risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Workflow access paths should be limited to the minimum needed for AI system operation. |
| IA-2 — Identification and Authentication (Organizational Users) | Human handoffs and approvals in AI workflows depend on strong user authentication. | |
| AU-2 — Event Logging | AI workflow governance needs auditability across prompts, tool calls, and handoffs. | |
| Recommendation — Restrict model-connected tools and data paths to the minimum required permissions. Authenticate users before they can submit prompts, approve outputs, or change AI workflows. Log prompt, retrieval, tool-use, and approval events for traceability and review. | ||
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | AI governance must align the workflow to the business purpose and operating context. |
| Recommendation — Define the AI system’s intended use, stakeholders, and operating boundaries. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The workflow depends on governed access to data sources, tools, and outputs. |
| Recommendation — Apply access control to every workflow component that can influence or consume AI output. | ||
Practitioner Guidance
What to prioritise: Start with the highest-risk workflow junctions, especially data ingestion, retrieval, tool invocation, and any step where model output can trigger action. Those are the points where governance failure becomes operationally visible.
What to verify: Confirm that every connected data source, permission scope, and handoff has an explicit owner and an allowed-use policy. If you cannot trace who can influence context or consume output, the system is not governed at the workflow level.
Decision rule: If the model is low risk but the workflow has broad access or autonomous side effects, treat the workflow as the primary control problem. If the workflow is tightly bounded but the model is inherently unreliable for the task, the model itself becomes the main governance concern.
Practitioner takeaway: The safe unit of governance is the deployed AI system, not the model file. In most real environments, that means controlling context, access, and action paths first, then validating the model inside those boundaries.