AI automation governance is the set of rules covering who may build an automation, what it is allowed to touch, who approves it before it runs on live data, what it records, and who owns it afterwards. Without those five answers written down, automations accumulate quietly until one breaks something nobody knew existed.
The Automation Nobody Could Turn Off
The finance team noticed the weekly reconciliation file had stopped arriving. It had run every Monday for fourteen months, pulling data from three systems and posting a summary into a shared folder. Nobody in the room had built it. The person who had built it left in March. It ran under their account, which IT had disabled, and the only documentation was a name in a scheduler nobody had permission to open.
This is not a story about a clever automation gone wrong. It is a story about an automation with no owner, no approval record and no inventory entry, which is the normal state of affairs in most businesses eighteen months into automating things. Governance is what prevents that, and it costs far less than the week finance spent rebuilding the file by hand.
In this guide, you'll learn the five questions governance has to answer, how to build an inventory of what already exists, where approval gates belong, what an audit trail has to record, and how to run a lightweight review cadence that people will actually keep.
The Five Questions Governance Answers
Governance sounds heavy. In practice it is five answers written down and kept current, and most businesses can produce a workable version in a fortnight.
- Who may build. Which roles can create automations, on which platforms, against which systems. A citizen developer building a reminder is not the same as someone wiring a bot into the general ledger.
- What it may touch. The systems, data and actions each automation is permitted to use, with the sensitive categories named explicitly rather than assumed.
- Who approves. The gate before an automation runs against live data, and a second gate before it performs anything irreversible.
- What is recorded. The audit trail: what ran, when, on whose authority, with what result, and what it changed.
- Who owns it. A named person accountable for each automation, and a named deputy. Ownership transfers when people change roles, which is the step almost everyone skips.
Authority Solutions® AI Automations engagements produce these five answers as a one-page policy rather than a document nobody reads, because a policy that fits on a page is a policy people follow.
Start With an Inventory of What Already Exists
You cannot govern what you cannot list, and nearly every business has more automations running than anyone believes.
- Look where they hide. Scheduled scripts, platform automations in your CRM and marketing tools, spreadsheet macros, inbox rules, and anything running under a personal account or a shared service login.
- Record six fields per automation. What it does, what it touches, who built it, who owns it now, when it last ran, and what breaks if it stops. Six fields is enough to make decisions.
- Flag the orphans immediately. Anything with no current owner or running under a departed employee's credentials is the urgent category, because it will fail silently at the worst possible time.
- Rank by blast radius. What happens if it runs wrong, not just if it stops. An automation that emails customers or posts to the ledger carries more risk than one that formats a report.
The inventory usually takes a week and routinely surfaces three times the number of automations the leadership expected. That surprise is the argument for the rest of the governance work.
Where Approval Gates Belong
Approval gates are expensive if you put them everywhere and useless if you put them nowhere. The placement rule is simple: gate on consequence, not on technology.
| Automation type | Before first live run | Per execution | Notes |
|---|---|---|---|
| Internal formatting, reporting, reminders | Light review by the owner's manager | None | Volume is high and consequence is low |
| Customer-facing messages | Owner plus the function lead | None, sampled after the fact | Template and audience reviewed, sending automated |
| Record changes in CRM or finance systems | Owner, function lead and systems owner | None for standard cases, gate for exceptions | Reversibility matters more than speed |
| Payments, contracts, anything irreversible | Full review including finance or legal | Human approval every time | The gate is the control, not the logging |
The most common governance failure is the opposite of over-control: an automation that quietly performs an irreversible action with no gate at all, because it started as a reporting script and grew.
What an Audit Trail Has to Record
An audit trail is what lets you answer "what happened" three months later, during a dispute or a compliance review. Five fields are the working minimum.
- What ran and which version. Automations change. Knowing which version executed is what makes an investigation possible.
- When, and what triggered it. Schedule, event or manual run, with the triggering record identified.
- On whose authority. The service account and, where there was one, the approver. Automations running under personal credentials break this immediately.
- What it changed. The records touched and the before and after values, or a reference to where that detail is stored.
- What the model contributed. Where a model made a classification or drafted content, record the input, the output and the confidence or the alternatives considered. This is the field that is new, and the one auditors increasingly ask about.
Retention matters too. Match the audit retention to the record it touches rather than to a default log retention that expires before anyone thinks to look.
Handling the Parts That Involve a Model
Automations with a model inside them need three controls that pure rules engines do not, and they are worth separating out.
- Input boundaries. What data may be sent to the model, which sensitive categories are excluded, and whether the provider retains anything. This belongs in the policy, not in a developer's judgement.
- Output validation. A rule that checks the model's output before the automation acts on it: format, range, allowed values, or a second check for high-consequence classifications.
- Confidence routing. Low-confidence outputs route to a human instead of proceeding. The threshold is set from evidence during the pilot and revisited as volumes grow.
Authority Solutions® Operations Consulting sets these three during the build, because adding validation to an automation already trusted in production means untangling decisions that were never recorded.
A Review Cadence People Will Keep
Governance fails through neglect rather than disagreement. The cadence has to be light enough that it survives a busy quarter.
- Monthly, fifteen minutes. New automations added to the inventory, ownership confirmed for anything whose owner changed roles, and failures from the previous month reviewed.
- Quarterly, an hour. Permissions reviewed against what each automation actually uses, orphans resolved, and anything not run in ninety days considered for retirement.
- On every departure. Ownership transfer is part of offboarding. This one control would have prevented the reconciliation story entirely.
- On every incident. A short write-up: what happened, what the trail showed, what control was missing, and what changed as a result.
What Good Governance Looks Like in Practice
The signals that governance is working are unglamorous and easy to check.
- Every running automation has a named owner who can be reached and knows they own it.
- Nothing runs under a personal account. Service accounts with scoped permissions, reviewed quarterly.
- Irreversible actions have a gate. Every one, without exception, and the gate is a person rather than a configuration flag.
- An incident can be reconstructed. Someone can say what ran, when, on whose authority and what changed, without a forensic exercise.
- Retirement happens. Automations get switched off when the process changes. A growing inventory that never shrinks is a maintenance burden compounding quietly, which is why our AI Services reviews treat retirement as a standing agenda item.
Where automations write into customer records, our CRM Implementation work ties the audit trail to the record itself, so the history is visible to the people who use the system rather than sitting in a log nobody opens.
Key Takeaways
- Governance is five written answers: who may build, what it may touch, who approves, what is recorded, and who owns it. Most businesses can produce a workable one-page version in a fortnight.
- The inventory comes first, because you cannot govern what you cannot list. Six fields per automation is enough, and the exercise routinely finds several times more automations than leadership expected.
- Approval gates are placed on consequence rather than technology. Reporting scripts need light review; anything irreversible needs a human gate on every execution, not just at launch.
- An audit trail records what ran and which version, when and what triggered it, on whose authority, what changed, and what the model contributed. That last field is the one auditors increasingly ask about.
- Automations with a model inside need input boundaries, output validation and confidence routing, set during the build rather than retrofitted once the automation is already trusted.
- A cadence people keep is monthly fifteen minutes, quarterly an hour, ownership transfer on every departure, and a short write-up after every incident. Governance fails through neglect, not disagreement.
FAQ
What is AI automation governance?
The rules covering who may build automations, what systems and data each one may touch, who approves it before it runs on live data, what it records, and who owns it afterwards. Written down and kept current rather than assumed.
Why does every automation need a named owner?
Because unowned automations fail silently. When the builder leaves and their account is disabled, the automation stops or breaks with nobody accountable, and the business discovers it through a missing output rather than an alert.
How do you find automations nobody documented?
Look in scheduled scripts, CRM and marketing platform automations, spreadsheet macros, inbox rules, and anything running under personal or shared accounts. Most inventories surface several times the number leadership expected.
Which automations need an approval gate on every run?
Anything irreversible: payments, contract actions, external commitments, bulk record deletions. Everything else is gated once before it goes live, with sampling afterwards rather than per-execution approval.
What should an audit trail record?
What ran and which version, when and what triggered it, the account and approver behind it, the records changed with before and after values, and for model steps the input, output and confidence.
How long should audit records be kept?
Match retention to the record the automation touches rather than to a default log policy. Financial and customer records usually have retention requirements that outlast standard log expiry.
What extra controls do model-based automations need?
Input boundaries defining what data may be sent and what is excluded, output validation before the automation acts, and confidence routing so low-confidence results go to a person instead of proceeding.
Who should own automation governance?
Operations usually owns the policy, with systems owners accountable for permissions in their own platforms and each automation having a named individual owner. A committee that owns everything in general owns nothing in particular.
How often should permissions be reviewed?
Quarterly, against what each automation actually uses rather than what it was granted. Permissions expand over time, and the gap between granted and used is where most of the risk sits.
What happens to automations when someone leaves?
Ownership transfer belongs in offboarding, alongside account disablement. Transferring ownership before the account is disabled is the single control that prevents most orphaned automation failures.
Conclusion
The missing reconciliation file was never really about a broken script. It was about fourteen months of running without an owner, an inventory entry or an approval record, which meant the failure was invisible until the output stopped arriving. Five written answers, a one-week inventory, gates placed on consequence and a cadence light enough to keep is the whole of it, and it costs a fraction of the week finance spent rebuilding by hand.
Authority Solutions® builds automation governance for businesses across Texas and beyond, starting with an inventory of what is already running. We set the approval gates where consequence sits, specify the audit trail including the model steps, and hand over a review cadence your team can keep through a busy quarter.
Book your automation governance review today.
We will inventory what is already running.
