Enterprise AEO Strategy and Governance: Who Decides What

Suppose a CMO asks three business units for one number: how often AI answers name the brand. North counts any answer that mentions the brand. South counts only answers that recommend it. West reports the share of its own prompts where the brand appears at all. The three figures land on one slide, and nobody can add them, compare them or say which unit is ahead. None of the units did anything wrong. Nobody decided in advance what the number means.

That gap is what enterprise AEO governance fills. Strategy is a short list of decisions made once. Governance is the record of who may change each decision, who must be consulted, and when it gets reviewed. This post sets out the decisions, sorts them into central, local and shared, shows what goes on a one-page charter, covers crawler access per host, and explains how to roll up unit results without mistaking a change in mix for a change in performance. It builds on the posts about the AEO team, regulated industries and regions and languages, and adds the decision map those posts do not draw. A workbook at the end holds the registers.

Strategy is five decisions, and governance is who can change them

Many enterprise AEO plans grow into long documents. The part that does the work is smaller. Five decisions, made once and written down, settle most arguments before they start.

Each decision gets an owner, a standard that is in force and a review date. Governance is that record. When a unit wants to depart from a standard, it needs a path: ask the owner, who consults the named parties and writes the answer down. Without a path, departures happen quietly and the numbers stop being comparable.

What research says about governing AI across a company

McKinsey's survey on how organizations are rewiring to capture value from AI had 1,491 participants in 101 nations, fielded in July 2024 and published in March 2025. About 28 percent of respondents said the CEO oversees AI governance, and about 17 percent said the board does. Governance was often owned jointly, with two leaders on average. Risk and compliance and data governance were most often fully centralized, for example through a center of excellence, while tech talent and adoption were most often hybrid. The results are self-reported and describe AI in organizations broadly, not marketing or search visibility. The source is McKinsey's State of AI report.

The US National Institute of Standards and Technology published its AI Risk Management Framework in January 2023. Its Govern function is described as cross-cutting, meant to run through every other function. It asks for policies and an inventory of AI systems, documented roles and executive accountability, and attention to third-party risk. It is voluntary and written to fit any use case. The text is in NIST AI 100-1.

Our reading, not either source's conclusion: the pieces that must be consistent everywhere, such as risk and compliance, tend to be centralized, and the pieces that depend on local work, such as adoption, tend to be mixed. That pattern is a reasonable starting guess for sorting AEO decisions. It is a guess, and the next section turns it into a test you can run on your own list.

Decide what is central, local or shared

Sort every decision into one of three bins. A central decision has one owner who decides for every unit. A local decision belongs to the unit, inside a central standard. A shared decision has one owner and named parties who must be consulted.

A decision goes central when results have to be comparable or when a mistake spreads to every unit. The metric definition, the run protocol, the roll-up method and the crawler default meet that test. A decision goes local when it depends on knowledge only the unit has, such as prompts for a local product or when a regional page gets refreshed. A decision is shared when both pressures apply: approved claims, crawler exceptions, approved tools and escalation. Write down whether "consulted" means advice or a veto, and put that next to the decision.

Figure 1. Eleven AEO decisions sorted by who can change them. Invented example for an invented company.

Use the map to find conflicts. If two units both believe a decision is theirs, the map has no owner for it, and that is the first thing to fix. If everything is central, units will route around the process. If everything is local, nothing rolls up. The team post covers who does the work. This map covers who may change the rules the work follows.

Write the charter on one page

A charter is the page a new unit lead reads on day one. One page forces choices. Six lines are enough.

If the charter runs past one page, some of its content probably belongs in the register. The charter points to the register and does not repeat it. For regulated products, the regulated industries post covers the claim register and review tiers that sit behind the escalation line.

Set crawler access once per host

Large companies run many hosts: a main site, docs, support, a store, a careers site, regional sites. Crawler access is set per host, and that is where central policy usually breaks.

The Robots Exclusion Protocol, published as RFC 9309, puts the rules in a file at the top level of the service, so each host has its own file. Crawlers should not use a cached copy for more than 24 hours unless the file cannot be reached. The RFC also states that these rules are not a form of access authorization. A robots.txt file is a request to well-behaved crawlers, and listed paths are visible to anyone. Private content needs real access controls.

OpenAI documents its crawlers in Overview of OpenAI Crawlers. OAI-SearchBot is used to surface sites in ChatGPT search. GPTBot crawls content that may be used to train its foundation models. ChatGPT-User handles actions a user starts, and robots.txt rules may not apply to it. Each robots.txt setting is independent, so a site can allow one and block another. Changes to search settings can take about 24 hours, and an opted-out site can still appear as a link. Google describes Google-Extended in its common crawlers documentation as a separate token that controls use of content for Gemini training and grounding. It does not affect inclusion in Google Search or ranking, and Googlebot is a separate crawler.

We are not telling you whether to allow or block any of these. That is a business and legal decision, and it can differ by site section. The governance job is smaller. Set a central default per crawler, record each host's actual setting, and require written approval for any departure. Record whether each host is indexable in Search too, so nobody confuses a crawler setting with a search setting. Table 1 shows the register for five invented hosts, using reserved example domains and a placeholder default of Allow for all three crawlers.

Table 1. Host register for five invented hosts.

Two rows fail. The careers host blocks two crawlers with no approval on file, and the shop host never set a rule for OAI-SearchBot. In this example both hosts are run by vendors, which is a place where an exception can appear without anyone choosing it. Docs and partners also differ from the default, but each has a recorded approval, so they pass. Schedule the check too. The workbook uses 90 days as a placeholder and flags any host whose last check is older.

Roll up numbers without fooling yourself

Once units use the same definition and protocol, the next trap is the roll-up. Figure 2 shows an invented example with four units measured in two quarters. Each unit counted answers that met the same metric, using the same prompts and the same number of runs.

Table 2. Invented unit results. The weights are percentages that total 100.

Every unit went up. The pooled rate, which adds the answers meeting the metric and divides by all answers, fell from 62.5 percent to 55.5 percent. The reason is the mix. In Q2, South supplied 50 of 400 answers. In Q3 it supplied 150. South is the weakest unit, so more of its answers pulled the combined rate down even though South itself improved. The fixed-weight rate multiplies each unit's rate by a weight set in advance, and it moved from 58.0 to 60.8 percent.

Figure 2. Every unit improved, yet the pooled rate fell 7 points. Invented example. Bars show Wilson 95 percent ranges.

The Stanford Encyclopedia of Philosophy describes this pattern in its entry on Simpson's paradox. An association in pooled data can disappear or reverse when the data are split by group, because the groups differ in mix. The entry adds that whether the pooled or the split view answers your question depends on causal assumptions. Here, the pooled rate answers "what share of all answers names us", and the fixed-weight rate answers "did the units improve with the mix held constant". They are different questions, so report both.

Do not read the gains as proof either. Each unit's Q2 and Q3 ranges overlap. North runs from 73 to 86 percent in Q2 and 69 to 90 percent in Q3, and South runs from 28 to 54 and 36 to 52. The 2.8-point rise in the fixed-weight rate is small against that noise. Four rules keep the roll-up from misleading you:

1. Pool counts, not percentages, so a unit with 50 answers does not count the same as one with 150.
2. Set weights once for the year from a stable basis, such as revenue or share of buyer questions, and do not change them between periods.
3. Report the pooled and fixed-weight rates side by side, with answer counts and ranges.
4. Leave a unit out of the fixed-weight rate when it has too few answers, and rescale the remaining weights. The workbook uses 30 answers as a placeholder minimum.
   
   

Run the cadence and escalation

Governance needs rhythm. Four are enough, and every interval here is a placeholder. A weekly check runs the shared prompt set the same way in every unit. The prompt design post covers why wording and run count have to stay fixed. A monthly review with unit leads looks at results with ranges. A quarterly pass reviews every decision whose date has passed. An annual pass resets the roll-up weights.

Escalation needs a named route. When a unit finds a harmful or legal claim in an answer, it goes to the owner of that claim within a set time, such as one working day. Page updates stay local, and the unit's content team makes them. The content teams post covers briefs and refresh. The facts those pages state come from one approved register, and the PR and comms post covers the fact sheet behind it.

Keep the decisions, hosts and roll-up in one workbook

The workbook has a decision register, a host register, a unit results log and a summary. Every grey row is invented, and every threshold is a placeholder.

1. On the Settings tab, set the as-of date, the review windows, the minimum answers per unit, the central crawler defaults and the fixed weights for your units.
2. On the Decisions tab, add one row per decision with its level, owner, consulted parties, the standard in force and the date it was last reviewed. A shared decision with no consulted party fails its row check.
3. On the Hosts tab, record each host's setting for the three crawlers, whether it is indexable in Search, the date you last checked it and whether any exception was approved.
4. On the Units tab, enter answers checked and answers meeting your metric for each unit and period, using the same prompts and run count everywhere.
5. On the Summary tab, read the count of decisions by level, overdue reviews, host exceptions without approval, and the roll-up with pooled and fixed-weight rates side by side. The flag column tells you when the two disagree.
   
   

Frequently asked questions

Who should own enterprise AEO?

We found no study that answers this for AEO. McKinsey's survey found AI governance often owned jointly by leaders. For AEO, name one accountable owner for each decision instead, with consulted parties written beside it. A single person or team can own many decisions, but no decision should have two owners.

Which decisions should be central?

Start with the ones that make numbers comparable or spread a mistake across every unit: the metric definition, the run protocol, the roll-up method and the crawler default. Leave local the decisions that need local knowledge. Then test the split on your own list, because the research here is general AI governance, not AEO.

Should we block AI crawlers?

That is a business and legal decision, and the provider documents describe options, not a recommendation. What governance adds is consistency: a default per crawler, a recorded setting per host and written approval for exceptions. Remember that robots.txt is a request to crawlers and not access control.

How do we compare units with different numbers of answers?

Pool the counts, fix the weights in advance and show ranges beside every rate. A rate from 50 answers is much less certain than one from 150. Set a minimum number of answers below which a unit is left out of the weighted rate, and say so in the report.

How often should governance be reviewed?

We found no study that sets an interval. Start with a pass on every decision at a pace you can keep, such as quarterly for fast-moving items and twice a year for stable ones, then adjust once the overdue flags show where the process slips.

List five decisions and mark each central or local this week

Write down five decisions your units make about AI search today, such as how a metric is counted, who adds prompts, which tools are allowed, what each website host tells crawlers and who approves a claim. Mark each one central, local or shared. Name one owner for each, and write the date it was last reviewed. Then open the robots.txt file on each host and note the setting for the three crawlers next to the owner. Do not put customer or personal information in any prompt, saved answer or note.

If you want a first reading to put beside your list, the AI Search Visibility Checker gives you one on a prompt you choose. If you want to watch the same prompts period after period, AI Search Intelligence tracks individual prompts.