I have sat in two kinds of meetings about AI.
In the first kind, a technical team presents what they have built. They are proud of it. The architecture is elegant. The model performance metrics are strong. The business leaders in the room nod and ask what the ROI is. The technical team gives an answer that doesn't quite address the question. The business leaders leave uncertain. Nothing happens.
In the second kind, the same work is presented differently. Not as a model with precision and recall metrics, but as a system that catches a specific category of problem earlier than the current process, with a specific quantified cost reduction and a specific set of assumptions that the business can validate. The business leaders ask questions about the assumptions. A real conversation happens. A decision gets made.
The technical work is identical. The outcomes are not.
What Gets Lost in Translation
The language of machine learning is the language of probabilistic optimization. We speak of loss functions, confidence intervals, training distributions, and inference latency.
The language of business strategy is the language of decisions under uncertainty. Executives speak of risk, opportunity cost, competitive positioning, and organizational capability.
These are not the same language. They are not even reliably isomorphic — there are ideas that translate cleanly and ideas that do not translate at all without careful work.
The translation failures I see most frequently:
Model accuracy presented as business reliability. A model with 94% accuracy sounds impressive until someone asks what happens in the 6% of cases where it is wrong. If those cases are randomly distributed, the impact is manageable. If they cluster if the model is systematically wrong about a specific customer segment, a specific product category, a specific time period — the business impact could be catastrophic. Accuracy is not reliability. The translation requires explaining where the model is right and where it is wrong.
Technical debt presented as a future problem. Engineers understand intuitively that shortcuts taken today compound into harder problems tomorrow. This is not intuitive to business leaders who have not experienced it. The translation requires making the future cost concrete and specific not "this will be harder to maintain" but "this architecture will cost us four additional weeks of development time for every major feature we add after the system reaches this scale."
AI capability presented without boundary conditions. An LLM can do an impressive range of things. Presenting those capabilities without their boundary conditions the input distributions where they fail, the contexts where they hallucinate, the latency constraints that make them impractical produces decisions based on an inflated model of what is possible. The translation requires honesty about limits, which feels counterintuitive when you are trying to make a case for investment.
The Translator's Discipline
Effective translation in both directions requires a specific discipline that I have tried to develop over 20 years of working at the interface of technical and business leadership.
In the technical-to-business direction, the discipline is: never present a capability without presenting its scope conditions and its failure mode. This feels like underselling. It is the opposite. Business leaders are sophisticated. They know that every system has limits. When you present a system without limits, they fill in the limits themselves — usually pessimistically. When you present the limits explicitly, you give them accurate information and you demonstrate that you understand the whole system, not just its strengths.
In the business-to-technical direction, the discipline is: never accept a requirement without articulating what it implies about the technical design. "We need the system to be real-time" is a business requirement. It implies specific architectural decisions streaming infrastructure, latency-aware model selection, different tradeoffs between accuracy and speed — that the business leader may not have intended when they said "real-time." Translation in this direction means surfacing those implications before they become expensive surprises.
What AI Changes About This
The current AI moment makes translation more important and more difficult simultaneously.
More important because the decisions being made about AI deployment are consequential and often irreversible architectural choices, vendor relationships, organizational capabilities built or not built.
More difficult because the pace of capability development means that both the technical language and the business implications are shifting faster than translation frameworks can stabilize.
I have found one principle that holds: the translation is always easier when both parties have genuine respect for the complexity of the other's domain.
Business leaders who believe that AI is simply a matter of buying the right software will consistently make bad decisions about it. Technical leaders who believe that business strategy is simply a matter of having the right data will do the same.
The CTO who can operate with genuine fluency in both languages — who can talk about attention mechanisms and market positioning in the same meeting, and mean something precise by both is not a rare individual who happened to develop two skill sets. They are someone who understood early that translation is itself the core technical and strategic competency of technology leadership.
Everything else is content. Translation is the infrastructure.