Business Value of Generative AI

The word "AI" covers several unrelated things, and the exam expects you to keep them apart.

Machine learning finds patterns in historical data and predicts a value or a category. Will this customer churn? Is this transaction fraudulent? What will demand be next quarter? The output is a number or a label, and you can measure whether it was right.

Generative AI produces new content (text, images, code, audio) that resembles its training data. The output is a plausible artifact, not a prediction you can score against a known answer.

That distinction decides which tool a problem needs, and it is the most commonly tested judgment in this domain. If the business question is "which of these will happen," you want machine learning. If it is "produce a first draft of this," you want generative AI. A forecasting problem handed to a language model is the classic wrong answer.

Pretrained versus fine-tuned. A pretrained model is used as it comes. A fine-tuned model has been further trained on your own examples to adopt a particular style, format, or domain vocabulary. Fine-tuning costs data preparation, money, and time, and it produces an asset you must maintain as the base model moves on.

The trap: fine-tuning does not teach a model facts about your organization. It shapes behavior. If you want the model to know your policies, that is grounding and retrieval, not fine-tuning. Reaching for fine-tuning to solve a knowledge problem is expensive and it does not work.

The machine learning lifecycle runs data ingestion → preparation → training → deployment → management. The exam-relevant part is the last one: a deployed model is not finished. Inputs drift, source data goes stale, and quality declines with nothing erroring. Anyone presenting a project that ends at deployment has presented half a plan.

Billing is per token, roughly three-quarters of a word, and you pay for both the text going in and the text coming out, at different rates, with output typically several times more expensive than input.

The part people miss: the input is usually far larger than the question. It carries the system instructions, any retrieved documents, and the conversation so far. In a chat feature every turn resends everything before it, so turn ten costs considerably more than turn one. A cost estimate built on "the answer is about a paragraph" will be badly low.

Building the ROI case. Do not present AI cost as infrastructure. Present it as cost per unit of work (per ticket handled, per document reviewed, per draft produced) set against what that work costs today. "$140 a month" invites a line-item argument; "1.6 cents per ticket against $4 of analyst time" is a margin conversation.

Where the value genuinely is:

• Scale: work that is individually cheap but happens tens of thousands of times
• Automation: steps that are mechanical but currently need a person
• Leverage: getting a competent draft in seconds so the expensive human time goes on judgment instead of first drafts

Where it usually isn't: low-volume tasks, anything with a single correct answer that code could compute, and anything where a wrong answer is expensive and nobody downstream is positioned to catch it.

Fabrication is the headline failure and the one Microsoft's blueprint names directly. These systems produce the most plausible continuation of the text so far; they are not looking anything up, and they have no internal signal separating "I know this" from "this is the shape an answer would take."

The consequence worth internalizing: fluency and accuracy are separate properties. A person who is unsure usually sounds unsure, and we read that signal automatically. A model produces confident, well-structured prose regardless. A fabricated citation reads exactly like a real one.

Reliability is the second: the same question can produce different answers on different runs. That is a design constraint, not a defect to be fixed, and it means anything requiring an identical answer every time needs deterministic code around it.

Bias is the third, inherited from training data and from your own data. It is invisible in aggregate accuracy figures, a system can be 94% accurate overall and much worse for one group. You only see it if you measure by segment.

Grounding is the main lever against fabrication. Rather than asking a model what it knows, you supply the source material and ask it to answer from that. Retrieval-augmented generation is the mechanism: search your documents for the passages relevant to the question, attach them to the prompt, then answer.

It doesn't eliminate the problem, the model can still misread what you gave it, but it changes the failure from "invented from nothing" to "misinterpreted something real," which is far easier to catch. Requiring citations makes it easier still.

Data quality decides the ceiling. A grounded system is only as good as what it retrieves. Three properties matter: is the data complete enough to contain the answer, is it current, and is it representative of the cases the system will actually meet. Incomplete data produces confident gaps. Stale data produces confident obsolescence.

Prompt quality changes output quality more than most people expect, which makes this an adoption issue as much as a technical one. Two people with the same license get very different value depending on how they ask.

The techniques worth knowing by name:

• Zero-shot: just ask. Fine when the task is common and the format obvious.
• Few-shot: include two or three worked examples. The right answer when the format keeps coming out wrong; examples teach shape far better than description does.
• Chain-of-thought: ask the model to reason through the problem before answering. The right answer when the format is fine but the reasoning is wrong.
• Role and context framing: state who the model is writing as and for whom. Cheap, and it moves tone and register a long way.

The diagnostic habit the exam rewards: name the failure before choosing the technique. Wrong format calls for examples. Missing domain rules call for context. Right shape but wrong thinking calls for explicit reasoning. Applying all of them at once obscures which one you needed and inflates the prompt.

For a manager, the practical implication is that a rollout without prompt training is a rollout that will under-deliver and then be judged on that. The license is the cheap part.

AI systems inherit every conventional security concern and add several of their own.

The permission problem is the big one in a Microsoft context. Copilot answers using content the user already has permission to open. That sounds safe, and it is, right up against the reality that most organizations have years of accumulated oversharing in SharePoint and OneDrive. Files "shared with everyone" that nobody could previously find are now one natural-language question away.

Copilot does not create the exposure. It makes existing exposure findable, which for practical purposes is the same thing. This is why Microsoft's own readiness guidance leans on tooling for reducing oversharing, restricting search scope during rollout, and classifying and labeling sensitive content before you switch anything on.

For a manager, the sequence matters: permissions hygiene comes before deployment, not after. A pilot that surfaces the salary spreadsheet in week one does lasting damage to trust.

Prompt injection is the AI-specific attack. Instructions hidden in content the system reads (a document, an email, a web page) can influence its behavior. The defense is architectural: constrain what the system is allowed to do, so a successful injection has nothing dangerous to reach.

Data handling. Know where prompts and responses go, whether they are retained, whether they leave your tenant, and whether they could be used for training. For a regulated organization these are the first questions legal will ask, and "I'll find out" is a poor answer in a steering meeting.