Most organizations do not set out to run several AI governance programs. It happens because security, privacy, legal, responsible AI and engineering each meet AI through their own obligations, and each is right about its part of the problem. The way out is to share one record and one front door while every team keeps its own decisions, and it doesn't take a reorganization to get there.

Why does every team end up with its own AI review?

Because each function meets AI through a different obligation.

• Security sees new data flows, new vendors and, more often now, agents with permission to call tools, so it stretches its vendor assessment and threat modeling to cover them.

• Privacy sees new uses of personal information and adds them to its privacy impact assessment.

• Responsible AI cares about fairness, explainability and human oversight, and builds a risk-tiered assessment against the organization's own principles.

• Engineering tracks models, versions, evaluations and deployments in a registry inside its own platform.

• Legal and compliance look at new regulatory obligations and contract terms, and add AI questions to the reviews they already run.

Each team builds a form, a spreadsheet or a queue, and once volume picks up, each goes looking for a tool. Every one of those requests is reasonable. Taken together, they are all asking where the record of each AI system should live.

What does the split cost?

The symptoms are easy to spot:

It gets worse with time. Product teams learn that governance is slow and start describing projects in ways that avoid review. The registers drift further apart, and reconciling them falls to whoever gets asked the next hard question.

The delay rarely sits in the reviews themselves. Most of the time passes between steps, while a request waits for the next team to notice it is ready. When four or five teams collect the same details separately, those gaps can add up to months.

Repetition also hurts the record. A business owner who meets the same question again gives a shorter, less careful answer, so duplicate questions lower the quality of what every team ends up reviewing.

What does each team need from the record?

Less than their forms suggest. Most of what each review asks for is the same basic description of the system. The difference is the decision each team makes with it.

The shared core (purpose, owner, data, model, the people affected and how much the system decides on its own) should be collected once, and every team reads from it instead of asking again.

What goes in the shared record?

A workable record has three layers, each filled in by a different step.

1. The description, collected once at intake. Purpose and use case; business and technical owners; who uses the system and who is affected by it; whether it was built, bought or switched on inside an existing product; the model and provider; the data it uses, including personal and sensitive data; the decisions it makes or informs; and how much it can do without a person approving.

2. The classification, derived from the description. The risk tier, the regulations and internal policies that apply, and the reviews that the tier requires.

3. The decisions and evidence, added by each team. Approvals and their conditions, assessment results, open findings, evaluation results tied to the model version, and the next review date.

Team-specific detail can stay with the team that needs it. Privacy's full impact assessment, security's threat model and engineering's evaluation suite can live in their own tools, as long as the outcome and a link come back to the record.

Approve the use, not just the software. Many existing processes hang off procurement, so they approve a piece of software once and never see what it is used for. The same writing assistant is routine for tidying an email and a real exposure when someone pastes in a confidential contract. Under the EU AI Act, risk depends on what a system is used for, so a new use of an approved tool should come back through the front door.

One record, separate decisions

The common mistake is to resolve the overlap by choosing one team's tool and asking everyone else to use it. It rarely holds, because each tool's data model reflects its home team. A privacy platform is built around processing activities, a security platform around assets and vendors, an ML platform around model versions. None of them is built around the AI use case, which is what every team is reviewing.

The pattern that works has four parts:

1. One front door. Every new AI request, whether built, bought or switched on inside an existing SaaS product, enters through a single intake.

2. One record per AI system. The intake captures the shared core and tiers the system by risk. Once the system is approved, that record becomes its entry in the AI inventory.

3. Parallel reviews, separate decisions. The record routes to whichever teams the tier requires. Each team runs its own review, keeps its own approvers and owns its own decision.

4. Findings flow back to the record. A security condition, a privacy finding or an evaluation result attaches to the same record, so every team sees the current state. If a team reviews in its own ticketing tool, the connection has to run both ways. The request opens the ticket, and the decision, conditions and comments come back to the record.

Existing systems stay where they are. Tickets still land in Jira or ServiceNow, and enterprise risk still rolls up into the GRC suite. Our guide to tiered AI intake covers the tiering and the handoffs into existing GRC processes in detail, and our comparison of AI governance tools and GRC modules sets out which records belong where.

How does routing work in practice?

Every organization draws the lines a little differently. In the workflows we've seen hold up, risk tiers decide which teams review what, so low-risk requests move quickly and high-risk ones get every review they need. The tier comes from a few screening questions at intake:

• Does the system use personal or sensitive data?

• Does it make or inform decisions about people, such as hiring, credit, pricing or access to services?

• Can it act in other systems without a person approving?

• Does its output reach customers directly?

• Was it built in house, bought, or switched on inside a product you already use?

• Where do the people it affects live?

A yes to any of the first three usually means at least the medium tier, and personal data combined with decisions about people or autonomous action usually means high. A simple three-tier version looks like this:

Take a common request: an HR team wants to switch on an AI feature in its existing recruitment software that ranks applicants. In the fragmented model, security might approve the vendor update in a day while privacy and the Responsible AI team never hear about it. In the consolidated model, the request comes through the front door. The record notes that the feature uses personal information to inform hiring decisions, which puts it in the high tier. Privacy runs its impact assessment, Responsible AI tests for fairness and sets oversight requirements, and security reviews the vendor's data handling, all against the same description. Each team's conditions attach to the record, and the feature goes live once they are met. When someone later asks which systems inform hiring decisions, the answer is a filter on the inventory.

Why does one record matter for regulation?

Regulators in several jurisdictions now expect organizations to know where automated systems make or inform decisions about people, and to be able to say so. The EU AI Act places obligations on deployers of high-risk systems, and GDPR restricts decisions based solely on automated processing. US states such as Colorado and California, along with Quebec and Australia, are bringing in rules that require organizations to disclose, and in some cases assess, their use of automated decision-making. Each law words it differently, but they all ask which systems are involved, what data they use, which decisions they affect and who checked them.

In the fragmented model, those answers are spread across several teams. Engineering knows which systems exist, privacy knows which use personal information, Responsible AI knows which inform significant decisions, and security knows which third-party tools were approved. With one record, privacy and legal can answer on request instead of assembling the picture from separate lists.

What trips teams up when they consolidate?

Most consolidations run into the same few problems.

• Two front doors during the switch. If the old form stays live during a migration, some requesters will use it and then assume their request was lost. Switch the old form off on the day the new one goes live.

• Inventory entries created too early. When submitting a request creates an inventory entry straight away, people enter the bare minimum to move it along, and the inventory fills with thin records for systems that may never be approved. Capture the description at intake and add the system to the inventory once it is approved.

• Risk results shown to the requester. Requesters who can see which answers raise the tier can learn to answer around it, and some see risk flags they can't interpret. It usually works better to show the result only to reviewers and approvers.

• Risk scores nobody has cleared with legal. A documented high risk score on a tool the organization goes on to approve can read badly in future litigation. It can be safer to start with plain reviewer outcomes, from no concerns to blocked, and add scoring once the risk taxonomy is settled and aligned with the enterprise risk matrix. Ask legal how risk should be recorded, not only what should be assessed.

• A control nobody designed. Agent numbers often stay low for reasons nobody chose, such as each agent still needing an IT ticket. That limit disappears once people can build agents themselves. If a queue is quietly doing the job of a control, bring agents into the front door before it clears.

• Everyone on the panel treated as an approver. Review panels tend to grow until the governance team spends its days chasing reviewers through chat and email, and panel members can't tell when a request actually needs them. Separate the people who must approve from the people who only need to know, and notify them differently.

How to get started

1. Map the overlap before choosing tools. List the fields each team's current form collects and mark the ones that describe the system rather than a team-specific decision. The overlap is usually large.

2. Agree on the shared record and its owner. Decide which fields live in the AI system record and who maintains it. The owner is often the Responsible AI or Head of AI function, working jointly with privacy.

3. Write down the tiers. Publish the screening questions, the reviews each tier needs and a target turnaround for each, so requesters know what to expect before they start.

4. Start with a short first version. Simple forms get used. Cover most of what you need in the first version and add the rest once people are using it. If different regions run their own questionnaires, merge them first and add jurisdiction-specific branches afterward.

5. Run one front door and route in parallel. Keep each team's approvers; change only where the request enters and where the record lives.

6. Bring in the systems already in use. Start with those that make or inform significant decisions about people or use sensitive data, because they carry the most risk and attract the most questions.

7. Choose tooling last. The right platform is the one whose data model holds the AI system record and hands off cleanly into each team's existing workflow.

Frequently asked questions

Does consolidating AI governance mean one team takes over the others' reviews?

No. Consolidation applies to the record and the front door. Each team keeps its own review and approvers and still makes its own decision; the teams just stop collecting the same information separately.

Do teams have to give up the tools they already use?

No. Privacy can keep its privacy platform, security its vendor risk tool and engineering its model registry. The AI system record can link to them and holds the outcome of each review, so the tools stop competing to be the inventory.

Who should own the shared AI system record?

Usually the Responsible AI or Head of AI function, jointly with privacy, because together they span the use case and the data. What matters most is one record, with named owners for the policy and for running the process. If the Head of AI also drives adoption, give review its own lead. Programs often stall while a steering committee debates ownership, and naming those two owners is usually what gets them moving.

How do you get product teams to use the front door?

Make it the fastest route to a decision. One form instead of three, clear tiers and parallel reviews give teams a reason to use it. Tying procurement and platform access to an approved record closes most of the rest.

Where Enzai fits

Enzai is built to be that shared record. One intake front door gives each AI system a single record, tiers it by risk, and routes it to each team's review with handoffs into Jira and ServiceNow. The AI inventory is built from those records, so every team keeps its decisions while working from the same facts. If you are consolidating AI governance across teams, talk to the Enzai team.