Enterprise AI in 2027: seven decisions to make before you scale

Revised October 18, 2026.

An AI budget can look convincing while leaving the operating decisions unresolved. Who owns a failed outcome? Which policy did the system use? How much review does a completed task need? Those questions become harder to postpone once an assistant starts changing records or acting across several systems.

For 2027 planning, I would spend less time trying to name the model that will lead the market and more time deciding how the organization will work when models change. That is the purpose of this outlook. The seven decisions below are my planning priorities, informed by the sources linked throughout. They are not seven predictions that I expect every enterprise to experience.

In a July 2026 conversation with Marina Mogilko on Silicon Valley Girl, economist Erik Brynjolfsson separates what AI can do from the organizational changes needed to make it useful. He describes jobs as bundles of tasks and distinguishes defining a problem, executing it and evaluating the result. For 2027, that puts process design and human judgment alongside model capability. Faster execution is valuable when it helps complete work that matters; the surrounding handoffs and decisions still need an owner.

There is a useful distinction in the evidence. Gartner’s June 2025 statement forecast that more than 40% of agentic AI projects would be canceled by the end of 2027. That is an attributed forecast with a future horizon, not an observed failure rate. Forrester’s public 2027 AI report summary also points to governance, context, and operating-model choices. These are reasons to examine our assumptions, not evidence that a particular architecture will succeed.

1. Decide which outcome earns the AI spend

A token budget is necessary for managing consumption. It is an incomplete basis for deciding whether a workflow deserves investment. I would ask each proposed initiative to name the outcome, its acceptance criteria, its current cost, and the person accountable for improving it.

For example, a procurement assistant might draft 1,000 reviews while producing only 850 that pass the agreed checks. Its unit cost should include the work spent on the rejected cases, along with review and rework. Comparing price per model call would hide most of that picture. The FinOps Foundation’s unit-economics guidance supports connecting technology consumption to meaningful business units rather than stopping at resource measures.

Before increasing the budget, require a small comparison using the same task mix and acceptance rules. Record cost per accepted outcome, review effort, elapsed time, and exceptions. My view would change if the measurement costs more than the low-risk task warrants; in that case, a simpler sampled baseline may be sufficient. It still needs a denominator people understand.

2. Give one person responsibility for the whole workflow

An assistant can make one step faster and leave the queue unchanged. A sales proposal may be drafted in minutes but still wait three days for pricing approval. If the proposal lacks the evidence the approver needs, faster drafting can increase the queue.

Consider an illustrative proposal process. Before redesign, a seller drafts the document, copies a price from a spreadsheet and emails an approver, who has to locate the current terms and ask for missing evidence. After redesign, the workflow assembles one versioned case containing the proposed price, applicable terms, supporting sources and unresolved conditions. It routes a complete case to the person authorized to judge a pricing exception. Missing evidence sends the case back with a reason; a generated explanation does not turn it into an approval.

The test runs from the customer’s request to an approved proposal ready to send. Compare elapsed time, waiting time, review and rework, exceptions, and cost per accepted proposal against the earlier process. Faster drafting may help, but the redesign earns its cost only if the complete outcome improves without weakening approval quality. If pricing authority or policy is the bottleneck, changing that handoff may matter more than changing the model.

This redesign requires investment beyond the software. Brynjolfsson, Daniel Rock and Chad Syverson’s Productivity J-Curve research examines complementary investments in processes, business models and human capital, including how they affect measured productivity. The workflow lesson I draw is to give those complements their own budget. For the proposal, that includes agreeing on the evidence standard, maintaining pricing sources and teaching people to handle exceptions. Test that work explicitly. The J-curve is no promise that an unproductive pilot will eventually pay off.

The decision for 2027 is who can change that workflow across team boundaries. Give that owner a baseline and explicit authority to redesign the handoffs, with the relevant control owners involved. A local assistant is perfectly reasonable when the task is local. The mistake is claiming an enterprise transformation from an improvement that stops at the next department’s inbox.

3. Treat current context as an operating responsibility

A more capable model does not make an obsolete policy current. If a refund limit changes while an approval is waiting, the system needs a way to recognize which version governed the recommendation and which version applies when the action is taken.

I would make context ownership visible: who maintains the source, how changes reach the workflow, what happens when sources disagree, and when the system must ask for clarification. In a supplier review, that means distinguishing the current approved policy from an old attachment and showing which one supported the recommendation. A large context window cannot settle that ownership question.

The Version Drift framework turns this into a concrete discussion about changed assumptions and pending decisions. Before scaling, test an actual policy-change scenario with synthetic records. If the system continues under obsolete authority, the workflow needs correction even if its answer remains plausible. A stable, low-risk reference task may justify a lighter process; freshness should follow the consequence of being wrong.

4. Choose models by workload and keep an exit route

Small models, frontier models, hosted services, and local deployment each belong in the evaluation. I would not make model size an enterprise policy before understanding the work. Document extraction, sensitive record handling, and a difficult multi-document judgment can have very different requirements.

Compare configurations on representative tasks, including the failures. Include latency, review effort, operating cost, privacy constraints, and the quality of the final state. A locally hosted model may reduce one exposure while introducing capacity, patching, and support responsibilities. A managed service may simplify operations while requiring careful contractual and data-handling review. Neither choice removes governance work.

The durable decision is how much of the workflow depends on one model’s behavior. Keep a small regression set and a documented replacement test. Maya reflects my own interest in this separation: models are replaceable kernels within a personal system whose memory and purpose should endure. That is a design principle from my work, not evidence that switching enterprise models is effortless or that every provider is interchangeable.

5. Draw the boundary between advice and authority

The difference between drafting a payment recommendation and issuing a payment is an operating boundary. It needs to be explicit in the system’s identity, permissions, and approval flow, not merely described in a prompt.

For each action, name the resource, the allowed operation, the conditions, and the approval required. Give a supplier assistant permission to prepare a change request before considering permission to change bank details. Test what happens when approval expires, a user asks for an out-of-scope action, or a tool returns an unexpected result. Keep these tests away from live financial records.

The Model Context Protocol authorization specification describes authorization for compatible HTTP-based connections. Using MCP does not establish that the business action is appropriate or approved. Application-level authority still needs an owner. My threshold would be more demanding for an irreversible external action than for a reversible draft, even when the same model proposes both.

6. Ask what evidence survives an incident

After a disputed action, an answer alone is rarely enough. The reviewer needs to reconstruct the request, the relevant source versions, the authority granted, the action attempted, and the result. That record must also respect privacy and retention limits; collecting everything indefinitely is not a sensible substitute for deciding what evidence matters.

The NIST AI Risk Management Framework provides a voluntary structure for governing, mapping, measuring, and managing AI risk. MIT’s AI Risk Repository helps surface a wider range of potential harms. Neither resource certifies a particular deployment. I would use them to challenge a workflow’s assumptions, then assign ownership and test the controls that are relevant to that workflow.

Take an assistant that sends a confidential attachment to the wrong recipient. The review needs more than an incorrect-output label. It needs to establish how the recipient was selected, which permission was checked, and whether a person could have interrupted the action. If that cannot be reconstructed in a safe test, increase the evidence quality before increasing autonomy.

7. Decide where human judgment must stay strong

People will still need to resolve ambiguity, challenge recommendations, and recognize when a task has changed. A process that asks for human approval should give the reviewer enough time, context, and authority to disagree. A button labeled Approve does not establish meaningful oversight.

For a complex case, test whether the reviewer can find the supporting evidence, identify a deliberately planted inconsistency, and send the work back with a reason. Measure that effort. If reviewers are expected to check hundreds of opaque recommendations at speed, the operating model may be relying on a safeguard it has made impractical.

Brynjolfsson warns that cutting junior hiring can weaken the route to experienced roles. My response at the workflow level is to make learning deliberate: if AI prepares the first proposal, give newer staff supervised opportunities to inspect its evidence, explain an exception and compare their judgment with an experienced reviewer. Decide how the resulting capacity will be used, whether to improve service, reduce backlog or create time for learning. I would apply his wider concern about shared prosperity at the firm level by asking who gains from the redesign and who gets the support to take on the changed work.

I would include capability development in the workflow budget: domain knowledge, source checking, exception handling, and the ability to work when the AI service is unavailable. The right level depends on the task. A low-risk formatting assistant needs a different oversight arrangement from a system influencing eligibility or moving money. The useful question is whether people retain the competence needed for the responsibility they still hold.

Leave the planning meeting with decisions you can test

The worksheet turns these seven areas into a short record: decision owner, current evidence, next test, acceptance condition, and review date. Start with one workflow rather than assigning a maturity score to the whole organization. A completed row should tell someone what will happen next and how they will judge the result.

For the procurement example, that could mean a controlled batch with known policy changes, a cost-per-accepted-review baseline, a denied-permission case, and an investigation record that a second reviewer can follow. It is a more useful commitment than saying the organization will become agentic in 2027.

This outlook would need revision if deployment economics, model capabilities, or regulation materially changed. The decisions themselves are deliberately practical enough to revisit. I want a system that can improve as the technology improves, while leaving responsibility for its use clear today.

Related reading

AI token economics: what does a successful task actually cost?

Frameworks: worked examples and practical worksheets

Share or cite this article

LinkedInEmail

Ajith Vallath Prabhakar. “Enterprise AI in 2027: seven decisions to make before you scale.” ajithp.com, 17 October 2026. https://ajithp.com/2026/10/17/enterprise-ai-2027/