The phrase “AI psychosis” is doing a lot of work in the current debate, but the more useful reading is less clinical than operational. In TechCrunch’s discussion of the topic, Box founder Aaron Levie’s point was not that executives should reject AI; it was that they should use it. That distinction matters. Companies cannot set a credible AI strategy from the conference circuit, the board slide deck, or a vendor demo alone. They have to sit inside the product, the workflow, and the failure modes.
That is why the debate feels more like a governance checkpoint than a culture-war sideshow. On one side, adoption is accelerating in visible ways: search, productivity software, customer support, and internal copilots are becoming normal features rather than experimental add-ons. On the other, resistance is becoming equally visible, from college students booing AI mentions to broader unease around layoffs and product changes that feel imposed rather than earned. TechCrunch’s reporting also pointed to a more subtle signal: some users appear to be moving away from AI-heavy experiences, as with the apparent install lift at DuckDuckGo after Google pushed more AI into search. Whatever one thinks of the causality, the pattern is clear enough for business leaders to notice. AI is not a neutral feature category. It changes user expectations, brand trust, and product positioning at the same time.
For executives, the first implication is simple and uncomfortable: if you are not using AI tools directly, you are outsourcing your understanding to other people’s abstractions. Levie’s comment lands because it describes a real managerial failure mode. Leaders often approve AI investment while remaining insulated from the actual experience of prompting, reviewing, correcting, or rejecting outputs. That distance makes it easy to overpromise and equally easy to underinvest in the engineering work needed to make AI dependable.
A better starting point is a controlled pilot plan.
Run pilots in narrow workflows where the outcome is measurable and the risk is bounded. That means choosing tasks with clear baselines: drafting internal summaries, routing support tickets, classifying documents, searching enterprise knowledge, or assisting analysts with structured extraction. Define a single primary success metric for each pilot, such as time saved per task, reduction in manual rework, accuracy against a labeled benchmark, or containment rate for human escalation. Then add an explicit failure criterion. If a model produces too many unsupported answers, degrades precision beyond a set threshold, or increases review time instead of reducing it, the pilot should stop or be redesigned.
The point is not to prove that AI works in the abstract. The point is to learn where it works, under what conditions, and at what cost.
That requires guardrails from day one. A pilot without operational constraints is just a sandbox with production ambitions. Teams should define data access rules, logging requirements, human review thresholds, and escalation paths before the first deployment. They should also decide what not to automate. In most enterprises, the highest-value use cases are not fully autonomous; they are decision-support systems with bounded autonomy and a human in the loop for edge cases. That is a product choice, not just a compliance requirement.
This is where an embedded AI governance framework becomes non-negotiable. The governance stack should include three layers working together:
- MLOps discipline. Version models, prompts, system instructions, retrieval sources, and evaluation datasets. Track which model produced which output and under which configuration. If a vendor updates a model, treat that as a change event, not a silent improvement.
- Model risk management. Define acceptable error budgets by use case, not by sentiment. A customer-facing summarizer and a legal research assistant do not share the same tolerance for hallucination, latency, or omission. Map each workflow to a risk tier and require approval proportional to that risk.
- Data governance. Control what enters prompts, what gets stored in logs, and what can be used for training or fine-tuning. For regulated or sensitive environments, the most important question is often not model quality but data handling. If teams cannot explain where inputs go and how outputs are retained, rollout should not proceed.
The current polarization makes this more urgent, not less. When users are skeptical, product teams cannot rely on generic “AI-powered” messaging to justify adoption. They need features that are obviously useful, transparent in behavior, and easy to opt out of when the model is uncertain. When users are enthusiastic, the risk is the opposite: overdeployment before the surrounding systems are ready. Both reactions can produce bad strategy. The answer is not to pick a side in the culture debate; it is to build enough instrumentation to see what is actually happening.
That instrumentation should extend into evaluation. Enterprises often underestimate how much model performance can drift once real users and real data enter the system. Static benchmark scores are not enough. Teams need recurring evaluations against production traffic, red-team prompts that probe failure cases, and quality reviews tied to business outcomes rather than model trivia. If a tool is supposed to reduce support burden, measure resolution time and customer satisfaction. If it is supposed to accelerate engineering, measure cycle time, defect rate, and review burden. If it is supposed to help sales, measure conversion quality, not just content volume.
The same logic applies to vendor selection. In a polarized market, it is easy to buy the loudest platform or the broadest copilot promise. That is usually the wrong move. Buyers should compare tools on integration depth, observability, privacy controls, evaluation hooks, and the ability to constrain behavior. A model that looks marginally better in a demo but cannot be audited, rolled back, or monitored in production is not enterprise-ready.
There is also a roadmap implication that product leaders should not miss. The AI psychosis debate is a reminder that user trust is now part of the feature set. In some categories, the most competitive product will be the one that is slightly less magical but more reliable, explainable, and easy to govern. That is particularly true in search, knowledge work, and any workflow where errors have reputational cost. The question for roadmaps is no longer whether to add AI. It is where to add it, how to fence it, and what operational evidence will justify expanding it.
The companies that come out ahead will not be the ones that talk the most about AI, or the ones that retreat entirely from the backlash. They will be the ones that treat this moment as a practical test of product maturity. CEOs should use the tools themselves. Product teams should instrument the pilots. Engineering should build the logs, evals, and rollback paths. Risk teams should define the boundaries. That combination turns a polarized debate into an execution advantage.
