Key Takeaways
- ERP projects frequently surface AI tool proposals at the same moment an enterprise-wide group is writing AI policy.
- Clear AI decision rights assign each type of AI approval to a named owner, so project teams know exactly where a request goes and how long the review should take.
- Well-defined AI governance roles and responsibilities give business leaders authority over value while security and legal hold clear authority over the risk thresholds each tool must meet.
- An executive’s role is to set the structure once at the enterprise level, so the question of who approves AI tools is clear from the first request forward.
Many companies now have two groups making decisions about AI. One is the ERP project team wanting to add AI tools for tasks like demand forecasting, and the other is a central AI committee setting the rules for how AI can be used across the company. Unfortunately, without defined AI decision rights, these two groups end up reviewing the same tools with different standards.
For CEOs, the pressing question is who approves AI tools when both groups believe the decision belongs to them. A clear answer lets the ERP team keep moving without building an approval process that competes with the committee's.
Today, we are exploring how to define AI governance roles and responsibilities so every AI request follows a single approval path.
The 2026 Top 10 AI-Enabled ERP Systems Report
Panorama’s experts share their insights on the ERP systems and AI platforms shaping the next phase of ERP evolution.
What AI Decision Rights Should Define
AI decision rights should settle two questions for every AI tool the organization considers:
- Who has the authority to approve the tool?
- What criteria does that person need to use before approving it?
Who Should Approve AI Tools?
The CEO or a delegated executive sponsor must establish and back an approval model that defines which group holds which decision. A practical model separates decisions about business value from decisions about risk, then assigns each decision to one of four groups:
- Business leaders: Own the decision about whether an AI tool solves a real operational problem and whether its expected benefit justifies the cost and the change it requires.
- IT: Owns decisions about architecture and integration, including whether a tool fits the ERP platform and can be supported after go-live.
- Security: Holds authority over data access thresholds and has the right to block a tool that exposes sensitive data beyond approved limits.
- Legal and compliance: Decides whether a tool's data use and vendor terms meet the organization's regulatory and contractual obligations.
The distinction between advising and deciding is where most models break down. Each role should be documented as either a decision-maker or a required reviewer for every category of AI tool.
This clarity pays off quickly. Organizations evaluating the top ERP systems will encounter AI features in nearly every vendor demonstration so they need a fast, consistent way to decide which features to pursue.
Expert Insight
Our AI readiness consulting team has found that the question of who approves an AI tool is often settled on paper long before it is settled in practice. Organizations that test their decision-rights model against a real AI request, before the ERP project needs an answer, uncover overlapping authority while there is still time to resolve it.
Who Should Approve AI Tools?
Naming an approver settles only half of a decision right. The approver also needs written criteria, because an owner without a defined standard will judge each tool differently depending on who is asking and how urgent the request feels.
Effective criteria turn each approval into a short set of questions that the request must answer with evidence:
- Measurable outcome: The request names the operational metric the tool should improve, such as days to close or forecast accuracy, along with the leader accountable for that result.
- Data exposure: The request identifies which data the tool can read or change and whether any of that data leaves the organization's environment.
- Level of autonomy: The request states whether the tool recommends an action for a person to review or carries out the action on its own, since automated decisions warrant a higher bar for approval.
- Exit path: The request explains how the tool's results will be monitored after launch and how quickly it can be switched off if those results fall short.
Publishing these questions in advance keeps approvals consistent as AI requests multiply across departments, because each approver can measure a new tool against the same standard applied to the last one.
Why ERP Projects Expose Competing Approval Processes
ERP projects operate on a fixed timeline with a vendor waiting on decisions, so project teams naturally build their own approval shortcuts when enterprise governance is still taking shape.
Compared to project teams, enterprise AI groups move more deliberately because they are setting policy that will apply to every department.
When the two timelines collide, a few patterns tend to appear:
- Duplicate reviews: The project team completes its own risk assessment of an AI feature, and the enterprise committee later requires a second review using different criteria.
- Unclear veto authority: A security concern raised late in the project stalls configuration because no one has defined whether security advises on the decision or makes it.
- Shadow approvals: Business leaders approve AI add-ons within their own budget authority, and those tools reach production without ever passing through enterprise review.
- Inconsistent standards: Two AI tools with similar data exposure receive different treatment because they entered the organization through different channels.
These patterns often surface early in the project.
For example, during the ERP comparison process, a food and beverage company evaluating manufacturing ERP systems may find that its shortlisted vendor bundles AI demand planning with its supply chain management software. If the project team approves that module as part of the ERP contract while the enterprise AI group is still defining acceptable uses of forecasting models, the organization may have accepted contractual commitments it would not have approved otherwise.
Aligning ERP Projects With Enterprise AI Governance
1. Route Project AI Requests Through the Enterprise Intake Path
Require every AI request from the project to enter the same intake process the rest of the company uses. This removes the need for a separate project-level risk review. The project team still prepares the evidence each reviewer needs, while the final decision follows the enterprise model.
2. Agree on Review Timelines That Fit the Project Schedule
Ask the AI committee to commit to a turnaround time for project requests, and build those review windows into the project plan. A committed timeline removes the schedule pressure that drives project teams to create their own approval shortcuts.
3. Appoint a Liaison Between the Steering Committee and the AI Committee
Designate one person who sits on both groups and carries decisions in each direction, so that project requests reach the committee early and policy changes reach the project team before configuration is locked.
4. Carry the Model Into Hypercare and Beyond
ERP hypercare, the stabilization period that follows go-live, is often when vendors release the first updates to the new system.
Assign the ERP team to review each release for new AI capabilities and route them to the right owner before anyone switches them on, which keeps embedded features inside the same approval model as the tools chosen during the project.
Learn More About AI Decision Rights
ERP projects frequently reveal AI governance problems. A project team working against a deadline may fill any gap in authority it encounters.
However, when the CEO defines decision rights once at the enterprise level, project teams can move quickly while the organization maintains a consistent standard for risk.
Panorama's independent ERP consultants help executive teams design AI governance models that align ERP initiatives with enterprise risk requirements. Contact us below to learn more.
