You are the translator

On an AI project you sit between two worlds: the technical reality (probabilistic models, retrieval, evals, tradeoffs) and the business audience (executives, end-users, ops) who think in outcomes, not tokens. Value only flows if you translate faithfully in both directions — surfacing what the business needs into technical requirements, and explaining what the system does and doesn't do back into terms each stakeholder cares about. Different audiences need different translations of the same system:

Audience	What they care about	How to frame it
Executive / sponsor	ROI, risk, strategic fit	business outcomes, payback, what could go wrong (Track 8 Topic 2)
End-user	"does it make my job easier or threaten it?"	concrete daily benefit, how it fits their workflow, that it assists not replaces
IT / security	integration, data, compliance	architecture, data handling, guardrails (Tracks 6–7)
Ops / process owner	reliability, exceptions, handoffs	when it works, when a human steps in, how errors surface

The skill is telling the same true story at the right altitude for each — not dumbing down, but selecting what matters to them.

Set expectations honestly

The fastest way to sink an AI project is to let stakeholders believe it's magic — perfectly accurate, fully autonomous, human-free. It isn't (Track 5): it's probabilistic, occasionally wrong, and best with guardrails and sometimes a human in the loop. Your job is to set accurate expectations up front, because the gap between expectation and reality is where trust dies:

• Frame it as assistance/augmentation, not full autonomy, unless you've genuinely earned the latter with evals.
• Name the failure modes plainly — "it will occasionally be wrong; here's how we catch that (verification, abstention, human review)" — so the first error isn't a betrayal of a promise you never should have made.
• Quantify, don't hand-wave — "~90% of these questions answered correctly, with citations, and it says 'I don't know' rather than guess" beats "it's very accurate."
• Under-promise on scope — the narrow slice (Topic 1), not the everything-machine.

Counter-intuitively, honest limitation-setting builds more confidence than hype — stakeholders trust someone who tells them the downside, and it inoculates the project against the inevitable first mistake.

Adoption: the project isn't done at "it works"

A system that passes every eval and that nobody uses delivered zero value. Adoption is a distinct problem from building, and it's where many technically-successful projects quietly fail. People resist new tools for real reasons — habit, distrust of AI, fear of being replaced, or the tool not fitting how they actually work. Driving adoption (change management / enablement):

• Involve users early — the people who'll use it should shape it in discovery (Topic 1); imposed tools get rejected.
• Integrate into existing workflow — meet people where they work (their inbox, CRM, chat), don't force a new destination. Friction kills adoption.
• Build trust incrementally — start with the AI assisting (suggestions a human confirms), earn trust, then expand autonomy. Citations and transparency (Track 6) help users trust outputs.
• Address the fear honestly — name the "will this replace me?" concern; position it as removing drudgery so people do higher-value work.
• Train and support — a short enablement session and a feedback channel; measure usage, not just capability.

Adoption is a success metric (Topic 2): track whether people actually use it, and treat low usage as a project problem to solve, not a user failing.

The two failure modes: hype and skepticism

Stakeholders sit somewhere on a spectrum, and both ends are traps:

• The hype-believer thinks AI is magic and wants it to do everything, now, autonomously. Risk: over-scoped, over-trusted deployments that fail publicly. Manage by grounding them in what's actually reliable (evals/limitations), steering to a de-risked slice, and channeling enthusiasm into a realistic roadmap.
• The skeptic has seen hype fail (or fears job loss) and dismisses AI entirely. Risk: blocks adoption of genuinely useful tools. Manage by acknowledging the valid concerns, starting with a small, low-risk, clearly-valuable win, and letting measured results (Topic 2) do the convincing.

Your credibility comes from being neither — the calm translator who is honest about both the real capabilities and the real limits. That balanced, evidence-based stance is exactly what a consultant sells.

Pitfalls

• One narrative for all audiences. Executives, users, and IT need the same truth at different altitudes — tailor it.
• Selling magic. Overselling accuracy/autonomy sets a gap that destroys trust at the first error — set honest expectations.
• Demoing on easy inputs. A cherry-picked demo promises what production can't deliver — demo on realistic, hard cases.
• Treating adoption as automatic. "It works" isn't "it's used" — plan enablement, integrate into workflow, address fears.
• Matching the client's hype or skepticism. Your value is the balanced, evidence-based middle, not either extreme.

Recap

• You are the translator between technical reality and business audiences — tell the same true story at each audience's altitude (ROI for execs, daily benefit for users, architecture for IT).
• Set expectations honestly: AI is probabilistic assistance, not magic; naming limits and quantifying builds more trust than hype and survives the first error.
• Adoption is a separate problem from building — involve users early, integrate into their workflow, build trust incrementally, address the replacement fear, and measure usage.
• Navigate the hype-believer (ground and de-risk) and the skeptic (small win + measured results); your credibility is the balanced middle.
• Worked examples map to the exercises: three-audience translation (Ex 1), honest-pitch rewrite (Ex 2), an adoption plan (Ex 3), handling hype vs. skepticism (Ex 4).