Enterprise AI Consulting: What Changes Above $50M.

"Enterprise AI consulting" is usually sold as the same engagement a $10M business buys, with a larger scope document and a larger invoice. That framing is wrong, and it is the reason so many enterprise AI programs produce impressive pilots and no production systems. Somewhere around $50M in revenue — or, more precisely, around the point where a business has a real IT function, a real security review, and more than one system of record — the binding constraint on an AI program stops being "which opportunity do we pick" and starts being "how does this survive contact with our organization." This is what actually changes.

What is different about enterprise AI consulting?

In our engagements, the difference concentrates in four places. Everything else — model selection, prompt design, evaluation, cost per call — is broadly the same work at both scales.

• Identity and access. A mid-market AI agent can usually run under a single service account. An enterprise agent cannot: it has to answer questions differently depending on who is asking, which means it needs to inherit the caller's permissions from the identity provider rather than hold its own.
• Data governance. At $5M there is one CRM. At $50M+ there are three systems that each believe they own the customer record, plus a warehouse that reconciles them nightly. Deciding which one is authoritative is a political act, not a technical one, and it has to happen before the build.
• Change management. A mid-market deployment changes the workflow of six people who all report to the person who bought the system. An enterprise deployment changes the workflow of two hundred people across three functions, none of whom were in the room.
• Audit evidence. Mid-market buyers want the system to work. Enterprise buyers need to be able to prove to a third party — a regulator, an auditor, an acquirer, a customer's security team — that it worked, on a specific date, for a specific transaction.

Why does the first enterprise system take longer?

It does, and firms that pretend otherwise are quoting a pilot. The build itself is not slower. What is slower is everything that wraps around it: security review, data access provisioning, legal review of the vendor terms, and the internal socialization required before anyone will let the system touch a production record.

A realistic enterprise sequence, based on what we see across engagements at this size:

1. Weeks 1–3 — diagnosis and system-of-record mapping. Not a discovery call. A written map of which system is authoritative for each entity the agent will touch, and what happens when they disagree.
2. Weeks 2–6 — security and access, running in parallel. Start this on day one. It is the single most common critical path item, and it is entirely outside the consultant's control.
3. Weeks 4–10 — build against a production-shaped environment. Not synthetic data. A system built against clean sample data will fail on the real thing, and the failure will surface after go-live rather than before it.
4. Weeks 8–12 — shadow mode. The agent runs on live traffic and produces recommendations that no one acts on, while operators grade the output. This step is skippable at $5M. It is not skippable at $50M+.
5. Weeks 12–16 — staged rollout and evidence handover. One team, then one function, then the org — with the audit trail already in place rather than retrofitted.

What governance does an enterprise buyer actually need?

Enterprise AI governance has largely converged on a common vocabulary, and a firm that cannot speak it will cost you months in review cycles. The two documents that matter most in practice:

• The NIST AI Risk Management Framework, which organizes AI risk work into four functions — govern, map, measure, manage. It is voluntary, non-prescriptive, and has become the default language enterprise risk committees use to ask their questions. If your consultant's governance deliverable does not map to it, your risk team will make them redo it.
• The EU AI Act, which matters to US enterprises far more than most of them expect — not because they operate in the EU, but because their customers do, and obligations flow downstream through vendor questionnaires. Systems that touch employment decisions, credit, or biometrics land in the higher-obligation tiers.

The practical artifact is narrower than either document suggests. What an enterprise actually needs handed over is: a written statement of what the system is allowed to decide, a written statement of what it must escalate, a per-decision log that a non-engineer can read, and a named human accountable for each class of decision. We cover the mechanics of that in Decision Log and Truth Boundaries.

What should an enterprise engagement cost?

The honest answer is that the ratio changes, not just the number. At mid-market, most of the budget is build. At enterprise, a substantial share goes to integration, security response, and the evidence layer — work that produces no visible feature but without which nothing ships.

• Assessment. A paid, standalone deliverable with its own scope. If a firm offers the enterprise assessment for free, it is a sales document. See What an AI Assessment Actually Produces.
• Build. Priced per system, not per seat. Ask specifically whether the price includes the integration work against your systems of record or assumes an API that already exists.
• Run. The line item enterprises consistently underestimate. Models change, upstream schemas change, and behavior drifts. Budget for it as an operating cost, not a warranty.
• Security and compliance response. Ask who fills out the vendor questionnaires and whether that is billed. For a regulated buyer this is real, recurring work.

For the underlying cost models and what drives them, the ranges in How Much Does an AI Agent Cost? still hold at the component level — enterprise pricing is those components plus an integration and evidence surcharge, not a different economics.

Where do enterprise AI programs actually fail?

The failure modes at this scale are organizational far more often than technical. Five we see repeatedly:

1. The pilot that cannot graduate. Built in a sandbox, against sample data, by a team with no path to production access. It demos well and dies at security review.
2. Ambiguous ownership. No single executive owns the outcome, so the system is everyone's priority and nobody's deadline.
3. Governance retrofitted. The logging and escalation layer is added after go-live because someone asked for an audit trail. It is three times the work and produces a worse result than designing it in.
4. The unmodeled disagreement. Two systems of record disagree about a customer, the agent picks one, and the error surfaces six weeks later in a finance reconciliation.
5. No operator in the loop. The system ships to a function that was never consulted, and adoption stalls at indifference rather than opposition.

None of these are model problems. They are the enterprise-specific version of the failure patterns in Why AI Projects Fail at $5M–$50M Businesses— same root causes, higher blast radius, longer feedback loop.

What should you ask an enterprise AI consulting firm?

Five questions that separate firms who have shipped inside a large organization from firms who have shipped demos:

• "How does the agent get its permissions?" If the answer is a service account with broad read access, they have not done this at enterprise scale.
• "What happens when two systems of record disagree?" A good firm has an opinion and a mechanism. A weak one says it will not happen.
• "Show me a decision log from a live deployment." Redacted is fine. Absent is the answer.
• "Who responds to our security questionnaire, and is it billable?" The answer tells you whether they have been through enterprise procurement before.
• "What does month seven look like?" Firms built around a project have no answer. Firms built around running the system answer immediately.

The broader version of that diligence — the four business models that all use the same job title — is in How to Choose an AI Consultant.

The one thing that transfers from mid-market

Enterprises tend to over-correct. Having concluded that their situation is uniquely complex, they buy platform programs that take a year to produce anything. The mid-market discipline still applies and is the single highest-value import: pick one workflow with a measurable dollar value, ship it end-to-end including the evidence layer, and let the organization see it work before scoping the second. The constraints above make that harder at enterprise scale. They do not make it optional.