Two failures cost roughly the same. One is an AI program with no governance, which produces a system that nobody will approve, a model whose decisions cannot be explained to a regulator, and a data practice that a privacy review will eventually stop. The other is an AI program with too much governance, which produces a committee calendar, a review board that meets monthly to consider requests, an intake form with forty fields, and eighteen months in which nothing reaches a user. The second failure is more comfortable, because everyone can point at their diligence. It is not cheaper.
The governance that works has a specific property: it moves the decisions earlier and makes them fewer. It does not add a gate at the end. It puts the security team, the model risk function and legal into the design conversation in the first weeks, agrees in advance what classes of system are pre-approved, and then lets engineering ship inside those boundaries without asking again. This is how a program stays both fast and defensible, and it is a design problem rather than a policy problem.
Decision rights before committees
Most governance failures are decision-rights failures wearing a committee costume. A body meets, discusses, and has no authority to decide, so it produces a recommendation that goes somewhere else. Two of those in a chain and every decision takes six weeks.
Write down four things before designing any forum. Who chooses which problems the program works on. Who approves a system for production. Who can stop a system that is already running. And who decides when those three disagree. If any of those has more than one name, or has a committee name rather than a person's name, the program will be slow and the slowness will be blamed on engineering.
A workable allocation: a steering group chooses the portfolio quarterly, an accountable executive sponsor approves scope and spend inside the quarter without reconvening anyone, a named control function can block or halt a system on defined grounds, and the chief executive or an equivalent named officer resolves conflicts. Four roles, all held by people rather than bodies.
What separates governance that speeds a program up from governance that stops it
Editorial weighting, illustrative rather than measured. The last row is deliberately low: long intake forms filter out the requests worth doing along with the ones that are not.
Tier the systems, then govern each tier differently
The most useful single move in enterprise AI governance is to stop treating every system the same. A model that suggests a document tag to an internal user and a model that influences a credit decision carry different consequences, and applying one process to both means the process is either too heavy for the first or too light for the second. Almost always it is both at once.
Three tiers are usually enough, defined by consequence rather than by technology.
Tier three: assistive and internal. The output is a suggestion to an employee who can see it is a suggestion and can ignore it without effort. Drafting help, search, summarization of internal documents, code assistance. Governance: an inventory entry, a data-handling check, a named owner, standard logging. No committee. Ship it.
Tier two: operational. The output routes work, prioritizes cases, prices something within a bounded range, or is used by an employee to make a decision that affects a customer. Governance: documented validation against a held-out set, a monitoring plan with thresholds, a human review path, an approved fallback when the system is unavailable, and a named business owner accountable for the outcome.
Tier one: consequential. The output materially affects a person's access to credit, employment, benefits, insurance or a legal right, or it operates without a human in the loop in a way that is hard to reverse. Governance: independent validation by someone who did not build it, documented conceptual soundness, testing across relevant subgroups, explainability appropriate to the decision, an appeal or override path, board-level visibility, and a defined review cadence.
Publish the tier definitions and the corresponding requirements before any project starts. Then the first governance question about a new idea has a fast answer, and most ideas turn out to be tier three, which is exactly the point.
Intake that takes ten minutes
The intake process should be short enough that a business unit uses it rather than routing around it. Routing around it is the real risk: a heavy intake process does not prevent shadow systems, it causes them.
Six questions are enough at the front door. What decision or task is this about, and who does it today. What would change if it worked. What data does it need, and does the organization already hold that data lawfully for this purpose. Who is accountable for the outcome. What is the consequence of the system being wrong, which sets the tier. And what number would show it worked, and what is that number today.
That last question is the one that does the filtering. A request that cannot name a number that already exists in a report is usually a request for a demonstration rather than for a system, and it is better to discover that in ten minutes than in two quarters.
Prioritization should be equally plain. Score each candidate on the size of the change if it works, the confidence that it will, the effort, and whether the data exists today. Rank, take the top few, and publish the list including what was not selected and why. The published rejection list is what makes the process credible; a prioritization that only ever announces winners looks like patronage.
Folding model risk and data governance into engineering
This is the section where enterprise AI programs are actually won or lost, and it is an engineering topic rather than a policy one.
The standard failure is that model risk management and data governance exist as separate review activities performed on artifacts handed over by the engineering team. Documents are written to describe systems, reviewed weeks later, and the review finds a problem that requires a change, and the change invalidates the document. Every cycle takes a month and the program slows to the speed of its paperwork.
The alternative is to implement the controls as part of the system, so that the evidence is produced by running the pipeline rather than by writing about it. Concretely, that means several things.
The model inventory is generated from the deployment pipeline rather than maintained by hand. If a model is running, it is registered, with its version, its training data reference, its owner, its tier and its approval state, because registration is a step in the deployment and an unregistered model cannot deploy. A hand-maintained inventory is out of date the week it is compiled.
Validation is a test suite. The held-out evaluation set, the subgroup breakdowns, the performance thresholds and the stability checks run automatically on every candidate version, and the result is stored against the version. Independent validation then reviews evidence that was produced mechanically rather than assembled by the team being reviewed, which is both faster and more credible.
Lineage is captured at ingestion. Every record carries its source system, extraction time and a content hash from the moment it lands, so any output can be traced to the inputs that produced it without an investigation. Retrofitting lineage into a system that did not capture it is close to a rebuild, which is why this decision belongs in week two of the platform and not in month ten of the review.
Decision logging is built into the serving path. For every scored decision: the inputs, the model version, the output, the confidence where meaningful, and whether a human overrode it. Retention set to match the longest question anyone will be asked, which is usually set by a regulator or a contract rather than by engineering preference. This single log answers most of what a regulator, an auditor or an unhappy customer will ask, and it is nearly impossible to reconstruct after the fact.
Monitoring covers data and behavior, not just uptime. Input distribution shift, output distribution shift, override rate by segment, and latency. The override rate is the most informative and the most neglected: when the humans who use the system start disagreeing with it more often than they did, something has changed, and that signal usually arrives before any accuracy metric moves.
Where recognized frameworks fit
Two references are worth naming because they save argument. The NIST AI Risk Management Framework organizes the work into governing, mapping, measuring and managing, and its value to a program is mostly that it gives four vocabulary buckets that security, legal and engineering can share. For firms in banking, supervisory guidance on model risk management, commonly cited as SR 11-7, established the pattern of conceptual soundness, ongoing monitoring and independent validation that most enterprise model risk practice still follows. Firms outside banking borrow it because the structure is sound, not because it applies to them.
Use them as a checklist for coverage rather than as a process to adopt whole. A program that maps its controls to a recognized framework can answer an auditor's questions quickly. A program that adopts a framework as its operating model inherits a lot of ceremony designed for a different kind of organization.
Evidence a reviewer can trust, ranked by how hard it is to reconstruct later
Editorial weighting, illustrative rather than measured. The last row is deliberately low: a document is the easiest artifact to produce and the weakest evidence of what a system did.
A release process security and legal have already approved
The single change that most reliably speeds up an enterprise AI program is to move the security and legal approval from the system to the pipeline.
Rather than reviewing each release, the security function reviews and approves the path: the code review requirement, the dependency scanning, the secret handling, the infrastructure definitions, the environment separation, the access controls, the logging. Once the path is approved, anything that travels it inherits the approval, and only changes to the path itself require a new review. Legal does the same for a class of use: an approved data-handling pattern, an approved set of retention rules, an approved disclosure to users.
Then per-release governance shrinks to a short set of automated checks: does this change alter the data flow, does it change the model tier, does it touch a new data category, does it change what is retained. If all four answers are no, it ships. If any is yes, it routes to the person who owns that question. Most changes answer no to all four.
| Governance element | The version that stops work | The version that keeps it moving |
|---|---|---|
| Approval | Every release reviewed by a board that meets monthly | The pipeline is approved once; releases inherit it |
| Model inventory | A spreadsheet maintained by hand, quarterly | Generated at deployment; unregistered models cannot ship |
| Validation | A document written after the model is built | A test suite that runs on every candidate version |
| Intake | A long form completed before technical contact | Six questions, ten minutes, tier assigned immediately |
| Risk tiering | One process applied to every system | Three tiers by consequence, published in advance |
| Benefits | Value described in a business case and never revisited | A ledger against baselines recorded before launch |
The benefits ledger
Governance that only manages risk will eventually be defunded, because it produces no evidence that the program is worth having. The counterweight is a benefits ledger, and it is cheap to run.
For every system, before it launches, record the current reading of a number that already exists in a report somebody reads. Cycle time on a named process. Cases handled per person per day. Error or rework rate. Cost per transaction. Then measure the same number after, at a stated interval, and record who verified it. Include the systems that did not deliver: a ledger that only shows successes is not believed, and the failures are what justify stopping things, which is the hardest and most valuable action a governance body can take.
One discipline makes the ledger credible: the finance function agrees the measurement method before the system launches, not after. A benefit computed by the team that built the system, using a method chosen once the result was known, persuades nobody who matters.
How an engineering partner works inside this
Precision Federal builds systems inside enterprise governance rather than around it, and the practical posture is worth stating plainly, because a partner that treats governance as friction will produce work that cannot be approved.
We build the controls into the system. The model registry, the validation suite, the lineage capture, the decision log and the monitoring are engineering deliverables in the same milestone as the functionality, not documents produced afterward. Evidence for a security or model risk review is generated by running the pipeline, which is why our clients' reviews tend to be short: the reviewer is reading output rather than assertions.
We work inside the client's forums. Our technical lead attends the client's steering group, brings the same measures every month, and writes the technical decision records that make an architecture choice survive a change of personnel. Where the client's security function wants to approve a pipeline rather than each release, we build the pipeline to be approvable and then hold to it.
Commercially the work is fixed-price milestones with acceptance criteria written as tests, or a committed team at a stated monthly cost against a quarterly roadmap approved by the sponsor. The client owns everything created: code, infrastructure definitions, data, models, evaluation sets and documentation, assigned in writing at the outset, with anything we bring named in a schedule and licensed back perpetually. Our engineers work in the client's repositories, ticket system and review process.
We also build and deploy inside federal agencies, where governance is at its strictest: authorization to operate, documented control implementation and evidence, controlled unclassified information handling, government cloud environments, accessibility. Enterprises pursuing government revenue find that this is the part that decides whether a system is fielded, and it is the part commercial engineering practice usually leaves out. The first step is one email with a one-page brief, and we return a scoped, priced statement of work.
Five habits that keep a program honest
- Publish the rejections. The prioritized list should say what was not selected and why. Credibility comes from the second half of the list.
- Stop something every quarter. A governance body that has never halted a system is not exercising judgment, and everyone knows it.
- Review the override rate before the accuracy metric. The people using the system notice a change before the dashboard does.
- Keep the same six measures every month. A report whose shape changes is a report written to describe events rather than to answer a question.
- Re-tier annually. A system that started as an internal suggestion tool has a way of becoming the basis of a customer-facing decision without anyone deciding that it should.
Bottom line
Governance that ships has four properties. Decision rights sit with named people, not with bodies. Systems are tiered by consequence in advance, so most work travels a light path and only the consequential few carry the heavy one. Controls are implemented as code inside the pipeline, so evidence is generated rather than written, and security and legal approve the path once rather than every release. And a benefits ledger, measured against baselines recorded before launch and agreed with finance, keeps the program funded and gives the governing body the standing to stop things. Build those four and governance stops being the reason nothing ships and becomes the reason things can.
Frequently asked questions
Move the decisions earlier and make them fewer. Tier systems by consequence and publish the tiers before projects start, so most work travels a light path. Give named people decision rights rather than routing everything through a committee. Have security and legal approve the deployment pipeline and a class of data use once, so individual releases inherit that approval. Then per-release governance is a handful of automated questions, and only a change to the path itself needs review.
Six things: what decision or task this is about and who does it today, what would change if it worked, what data it needs and whether the organization already holds that data lawfully for this purpose, who is accountable for the outcome, what happens if the system is wrong, and what number would show it worked along with its current reading. Ten minutes. A long form does not prevent shadow systems; it causes them.
As code rather than as a review of documents. Generate the model inventory from the deployment pipeline so an unregistered model cannot ship. Make validation a test suite that runs on every candidate version, including subgroup breakdowns and stability checks. Capture lineage at ingestion. Log every scored decision with its inputs, model version, output and any human override. Then independent validation reviews evidence produced mechanically, which is both faster and more credible than a document.
The NIST AI Risk Management Framework is useful mainly as shared vocabulary across security, legal and engineering, with its governing, mapping, measuring and managing structure. In banking, supervisory guidance on model risk management commonly cited as SR 11-7 established the conceptual soundness, ongoing monitoring and independent validation pattern that most enterprise practice still follows, and firms outside banking borrow the structure. Map controls to them for coverage; adopting either as an operating model imports ceremony you may not need.
Keep a benefits ledger. Before each system launches, record the current reading of a number that already exists in a report your organization runs, and agree the measurement method with the finance function in advance. Measure the same number afterward at a stated interval and record who verified it. Include the systems that did not deliver, because a ledger showing only successes is not believed and the failures are what justify stopping work, which is the most valuable action a governing body takes.