What is AI governance?
AI governance is the set of responsibilities, decisions, and checks a company uses to guide how AI is chosen, used, and reviewed. It covers more than software access. It also asks whether a use is appropriate, how people can challenge an output, and who acts when something goes wrong.
An inventory is a useful start. A usable governance process connects each AI use to a business purpose, a responsible person, an approval, and evidence of what happened.
Four questions to organize the work
NIST’s voluntary AI Risk Management Framework uses four functions: Govern, Map, Measure, and Manage. It is a way to organize risk work, not a certification.
Govern: Who makes decisions and who is accountable? Map: What is the context, who is affected, and what could go wrong? Measure: What evidence tells us how the system behaves? Manage: What will we change, limit, or stop when the evidence calls for action?
Start with one real task
Consider a team preparing supplier records. An assistant might read a packet and draft missing fields. Changing bank details or approving a supplier is a different action with different consequences. Calling all of these “supplier automation” hides the decisions that matter.
Write down the input, the steps, the expected output, the next recipient, and the software used. Then identify the steps that need a person’s judgment and the actions that require separate permission. This makes a policy specific enough for an operator to use.
Separate the types of control
Business review asks whether the work should be done and whether the result is useful. Identity and access controls determine which account can act on which resource. Runtime controls check actions as they happen. Risk and compliance work sets the wider rules and retains evidence.
These layers overlap. Buying one tool does not remove the need to decide who owns the process. Ask which controls are actually enforced, which are recommendations, and which require another system.
What to collect in discovery
Ask leadership for goals, priorities, departments, and the people who should take part. Ask team members to explain a recent task in their own words. Capture delays, exceptions, handoffs, and software use alongside the normal process.
Let each person review the task description extracted from their account. Their confirmation means “this describes my understanding of my work.” It does not grant access, prove company policy, or settle a disagreement with another team. An advisor can compare those accounts and resolve the gaps.
Where DutyGraph fits
DutyGraph starts with advisor-led discovery and a connected record of people, duties, and tasks. The pilot is intended to test that process with real teams. Its governance sample illustrates how that work context can inform an agent request and a proposed manifest.
The sample does not provision a live identity or enforce permissions in another system. Use the landscape guide to understand the other layers a production program may need.
Sources
Primary references used in this guide.