What should organisations do first when they cannot fully describe an AI workflow?

What “first” means when an AI workflow is too ambiguous to govern

The first task is not approval, policy tuning, or control selection. It is to force the workflow into a describable state: who or what acts, which model is used, which tools are invoked, what data is read or written, and which identities hold authority at each step. If those elements are still fuzzy, the organisation does not yet have a governable workflow.

This is a subject-definition problem before it is a control problem. A vague workflow cannot be reliably assessed for approval, monitored for deviation, or attributed after an incident because the effective system boundary is unknown. The description has to be specific enough that a reviewer can trace the decision path and the authority path separately.

That usually means building a minimum operational inventory rather than a full policy document. At a practical level, the workflow description should distinguish the agent, the model, the tools, the prompts or instructions that shape behaviour, the data sources involved, and the identities or service accounts that can act on behalf of the system. If any of those are missing, the organisation is still guessing about what it is actually operating.

Why description comes before approval, monitoring, or attribution

Governance depends on a stable object. When a workflow cannot be described, reviewers cannot tell whether the same process is being used across teams, whether a new tool has been introduced, or whether an identity has broader access than intended. That is why description is the prerequisite for any credible control model, not just an administrative nicety.

It also sets the baseline for change control. Once the workflow is describable, the organisation can decide what needs human review, what needs logging, what needs access restriction, and what should be disallowed altogether. Without that baseline, monitoring becomes noise and approvals become performative because there is nothing concrete to compare against.

NIST AI Risk Management Framework is relevant here because it treats AI risk management as an organised, lifecycle activity that depends on knowing what system you are governing. In practice, use that discipline to define the workflow before deciding how it should be trusted or controlled.

NIST Cybersecurity Framework 2.0 also fits because the Govern and Identify functions both assume an understood asset or service boundary. If the workflow cannot be described, those functions cannot be applied consistently to it.

NIST Privacy Framework is useful where the workflow touches personal or sensitive data, because data flow description is what makes downstream privacy review possible. If you do not know which data moves through the workflow, you cannot evaluate exposure with any confidence.

What the minimum workable description should contain

The minimum description should answer five questions: what the workflow is trying to do, what component makes decisions, what tools it can invoke, what data it can access, and which identities are responsible for each action. That is enough to separate intent from implementation and to identify where authority actually resides.

For agentic systems, the identity boundary matters as much as the model boundary. A workflow may be technically “one system” but still rely on multiple identities, each with different permissions, tokens, and execution paths. If the same description does not capture those identities, the organisation will miss where privilege is concentrated or where an apparently small change can expand blast radius.

OWASP Agentic AI Top 10 is a useful companion once the workflow is describable, because several of its risks depend on knowing how agents, tools, and privileges are actually arranged. Use it to pressure-test the description, not to replace the description itself.

OWASP Non-Human Identities Top 10 is relevant when the workflow uses service identities, tokens, or keys to reach tools and data. That matters because hidden or undocumented machine authority is one of the fastest ways a workflow becomes unreviewable in practice.

NIST Cybersecurity Framework 2.0 and the control catalogs that sit behind it both assume that assets, identities, and boundaries are knowable before they can be protected. The same logic applies here: description is the prerequisite for control selection, not the result of it.

Risk and Threat Considerations

Ambiguous AI workflows create hidden authority. That is dangerous because an attacker, a rogue configuration, or an overbroad integration can exploit the uncertainty to move through tools, data, or identities that were never meant to be part of the approved operating model.

Failure mechanism: The organisation cannot distinguish the intended workflow from the effective workflow, so access, logging, approval, and ownership controls are applied to the wrong object or to only part of the actual execution path.

Impact: Undocumented tool use, excessive privilege, untraceable actions, and weak incident attribution become more likely, especially when the workflow reaches production data or can trigger external side effects.

Practitioner Guidance

What to prioritise: Start with a one-page operational description that names the actor, model, tools, data sources, and identities involved. If any of those cannot be named clearly, treat that as a governance gap that must be resolved before any approval discussion.

What to verify: Check that the description matches actual runtime behaviour, not just the intended design. The most common mistake is approving a diagram while the live workflow has additional tools, fallback paths, or service credentials that were never reviewed.

Decision rule: If you cannot explain who can act, what they can access, and what they can change, do not classify the workflow as governed yet. Require description first, then control design, then monitoring, then approval.

Practitioner takeaway: The right first move is to make the workflow legible enough that authority, data movement, and tool use can be reviewed separately; until then, any approval is premature.

Related resources from NHI Mgmt Group

• What should organisations do first when they cannot see data flow between AI tools and SaaS apps?
• Should organisations prioritise external exposure or internal credential governance first?
• What should organisations do first when they start governing AI agent behaviour?
• How should organisations govern AI models that cannot fully explain their outputs?