Adopting generative AI in a business is the work of getting from an interest in the technology to something that changed a number. It sits closest to the day job of anyone on the Practitioner course, and it is also the part of the vendor examinations that asks the least about models and the most about organisations. The subject has a shape that repeats across vendors, which is matching a solution type to a business need, naming the constraints, getting the thing into the organisation and measuring whether it worked.
The sections below take those four in order, then say where each vendor syllabus places the same material.
The four types of solution
Four types cover most business problems, and a scenario will describe a situation that points at one.
Text generation covers drafting, summarising, rewriting, translating, answering and extracting. The broadest category and the one most business problems fall into.
Image generation covers producing and editing visuals, for marketing, product imagery and design exploration.
Code generation covers writing, explaining, translating and testing code, which raises engineering throughput and reaches the customer only indirectly.
Personalised user experience covers tailoring what somebody sees to what is known about them, in recommendations, content and interfaces.
What decides the choice
Business requirements first. What outcome is to be moved, who is affected, what a wrong answer costs and what would count as success.
Technical constraints second. Where the data is and whether it may be used, where processing may happen, what latency the experience allows, what it may cost per interaction and what has to be integrated with.
The cost of a wrong answer is the constraint people underweight. It decides whether a person has to be in the path, and that decision changes the economics of the whole thing far more than the choice of model.
Getting it into an organisation
The sequence every vendor recommends is unremarkable and mostly ignored.
The work starts from a business problem, with the technology second. A use case is picked where the outcome is measurable and a wrong answer is survivable. The data is checked, for existence, for permission and for reach. The smallest version that answers the question is built. It is measured against what happened before. Then the decision is whether to widen, and only then does the platform it should sit on permanently come up.
Two things sit alongside that sequence throughout. Somebody has to own it, and people have to be trained, because a capable system that nobody trusts or knows how to use changes nothing.
Measuring impact
The techniques that matter are ordinary ones.
Against a baseline. Measure the thing before, then after. Handling time, conversion, time to draft, tickets resolved without escalation.
Against a control group. Some teams get it and some do not, which separates the effect of the tool from everything else changing at once.
Quality alongside volume. Faster output that is worse is no improvement, so a throughput measure is paired with a quality one.
Cost per interaction. Token cost, review time and the engineering to keep it running. A system that helps and costs more than it saves is a decision, and a success is a different thing.
Adoption as a diagnostic. Usage says whether people came. It says nothing about whether anything changed.
The honest final question is the counterfactual. Whether the output is impressive is the wrong question. The right one is whether it beats what people were doing before, at a cost the result justifies.
Where each syllabus puts it
The Google Cloud Generative AI Leader exam guide covers this material in its section on business strategies for a successful generative AI solution, which asks a candidate to recognise the four solution types, identify the factors that influence the need, choose a solution for a business need, name the steps to integrate it into an organisation and identify techniques to measure impact. The AWS Certified AI Practitioner exam guide spreads the same ground across its task statements on practical use cases and on the business value of generative AI. The Practitioner course here treats it as the decision that comes before any control.
Practise this
The exercise needs fifteen minutes and a complete list of what the organisation has shipped or has in flight, which may take a message to colleagues to assemble.
List every AI feature by name, including the ones demonstrated once and quietly dropped. Against each, write the problem it exists to solve as a sentence somebody outside the team would recognise, and the number it was meant to move. Then mark it P where a named problem came first, and A where the honest history is that the technology came first and a use was found for it.
Feature Problem it solves, in one sentence Number it moves P / A
.......... ................................... .............. P A
.......... ................................... .............. P A
.......... ................................... .............. P A
P somebody named this problem before anyone mentioned AI
A this started from the question of what to do with AI
Count of P ____ Count of A ____
Watch what happens when the third column is filled in. A feature that started from a problem usually has a number waiting, because whoever noticed the problem was already measuring it, while one that started from the technology tends to produce a blank or a usage figure, and usage records who turned up and says nothing about what changed. The ratio of P to A is a fair estimate of how much of the organisation's AI spending is buying an outcome.
The exercise shows that the adoption question is largely settled before any model is chosen, in whether a problem or a technology came first.