Petri IT Knowledgebase’s latest Petri Dish episode makes a blunt case for enterprise AI programs: start with the business problem, not the model or chatbot. Troy Norcross, AI governance advisor and founder of SERTeam, argues that companies chasing AI adoption as an end in itself are producing expensive experiments rather than measurable returns.
Norcross calls the pattern “AI theater”: separate teams deploy tools, run hackathons, or build proofs of concept primarily to demonstrate innovation. The predictable result is AI sprawl, shadow AI brought in by employees, and no agreed measure of whether the work improved cost, speed, quality, risk, or customer outcomes.
For Windows and IT administrators, this is not merely a boardroom strategy problem. It becomes an operational one when unsanctioned generative-AI services begin receiving corporate documents, when teams use unmanaged browser extensions, or when separate departments connect models to the same Microsoft 365 data without common access controls.
Norcross’s proposed sequence is conventional but often ignored: define what is broken, quantify the consequence, decide what a successful outcome looks like, and then determine whether AI is actually the appropriate component of the solution.
That framing can eliminate bad projects early. An overloaded service desk may need better knowledge management, cleaner ticket categorization, or fewer application failures before it needs a large-language-model assistant. An AI copilot may help after those foundations are in place, but it should not substitute for them.
The key test is whether a team can state the expected operational change. “Deploy an AI assistant” is activity; “cut first-response time for password-reset tickets while maintaining resolution quality” is a business outcome that can be measured.
That does not make AI unusable. It means the surrounding system must carry more of the control burden. In practice, organizations need approved-model policies, identity-based access, data classification, logging, retention rules, evaluation processes, and human review for consequential actions.
For Microsoft-centric environments, that may mean treating AI access as part of the existing governance estate: Entra ID groups, Microsoft Purview sensitivity labels and data-loss-prevention controls, Defender monitoring, approved Copilot configurations, and a clear process for reviewing third-party AI services. The model may be probabilistic; the permissions and safeguards cannot be.
A workable policy should make clear which tools are approved, which data may be entered into them, who can authorize new use cases, and what must happen when AI output influences customer, financial, legal, security, or employment decisions. Without those answers, shadow AI will fill the vacuum.
The most useful AI project may ultimately be modest: extracting information from a constrained document set, improving internal search, classifying low-risk requests, or assisting a defined support workflow. If it solves a named problem with a measurable baseline, it has a route to ROI. If its primary purpose is to show that the organization is “doing AI,” it is already at risk of becoming theater.
For Windows and IT administrators, this is not merely a boardroom strategy problem. It becomes an operational one when unsanctioned generative-AI services begin receiving corporate documents, when teams use unmanaged browser extensions, or when separate departments connect models to the same Microsoft 365 data without common access controls.
The business case has to arrive before the AI stack
Norcross’s proposed sequence is conventional but often ignored: define what is broken, quantify the consequence, decide what a successful outcome looks like, and then determine whether AI is actually the appropriate component of the solution.That framing can eliminate bad projects early. An overloaded service desk may need better knowledge management, cleaner ticket categorization, or fewer application failures before it needs a large-language-model assistant. An AI copilot may help after those foundations are in place, but it should not substitute for them.
The key test is whether a team can state the expected operational change. “Deploy an AI assistant” is activity; “cut first-response time for password-reset tickets while maintaining resolution quality” is a business outcome that can be measured.
Probabilistic systems need deterministic controls
The episode also identifies a gap between conventional enterprise software and generative AI. Most line-of-business systems are expected to behave predictably for a given transaction; models can generate different answers, make unsupported claims, or handle edge cases inconsistently.That does not make AI unusable. It means the surrounding system must carry more of the control burden. In practice, organizations need approved-model policies, identity-based access, data classification, logging, retention rules, evaluation processes, and human review for consequential actions.
For Microsoft-centric environments, that may mean treating AI access as part of the existing governance estate: Entra ID groups, Microsoft Purview sensitivity labels and data-loss-prevention controls, Defender monitoring, approved Copilot configurations, and a clear process for reviewing third-party AI services. The model may be probabilistic; the permissions and safeguards cannot be.
“AI-ready” is a leadership and governance condition
Norcross defines practical AI readiness around three requirements: executive commitment and communication, an AI-use policy, and appropriate technical infrastructure and controls. The point is not to make every experiment slow or bureaucratic. It is to let teams test useful ideas without turning sensitive data and compliance obligations into afterthoughts.A workable policy should make clear which tools are approved, which data may be entered into them, who can authorize new use cases, and what must happen when AI output influences customer, financial, legal, security, or employment decisions. Without those answers, shadow AI will fill the vacuum.
The most useful AI project may ultimately be modest: extracting information from a constrained document set, improving internal search, classifying low-risk requests, or assisting a defined support workflow. If it solves a named problem with a measurable baseline, it has a route to ROI. If its primary purpose is to show that the organization is “doing AI,” it is already at risk of becoming theater.
References
- Primary source: Petri IT Knowledgebase
Published: 2026-07-31T14:48:55+00:00
Why AI Projects Fail: Start with the Business Problem
AI initiatives fail when organizations chase the technology instead of defining the business outcome they need to achieve.
petri.com