AI Strategy
What AI Governance Consulting Covers Before an Agent Acts
Published Oct 29, 2026
AI governance consulting sets the usage policy, approval gates on send, pay, post, and delete, the audit trail, and vendor risk before an agent acts.
What AI Governance Consulting Covers Before an Agent Acts
AI governance consulting writes the rules for how a company uses models and agents: who may use them, which actions need a person before they send, pay, post, or delete, what the audit trail must show, and which vendors are allowed to see the data. It is not a data dictionary. It is the control on the action.
I write this for the operator who was told to "put governance around AI" after a pilot already sent a customer email, or just before one is about to. I build the loops. The failure I see is not a missing principle. The failure is an action that left the building with no named person and no record. The principle poster was on the wiki the whole time.
How mid-market companies choose AI consulting services is the hub above this page. That page is how you pick a partner and a first workflow. This page is the control that partner has to leave behind. If you do not yet have a workflow, do not start with a policy for every model in the market. Pick the action you are about to allow. Govern that.
What does AI governance consulting actually cover?
It covers four controls. I keep them on one workflow. A company-wide AI policy that names every future use case is a writing project. It will be stale before the second team reads it.
Usage policy. Who may use which model or agent, and what data may enter a prompt. The policy is a card. This role may use this agent. Customer data may not go into a personal chatbot. A draft may be generated. A send may not. If the card does not fit on a screen, the real policy will be whatever the last person pasted into a prompt.
Approval gates. A person, on the actions that commit the business. Four verbs. Send. Pay. Post. Delete. Anything that transmits a commitment, moves money, publishes in the company's voice, or destroys a record stops for a named person. Lookups do not. Drafts do not. The gate is a control in the path, not a meeting.
Audit trail. What you can reconstruct on a Thursday without asking the vendor to export a feeling. Who approved. Which model. Which tool. Which record. What actually left. A chat transcript is not that record. The next message can edit a transcript, and a transcript does not prove a click.
Vendor risk. Who else can see the prompt, the tool payload, and the log. The model vendor. The tool vendor. The subprocessor under them. The builder's personal account, if that is where the key still lives. A vendor login is not an owner. If the only person who can revoke the key rolled off, you do not have vendor risk managed. You have a key.
If any of the four is a slogan, the consulting is not done. Is there a name. Is there a behavior in the system. Can a person who missed the meeting still tell whether it ran.
What does a first engagement produce?
A first engagement produces those four controls for the workflow that is about to act. It does not produce a model registry of things you might buy next year.
The packet I leave is short.
The usage card. Roles, agents, and the classes of data that may enter a prompt. Customer content, credentials, and the unpublished number the board has not seen are either allowed, with a named vendor, or they are not. A poem about confidentiality is not a card.
The gate list. One row per committing verb this workflow can actually perform. Each row names the person, the action they take, and what happens if they do not take it. The default is that the action does not happen. "Send anyway after an hour" is a delay, not a gate.
The audit fields. Columns you store yourselves. Who, when, which model, which tool, which record, what left. A console you can see only while the contract is paid up is not your record. If a column cannot be filled, the gate is theater.
The vendor sheet. For each vendor in the path, what they receive, and who on your side can revoke access this week. Their trust center is their document. The sheet is yours.
The refusal list. Agents that stay off until the card, the gate, and the audit exist. A project that turns every toggle on is a launch plan.
Hand the packet to the person who will pause the loop next month. If it lives only in a slide, the first send will not consult the slide.
What does an approval gate look like when it is real?
A real gate has a person, an unambiguous action, an expiry, and a record. I am particular about this because I have watched the fake version. The fake version is a sentence. "The agent should ask a human." The agent asks in the chat. Someone types yes. The send goes out. On Thursday you have a transcript and a customer, and you cannot tell the yes from a guess the model made about what yes should look like.
On a media production pipeline we build, a high-impact step proceeds only when the owner uses a one-time link. The link expires after 15 minutes. When it expires, the agent mints a fresh link. It does not accept yes in the chat as a substitute. The click is the audit trail. The chat message is not. I am not telling you to copy the 15 minutes. I am telling you the properties. The approval is outside the transcript. It expires. The agent cannot upgrade a stale approval into a current one. A new action needs a new click.
Put that shape on send, pay, post, and delete. Do not put it on every lookup. The other failure is the one digital transformation governance bottlenecks already describe. Every ordinary change waits on too many people, the work stalls, and someone routes around the process. AI governance that escalates every token will be routed around. That sibling page is approval debt on transformation. This page is a few gates on committing actions. If nothing can ship because six people must bless a field change, read that page. If an agent can email a customer while you are in another meeting, stay here.
The person on the gate has to be reachable. A gate owned by someone with no delegate will be bypassed the first time a customer is waiting. Name the delegate on the card.
What has to be in the audit trail?
The audit trail answers a reconstruction, not a vibe. A customer got the wrong email. A payment left. A post went up in the company's voice. A record disappeared. You open one place and you see the path.
Store the fields where you can export them without a support ticket. Who approved, as a person. When, including an approval that expired unused. Which model, by a name you can say again next month. "The AI" is not a name. Which tool, the action, not the platform. Which record, so you can tell this customer from the one the model almost used. What left: the payload that was sent, paid, posted, or deleted, not a summary the model wrote afterward.
If the only copy of that story is the vendor's console, you are renting your own history. I treat that as an unfinished engagement. A green dashboard is not the same as opening the record of what a customer received. After an agent can send, someone on your side has to be able to open that record.
What vendor risk belongs in the engagement?
Vendor risk, for this work, is not a questionnaire you file. It is a map of who can see the data and who can cut them off.
Start with the key. Where it lives, and who can rotate it this week. I keep finding it in a personal account or a shared password note. The agent runs. The company does not own the off switch. On a mobile identity app I build, a screen kept sending a stored login token that had already expired. The token was there. It was old. A vendor key has that shape. Present is not the same as owned.
Then the payload. On a normal step, does the model vendor get the full customer record, or an id and a question. Does the tool vendor get the draft, or the draft plus attachments nobody meant to include.
Then the log and the exit. Who else can read the prompts, and what you keep if you cut the vendor off this afternoon. An agent that only lives in a console you are about to lose is hosted, not governed. Technical due diligence asks the same question on a deal. Can you operate, revoke, and reconstruct when that login leaves.
A usage policy that does not name vendors is a poster.
How is this different from data governance consulting?
Data governance consulting is the other job. It names who owns a record, what the word means, who may read it, and which quality check fails a bad row. This page decides what an agent is allowed to do once that row exists.
I split them because buyers keep hiring one phrase and expecting both. A perfect definition of "active customer" will not stop an agent from emailing the wrong person. A perfect gate on send will not stop the email from using two meanings of "active" and sounding sure. If the row is the fight, do the data page. If the action is the fight, stay here. Most mid-market teams I sit with need both, in that order when the data is split, and in this order when someone has already wired a send button.
When do you need this before the pilot, and when can a pilot wait?
You need AI governance consulting before the pilot when the pilot can commit the business or move data to a vendor you have not named. Send, pay, post, delete. Customer content into a model outside the tenant. A key you cannot rotate. Any one of those, and the gate comes first. I would rather delay a demo than explain a send.
You can start smaller when the agent only reads, the data stays in a system you already operate, a named person can turn it off, and nothing is sent, paid, posted, or deleted. The gate list can say "no committing actions exist." The next request will be to add send, and the sentence is what you amend on purpose.
You do not need a program when there is no workflow yet. Pick the action. Then write the card.
If nobody employed can pause the loop and explain the audit row, that is a seat question. The business case for a fractional CTO is the seat when the blank is product and engineering judgment, including the gate. Do not hire it to decorate a policy.
What I will not call AI governance
Five substitutes show up in the proposals. A principle poster with no verb and no name. A banned-tools list with no owner, which people route around with a personal login. A training that finishes on Friday while the send button is still ungated on Monday. A committee that reviews prompts monthly. The agent does not wait for the month. A vendor checkbox, accepted in procurement and never opened again. The checkbox says the vendor has policies. It does not say your send is gated, your audit is yours, or your key is revocable by a person you employ.
What to do this week
Name the workflow that is closest to acting. Write the four verbs it can perform. For each verb that is send, pay, post, or delete, write the person, the click, and the field you will store. If you cannot write them, turn the verb off. A draft can stay on. The commit stays off.
Then write the vendor line. Who receives the prompt. Who can revoke the key this week. If the answer is a personal account, move the key before you add a single tool.
If you already know which action is ungated, start in chat. Bring the verb. I will tell you whether you are missing a gate, a record, or a row that should have been defined first.
Related reading
Frequently asked questions
What is AI governance consulting?
AI governance consulting writes the rules for how a company uses models and agents. A first engagement covers who may use them, which actions need a person before they send, pay, post, or delete, what the audit trail must show, and which vendors may see the data. A banned-tools poster with no owner is not that work.
What does an AI governance engagement produce?
It produces a usage policy a manager can repeat, a gate on each committing action, an audit record you can open without the vendor, and a vendor list that says who holds the prompt, the key, and the log. It also produces a refusal list. Agents that can act before those four exist wait.
How is AI governance different from data governance?
Data governance decides whether a row is owned, defined, and current. AI governance decides what a model or an agent may do once that row exists, including any action that leaves the building. A clean row can still be emailed. A gate on send does not define the word in the email.
When do you need AI governance consulting before a pilot?
You need it when the pilot can send, pay, post, or delete, or when customer data will leave your tenant into a vendor model. A read-only assistant on data that never leaves, with a named owner, can start smaller. The moment the loop can commit the business, the gate has to exist first.
How is this different from transformation approval debt?
Transformation governance bottlenecks are too many approvals on ordinary change. AI governance is the opposite mistake when it is missing, and the same mistake when every token needs a meeting. The fix is a few gates on committing actions, with a named person and a time limit, not a committee on every prompt.
Written by Anthony Wentzel