👋 Hey, this is Artem and this is The Blueprint. At WIQ, we spend each day forward deployed at Fortune 500 companies working through the hairy journey of AI transformation.
This issue: why AI governance has to follow the work an agent performs.
During a recent review, an AI leader at a large SaaS company stopped us as we walked through how we scored an agent for risk.
We had started at the tool level. If security had approved Gmail, Salesforce, and the automation platform, a workflow using those tools would inherit the approval. This would spare her team from reviewing the same permissions every time someone built an agent.
She disagreed.
Her company already classified tools and data into different risk tiers. The problem was what happened when an agent combined them. Reading an internal email carried one level of risk. Pulling protected customer data into that email and sending it under the company's name carried another.
Both agents could use the same three tools. Each one needed a different approval path.
Enterprise AI governance gets specific at the step level.
Tool approval is too blunt for agent governance
Software used to arrive as a relatively stable bundle of permissions. Security could review what a tool accessed, what it could change, and where it could send data.
An agent assembles those permissions into a process. Its risk changes with the data it touches, the action it takes next, whether that action can be reversed, and who will see the result.
Take an agent using Gmail. It might read an internal thread and summarize the open questions. It might also pull a customer's account history from Salesforce, decide what to offer, and send the response from an employee's address.
The second workflow has more ways to hurt the company. It handles customer data, makes a decision, and speaks for the business. Approving Gmail tells you almost nothing about whether that workflow is safe.
The AI leader showed us how her company wanted those decisions to work. A step that touches protected data may require privacy review. A high-risk action may require security sign-off. Anything that sends a communication on behalf of the company has to be flagged before the workflow reaches production.
The rules describe actions and data flows. The governance system has to do the same.
Put company policy on the steps it governs
Most companies already have the policies they need. They have data classifications, privacy rules, security reviews, and approval requirements. Those policies were written for people and software teams, so they usually live in documents and ticketing systems.
An employee can interpret them as a case develops. An agent needs the relevant rule attached to the moment when it acts.
For each step in a workflow, I would record five things:
the data the agent reads
the system it reads from or writes to
the action it is allowed to take
whether the action can be reversed
the person or team that approves it
That gives security and privacy teams something concrete to review. They can inspect the step where customer data enters the workflow or where the agent creates an external communication. They do not have to approve an abstract description of what the agent might do.
It also makes the policy reusable. If every external communication needs review, the same rule can be applied across sales, support, finance, and procurement workflows. The company maintains one policy while each agent inherits the parts that apply to its job.
Keep the risky step with a person
The most useful moment in our review came when we changed one step from agent-run to human-run.
The workflow's overall risk rating dropped immediately. The builder could see which step had triggered the additional review and decide whether automating it was worth the burden.
This is a much more practical way to think about human approval. The person does not have to sit in front of every routine step. They stay on the decisions where the company needs accountability.
We have seen the same shape in sales workflows. An agent can find a portfolio gap, research the account, and draft an upsell note. The account manager still decides whether the note should be sent. Their approval protects the customer relationship and gives the company a person who owns the outcome.
As the agent proves itself, the boundary can move. A low-risk lookup might become autonomous after enough clean runs. A payment, customer communication, or protected-data decision may remain with a person indefinitely.
The boundary gets chosen one step at a time.
Governance starts while the agent is being designed
Many AI programs treat governance as the review at the end. A team builds the workflow, connects the systems, and then asks security whether it can go live.
By that point, a policy objection can send the whole design backward. The agent may have been built around a data source it cannot use or an action the company will never allow it to take alone.
Apply policy while the workflow is still editable. Show the builder which step touches the most sensitive data. Flag the communication that requires review. Let the process owner keep an irreversible action with a person before engineering builds around the wrong assumption.
At WIQ, we call the resulting record a blueprint. It holds the steps, systems, approval points, and company rules that govern one job. The name matters less than having one place where the process owner, security team, and agent builder can review the same workflow.
Tool permissions remain important. They are simply the first layer. The workflow tells you what the agent will do with them.
If you're working through these decisions now, we keep our practical guides to enterprise agent deployment at getwiq.ai/resources.
The Blueprint. Stories and lessons on AI transformations from founders and operators making it happen.